Re: On told-bnodes in queries

On 3 Nov 2005, at 04:45, Pat Hayes wrote:
>> 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].
>
> But this case is impossible. The only way such a bnode can occur in  
> a query is if it were provided as a binding to a variable in a  
> previous query on the same graph. So the bnode must occur in the  
> graph somewhere. Then creating the union will cause the bnode in  
> the (subsequent) query to be identified with its previous  
> occurrence in the graph.

Aha! But how do you know?
How do you bootstrap the process to understand which are the bnodes  
occurring in a graph? There is no way, because the only way to access  
the information from a graph is through querying anyway. The only  
solution would be to systematically add as a first step of any chain  
of queries a query of the type { ?x ?y ?z } to fetch all the bnodes  
names in the graph, and then you can proceed from that list. This is  
very artificial and really bad. Moreover, nobody guarantees that in  
the case of multiple graphs in a dataset the process of graph merging  
to build the unified dataset will return the same fresh bnode names  
twice.
On the other hand, our approach says:

GRAPH: :s :p _:b .

query 1:  { ?x :p ?{_:a} }

to get the empty answer, as opposed to

query 2:  { ?x :p _:a }

to get the answer [?x/:s].

cheers
--e.

Received on Thursday, 3 November 2005 09:07:33 UTC