- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 24 Apr 2006 18:08:48 +0100
- To: Jorge Pérez <jperez@utalca.cl>
- CC: public-rdf-dawg-comments@w3.org
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