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.