- From: Ivan Herman <ivan@w3.org>
- Date: Sun, 2 Oct 2011 06:51:09 +0900
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-linked-json@w3.org
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 UTC