Re: Abiguities in combination of group graph patterns

From: Jorge Pérez <jperez@utalca.cl>
Date: Mon, 24 Apr 2006 16:07:29 -0400
Message-ID: <1145909249.444d300179af5@webmail.utalca.cl>

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT