W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2011

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 19 Jul 2011 00:22:34 -0400
Message-ID: <4E25068A.2070201@digitalbazaar.com>
To: public-linked-json@w3.org
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. :)

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. 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.

I agree that it is not "Linked Data" for some definition of Linked Data,
but the line is fuzzy. 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. I know that there are people that want to do that,
but what is the end-goal of drawing that line? What result are we
attempting to achieve by telling people that something isn't Linked
Data? Do we really care that much if they decide to co-mingle Non-Linked
Data with Linked Data?

I don't think that we should care, and I don't think there is a definite

> 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".

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? How is the data, and the world, better off by assigning
a URL to the "dc:creator" and the "sig:signature"?

> 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?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
Received on Tuesday, 19 July 2011 04:23:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:30 UTC