FYI, the term "refraction" is traditional for the act of removing an activation of a rule from the conflict set upon its execution.
Paul Haley President & CEO The Haley Enterprise, Inc. http://www.haley.com (412) 741-6420 Solutions that do what they're told. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 05, 2003 12:57 PM > To: [EMAIL PROTECTED] > Subject: Re: JESS: Proposed feature > > > I think James C. Owen wrote: > > Ernest: > > > > Let me see if I can understand what we're actually saying here: As > > written below, since ?fact is being modified in the RHS of the rule > > then the rule will be placed on the agenda as available to be fired > > again, even though the recursion principle would otherwise have > > removed the rule from consideration.. This is basically the > > data-driven concept of almost all Rete-type rulebased > systems and some > > that are not Rete-based. In fact, the rule will be removed > (via the > > recursion principle) from the agenda and never be replaced > if the rule > > fires and the data are NOT changed. Recursion is the first rule of > > conflict resolution of both LEX and MEA and is used by, well, > > everybody who builds a rulebased system of any kind of > merit. (Jess, > > JRules, OPSJ, JEOPS, Advisor, Expert, ART, etc., etc.) > > That's right. The current behavior in all cases is that a > rule won't fire on a given set of unchanged facts more than once. > > > > > So. Now. Are we asking that this should be changed so that if the > > rules are slot-driven rather than data-driven,? Meaning > that the rule > > will be removed if the rule, regardless of data, fires? If so, it > > can't work because then only one case would match. i.e., > we would be > > asking the question, "Is there ANY case" and when the case > is answered > > true then the engine stops. > > No, not quite. The proposal is for a new, special class of > rules that will fire no more than once for a given set of > facts, regardless of whether their slot data changes. > Currently, modifying any slot in a fact on a rule's RHS will > make the LHS match again. Under this proposal, this wouldn't > happen for this special class of rules. > > In classical expert systems, facts were just tuples, without > their own independent existence. In Jess, a fact is a lot > more like an Object, and it persists over time. Note that in > OPS-derived systems, where each fact has a numeric id, that > id traditionally changed when a fact was modified. In Jess, > the id -doesn't- change, highlighting the Object-ness of a fact. > > In a way, there are two different ways to think about Jess > rules. You can be matching a fact with particular slot data, > or you can be matching a particular fact object. The latter > class of rules can sensibly be expected to match a given fact > (or set of facts) only once; that's the class of rules for > which the "one-shot" idea is useful. > > > --------------------------------------------------------- > 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] --------------------------------------------------------------------
