Re: Querying Named Graph using SPARQL

Hi David,

the empty mapping is compatible with any other mapping, thus also with Ω(?var->i).

best,
Axel
-- 
Dr. Axel Polleres
url: http://www.polleres.net/  twitter: AxelPolleres



On 14 Aug 2013, at 15:34, David Booth <david@dbooth.org> wrote:

> [Copying Andy Seaborne and Steve Harris for their input.]
> 
> 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.
> 
> 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.)
> 
> Andy or Steve, have I got this right?
> 
> 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 22:52:50 UTC