Re: putting entailment into SPARQL

Pat Hayes wrote:
>>Pat: specific question:
>>
>>In 2.7, you suggest text
>>
>>"""
>>Blank nodes in the results of a query are identical to those 
>>occurring in the dataset graphs ...
>>"""
>>
>>Not sure about "identical".
>>
>>A solution matches a basic graph by simple entailment so any bNode 
>>in the solution is not necesarily the same as the one corresponding 
>>one in the graph.
> 
> 
> BUt there is an additional restriction (in the definition of pattern 
> solution), that the range of the substitution is a subset of the 
> terms actually occurring in the graph. So the answer bindings have to 
> be the actual IRIs, literals and bnodes in the graph. (Otherwise 
> there could be infinitely many bnodes in answer bindings, and every 
> matching query would have infinitely many answers; and without this 
> the told-bnode trick wouldnt work.)
 >
 >
 >> Together with the document scope of bNode labels in teh XML rsult
 >>format and in any RDF serialization, means that even if they were
 >>the same, you can't tell.
 >
 >
 > If there aren't any told bnodes, you can't tell, its true. We still
 > need a way to stop bnode-bleeding in the answer bindings, however.
 >
 > Pat
 >

That condition isn't enough though - there can be rearrangement.  _:a and _:b 
in the graph may be _:b and _:a in the results.  I couldn't see a way to 
connect the solution to the data except via a layer of entailement.

Data:
_:a :p 1 .
_:b :p 2 .

Query: { ?x :p ?v }

Results
?x/_:b ?v/1
?x/_:a ?v/2

meets the conditions of being RDF terms from the graph.  The restriction of 
being from the graph at least means a finite input graph leads to finite results.


I'm not sure we are in a different position here because we want query over 
deductive closure to work and give finite results.

	Andy

> 
> 
>> All that is transmitted is whether two bNodes in the document are 
>>the same or different.
>>
>>Or have I missed something?
>>
>>	Andy
>>
>>
>>>>PS. One other rewording in section 2.7:
>>>>
>>>>"An application or client receiving the results of a query can 
>>>>tell that two solutions or two variable bindings differ in blank 
>>>>nodes but this information is only scoped to the results as 
>>>>defined in "SPARQL Variable Binding Results XML Format" or the 
>>>>CONSTRUCT result form."
>>>>//
>>>>SIMPLE CASE A:
>>>>"Blank nodes in the results of a query are identical to those 
>>>>occurring in the dataset graphs, but this information cannot be 
>>>>used by an application or client which receives these results, 
>>>>since all blank nodes in subsequent queries are treated as being 
>>>>local to that query. In effect, this means that information about 
>>>>co-occurrences of blank nodes may be treated as scoped to the 
>>>>results as defined in "SPARQL Variable Binding Results XML Format" 
>>>>or the CONSTRUCT result form."
>>>>
>>>>OR, complex case B with persistent bnodes:
>>>>
>>>>//"Blank nodes in the results of a query are identical to those 
>>>>occurring in the dataset graphs, and may be re-used in subsequent 
>>>>queries as persistent blank nodes. Servers which accept a query 
>>>>containing a persistent blank node must respect the identity of 
>>>>such blank node identifiers across multiple queries and answer 
>>>>bindings. In contrast, blank nodes which appear in queries as 
>>>>nonpersistent blank nodes are treated as being local to that 
>>>>query, and bear no relationship to occurrences of the same blank 
>>>>node in other queries or their answer bindings."
> 
> 
>

Received on Friday, 16 December 2005 16:23:12 UTC