I'm still not seeing the difficulty. When each fact is asserted,
modified, or retracted, log the fact and the rule that made the
change. Now you have a history of exactly how each fact came to be in
the state it's in. Then when a rule fires, log the facts that
activated it; now you can trace cause and effect back as far as you'd
like.


I think qfhe wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Sorry, I used the wrong terminology. I meant "facts"
> trigger rules, not rules trigger rules.
> 
> Let me rephrase my question a little bit. Suppose
> there are three rules:
> a) (defrule rule1
>       ?fact <- (Test (a 0))
>     =>
>       (modify ?fact (a 1)))
> b) (defrule rule2
>       ?fact <- (Test (b 0))
>     =>
>       (modify ?fact (b 1)))
> c) (defrule rule3
>       ?fact <- (Test (a 1) (b 1))
>     =>
>       (modify ?fact (c 1)))
> 
> The syntax of the above rules may have some problems,
> but let's forget about the syntax and just use the
> example to illustrate the problem.
> 
> At the beginning we have one fact in which the three
> fields a, b, and c are equal to 0. The execution order
> of the above rules will be either a) b) c) or b) a)
> c). Rule c) will be placed in the agenda only when
> both field a and b are set to 1. But an eventing
> mechanism will only capture the last rule that cause
> rule c) to be activated. In this example, if we start
> from c) to trace back, we will only capture either b)
> or a), not both.
> 
> This is a bit confusing but I hope the example helps
> me explain the question.  
> 
> p.s. If the above explanation makes it even more
> confusing, could you comment on Jess's explanation
> capability in general? thanks.
> 
> --- [EMAIL PROTECTED] wrote:
> 
> > Rules don't trigger rules; facts do. You can keep
> > track of what rule
> > asserted (or last modified) every fact, and this
> > gives you the set of
> > rules that contributed to activating each other
> > rule. I really
> > couldn't follow the whole rest of your discussion
> > because it was based
> > on some invalid assumptions.
> > 
> > > When the rule that we're interested in is
> > violated, it is hard to
> > > backward-trace its causes at that time.
> > 
> > If you keep track of what rule asserted what fact,
> > then at any time,
> > working backwards, you can generate an execution
> > trace for any rule
> > that fires.
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 



---------------------------------------------------------
Ernest Friedman-Hill  
Advanced Software 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]
--------------------------------------------------------------------

Reply via email to