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

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 06:40:22 UTC