- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 20 Jul 2011 00:12:55 -0400
- To: public-linked-json@w3.org
On 07/19/2011 11:00 AM, Ted Thibodeau Jr wrote: > It seems that your definition of "sub-set" may differ from mine. Yes, after re-reading my response, the explanation I gave was confusing. Let's use your points below because I think they're more precise: > - JSON is less restrictive than JSON-LD. Agree. > - JSON is more permissive than JSON-LD. Agree. > - All JSON-LD is JSON. Agree. > - Some JSON is not JSON-LD; is JSON-NLD ("Non-Linked Data"). Agree. > If this were a Venn Diagram, you'd see two circles, one (JSON-LD) > entirely contained within the other (JSON). Right. > Further -- > > - JSON allows for IRI-less nodes. Correct. > - JSON-LD *SHOULD NOT* allow for IRI-less nodes. This is the point of contention. I think you mean that I /could/ express an unlabeled node in JSON-LD, but I shouldn't. I think Kingsley means that I MUST NOT express an unlabeled node in JSON-LD. Let me add a few others, introducing another level of nuance. There are really three levels here that I can see: Level 1: JSON Level 2: JSON-SD (Structured Data) Level 3: JSON-LD (Linked Data) JSON-SD allows for IRI-less nodes. JSON-SD ensures that all properties are IRIs. JSON-SD ensure that all values can be strings, properties, IRIs or IRI-less identifiers. So, the Venn Diagram would show three circles, JSON-LD contained entirely in JSON-SD, and JSON-SD contained entirely in JSON. In my mind, it is JSON-SD that strikes the right balance between theoretical purity and real-world needs. > An IRI-less node cannot be usefully referred to over time, This is pedantic, but I disagree. You can do it w/ Framing. We do this all the time w/ PaySwarm. > nor across graphs (or JSON or other documents). This is true. > Such a node's description cannot be re-retrieved later. Again - being pedantic, but I disagree. You can always find the node by referring to a named node that contains the node in question and then you can frame the data to get to it. > Such reference (and dereferenceability) is the most important > aspect of Linked Data (LD) that sets it apart from Non-Linked > Data (NLD)-- i.e., the LINK. > > Given all that, I think this follows -- > > - A JSON-LD document MUST NOT include JSON-NLD. I have serious reservations about this. It'll make JSON-LD completely useless for our use case. > - A JSON document MAY include JSON-NLD and JSON-LD -- i.e., > it MAY intermingle Linked Data and Non-Linked Data. So what do we call this solution? This is the solution that is going to be useful to us (and a ton of other people out there dealing with real data - some of which will never have an IRI). Do we call this JSON-SD (JSON for Structured Data)? > - Intermingled JSON-LD and JSON-NLD is preferred over pure > JSON-NLD. I agree with this. I think this is practical. > Pure JSON-LD is preferred over such intermingling. I don't think asking developers to create IRIs for everything is practical, but we shouldn't stop people from doing this if they want to do so. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarm Developer Tools and Demo Released http://digitalbazaar.com/2011/05/05/payswarm-sandbox/
Received on Wednesday, 20 July 2011 04:13:24 UTC