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

RE: [RIF] A Modest Proposal: Work Out Some Concrete Examples; Example-1: CHANGE-BABY-IF-WET rule

From: Ginsberg, Allen <AGINSBERG@imc.mitre.org>
Date: Fri, 27 Jan 2006 09:41:01 -0500
Message-ID: <90A462F2D6E869478007CD2F65DE877C702B12@IMCSRV5.MITRE.ORG>
To: "Michael Kifer" <kifer@cs.sunysb.edu>
Cc: <public-rif-wg@w3.org>

Hi Michael, Thanks for your response. For now I just want to respond to
your statement that first-order logic is ill-suited to analyze the
meaning of production rules. I want to stress that first-order logic,
in this instance, is just a vehicle for expressing an analysis.   The
analysis could be done in natural language, but I find using logical
notation to be helpful in expressing things and also as a step towards
a more formal analysis.

Let me restate what it is that I think needs to done, and let me do
that by means of another example.

Let's consider the necessity operator in modal logic, let us denote it
"N".   "Np" (p is necessarily true) means, according to a kripkean
semantics that p is true on all possible worlds.  To be clear about
what that means, we can quantify over possible worlds and explicate the
meaning of Np as 
	(forall x)(PW(x) -> T(p,x))  

i.e., if x is a Possible World [Pw(x)] then p is True in x T(p,x].

We should, of course, go on to provide first-order axioms that express
our interpretation of PW(x) etc. 

Clearly if I want to use modal operators in practice, some form of
modal logic is a cleaner way to do that.

BUT, if I want to EXPLAIN to someone what these operators MEAN then I
need to tell them the story about possible worlds and truth in a
possible world, etc.  The full story would involve explicating
kripke-structures and accessibility relations and so on.  

My feeling is that if one wanted to express the semantics of
modal-logic in a formal fashion, then using first-order logic is a good
way to do that.

In the same way, if I want to explain to someone what a production
system is, then I need to tell them the story about Working Memory,
facts being in working memory, facts being added or deleted from
working memory, etc.  That is what my analysis was trying to do and
that is what I think the RIF should enable.    My feeling is that using
first-order logic is a good way to express those semantics.

I don't know much about the particulars of Flora-2 or transaction
logic, but it sounds to me that the semantics of that logic could
equally be explicated in first-order logic.  In other words, to
understand the meaning of the Flora-2 version of change-baby-if-wet
requires quantifying over states and probably actions.  The semantics
of states and actions needs to be explicated. 

Using first-order logic to do these sorts of analyses is good because
it forces one to say exactly what types of things one is postulating as
basic entitles and so forth.


-----Original Message-----
From: Michael Kifer [mailto:kifer@cs.sunysb.edu] 
Sent: Thursday, January 26, 2006 10:14 PM
To: Ginsberg, Allen
Cc: public-rif-wg@w3.org
Subject: Re: [RIF] A Modest Proposal: Work Out Some Concrete Examples;
Example-1: CHANGE-BABY-IF-WET rule 

You are trying to use first-order logic to analyze what this logic is
ill-suited to do. It is a production rule whose semantics is best and
described in Transaction Logic
For instance, in
FLORA-2, which supports much of Transaction Logic, this Jess rule would
look like this:

changeBabyIfWet(?Baby) :-

change(?Baby) can also be defined via a rule as deleting the old diaper
inserting a new one where appropriate. The exact definition depends on
exactly you represent diapers and the fact that a particular diaper is
on a
particular baby.

In Transaction Logic, the above changeBabyIfWet(?Baby) would be a
state-changing action. It is defined as a sequence of queries and other
actions. In our case, it is defined as a query (wet(?Baby)) followed by
action (changeBaby(?Baby)), which changes the underlying state by
the old diaper with a new one, and then deleting the fact that the
specified baby is wet. 


"Ginsberg, Allen" <AGINSBERG@imc.mitre.org> writes:
> Dear RIF-WGers,
> It seems to me that one way of clarifying what the RIF is and what it
> can or should enable is to work on some concrete examples.
> So here is a contribution to that effort:
> Consider the following rule definition (taken from the book "Jess in
> Action" by Ernest Friedman-Hill, p. 98)
> (For those not familiar with this syntax I have provided comments.)
> (defrule change-baby-if-wet 
> 	 // bind the working memory element that satisfied the pattern
to the variable ?wet
> 	?wet <- (baby-is-wet) 
> 	=>
> 	(change-baby)
> 	// remove the element bound to the variable ?wet from the
working memory
> 	(retract ?wet)  
> )
> Here are some questions: 
> 1) From a theoretical point of view, is there a single optimal or
> correct analysis of the "semantics" of this rule?
>    Or is it possible that more than one reasonable analysis can be
> given?  If so, must these analyses be equivalent?
>    To flesh this out a bit, here are two possible analyses
> 	(A) the meaning of this rule can be represented in classical
> propositional logic as follows:
> 		(P & Q) -> (R & S)
> 	where 
> 		P = "The variable ?wet is bound to an element in
> working memory"
> 		Q = "The fact [baby-is-wet] is in working memory"
> 		R = "The fact [baby-is-changed] is in working memory"
> 		S = "The element bound to variable ?wet is not in the
> working memory"
>      OR  (B) using first-order logic we might try something like
> 	  (ForAll x)(Forall y) (Forall t) 
> 		[ InWM(y,t) & y = fact("baby-is-wet") & Bound(x, y) ->
> (Exists z) (z = fact("change-baby")) & InWM(z,t+1) & ~InWM(y,t+1) ]
> 	Where 
> 		InWM(x,t) = "x is in Working Memory at time t"
> 		fact(<string>) is a function that returns the fact
> associated with <string>
>             Bound(x,y) = "x is bound to y"
> To me, analysis (B) captures more of what is going on then analysis
> (A). However, both analysis represent the meaning of the original
> in terms of a formal language that has well-defined semantics itself.
> Neither analysis is complete because they do not explicate the
> predicates or terms involved in their representations of the rule
> meaning, but that could be done.  In particular, there is a discrete
> time-model involved regarding Working Memory that needs to fleshed
> 2) Assuming an analysis like (B) is more in line with our
> and expectation concerning the RIF, how should it be done in the RIF?

>    Rather than answering that question I would state some criteria on
> any proposed answer (relative to this concrete example for now):
> 	1) It should be clear that the RIF representation of the
> change-baby-if-wet-rule can be generated by a general algorithm
> 	2) It should be clear that the resulting representation can be
> used to generate an equivalent change-baby-if-wet rule in systems
> belong
> 		to the same family as CLIPS/JESS, for example, JRULES. 
> 	3) For systems in a different family (having a different
> meta-model) such as a prolog-based system, the RIF should make it
> possible to transform
>          the original RIF representation of the meaning of the
> change-baby-if-wet rule into a RIF-representation of the meaning of
> that rule in the for
>           systems in the other family.
> NEXT STEPS for example-1:  
>     1) Find equivalent rules for change-baby-if-wet rule in other
> systems in the same family
>     2) Find equivalent rules for change-baby-if-wet rule in other
> systems in different families
>     3) for each of the families on step (2), figure out reasonable
> possible representations of the meaning of the change-baby-if-wet
> in terms
>          of a language or model that has well-known semantics.
> _______________________________________________________________
> Dr. Allen Ginsberg        The MITRE Corporation, Information
> aginsberg@mitre.org       Center for Innovative Computing &
> Voice: 703-983-1604       7515 Colshire Drive, M/S H305 
> Fax:   703-983-1379       McLean, VA 22102-7508, USA 
Received on Friday, 27 January 2006 14:42:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:36 UTC