Re: [JSON] Clarification on JSON-LD

Hi Manu

On Mar 16, 2011, at 24:33 , Manu Sporny wrote:

[snip]
> 
>> 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?

Well, it makes sense because you defined it:-) But I do not like it. I know it is early to get into a detailed syntactical discussion here because we have much more fundamental issues to handle, including the concepts of g-* in the first place. But what you propose means that the what the { ... } syntax means is different on whether it appears in an 'object' position in the syntax or as a value for '@'. And personally I am against this type of mixup. In my mind

{
 "@" : { "a":"b" },
 "q" : "r"
}

is a direct equivalent to 

[ a b ] q r .

in Turtle, which is a clear and clean approach. If we want to express g-*  then I would propose to have an explicit syntax for it and not such an 'implicit' one.

But, as I say, it is too early to decide on this...

Ivan



> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Towards Universal Web Commerce
> http://digitalbazaar.com/2011/01/31/web-commerce/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf