From: Jorge Pérez <jperez@utalca.cl>

Date: Mon, 24 Apr 2006 16:07:29 -0400

Message-ID: <1145909249.444d300179af5@webmail.utalca.cl>

To: andy.seaborne@hp.com

Cc: public-rdf-dawg-comments@w3.org

Date: Mon, 24 Apr 2006 16:07:29 -0400

Message-ID: <1145909249.444d300179af5@webmail.utalca.cl>

To: andy.seaborne@hp.com

Cc: public-rdf-dawg-comments@w3.org

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.clReceived on Monday, 24 April 2006 20:12:06 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:52:07 UTC
*