W3C home > Mailing lists > Public > www-rdf-comments@w3.org > July to September 2003

Re: problems with simple entailment rules

From: pat hayes <phayes@ihmc.us>
Date: Sat, 9 Aug 2003 20:30:53 -0700
Message-Id: <p06001a00bb5b6a50c791@[10.0.1.2]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-rdf-comments@w3.org

>From: pat hayes <phayes@ihmc.us>
>Subject: Re: problems with simple entailment rules
>Date: Thu, 7 Aug 2003 23:44:03 -0500
>
>>  >From: pat hayes <phayes@ihmc.us>
>>  >Subject: Re: problems with simple entailment rules
>>  >Date: Tue, 5 Aug 2003 10:55:50 -0500
>>  >
>>  >>  >I believe that there is a problem with the definition of 
>>``allocated to''
>>  >>  >in the simple entailment rules.  The definition currently (as of the 31
>>  >>  >July version) states
>>  >>  >
>>  >>  >	The terminology 'allocated to' means that the blank 
>>node much have
>>  >>  >	been created by an earlier appliation of the 
>>specified rules on the
>>  >>  >	same URI reference or literal, or if there is no such 
>>blank node
>>  >>  >	then it must be a 'new' node which does not occur in the graph.
>>  >>  >
>>  >>  >My reading of this is that the following RDF graph
>>  >>  >
>  > >>  >	<ex:a> <ex:p> <ex:b> .
>>  >>  >
>>  >>  >cannot be expanded to
>>  >>  >
>>  >>  >	<ex:a> <ex:p> <ex:b> .
>>  >>  >	<ex:a> <ex:p> _:a .
>  > >>  >	<ex:a> <ex:p> _:b .
>>  >>  >
>>  >>  >using the simple entailment rules because once there is a blank node
>>  >>  >created from <ex:b> then all subsequent rule applications must use that
>>  >>  >blank node for <ex:b>.
>>  >>
>  > >>  That is correct. This construction was adopted in order to make
>  > >>  closures be finite under these rules, and because this restricted
>>  >>  version is sufficient to produce the required completeness result for
>>  >>  the vocabulary entailments.  As the text notes, a modification of the
>>  >>  rule which allows bnodes to be allocated to other bnodes would allow
>>  >>  this inference and would be complete. The text states this explicitly
>>  >>  (last para section 7.1):
>>  >>  "These rules will not generate all graphs which have the original
>>  >>  graph as an instance, which could include arbitrarily many blank-node
>>  >>  triples all of which instantiate back to the original triples.
>>  >>  Modifying the rules so that new blank nodes could be allocated to
>>  >>  existing blank nodes would generate all such graphs. "
>  > >>
>>  >>  >
>>  >>  >Also
>>  >>  >
>>  >>  >	<ex:a> <ex:p> _:a .
>>  >>  >
>>  >>  >cannot be expanded to
>>  >>  >
>>  >>  >	<ex:a> <ex:p> _:a .
>>  >>  >	<ex:a> <ex:p> _:b .
>>  >>  >
>>  >>  >because se1 requires that the object of the triple be a URI 
>>reference or
>>  >>  >literal.
>>  >>
>>  >>  Indeed; see comment above.
>  > >>
>>  >>  >This means that the simple entailment rules are not a 
>>replacement for the
>>  >>  >instance relationship, which counters the claim in Section 7.1.
>>  >>
>>  >>  What claim?
>>  >
>>  >The very first sentence in Section 7.1 says
>>  >
>>  >	The instance lemma in Section 2 can be stated as inference rules on
>>  >	triples.
>>
>  > Which is correct.
>>
>>  >Section 7.1 then goes on to give the simple entailment rules.
>  >
>>  And, in addition, it says explicitly that the rule as stated is not
>>  exactly equivalent to the instance lemma, but that a modification of
>>  it- which it describes - is.  I see no problem with this.
>
>I do.  The modification is not described in sufficient detail to determine
>exactly what the rule set is.

It is described perfectly clearly: modifying the rules to allow new 
blank nodes to be allocated to existing blank nodes. The change to 
the literal statement of the rule, using the textual conventions 
indicated in the immediately preceding section, would be to replace 
vvv by xxx in se1 and bbb by uuu in se2. This seems to me to be 
obvious.

This change then allows the following derivation of your example:

<ex:a> <ex:p> <ex:b> .

<ex:a> <ex:p> _:a .  [se 1 with _:a allocated to <ex:b> ]
<ex:a> <ex:p> _:b .  [se 1 from previous triple with _:b allocated to _:a]


>In particular, simply allowing new blank
>nodes to be allocated to existing blank nodes does not change the rule set
>at all, as this would not change the restrictions on which kinds of triples
>the rules can be applied to.

See above.

<snip>

Pat


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Saturday, 9 August 2003 23:30:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:32 GMT