Re: On told-bnodes in queries

Enrico Franconi wrote:
> 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} }

Not sure what the ?{} syntax exactly means : original example was :

GRAPH: :s :p _:b .

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

The syntax for getting a literal bNodes (a constant for the query) that we 
have discussed before is <_:a>, that is, a pseudo-URI scheme called "_", 
followed by the system dependent bNodes label.  This is not licensed by rq23 
but the grammar allows it.  This need only apply when treating the graph as 
abstract syntax.  A number of other things need to line up as well (e.g. label 
stability; the way results of earlier queries were delivered exposed the bNode 
label (which is not true by default in the XML Results form but again not 
ruled out)).

> to get the empty answer, as opposed to
> query 2:  { ?x :p _:a }
> to get the answer [?x/:s].

I would expect to get (and do get) this answer to both queries.  bNodes in 
query syntax arose from the requirements for the syntax to be N-Triple/N3-like 
we discussed at the Feb F2F.

In Enrico's original message:

 > In this case the user may wrongly gather that the triple <:s :p _:a>
 > was *explicitely* asserted in the graph.

Why might the user make that assumption?  I haven't come across a user who has 
done so.  There is another level of bNode label scoping in the XML results set 
so the user doubly can't assume that.  bNode labels are not exposed.


Bijan's example [1] is a single basic graph pattern.

Suggestion: for this version of SPARQL, entailment beyond what can be done by 
logical closure only applies to queries with a single basic pattern matching 
Maybe some restricted set of FILTERs as well.

The rest of the algebra applies to abstract syntax queries (and hence over 
logical closures).  We hope a later working group will extend the algebra to 
entailment uses based on reseach done between the end of the WG and the start 
of the next.

Question to everyone: the best way to this would be a concrete use case for 
entailment beyond RDFS that isn't covered.  Anyone got one?



> cheers
> --e.

Received on Thursday, 3 November 2005 18:40:51 UTC