From: Michael Kifer <kifer@cs.sunysb.edu>

Date: Thu, 26 Jan 2006 22:13:39 -0500

To: "Ginsberg, Allen" <AGINSBERG@imc.mitre.org>

Cc: public-rif-wg@w3.org

Message-Id: <20060127031339.2144A207378@kiferdesk.lmc.cs.sunysb.edu>

Date: Thu, 26 Jan 2006 22:13:39 -0500

To: "Ginsberg, Allen" <AGINSBERG@imc.mitre.org>

Cc: public-rif-wg@w3.org

Message-Id: <20060127031339.2144A207378@kiferdesk.lmc.cs.sunysb.edu>

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 http://www.w3.org/2005/rules/wg/wiki/Transaction_Logic. For instance, in FLORA-2, which supports much of Transaction Logic, this Jess rule would look like this: changeBabyIfWet(?Baby) :- wet(?Baby), changeBaby(?Baby), delete{wet(?Baby)}. change(?Baby) can also be defined via a rule as deleting the old diaper and inserting a new one where appropriate. The exact definition depends on how 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 an action (changeBaby(?Baby)), which changes the underlying state by replacing the old diaper with a new one, and then deleting the fact that the specified baby is wet. --michael "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 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 Friday, 27 January 2006 03:13:43 UTC

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