Re: Allow HTTP Link header as _alternative_ @context provision method

On Aug 26, 2011, at 6:28 AM, Alexandre Passant wrote:

Hi,

On Fri, Aug 26, 2011 at 1:16 PM, Thomas Steiner <tomac@google.com<mailto:tomac@google.com>> wrote:
Hi all,

This is to get people's opinion on allowing HTTP Link headers [1] as
an _alternative_ means of providing @context to JSON payload.

+1, cf also the ongoing discussion at [1]

http://tools.ietf.org/html/draft-zyp-json-schema-03

We've discussed both Link and Accept/Content HTTP headers as impacting a JSON-LD processor. I think using Link makes sense.

+1

* This is how it _currently_ works (shortened for legibility):

$ curl -i https://www.example.com/test.jsonld
HTTP/1.1 200 OK
Date: Fri, 26 Aug 2011 07:33:56 GMT
Status: 200 OK
ETag: "72054d9a6fbdcc7df012e19f32345b65"
Last-Modified: Fri, 26 Aug 2011 07:33:56 GMT
Content-Type: application/json; charset=utf-8

{
 "@context": "http://example.org/json-ld-contexts/person",
 "name": "Manu Sporny",
 "homepage": "http://manu.sporny.org/",
 "avatar": "http://twitter.com/account/profile_image/manusporny"
}

* This is how it could also work _in the future_ (shortened for legibility):

$ curl -i https://www.example.com/test.jsonld
HTTP/1.1 200 OK
Date: Fri, 26 Aug 2011 07:33:56 GMT
Status: 200 OK
ETag: "72054d9a6fbdcc7df012e19f32345b65"
Last-Modified: Fri, 26 Aug 2011 07:33:56 GMT
Content-Type: application/json; charset=utf-8
==> Link: <http://example.org/json-ld-contexts/person>; rel="@context
http://json-ld.org/spec/latest/#the-context" <==

{
 "name": "Manu Sporny",
 "homepage": "http://manu.sporny.org/",
 "avatar": "http://twitter.com/account/profile_image/manusporny"
}


I'd however favor describedby instead of "context" in the header [2]

Agreed, describedby seems appropriate here. Also, note the Mime-types are somewhat different (application/ld+json with optional parameters). Also, I think the Link format is a bit different.  The HTTP response might be the following:

HTTP/1.1 200 OK
Date: Fri, 26 Aug 2011 07:33:56 GMT
Status: 200 OK
ETag: "72054d9a6fbdcc7df012e19f32345b65"
Last-Modified: Fri, 26 Aug 2011 07:33:56 GMT
Content-Type: application/ld+json; charset=utf-8
Link: <http://example.org/json-ld-contexts/person>; rel="describedby"; type="application/ld+json;form=context"

{
 "name": "Manu Sporny",
 "homepage": "http://manu.sporny.org/",
 "avatar": "http://twitter.com/account/profile_image/manusporny"
}

The uses the "descdribedby" del to a URI with type "application/ld+json;form=context", indicating context sub-format of JSON-LD, as the format of a context document is a subset of normal JSON-LD.

Alex.

[1] http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0058.html
[2] http://tools.ietf.org/html/draft-zyp-json-schema-03#section-4

Gregg

Link headers, the mullet of the Web: business in the front, party in
the back. Idea: serve #JSON, make it #jsonLD by a @context Link
header. [2]

Arguments pro:
- might improve adoption (as no payload change for "legacy" JSON)
- saves minimal payload space
- elegant (IMHO)

Arguments contra:
- may be hard for webmasters to add Link headers
- little advantage over direct @context link in payload
- might remain undiscovered by consumers
- might cause confusion for implementers (what @context mechanism to choose)

Best,
Tom

[1] http://tools.ietf.org/html/rfc5988
[2] http://twitter.com/tomayac/status/106304670464606208

--
Thomas Steiner, Research Scientist, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac





--
Dr. Alexandre Passant - @terraces
Founder, CEO - seevl.net<http://seevl.net> - @seevl
Reinventing Music Discovery