Allow HTTP Link header as _alternative_ @context provision method

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.

* 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"
}

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

Received on Friday, 26 August 2011 11:17:27 UTC