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

Re: Distinguishing a context document from an instance document

From: Ivan Herman <ivan@w3.org>
Date: Sun, 2 Oct 2011 06:51:09 +0900
Cc: public-linked-json@w3.org
Message-Id: <9A688511-018D-4732-9492-CB3FC332AA53@w3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
We should be careful of recursion issues, though. If context document may refer to other context documents, that can play some nasty tricks.

We may declare that when a context document is imported, json-ld processors to do not follow further context imports, ie, it stops at one level.

I.

On Oct 2, 2011, at 04:34 , Manu Sporny wrote:

> On 09/28/2011 06:31 AM, Markus Lanthaler wrote:
>> What's the currenty way to distuingish a context document from an instance
>> document?
> 
> There is none because a use case has not been presented where it is necessary to differentiate. I do agree that it may be cleaner if one could differentiate, but I don't know what new application this would enable for JSON-LD.
> 
>> There are a couple of options to solve this issue (ISSUE-30)
>> 
>> - create a new MIME type
> 
> -1
> 
> I like this one the least, it's a bit heavy weight and would require us to create a new MIME type and file extension for JSON-LD documents.
> 
>> - use the form MIME type parameter, i.e., form=context
> 
> -0.5
> 
> I like this better, but it would still be difficult for a Web Server to decide what it is serving without looking in the file. The easiest thing for a web server is to have a file extension, which would make registering a MIME type a better solution, albeit, overkill.
> 
>> - include @context also in pure context documents
> 
> +0.5
> 
> I think this is the best solution. However, what important use case is this a solution to?
> 
>> Using a MIME type (parameter) for this is problematic for client-side
>> JavaScript implementations. Including @context also in context documents
>> seems to be a straightforward and simple way to do it. The only issue then
>> is to ensure that there isn't any data in a context document - but I'm not
>> even sure if we need to do that.
> 
> I wouldn't expect data in context documents to be a bad thing, necessarily. You could have triples that describe the context document as data. The processing rules for "@context" could specify that the only thing read from the remote document is the "@context" key. However, applications could still read the document in its entirety to find out more about each item in the context.
> 
>> Perhaps we also just say it's not important to be able to distinguish it
>> because a client has to know what it requests!?
> 
> Perhaps a good compromise is to require that JSON-LD Context documents are valid JSON-LD documents. That is, "@context" is required... and if it has any triples, those triples could describe the context document.
> 
> This wouldn't complicate implementations that much, and wouldn't require a new MIME type and file extension. I don't feel very strongly about this... but if we want this feature, this may be the way to go. Thoughts?
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Standardizing Payment Links - Why Online Tipping has Failed
> http://manu.sporny.org/2011/payment-links/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Saturday, 1 October 2011 21:50:23 GMT

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