W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > April 2006

Re: Abiguities in combination of group graph patterns

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 24 Apr 2006 21:49:29 +0100
Message-ID: <444D39D9.9040404@hp.com>
To: Jorge Pérez <jperez@utalca.cl>
Cc: public-rdf-dawg-comments@w3.org



Jorge Pérez wrote:
> 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

It appears that these are not different implementation - they are both using 
ARQ as their SPARQL query processor.

According to the web page
http://xmlarmyknife.org/docs/rdf/sparql/#impl
for XML ArmyKnife, it is using Jena 2.3 implying it is using a version of ARQ 
(specifically , version 1.0)

SPARQLer is running a build of the development version of Joseki 
(http://www.joseki.org/) which is ARQ + an implementation of the SPARQL 
protocol for HTTP.

You can obtain the latest release of ARQ from http://jena.sourceforge.net/ARQ 
which includes various command line tools for executing queries and printing 
query structures.  You can also get the development copy of ARQ from CVS on 
SourceForge, although, just at the moment, SourceForge have disabled the link 
between developer and anonymous CVS access as described in the SourceForge 
status page.

	Andy


> 
> 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:49:53 GMT

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