Re: On told-bnodes in queries

Pat,
you have to have a mechanism that distinguishes the use of a bnode as  
a normal bnode from a told-bnode. Otherwise, in the case you don't  
want to use told-bnodes, how can you avoid possible clashes between  
the (arbitrary) bnode names chosen for the query, and the (unknown)  
bnodes in the graph? That's why you need merge-union. And that's why  
you then need a mechanism to make a distinction between the two  
different meanings of a bnode in the query.
All your cases are covered by our simple semantics; but we guarantee  
safety in the case the user does not know the bnode names in the  
original graph while you don't have such a guarantee. If you think  
about it, the way to fix your weak semantics is to have a union  
semantics *after* you have renamed the bnodes that you don't want to  
use as told-bnodes. Well, this is what we do: we first have to  
provide a syntax to distinguish which role should a bnode play in the  
query, and then we make sure that for the bnodes to be treated as  
told-bnodes in the query the coreference with the dataset bnodes is  
possible. That's our semantics.
--e.

Received on Saturday, 5 November 2005 16:47:44 UTC