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

From: Ginsberg, Allen <AGINSBERG@imc.mitre.org>
Date: Thu, 26 Jan 2006 12:27:47 -0500
Message-ID: <90A462F2D6E869478007CD2F65DE877C702927@IMCSRV5.MITRE.ORG>
To: <public-rif-wg@w3.org>

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 rule
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 out.

2) Assuming an analysis like (B) is more in line with our understanding
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 that
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 rule
in terms
of a language or model that has well-known semantics.

_______________________________________________________________

Dr. Allen Ginsberg        The MITRE Corporation, Information Semantics
aginsberg@mitre.org       Center for Innovative Computing & Informatics

Voice: 703-983-1604       7515 Colshire Drive, M/S H305
Fax:   703-983-1379       McLean, VA 22102-7508, USA
Received on Thursday, 26 January 2006 17:28:25 UTC

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