Re: comments/questions on JSON-LD spec (but _not_ for the CG->WG transition!)

(where emails replies go to needs sorting out)

>>> Question 2: My understanding is that
>>>
>>> {
>>> "@context" : ...
>>> "@graph" : ...
>>> }
>>>
>>> (without @id) defines triples into the default graph. Which also means that if I have a nested situation of the sort:
>>>
>>> {
>>> "@context" : ...
>>> "@id" : URI
>>> "@graph: {
>>>     "a" : "b",
>>>     "@graph" : {
>>>         "q" : "r"
>>>     }
>>> }
>>> }
>>>
>>> translates into
>>>
>>> URI {
>>> "a" : "b"
>>> }
>>> {
>>> "q" : "r"
>>> }
>>>
>>> Is that correct?
>> This is certainly not intended usage, as @graph evolved from a desire to be able to define multiple top-level entities (subject definitions) where an array would otherwise be used.
>>
>> However, this can be interpreted by the processor to generate quads. Basically, the [a,b] tuple belongs to an anonymous entity (blank node subject), which is in the graph denoted by URI. The [q, r] tuple also belongs to an anonymous entity (with a different BNode) in a named graph denoted by the BNode of the including entity. (JSON-LD syntax allows the use of BNodes for graph names, even though it might not result in valid RDF).
>>
>> If you run a cleaned up example through the playground, you can see the Quads which are emitted:
>>
>> {
>> "@context" : {"a": "http://foo/a", "q": "http://foo/q", "URI": "http://URI"},
>> "@id" : "URI",
>> "@graph": {
>>     "a" : "b",
>>     "@graph" : {
>>         "q" : "r"
>>     }
>> }
>> }
>>
>> _:t0 <http://foo/a> "b" <http://URI> .
>> _:t1 <http://foo/q> "r" _:t0 .
>>
>>
> Well, to be honest, I am actually lost (and that shows either that I am stupid, or that the section seems to be half baked, or both...) and I am not 100% sure how the @graph syntax works. Just to make it very clear, how would you encode a simple TriG thing:
>
> {
>   <a> <b> <c> .
> }
> <URI> {
>    <p> <q> <r> .
> }
>
> I see where I did make some mistake, but I also do not fully grasp, out of the description, what the 'value' of the "@graph" really is, and on what does "@id" applies in that case.
>
> Note that TriG, as it stands, does not allow nested graphs, ie,
>
> <URI> {
>    <a> <b> <c> .
>    <URI1> {
>       <p> <q> <r> .
>    }
> }
>
> is not accepted. (There was some discussion about nested named graphs in the group, and the agreement is that there is no strong enough use case to go there.) I wonder whether JSON-LD should not take the simple approach to adopt the same principle for now, just to simplify matters (just raising this, not sure yet myself).
>
> Also, as far as I remember, there is currently an open issue (not necessarily a formal one) whether a Graph ID can be a blank node or not. But do not trust my memory, I am too old for that...
>
>

FWIW:

In SPARQL Update

INSERT DATA {
   GRAPH <U>
   { <s> <p> <o>
     GRAPH <V>
     { <s1> <p1> <o1> }
   }
}

is a syntax error - GRAPH can only at the top level of the data block.

In SPARQL Query, in a pattern,

   GRAPH <U>
   { <s> <p> <o>
     GRAPH <V>
     { <s1> <p1> <o1> }
   }

or in the algebra:

   (graph <U>
      (join
        (bgp (triple <s> <p> <o>))
        (graph <V>
          (bgp (triple <s1> <p1> <o1>))
        )))

i.e. the inner graph <V> is matched against the dataset, and is not 
related to contents of <U>

	Andy

Received on Friday, 15 June 2012 07:50:57 UTC