[PRD] Rule instances, refraction and Modify [Was: Re: Fwd: Clips behavior]

All,

Gary and Neal are right: the specification of refraction in PRD is wrong.

I propose that we have a PRD TF telecon tomorrow to discuss the changes 
needed. Here below are the results of my analysis of the problem, and a 
proposed solution.

I made some testing with CLIPS and JRules, on the assumption that what 
worked for CLIPS would work for almost any other engine (and, esp., on the 
assumption that Jess and Oracle --and, maybe, Tibco-- would work like 
CLIPS, whereas Drools, Blaze etc would work like JRules) and I identified 
three problems with the PRD spec:

1. Refraction and recency should depend on the state changes that result 
from atomic actions, not on the state changes that result from action 
blocks: that means that we need to take intermediate states of the fact 
base into account. The definition of a state of the system will need be 
changed accordingly, but, apart from that, the semantics remains 
unchanged. Stretching it a little bit, we could consider that this is not 
such a substantial change (and, thus, no need to get back to LC).

2. in CLIPS, the Modify is, really, a Retract followed by an Assert, in 
the sense that it remove the modified fact from the RETE, and add it back 
after modification: that means that we cannot have, in PRD, a Modify that 
does not retract, then insert a new fact, with all the consequences on the 
agenda, if we want CLIPS and the engines that work the same way to be able 
to implement PRD.

That point is not really a problem, as far as regards CR etc, because 
this, is, really, what the spec says it does, already. My suggestion is 
that we, only, make the fact that Modify = Retract+Assert more explicit, 
in PRD (if only because this is not what the spec was intended to say :-). 
 [1]

It is more of a problem for implementation in object-oriented engines, 
such as JRules, because it makes Frames even more inappropriate to 
represent objects, but this is a different question (the problem is really 
with retracting a field value without retracting the object instance; that 
could be, at least, simulated as long as the value of the field could be 
modified without a Retract; that will not be the case anymore).

Notice that it follows that the Modify_noloop test case cannot work, 
existential variables or else: my best suggestion is to remove it (the 
test case); but this has no incidence on the status of the PRD spec wrt 
CR, LC etc.

3. the binding of the rule (universal) variables is not always 
discriminant enough to characterize a rule instance. That is, it does not 
allow to decide, in all cases, whether two instances of a rule are equal 
or not: in the following example, the rule should have two different 
instances, for the conflict resolution algo, but the binding of the unique 
rule variable is not enough to distinguish them:
   Rule: FORALL ?x, IF test(?x) AND ( foo(1) OR bar(B) ) THEN...
   Facts: (test a), (foo 1), (bar B)
That shows that the characterization of a rule instance, in PRD, should 
take the facts that matched the condition into account, not only the 
binding of the rule variables (at least, I found no other way to take this 
kind of cases into account).

My proposal is:
 a. to modify the definition of a rule instance [2], to add the definition 
of the matchedFacts, where matchedFacts(ri) is a set of ground facts that 
is associated to a rule instance ri;
 b. to change the definition of rule instance equality to add that the set 
of the matchedFacts must be equal as well;
 c. to modify the definition of a matching rule instance [3], to add the 
condition that matchedFacts(ri) must be a minimal subset of the matched 
state of facts, such that ri matches matchedFacts(ri) if all the 
existential formulas in the condition and patterns in rule(ri) are 
replaced with TRUE. The reason why we need not keep track of the facts 
that match the existential parts in a rule, is that which specific facts 
matched the existential parts of a rule does not make a difference wrt 
refraction (at least with CLIPS and JRules, but that also makes sense wrt 
intuition and the basic working of a RETE), and  the existing definition 
of a matching rule instance guarantees already that they are matched.

That modification in the spec does not change anything wrt to the current 
characterization of rule instance (in terms of the bindings of the 
universal variables), except when there are different possible sets of 
matching facts for the same binding, which, as far as I can see [4], 
happens only when the (non-existential part of the) condition contains a 
disjunction where different terms match different ground facts for the 
same bindings (e.g. the example above, or "test(?x ?y) AND (foo(?x) OR 
bar(?y)), etc).

We can, therefore, consider that this is not a substantial change either: 
only that we complete our definition to take care of a corner case that we 
did not think of initially.

Of course, the catch is that the conjunction of change 1 and 3 modifies 
the behaviour of the conflict resolution quite significantly...

I started modifying the spec tentatively along these lines, in case we 
would agree that the proposed changes are needed, and that they are 
correct.

Can we have a PRD task force meeting tomorrow at the usual time (after the 
RIF telecon) to discuss them?

[1]  Btw, another point where we might want to be more explicit is wrt the 
unicity of facts: can we have twice the same fact? That is, what happens 
if one asserts twice the same fact, and then retract it once: would a 
condition testing the fact still be true, or not? The current spec 
strongly suggests that this is not the case (that is, a fact cannot be 
duplicated), and this is how CLIPS works: shall we clarify the spec in 
this sense?
[2] http://www.w3.org/TR/rif-prd/#def-rule-instance
[3] http://www.w3.org/TR/rif-prd/#def-matching-rule-instance
[4] that is, if there cannot be multiple instances of the same fact at the 
same time in the working memory

Cheers,

Christian

IBM
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10




From:
Gary Hallmark <gary.hallmark@oracle.com>
To:
RIF WG <public-rif-wg@w3.org>, Neal Wyse <neal.wyse@oracle.com>
Date:
25/11/2009 17:15
Subject:
Fwd: Clips behavior
Sent by:
public-rif-wg-request@w3.org



A colleague and I have tested OBR, Jess, and Clips refraction behavior. 
All are consistent. All contradict PRD. I do not think the issue is 
whether actions are effective immediately, although there may also be 
issues with that. Rather, the issue ssems to be that PRD should consider 
all rule vars in the IF part, even existential vars, as part of the rule 
instance. Thus far, I have only heard that ILOG works like PRD says, and I 
haven't actually seen a test report verifying that.

-------- Original Message --------
Subject: Clips behavior
From: Neal Wyse <neal.wyse@oracle.com>
To: Gary Hallmark <Gary.Hallmark@oracle.com>
CC: null

Hi Gary,

I've attached 3 Clips examples.
rif1.clp - Modify_loop test
rif2.clp, rif3.clp - two approaches to the Modify_noloop test
They all loop with Clips which is what I expected.
I'm not sure if we can get closer than that for the noloop test.

Neal
(deftemplate foo
    (slot count)
)

(defrule r3
 (and
   ?f1 <- (foo (count ?c))
   (not (not (test (> ?c 0))))
 )
 =>
 (modify ?f1 (count (- ?c 1)))
 (printout t (str-cat "r3 fired: ") ?c crlf)
)

(assert (foo (count 10)))
(run)
(deftemplate foo
    (slot count)
)

(defrule r1
   ?f1 <- (foo (count ?c&:(> ?c 0)))
 =>
 (modify ?f1 (count (- ?c 1)))
 (printout t (str-cat "r1 fired: ") ?c crlf)
)

(assert (foo (count 10)))
(run)
(deftemplate foo
    (slot count)
)

(defrule r2
 (and
   ?f1 <- (foo)
   (not (and  (foo (count ?c))
      (test (not (> ?c 0))))
   )
 )
 =>
 (bind ?cnt (fact-slot-value ?f1 count))
 ;(modify ?f1 (count (- (fact-slot-value ?f1 count) 1)))
 (modify ?f1 (count (- ?cnt 1)))
 (printout t (str-cat "r2 fired: ") ?cnt crlf)
)

(assert (foo (count 10)))
(run)




Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siege Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 611.451.766,20 ?
SIREN/SIRET : 552 118 465 03644