- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 26 Feb 2013 23:11:09 +0100
- To: "'Robert Sanderson'" <azaroth42@gmail.com>
- Cc: <public-linked-json@w3.org>
On Tuesday, February 26, 2013 10:05 PM, Robert Sanderson wrote: > Our thinking was the following: > > 1. The context definition shouldn't be simply copied everywhere as > then it wouldn't be cached properly or easily recognizable by clients > without dereferencing it. If it has a single well known URI, then > clients can simply check for that URI and if present know what they're > looking at. At that point they can likely process as simple JSON, > rather than RDF. On the other hand, if the same context is copied > around the place, clients would have to at least inspect it to see if > there were changes, at which point they might as well process as RDF > rather than JSON. I see. > 1.5 ... Unless there's a mechanism for asserting the equivalence of > two contexts? One could somehow assert owl:sameAs, but that seems to > be mixing serialization metadata and real triples from the graph and > seems undesirable. No there isn't any such mechanism. > 2. If there's to be a single well known URI, then it should be as > permanent and "official" as possible. The openannotation.org site is > fine for the moment, but of course we hope to transition to a working > group structure towards a Recommendation. At which point having a Tech > Report on the W3C site pointing to a URI somewhere else would seem > very strange, if not suspicious. Well, that's typically the reason why purl is used. But I see your point. > As the W3C (thank you Ivan) lets us > publish our namespace documents, we figured that they'd also let us > publish the JSON-LD context file, but they don't have anything in > place for doing that yet. I didn't know that. If that's the case, why don't combine your namespace document with your external context? The external context would end up being slightly bigger, but that shouldn't really matter. That even has the advantage that your namespace document is available as JSON-LD and there won't be an additional round-trip to fetch its definitions. So, what I mean is this. You upload a JSON-LD document describing your vocabulary. In that document you also include an @context element at the top-level JSON object. You can even use that local context when describing your vocab. { "@context": { ... }, ... your vocabulary ... } When retrieving an external context, a JSON-LD will ignore everything but the context. Et voila, everything works as expected. You have your context at a stable location and even reduced the number of necessary roundtrips if you need, e.g., the labels for some properties. > Thanks Markus :) You are more than welcome. -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 26 February 2013 22:11:42 UTC