W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2006

Re: On production rules and phase I&II

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 08 Mar 2006 13:49:56 -0500
To: Frank McCabe <frank.mccabe@us.fujitsu.com>
Cc: public-rif-wg@w3.org
Message-Id: <20060308184955.574494F4DE@homer.w3.org>


> There may be hidden difference difference here in semantics. Here I  
> am referring specifically to RETE rather than OPS5
> 
> A precondition in a RETE rule is closer to a Prolog-style pattern  
> match than a predication. I.e., in (using my own made on the fly  
> notation)
> 
>    when parent(x,y) and ancestor(y,z) assert ancestor(x,z)
> 
> there is no sense in which, in RETE land, parent(x,y) can be said to  
> be true. It is a pattern that should be matched by an object in the  
> set of objects managed by the RETE engine.
> 
>   Re-expressing this in a form that is closer to RETE-speak, you get
> 
>    when {parent = x, child=y} and {ancestor=y, descendant=z}
> 	assert {ancestor=x, descendant=z}
> 
> highlights this a little more clearly (I hope) The expressions  
> {parent=x,child=y} etc are patterns that are applied to the objects  
> in the pool.
> 
> I.e., the semantics of RETE is inherently operational - the RETE  
> inference rules express the kinds operations you can make on a set of  
> objects.
> 
> As we know, we *can* model such a semantics, in effect constructing a  
> denotational semantics for RETE. But, this is not the same thing as  
> mapping RETE rules into predicate logic; any mapping has to carry  
> with it the operational semantics of RETE otherwise it will not be  
> faithful to the RETE semantics.

That's quite clearly stated, thank you.  Can you give an example of a
RETE ruleset where the only actions are assert and where the end results
would be different between using the rules via RETE and using them via
the trivial mapping to depth-limited pure prolog, or FOL given to a
resolution theorem prover?

     - sandro
Received on Wednesday, 8 March 2006 18:49:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:27 GMT