Re: subgraph/entailment

((I am sorry that I did not get engaged in this discussion earlier: I 
have been off-network for a couple of weeks.))

>On 8 Sep 2005, at 10:03, jos.deroo@agfa.com wrote:
>>>>>>I should *not* get the bnode coming from the redundant
>>>>>>triple, but simply {<http://example.org/book/book1>}.
>>>>>
>>>>>Otoh, for
>>>>>
>>>>>CONSTRUCT { ?x dc:title "SPARQL" }
>>>>>WHERE { ?x dc:title "SPARQL" }
>>>>>
>>>>>I actually get
>>>>>
>>>>><http://example.org/book/book1> dc:title "SPARQL".
>>>>>_:b_0_ dc:title "SPARQL".
>>>>>
>>>>>which I assume to be fine, no?
>>>>>
>>>>
>>>>The result form shouldn't affect the (number of) results
>>>>unless there's something expicit in the form which does that
>>>>(which I don't think is true for construct). At least,
>>>>that's what I would expect!
>>>>
>>>
>>>Indeed. I expect no bnode in this case too, independently on
>>>the type of query, since the answer should be the same as the
>>>one with the dataset without the bnode.
>>>
>>
>>[[
>>The CONSTRUCT result form returns a single RDF graph
>>specified by a graph template. The result is an RDF
>>graph formed by taking each query solution in the
>>solution sequence, substituting for the variables
>>into the graph template and combining the triples
>>into a single RDF graph by set union.
>>]]
>>http://www.w3.org/2001/sw/DataAccess/rq23/#construct
>>
>>and
>>
>>###
>><http://example.org/book/book1> dc:title "SPARQL".
>>_:b_0_ dc:title "SPARQL".
>>###
>>
>>is a single RDF graph and a single result and I don't
>>see any issue wrt to bnodes or minimality in it;
>>what is the issue in this case?
>
>As I argued with my latest long email 
><http://www.w3.org/mid/E1ED5pH-0005ls-Kz@lisa.w3.org>, there only 
>one binding (query solution) for ?x according to RDF-MT semantics, 
>namely <http://example.org/book/book1>.
>Therefore, substituting the variable ?x in the graph template gives 
>you only the triple
>
><http://example.org/book/book1> dc:title "SPARQL".
>
>even in the case of the dataset
>
><http://example.org/book/book1> dc:title "SPARQL" .
>_:b dc:title "SPARQL" .
>
>
>Is there something I'm missing?

Yes.

You are making a central confusion, between query matching and 
entailment. Querying is NOT checking entailment. Querying is checking 
what patterns are actually present in the graph (possibly under 
various constraints, etc., but leave such complexities aside for 
now.) This is not the same task as checking that the query is 
entailed by the graph. It is an essentially syntactic, algebraic kind 
of business, not a semantic one.

If you are used to thinking of a query as similar to a goal to be 
proved, as is commonly done in LP, please try to put that idea aside, 
as it is actively misleading here. This is not the way that SPARQL is 
designed. For very simple queries and for entailment = simple 
entailment, and if we think of query variables as being specially 
marked bnodes, then they are almost indistinguishable, since A simply 
entails B just when an instance of B is a subgraph of A: but as soon 
as we consider more complex kinds of entailment or querying, the 
analogy breaks down.

Thus, I find your assertion above mistaken, in its reference to the 
RDF semantics. The RDF MT makes no reference to queries, and SPARQL 
does not refer to entailment as defined by the RDF MT. So to make any 
assertion about the correctness or otherwise of a query by reference 
to the RDF MT is to conflate two topics that should be kept separate. 
The signs of this mistaken conflation are evident in the long email 
you refer to, for example (in response to Dan C.):

"Specifying query answering by looking at the deductive closure is an 
unhortodox way to see entailment"

It would be an unorthodox way to see entailment, if it were a way to 
see entailment at all. But it is not: entailment is one topic, query 
answering is a different topic. The confusion arises from viewing the 
latter as though it were the former.  Again, the example that you 
have identified:

<http://example.org/book/book1> dc:title "SPARQL" .
_:b dc:title "SPARQL" .

which as you point out is redundant (non-lean) because it both 
entails and is entailed by a proper subgraph

<http://example.org/book/book1> dc:title "SPARQL" .

of itself, so both these graphs have the same deductive closure. 
However, you then go on to make an inappropriate claim:

"In other words, the deductive closures according to RDF-MT of the 
two graphs above *are the same*. And I have to get the *same answer* 
when I query these two gr
aphs!

No, that does not follow. Logically equivalent graphs are not 
required to give identical query results. In fact, the contrary is 
true, it seems to me: an appropriate query process should not give 
the same results from these two graphs, precisely because one of them 
is redundant and the other is not. An accurate query service should 
then give redundant answers in one case but not the other, accurately 
reflecting the structures it finds in the graph. Put another way, it 
is not part of the task of the basic querying process to perform 
inferences: its role is, rather, to accurately respond to the 
structures it actually finds in the graph itself. The task of the 
querying process is to match a pattern against a graph and send back 
the results it finds in that graph. It is not to indicate that the 
query pattern is entailed by the graph.

(BTW, there is a perhaps unfortunate possible misunderstanding about 
what 'equivalent' means. There is a definition of 'equivalent graph' 
in the RDF Concepts document, cited in an email by Peter, but this is 
not the same meaning as 'logically equivalent' in the sense of 
'entails and is entailed by'. That notion of logical equivalence is 
nowhere defined in the RDF specs, in fact. The equivalence cited 
there refers to re-naming bnodes, in effect: two graphs are 
equivalent just when they are bnode-re-namings of each other. So in 
this (strong) sense, a non-lean graph is not equivalent to its lean 
subgraph, and the two graphs in the example are not equivalent.)

If one wishes to offer a query-answering service that does check 
entailments, then the appropriate thing to do within the SPARQL 
framework is to declare that one is matching queries against a 
'virtual graph' which is some kind of logical closure of the graph, 
rather than the graph itself. But these are different graphs, note. 
SPARQL does not require queries to be evaluated only against graphs 
which are closed under some notion of entailment: it is 
entailment-neutral (except, as noted above, regarding simple 
entailment, which follows in effect as a structural consequence of 
the very act of matching itself.) This is not an error or an 
omission, I would emphasize, but a design decision.

There is lot more that could be said, particularly about the reasons 
and justifications for this decision, but I will whisk this off so 
y'all can read it before the telecon tomorrow.

Pat


>--e.


-- 
---------------------------------------------------------------------
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 Monday, 19 September 2005 18:32:28 UTC