W3C home > Mailing lists > Public > public-linked-json@w3.org > October 2011

Re: ISSUE-30 - JSON-LD Telecon Minutes for 2011-10-04

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Wed, 5 Oct 2011 12:24:05 -0400
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: Linked JSON <public-linked-json@w3.org>
Message-ID: <3E70B941-B668-45DE-9EB1-21535980578F@kellogg-assoc.com>
On Oct 5, 2011, at 8:14 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:

> Following up on ISSUE-30: Distinguishing @context documents.
> 
> Since we run out of time we didn't came to a resolution regarding this issue. Most people agreed that we should also require a @context in context documents to eliminate the need to be able to distinguish between context and instance documents. Ted had some issues with that proposal - probably due to the wording.
> 
> So let me try to re-explain and reformulate it in the hope to come to a consensus.
> 
> Currently context documents have a completely different structure than JSON-LD instance documents. Thus, a parser needs to switch it's parsing mode between instance and context documents as it has to look into different places for the information. To be a good web-citizen we would either have to create a completely new MIME type (considered as overkill), a MIME type parameter (hard for Web servers to determine without a different file extension, i.e. MIME type) or remove the difference by adding @context also to context documents.
> 
> In consequence, context documents would look exactly the same way as instance JSON-LD documents. The parsers would remain more or less the same, the only required change is that they now have to look into the top-level @context element instead of taking the whole object as context. So, that would mean that if there is a reference to an external context in a JSON-LD instance document, the parser would retrieve that document and use the data in the @context element in the root-object. If no such element is present, the parser would leave the active context unchanged.
> 
> Maybe a simple example helps. Let's assume we have a JSON-LD document as the one below which references an external context:
> 
> {
>  "@context": [
>    "http://example.org/json-ld-contexts/person",
>    {
>      "somethingelse": "http://kjfdh.com/something"
>    }
>  ],
>  "name": "Markus",
>  ...
>  "somethingelse": "Just random stuff"
> }
> 
> 
> The external JSON-LD document could be something like
> 
> {
>  "@context": {
>    "name": "http://xmlns.com/foaf/0.1/name",
>    "somethingelse": "http://xyz.com/abc"
>  },
>  "name": "Lanthaler",
>  "id": 20,
>  ...
> }
> 
> What then happens is that the parser retrieves the second document, checks if there is a @context key in the root-object and if so merges that context to the active context. So the result would be the same as having
> 
> {
>  "@context": {
>    "somethingelse": "http://kjfdh.com/something",
>    "name": "http://xmlns.com/foaf/0.1/name"
>  }
>  "name": "Markus",
>  ...
>  "somethingelse": "Just random stuff"
> }
> 
> Please note: The local context takes precedence (i.e., "somethingelse" is set to "http://kjfdh.com/something" instead of "http://xyz.com/abc"), all data outside the @context element in the remote document gets ignored (i.e. "id: 20"). So simple speaking, a IRI in @context addresses the top-level @context element in the referenced remote document.
> 
> So let my try to reformulate the proposal and see if we can come to a resolution.
> 
> PROPOSAL:
> Do not differentiate between JSON-LD Context documents and JSON-LD instance documents. If @context is specified in a JSON-LD document and a remote document is listed, the remote document's @context element is merged into the current active context. If there is no @context element in the remote document, the active context remains unchanged.

+1, but we'll need to be more explicit in the processing steps. We also need to introduce the array notation to specify multiple contexts for a single key.

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
> 
> 
Received on Wednesday, 5 October 2011 16:24:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:35 GMT