Re: On told-bnodes in queries

On 3 Nov 2005, at 19:38, Seaborne, Andy wrote:
> 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.

Yes, if you mean the occurrence of both _:a and _:b in the query as  
standard bnodes. (but we meant them to be told-bnodes -- or, as you  
call them, literal bnodes). So, in your syntax,

[[
GRAPH: :s :p _:b .

query 1':  { ?x :p <_:a> }
query 2':  { ?x :p <_:b> }
]]

I expect the answer of query 1' to be empty, while query 2' should be  
[?x/:s].

> > 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.

Yeah, sorry if we were not clear enough: the thread is about told- 
bnodes, so we were assuming that the bnodes in the above example  
queries were actually told-bnodes. So, our proposal is to be able to  
specify in a query which bnodes are to be treated as told-bnodes (or  
literal bnodes). I am happy to know (I missed this before) that there  
is a syntactic way to distinguish them in the spec as <_:b> as  
opposed to _:b.

> 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?
>
> More - there could be further restrictions such as:
>
> 1/ No told bNodes - I guess this is necessary
> 2/ Even no bNodes in the query at all - that might be restrictive  
> on syntax but may be acceptable.

I don't fully understand why are you requiring such restrictions.
Bu most importantly, I don't understand at all the following statement:
"Entailment beyond what can be done by logical closure only applies  
to queries with a single basic pattern matching."
What does it mean?
Nor I understand:
"The rest of the algebra applies to abstract syntax queries (and  
hence over logical closures)."
Can you explain?

--e.

Received on Friday, 4 November 2005 10:56:11 UTC