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

  On 18/01/2010 14:43, Christian De Sainte Marie wrote:
>
> 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:
On the issue of "refraction", Drools works like Jess and Clips - none of 
us implement it. The OPS5 manual on refraction:
http://www.math-cs.gordon.edu/courses/cs323/OPS5/ops5.html

     REFRACTION

         This term comes from the neurobiological observation of a/refractory
         period/  for a neuron, which means that the neuron is not able to fire
         immediately without first going through a relaxation process.  In a
         similar way, OPS5 will not allow the same instantiation in the conflict
         set from firing twice in a row.  This prevents the inference engine from
         entering into an infinite loop.

>
> 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.
Jess + Clips + Drools 4.0/5.0 a modify is a retract+assert. Drools 5.1 
does modify as a single propagation through the network.

However my experience is that except for TMS and agenda events 
(activation created, cancelled and modified) retract+assert can still be 
treated as "atomic", as the result is the same. The only time this is 
noticable is on TMS where the modify's retrat can cause a justification 
to be removed and thus a logical insertion to be retracted, when after 
the assert part of the modify the justification would still be backed.

Except TMS I don't believe the spec should care whether a modify is a 
single propagation or a retract+assert. I think what is important is 
that the modify action is accompanied by the fields changed; which is 
necessary for the implementation of 'slot-specific' and also for other 
engine optimisations. It is possible for a retract+assert modify to 
"mask" itself and emit correct agenda events and stop the justification 
being removed.
>
> 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;
Are we talking identity equal or content equals of those facts? i.e. the 
same set of time stamps or actually the same field values? In java that 
would be == versus equals().

Refraction typically is the set of timestamps
>  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 EUR
> SIREN/SIRET : 552 118 465 03644
>