Re: JSON-LD Telecon Minutes for 2011-07-04

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