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.

Not with the case B definition I sent you, because that includes the 
graph in the entailment. See below.

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

Right, but that doesn't satisfy the condition for being a match, if 
we use the case B defs, because

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

doesn't entail

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

or

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

This kind of example is why we include the graph in the entailment, 
to keep the bnodes in line with their original usage. If there are no 
bnodes then its redundant because then G entails B iff G entails (B 
union G) when B has no bnodes in it (more generally, when B an G have 
no shared bnodes).


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


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 16 December 2005 19:43:07 UTC