Re: Abiguities in combination of group graph patterns

Jorge Pérez wrote:
> Hi! In the last draft, little attention is put on group graph patterns 
> and "combinations" of group graph patterns. The draft says nothing about how 
> the solution of
> 
> WHERE {
>   { A . }
>   { B . }
> }
> 
> is. There is just an example in where A and B are triple patterns, in which 
> case the above WHERE clause is the same as
> 
> WHERE {
>   A .
>   B .
> }

This two queries are not necessarily the same, assuming A and B are triple 
patterns.  { A . B } is a single basic graph pattern, in a group of one. { {A} 
{B} } is two basic graph patterns, each of one triple pattern, in a group of 2.

This makes a difference depending on what entailment is being used.  There is 
also the matter that is A and B have a blank node with the same label, it will 
not be the same blank node in the { {A} {B} } case.

With ARQ, when querying a plain RDF graph, if the triple patterns do not use 
blank nodes, then the answers will be the same.

> 
> but what if A or B are more complex graph patterns? It is not clear what the 
> example is trying to say: 
> 
> 1) does it say that {} (inside other {}) are useless and on can just omit 
> them? and then {{ A. } { B. }} is alway equal to { A. B. }
> 2) Other possiblity of evaluation is to think that { A. } and { B. } are graph 
> patterns in the same group graph pattern, aplying the group graph pattern 
> formal definition, a solution to the pattern { { A. } { B. } } must 
> *independently* match the patterns A and B.

A solution will be a solution to both.

> 
> what is the right? When looking in some implementations (SPARQLer and others) 
> it seems that they are just omiting {}, i.e. using 1). following my example in 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Apr/0020.html
> what would be the answer for

Omitting the {} will get the same answers in ARQ when the query is being made 
against a plain RDF.

> 
> WHERE {
>   { ?B :titlename ?N . }
> 
>   { ?B :year ?Y .
>     OPTIONAL { ?B :authorname ?N } }
> }
> 
> if one agree with 2) the solution must be the same as the solution for
> 
> WHERE {
>   { ?B :year ?Y .
>     OPTIONAL { ?B :authorname ?N } }
> 
>   { ?B :titlename ?N . }

This is an artifect of the ARQ execution strategy.  It processes queries in 
the order the query has them - OPTIONAL acts like a left join in SQL (with all 
the same issues as regards optimizations and transformation of queries that 
that brings).

rq23 says
"""
A solution of Group Graph Pattern GP on graph G is any solution S such that, 
for every element GPi of GP, S is a solution of GPi.
"""
so ARQ is failing to find some solutions.  It should be treating OPTIONAL more 
like a full outer join.

> }
> 
> but implementations gave me differents results...

Which implementations?  You mentioned SPARQLer (which is running ARQ).  It 
would be good to know what other implementations you are referring to so we 
can draw on implementation experience.

> 
> Note that there may be more complex forms of combinations, so this issues 
> deserves clarifications. If the editors agree with 1) then for simplicity the 
> {} must be refused inside other {}, this is the most simple way to avoid the 
> problem, for example
> 
> { A. { B. { C. } { D. }} . OPTIONAL E. }} == { A. B. C. D. OPTIONAL E. }
> 
> If they agree with 2) (not the most simple but seems to be the more "natural") 
> I think that some clarifications may be added to the draft.
> 
> - Jorge

	Andy

Received on Monday, 24 April 2006 17:09:12 UTC