Re: Querying Named Graph using SPARQL

On 14/08/13 14:34, David Booth wrote:
> [Copying Andy Seaborne and Steve Harris for their input.]

Axel is right.

>
> Hi Axel,
>
> The part of the spec that I was trying to bring to your attention was
> where it says that the empty group graph pattern "does not bind *any*
> variables" (my emphasis).  If ?G is not bound then that short form of
> listing existing graphs would not work.  But I am not sure from reading
> the spec whether ?G is supposed to be bound or not.  The SPARQL algebra
> says:
>
> http://www.w3.org/TR/sparql11-query/#defn_evalGraph
> [[
> eval(D(G), Graph(var,P)) =
>       Let R be the empty multiset
>       foreach IRI i in D
>          R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) )
>       the result is R
> ]]
> Hmm, there's right parenthesis missing, which I guess I'll report
> separately.
>
> It looks like Ω(?var->i) is binding the graph variable, but then it's
> doing a "Join", which is defined as:
> http://www.w3.org/TR/sparql11-query/#defn_algJoin
> [[
> Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1 and μ2 are
> compatible }
> ]]
>
> I couldn't readily find the definition of the merge function, but I
> think I found the definition of "compatible":
> http://www.w3.org/TR/sparql11-query/#defn_algCompatibleMapping
> [[
> Two solution mappings μ1 and μ2 are compatible if, for every variable v
> in dom(μ1) and in dom(μ2), μ1(v) = μ2(v).
> ]]
> which seems to be saying that the variables being joined must be bound
> to the same values.  But since the empty basic graph pattern does not
> bind ?G, I *think* this means that Ω(?var->i) would *not* be compatible
> and ?G would therefore not be bound in the result.

It is compatable.  It says variables in common must match, not all 
variables must match.  If dom(μ1) is the empty set, the "forall" 
condition is trivially true.

Join(eval({}), X) = X for any pattern X.

One row, no bindings is the join identity.

(Otherwise LeftJoin would not work, nor Union, ...)

try

ASK{}

> So, if I have properly followed the SPARQL algebra, I *think* this means
> that the short form that you suggested for listing graphs will not work,
> and it is not possible to get a list of graphs that includes empty
> graphs.  (Hence the Sesame 2.7.1 behavior is correct.)

You may find this relevant:

https://openrdf.atlassian.net/browse/SES-1119

> Andy or Steve, have I got this right?

 Andy

>
> Thanks,
> David
>
> On 08/13/2013 03:10 PM, Axel Polleres wrote:
>>> [[ The group pattern: { } matches any graph (including the empty
>>> graph) with one solution that does not bind any variables. ]]
>>
>> This only means that upon
>>
>> SELECT ?G WHERE { GRAPH ?G {} }
>>
>> also empty named graphs should be returned, which would not be the
>> case for
>>
>> SELECT ?G WHERE { GRAPH ?G { ?S ?P ?O } }
>>
>> Obviously, this makes a difference for all graph stores that support
>> empty named graphs. So, to my understanding at least, this is not a
>> bug in the spec.
>>
>> HTH, Axel
>>
>> On 13 Aug 2013, at 20:21, David Booth <david@dbooth.org> wrote:
>>
>>> Hi Axel,
>>>
>>> That doesn't work in Sesame 2.7.1 at least, apparently because ?G
>>> is not bound, even though there is one solution.  The SPARQL 1.1
>>> spec says: http://www.w3.org/TR/sparql11-query/#emptyGroupPattern
>>> [[ The group pattern: { } matches any graph (including the empty
>>> graph) with one solution that does not bind any variables. ]]
>>>
>>> Is this a bug in the spec?
>>>
>>> David
>>>
>>> On 08/13/2013 11:48 AM, Axel Polleres wrote:
>>>> Hi Quentin,
>>>>
>>>> how about just
>>>>
>>>> SELECT ?G WHERE { GRAPH ?G {} }
>>>>
>>>> (no need to dump all triples, if the only concern is which ?G
>>>> exist)
>>>>
>>>> BTW, public-sparql-dev@w3.org may be the list you wanted to use.
>>>>
>>>> best, Axel
>>>>
>>
>>
>>
>>

Received on Wednesday, 14 August 2013 15:19:17 UTC