Ernest:
Sorry for taking so long to get back to you and the group but I've been
really busy the past few days. After reading your description below,
perhaps we're in agreement. My knowledge of OPS-5 comes from
(basically) two books on the subject: "Rule-Based Programming with
OPS5" by Cooper and Wogrin and "Programming Expert Systems in OPS5" by
Brownston et. al. Both are quite old but they both include refraction
as the first step in conflict resolution.
By definition, refraction means a rule = logic + data, where data is the
objects on which the rule works. If a single datum is changed, then the
rule has changed, or, better yet, it is a new rule since the rule and
data have changed. Since the refraction part of the engine usually does
not know what to do when a datum changes, it re-examines the rule. Now,
if the data are re-set to a previous refracted condition (as shown
below) I'm not exactly sure what happens. I think what I have outlined
below is correct but I'll have to check it later. (Theory is probably
OK. Depending on the implementation.)
One other thing: Different engines handle conflict resolution
differently but most of them follow MEA or LEX, both of which use
refraction as the first item in resolving conflicts. Now, once the data
are updated, the engine must be aware of the change; which is where you
use either an update or modify command, again depending on the engine
being used.
Considering refraction; after (or during) a change to a datum, there
should be an update or modify command that does this change. A poorly
designed ruleset might be as follows:
Rule Set:
-------------------
Rule One:
If getA() == 2 and getB() == 3
then X is true.
Rule Two:
If getA() == 2
then setA(3)
Rule Three:
If getA() == 3 and getB() == 2
then Y is true
and setA(2)
and setB(3)
Rule Four:
If getB() == 3
Then setB(2)
-------- what happens ---------------
Cycle 1: Engine determines A == 2 and B == 3
Rule One is eligible to fire.
Rule Two is eligible to fire.
Rule Four is eligible to fire.
Rule One has more Condition Elements than Rule Two or Rule Four.
Rule One fires, sets X to true and it is then removed by refraction.
Cycle 2:
Rule Two is eligible to fire.
Rule Four is eligible to fire.
Rule Two appears first in list and is selected on that basis.
Rule Two fires, sets A to 3 and is removed by refraction.
Cycle 3:
Engine notes that Datum A has changed.
Rule One and Rule Three are re-examined for eligibility to fire.
Rule Four is Eligible to fire.
Rule Four fires, sets B to 2 and is removed by refraction.
Cycle 3:
Engine notes that Datum B has changed.
Rule One and Rule Three are re-examined for eligibility to fire.
Rule Three is eligible to fire.
Rule Three fires,
Sets Y to true
Sets A to 2
Sets B to 3
And is removed by refraction.
Cycle 4:
Engine notes that datum A and datum B have both changed.
Rule One, Rule Two, Rule Three and Rule Four are all re-examined.
Rule One is eligible to fire.
Rule Two is eligible to fire.
Rule Four is eligible to fire.
Time Stamp on B is more recent than A.
Rule One and Rule Four both use element B => either can fire first.
Rule One has more Condition Elements than Four => Rule One has
precedence.
Rule One fires, sets X to true and is removed by refraction.
Cycle 5:
No datum changes.
Rule Two is eligible to fire.
Rule Four is eligible to fire.
Time Stamp on B is more recent than A.
Rule Four fires, sets B to 2 and is removed by refraction.
Cycle 6:
Engine notes that Datum B has changed.
Rules One, Two and Three are re-examined for eligibility because of B.
Rule Two is eligible to fire.
Rule Two will fire, sets A to 3 and is removed by refraction.
Cycle 7:
Engine notes that datum A has changed.
Rules One, Three and Four are re-examined for eligibility because of A.
Rule Three is again eligible to fire because of A and B.
Rule Three fires and start the sequence all over again at Cycle 3b.
--------------------------------------------------------
SDG
jco
James C. Owen
Senior Knowledgebase Consultant
6314 Kelly Circle
Garland, TX 75044
972.530.2895
214.684.5272 (cell)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: Monday, June 16, 2003 6:06 PM
To: [EMAIL PROTECTED]
Subject: Re: JESS: Refraction
I think James Owen wrote:
>
> Hmmm... This is something that I had not realized until now.
However,
> section 2.8.1.3 of the Jess manual explains that there are two
available
> conflict resolution strategies, basically LIFO and FIFO. Refraction,
> MEA and/or LEX are not discussed. Only breadth and depth strategies,
> along with salience (sometimes called priority in other systems) are
> discussed.
Hmmm. Thinking of refraction as being part of conflict resolution is
rather different than my viewpoint. In any event, yes, there are other
ways of dealing with refraction that are different than what Jess
does. We've discussed all this before, though. Note that Jess's
default behavior is the same as CLIPS', and also the same as the
default for OPS5 and other similar Rete-based systems. Whether the
default is different for other products, I can't personally say.
>
> One last thing: I took the survey indicated without reading the line
> below that says (or seems to indicate) that "per slot activation" is
the
> same thing as "refraction" - Maybe I'm dense (Shut up Richard! You too
> Joe!) but I can't see the relationship between "per slot activation"
and
> refraction as a means of conflict resolution.
>
The behavior that people want, that Jess doesn't offer currently, is
this: Let's say deftemplate A has slots X, Y, and Z. Now, let's say
that there's a rule that matches some value in slot X. There's a fact,
fact-1, which matches the rule nd the rule fires. Now, something
modifies slot Y of fact-1. In Jess, the rule can now be matched and
fired again (CLIPS behaves precisely the same way using the default
conflict resolution strategy -- If changing the strategy changes this
behavior, I was not aware of this.) If fact-1 were never modified,
then the rule would not fire again. The behavior people have asked
for, as I understand it, is that only changes in the slot being
matched may allow the rule to re-fire; changes in other slots would
have no effect.
What you're describing is slightly different, really. There, changes
in any slot would not cause the rule to re-fire until the match that
was fired has been removed entirely -- i.e., X were modified such that
it would not match -- and then reinstated -- i.e., modified so that it
matched again. I can see where this would probably be even more
useful. I can also see where the record-keeping required to do this
would increase the memory usage and decrease the performance of the
engine -- and I can easily think of pathological cases where the
memory usage would tend to infinity. So this would make a bad default
behavior -- but could be available as an option.
Anyway, that's why this is called "single-slot activations," because
changes in unmatched slots are immaterial.
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify
[EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
