Re: On told-bnodes in queries

>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