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

On 15/06/12 09:43, Ivan Herman wrote:
> Just to make it clear: what it means that an inner graph in a query pattern is just syntactic sugar, and is equivalent to have them all defined on the 'top level' (I am not talking about the query itself, just the graph definition). Is that correct?

In effect yes - but I think the phrasing is a little off - the GRAPH 
pattern affects the part of the dataset being referenced.

If it's inside or outside a containing GRAPH pattern does not matter 
because it references the dataset, and is not related to part named 
graph being matched.

There is no graphs-in-graphs.

The two forms have different algebra which are equivalent:


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


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

vs:

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

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

To show the equivalence, they both produce the same (not part of SPARQL) 
quad algebra:

(join
    (quadpattern (quad <U> <s> <p> <o>))
    (quadpattern (quad <V> <s1> <p1> <o1>)) )


There are various equivalences around here about pushing (graph) around.

	Andy

>
> Thanks
>
> Ivan
>
> On Jun 15, 2012, at 09:50 , Andy Seaborne wrote:
>
>> (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
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>

Received on Friday, 15 June 2012 09:04:36 UTC