Re: On told-bnodes in queries

On 2 Nov 2005, at 21:07, Pat Hayes wrote:

>> We have formalised very simply the l3 condition in our semantics 
>> document <http://www.inf.unibz.it/krdb/w3c/sparql/>, along the lines 
>> I was telling yesterday. We added an annotation on variables in 
>> queries: "Variables may be annotated with a set of elements of RDFT - 
>> to restrict the possible assignments of variables". And we added a 
>> condition in the definition of query answer: "if a variable is 
>> annotated with a set of elements of RDFT then S must map that 
>> variable to one of these elements". As simple as that.
>
> That is conceptually simple, indeed, but the annotations will require 
> revising the SPARQL test cases and changes to the SPARQL syntax.
>
>> Please check it out. Comments welcome.
>
> OK, but in an earlier email I suggested that l3 should be weakened in 
> a significant way, which permits a simpler approach to be used. If 
> that suggestion is accepted then I think much of this is no longer 
> needed.

What we meant with our (l3) condition is exactly what you mean with 
your (l3'); we just stated it in a sloppy way. So, here it is:

l3) *some* 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.

In fact, our characterisation in the semantics document captures 
exactly this optionality, by allowing to choose which bnodes to treat 
as "told-bnodes", by doing with them what is meant to be: treat them as 
constrained query variables, while normal bnodes are left as normal 
bnodes in the query.

On the other hand, I don't believe that your alternative semantics 
based on "union" works.
Here is the counterexample - the same as before :-)

GRAPH: :s :p _:b .

query:  { ?x :p _:a }

where we mean _:a in the query to be used as a told bnode.
Well, I expect to get the empty set as the answer, but with your union 
semantics I get [?x/:s].

cheers
--e.

Received on Wednesday, 2 November 2005 20:49:49 UTC