Re: Abiguities in combination of group graph patterns

Mensaje citado por "Seaborne, Andy" <andy.seaborne@hp.com>:

> 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.

but there are cases in wich omitting the {} must result in different answers...

> 
> > 
> > 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.  

Not only failing to find, it is finding solutions that do not exist!
I understand then that ARQ is following in a wrong way the specification in 
the case of evaluation of group graph patterns.

> 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.

I have been trying SPARQLer and the one by XML ArmyKnife 
http://xmlarmyknife.org/api/rdf/sparql/query

This two implementations are evaluating combinations of group graph patterns 
in the wrong way. I think that this is in part because the SPARQL 
specification is very short in this issue... the two implementations gave me 
different aswers for the patterns { {A} {B} } and  { {B} {A} } that must 
result in the same.

- Jorge

> 
> > 
> > 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
> 

-------------------------------------------------
Este mensaje fue enviado por: http://webmail.utalca.cl

Received on Monday, 24 April 2006 20:12:06 UTC