W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: On told-bnodes in queries

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 2 Nov 2005 11:53:40 -0600
Message-Id: <p06230907bf8e979d2da1@[]>
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 
>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.



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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:49 UTC