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?

	Andy

(*)
[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0498.html

> 
> cheers
> --e.
>

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