- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 2 Nov 2005 11:53:40 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
>Hi Pat, >Here it is the example of why the definition of query answer using >union rather RDF-merge does not work as desired to capture what I >called (l3): > >>l3) the bnodes names in a query have to be treated as told-bnodes, >>i.e., they have to match only with bnodes with the same name in the >>dataset. > >GRAPH: :s :p _:b . > >query 1: { ?x :p _:a } >query 2: { ?x :p _:b } > >According to (l3) query 1 has the empty answer, >while query 2 has the answer [?x/:s]. > >using the semantics proposed by you: > >G |= (G U Q)[s] > >both queries have the answer [?x/:s] Yes, of course you are right. Stupid of me to not see this immediately. I had not fully internalized the meaning of your l3 condition, I now realize. Thinking some more about your l3 condition, I think it is too strong, and we should weaken it, and the union design will then be acceptable. The use case we want to support is where a query answer introduces a bnode as an answer binding, and the use of *that bnode* in a subsequent query is understood to refer to the same entity as it did in the earlier query: call this a 'rigid' use of the bnode. This is actually a weaker condition than your l3, which requires that *all bnodes* in a query must be treated rigidly. Moreover, I think in fact that this weaker condition is more useful, since later queries might wish to use other bnodes simply as existentials. So for example consider a setting where the graph contains collections which are used to encode n-ary relations, so that G might contain {... :Arthur type Person :Arthur :siblings _:l34 _:l34 type collection _:l34 first _:Person55 _:l34 rest _:l35 _:l35 first :Susan _:l35 rest _:l36 _:l36 first :Bill _:l36 rest nil _:Person55 type Person _:Person55 :gender male ...} i.e. Arthur has siblings Susan, Bill and some guy. Now imagine a query intended to discover whether Arthur has any siblings: :Arthur :siblings ?L ?L first ?V This gives the answer L/_:l34, V/_:Person55 . It would be natural at this point to ask further queries in which _:Person55 and/or _:l34 are used rigidly, but other bnodes are not: for example _:l34 rest _:x _:x first ?W asks for the next sibling on the list, if there is one, and should produce the answer V/:Susan, but not the answer W/:Bill, because _:l34 is understood rigidly: but if _:x were also understood rigidly, as with your l3 as stated, it would not produce any answers since _:x does not occur in the graph (let us suppose). So my suggestion is that we alter the l3 condition to read: L3') the bnodes names in a query which were introduced as answer binding in earlier queries have to be treated as told-bnodes, i.e., they have to match only with bnodes with the same name in the dataset. And then, I believe, the 'union' condition works as intended, which simplifies everything quite a lot. And, to emphasize, this is not a hack trick to rescue a simple definition, but in fact accords better with the intended use cases, which would not work properly with l3 as currently stated. Comments? Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 2 November 2005 17:54:23 UTC