W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] Clarification on JSON-LD

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 15 Mar 2011 19:33:33 -0400
Message-ID: <4D7FF74D.5040108@digitalbazaar.com>
To: RDF Working Group WG <public-rdf-wg@w3.org>
On 03/11/2011 03:20 AM, Ivan Herman wrote:
>> Yes. However, I'm going to be pedantic here: In JSON-LD, the
>> "value" of the JSON key-value pair can be an associative array. An
>> associative array in JSON-LD can be thought of as a self-contained
>> graph.
> Hm. We may have issues here in understanding or in the terms we use.
> See below

Yes, I think there a terminology problem here... I think I confused the
issue by using the term "self-contained graph". All I mean by a
self-contained graph is that this:

{ "foaf:name" : "Ivan" } is a self-contained graph that can be placed
into another graph, like so:

{ "ex:prop" : { "foaf:name" : "Ivan" } }

You could also call it a "sub-graph". I don't know if that helps.

>> When it is in the "value" position, the current predicate is linked
>> to the self-contained graph. That is, this:
>> { "ex:prop" : { "foaf:name" : "Ivan" } }
>> would give you this:
>> @prefix foaf: <http://xmlns.com/0.1/foaf/> . _:bnode1 ex:prop
>> _:bnode2 . _:bnode2 foaf:name "Ivan" .
> But this is not what you wrote above. The turtle code that you gave
> above simply means that the object of the first triple is bnode, and
> the latter is also a subject of another triple (and yes, the turtle
> you gave is the same as what I gave. There is 'graph' here. To give a
> slightly more elaborate example, and using URI-s, the following:
> { "@" : "<lala>" , "ex:prop : { "@" : "<bla>", "ex:a" : "Ivan" , 
> "ex:b" : "Manu" } }
> should translate into
> <lala> ex:prop <bla> . <bla> ex:a "Ivan" , ex:b "Manu" .
> _which is perfectly consistent and fine_, but there is _no_ notion of
> a self contained graph here!

All I'm saying is that the sub-graph:

{ "@" : "<bla>", "ex:a" : "Ivan", "ex:b" : "Manu" }

Can stand on it's own. I think you agree with that concept (since it's
logically true). In other words, I don't think we're discovering
anything new here - we just mis-communicated.

> The 'model' that I have is:
> - { .... } provides a set of triples with a common subject - that
> subject is either a new bnode (like the [] construction in Turtle) or
> an explicit URI/bnode if the "@" key is used - that common subject
> may appear as the object for a property if this is where {} is used.

In general, yes. I say "In general" because we're not considering graph
literals/named graphs/g-text-of-g-snaps, but we may want to also support
those. So, I would extend your description above by saying this:

{ ... } provides a set of triples with a common subject. The subject is
set using the '@' key. That subject is either an implied bnode (like the
[] construction in Turtle) if the "@" key is missing, or an explicit
URI/bnode/g-snap if the "@" key is used - that common subject may appear
as the object for a property if this is where {} is used.

This is where things get tricky... let me try to explain. If we want to
support graph literals/named graphs/g-snaps in RDF in JSON, we could do
something like this:

   "@" : { ... },
   "dc:created": "2011-03-15T02:30:00Z"

Note that in the example above, the subject is a graph literal/named
graph/g-snap and the "dc:created" is a predicate that describes that
graph. It effectively states something like this in TRiG:

:G1 { ... } .
:G1 dc:created "2011-03-15T02:30:00Z" .

We could also do something like this (which is really ugly):

   "ex:snapshot": { "@": { ... } }

This is how you could specify the graph literal/named graph/g-snap in
the object position. This statement looks like this in TRiG:

:G1 { ... } .
_:bnode1 ex:snapshot :G1 .

> Which also means that the following:
> { "@" : { "ex:a" : "Manu" }, "ex:b" : "Ivan" }
> crazily enough, translates into
> _:x ex:a "Manu" .  <- that is the translation of the internal object 
> _:x ex:b "Ivan" .  <- that is the translation of the outer object
> If your intention was (which I believe it was) to have some sort of a
> 'graph literal' here, I think that becomes linguistically
> inconsistent!

I don't think it does, but that's probably because the processing model
that you have in your head is different from the one that I have in my
head. :)

Did the graph literal/named graph/g-snap stuff I stated above make sense?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
Received on Tuesday, 15 March 2011 23:34:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC