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

I think we're getting caught up in the definition of "Linked Data" and the requirements for Linked Data in JSON. Certainly, to express Linked Data as JSON, unnamed nodes are not necessary. However, as language creators, we may need to take into consideration other reference points. Finding a way to accommodate existing JSON practice and make sense of it in the context of JSON-LD is also important IMO.

If the JSON-LD spec says "Items SHOULD be named with an IRI" this might imply that the processing steps do not need to consider the case when it's not, or that authors using unnamed items (or even items named with literals, for example) are somehow wrong. If an author conceivably COULD name all nodes with an IRI that means that they MUST.

I'd be fine with a statement somewhere that extolls the virtue of pure Linked Data, but we need to take into consider the practical considerations for JSON-LD authors.

Gregg

On Jul 18, 2011, at 11:39 PM, Kingsley Idehen wrote:

> On 7/19/11 5:22 AM, Manu Sporny wrote:
>> On 07/18/2011 09:35 PM, glenn mcdonald wrote:
>>>     Try telling someone that has been living and breathing JavaScript and
>>>     JSON for the past 5 years that they can no longer do this:
>>> 
>>>     {
>>>       "name": "Kingsley Idehen"
>>>     }
>>> 
>>> 
>>> But I still don't follow this objection. Nobody is saying that JSON
>>> developers can't do that, just that if they do that, they're not doing
>>> Linked Data.
>> Then there is a mis-communication at some level here. :)
> 
> Yes, there clearly is :)
> 
>> At the specification level, if JSON-LD doesn't allow markup like the
>> above, we are telling JSON developers that they can't do that.
> 
> No, you are saying: it isn't Linked Data. That's all.
> 
>>  That is,
>> if it is syntactically illegal in JSON-LD to do the above, your
>> statement that "Nobody is saying that JSON developers can't do that" is
>> not true. We are telling them that they can't do that if they want to
>> use JSON-LD.
> 
> Again, no. It means: that isn't Linked Data since every data object 
> (observation subject) needs to have a de-referencable Name.
> 
>> I agree that it is not "Linked Data" for some definition of Linked Data,
>> but the line is fuzzy.
> 
> No, Linked Data is unambiguous, Names resolve to Representations of 
> their Referents.
> 
> Why are we bringing this all up again when the core matter was resolved? 
> Bradley Allen pretty much closed this matter by translating my 
> permarant. Greggs updated his doc etc..
> 
>> I don't believe that there is a line that we can
>> draw that places "Linked Data" squarely on one side and "Non-Linked
>> Data" on the other.
> 
> Of course there is, and conflating matters will never offer a solution. 
> The fact that the Linked Data meme is catching on doesn't mean we pile 
> everything into the Linked Data bucket, come on!
> 
>>  I know that there are people that want to do that,
>> but what is the end-goal of drawing that line?
> 
> See comment above. It's about clarity of purpose reflected clearly in a 
> spec.
> 
>>  What result are we
>> attempting to achieve by telling people that something isn't Linked
>> Data?
> 
> Clarity.
> 
>>  Do we really care that much if they decide to co-mingle Non-Linked
>> Data with Linked Data?
> 
> Yes, but I ask you one more time: what is the purpose of JSON-LD? Why is 
> the "LD" so important? Thus far it simply reeks of: we would like to 
> have a piece of this Linked Data meme that seems to be catching on etc..
> 
>> I don't think that we should care, and I don't think there is a definite
>> line.
> 
> Then why bother with a spec?
> 
>>> it seems to me that means you're making Partially Linked
>>> Data.
>> Here is a real-world example. Pay particular attention to "dc:creator"
>> and "sig:signature":
>> 
>> {
>>     "@context": "http://purl.org/jsonld/payswarm"
>>     "@subject": "http://localhost:19100/test/listings/test64#asset",
>>     "@type": ["ps:Asset", "ps:WebPage"],
>>     "dc:creator": {
>>         "foaf:name": "John Doe"
>>     },
>>     "dc:title": "Simple PaySwarm Test",
>>     "ps:assetProvider": "https://payswarm.dev:19443/i/devuser",
>>     "ps:authority": "https://payswarm.dev:19100/client-config",
>>     "ps:contentUrl": "https://localhost:19100/test/listings/test64",
>>     "sig:signature": {
>>         "@type": "sig:JsonldSignature",
>>         "dc:created": "2011-01-01T00:00:00Z",
>>         "dc:creator": "https://payswarm.dev:19443/i/authority/keys/1",
>>         "sig:signatureValue": "d/RlMHNM+qQydy7tpDu0gm3SjKgxls.../4A=="
>>     },
>> }
>> 
>> Note that both of those fit your definition of "Partially Linked Data".
>> However, using JSON-LD Framing, I can still access both values easily by
>> starting off with something that /does/ have an IRI identifier, which is
>> the asset.
>> 
>> That is, we use HTTP to get us to the asset. We use framing to get us
>> the rest of the way to the creator or the signature. You can argue it
>> both ways:
>> 
>> You can say "Well, it is Linked Data because I can get to every leaf
>> node in the graph". You can say "Well, it is not Linked Data because
>> every set of nodes does not contain an identifier".
> 
> Blank Nodes degrade Linked Data. The degradation affects the FYN pattern 
> while introducing escape velocity inertia. It isn't a matter of partial 
> or full linked data, its about boostrap. If JSON-LD is supposed to 
> deliver a lightweight mechanism for constructing Linked Data using JSON 
> then make it simple, otherwise, leave it confusing (which ultimately 
> means: complex) and don't make the grab for "Linked Data" via "-LD".  My 
> only interest in this effort was to get clarity, and funnily enough we 
> reached that (I thought) via the editorial work of Gregg and Bradley.
>> So, call it what you will - but what's the problem with "partially
>> linked data" in this scenario? Why are we trying so hard to prevent it
>> from happening?
> 
> We are trying so hard to somehow deliver a lightweight mechanism for 
> constructing Linked Data using JSON without unnecessary baggage.
> 
>> How is the data, and the world, better off by assigning
>> a URL to the "dc:creator" and the "sig:signature"?
> 
> The cannot be better assigning URLs (Address Names), but they are 
> infinitely better when every observation subject is identified by a Name 
> that resolves to the Representation of its Referent. Where said 
> Representation is an EAV/SPO graph pictorial, supporting resolvable 
> Names (de-referencable identifiers) in slots 1&2, and optionally in 3 :-)
> 
>>> Specifying how JSON-LD data can be intermingled unambiguously with
>>> JSON-non-LD data sounds like a simpler and more general approach than
>>> introducing blank nodes.
>> I thought that's what we're doing above? How is this last sentence
>> different from what I describe above?
> 
> You state: co-mingling non-Linked Data with Linked Data. That sentence 
> alone is confusing and contradictory re. an argument about clearly 
> defining the latter. We just need a clear definition of Linked Data, not 
> trying to eradicate the existence of partial or non-Linked Data, re. 
> JSON. At the end of the day, this is just about Syntax.
>> -- manu
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
> 
> 
> 
> 
> 
>

Received on Tuesday, 19 July 2011 15:52:02 UTC