W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > August 2006

Re: What is "the serious bug in entailment semantics" found by J.Perez"?

From: Jorge Pérez <jperez@ing.puc.cl>
Date: Fri, 11 Aug 2006 10:35:51 -0400 (CLT)
Message-ID: <52711.146.155.4.12.1155306951.squirrel@mail.ing.puc.cl>
To: "Pat Hayes" <phayes@ihmc.us>
Cc: franconi@inf.unibz.it, public-rdf-dawg-comments@w3.org

Pat Hayes wrote:

[...]

>
> [Later: And the other example in
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Aug/0005
> makes the basic point more effectively.]
>
> However, consider the following example: same query, but against the graph
>
> {(a p a) (X p X) (X p b) }
>
> Here, I suggest, the answers ?q->a, ?q->X would
> be correct, in spite of the apparent redundancy,
> because the third triple clearly distinguishes
> (what is known about) X from (what is known
> about) a; so the redundancy is indeed only
> apparent.

I totally agree with you that the answer ?q->a, ?q->X is correct in this
case, but I think that your example is not related to the core of this
discussion. The "bug" in BGP E-matching is originated by redundancy in the
dataset side (and queries about such redundancies) and has nothing to do
with redundancy in the answer side, that (as your example shows) one not
always want to eliminate.

Your example is "a good example" for the definitions, the dataset has no
redundancy and the BGP E-matching definition (with simple entailment)
gives the same solutions as the subgraph matching approach, so the "bug"
is not present. Indeed, I think that it is a theorem that in the case of
lean datasets the two approaches are always equivalent.

- jorge

>
> Pat
>
>
> --
> ---------------------------------------------------------------------
> 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, 11 August 2006 14:36:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT