[rules-users] Misunderstanding salience?
Wolfgang Laun
wolfgang.laun at gmail.com
Thu Mar 10 02:36:27 EST 2011
Hello Peter,
Perhaps I'm overly apprehensive, but I feel compelled to throw in a word of
warning concerning the idea of creating high salience rules for "special
cases" so as to avoid using a full set of constraints for clear separation
of the "symptom sets". Assuming (for the moment) that all symptoms are
booleans, let's say that we have to deal separately with the special cases
s1&&s2 as opposed to s1&&s2&&s3, s1, and s2. Clearly, you cannot have them
all at the same salience level. Given that this is realistic:
- Will your "clinical content experts" be able to assign the correct set
of salience values?
- Who will validate this, and how?
Also, what if none of the "special" rules fires so that the "general case"
kicks in but there is a set of deviations from the norm, hitherto
unobserved?
Clearly, adding all the negatives is tedious work, but that's what code
generators are there for. Using decision tables with suitable defaults would
be one way of dealing with this. I'd even investigate the implementation of
a special decision table parser/compiler for this use case.
-W
2011/3/9 Peter Ashford <petera at bestpractice.org.nz>
> Ok, thanks. I can see how asserting a control fact would work here – I
> only asked about a terminate option to be able to avoid having to check for
> the absence of the control fact in every rule, but that’s fine if that’s
> what I have to do.
>
>
>
> Thank s everyone for the help – it’s been excellent and very instructive
> :o)
>
>
>
> p.s.: No, I don’t use RuleFlow or jBPM. We’re writing DRL’s by hand and
> it’s our expectation that we will have clinical content experts using Guvnor
> to author rules once we’ve got our new system up and running. At this point
> I’m just trying to establish what best practice for our domain ought to be.
>
>
>
> Peter.
>
>
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Michael Anstis
> *Sent:* Thursday, 10 March 2011 10:45 a.m.
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Misunderstanding salience?
>
>
>
> I don't suppose you (Peter) use RuleFlow or jBPM?
>
> If not then remember rules' patterns are matched as facts are inserted into
> WM. The resulting activations are ordered by controlling semantics such as
> salience, no-loop, lock-on-active etc. Therefore should higher salience
> rules activations (that will be executed first) alter the state of WM lower
> salience rules' activations could be removed (by the presence of the control
> fact or non-null "advice" depending on what approach you take) and hence not
> be candidate for execution.
>
> This is why, IMO, people talk about considering all rules executing in
> parallel rather than sequentially.
>
> If you're using jBPM then fail-fast is an option, but not something I know
> much about.
>
> Cheers,
>
> Mike
>
> 2011/3/9 Greg Barton <greg_barton at yahoo.com>
>
> "Control facts" is a term for objects in working memory that are not
> directly derived from outside data, or used as output. As their name
> implies, they're used to explicitly control flow of the rules.
>
> --- On *Wed, 3/9/11, Peter Ashford <petera at bestpractice.org.nz>* wrote:
>
>
> From: Peter Ashford <petera at bestpractice.org.nz>
>
>
> Subject: Re: [rules-users] Misunderstanding salience?
>
> To: "Rules Users List" <rules-users at lists.jboss.org>
> Date: Wednesday, March 9, 2011, 2:54 PM
>
>
>
> Working with Zombies? No... although some of our clients....
>
>
>
> A wrinkle we have is that sometimes an exception case should terminate the
> decision. Usually that’s an emergency case and it will be something like
> “this patient needs to be admitted to hospital immediately”. In other
> cases, we want to provide some advice which a clinician may or may not
> choose to heed. It sounds to me that the insertLogical mechanism might well
> work for those latter cases (was this what you were referring to when you
> talked about ‘control facts’?) In the other case – an emergency when you
> need to give one element of critical advice then quit – is there an option
> to terminate the rules immediately and return the current result?
>
>
>
> Peter
>
>
>
>
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Swindells, Thomas
> *Sent:* Wednesday, 9 March 2011 10:23 p.m.
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Misunderstanding salience?
>
>
>
> I don’t think you even need it that complicated.
>
> Just have your constraints in the form
>
> Patient(advice == null, ...)
>
>
>
> This assumes you only give the patient one advice at a time – if not
> control facts would have to be the way to go.
>
>
>
> You also need to make sure you actually tell the rule engine you have
> modified the patient when you set their advice – you need to wrap the call
> with a modify(p) {...}.
>
>
>
> Hope you get your zombies under control soon,
>
>
>
> Thomas
>
>
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Michael Anstis
> *Sent:* 09 March 2011 07:58
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Misunderstanding salience?
>
>
>
> You had me fooled Peter, I thought you worked in a zombie related field ;-)
>
> Control Facts can also be used, which I think David eluded to with his use
> of "null advice", such that:-
>
> *rule* "General brain eating advice"
>
> *when*
>
> p : Patient(eatsBrains == *true*)
>
> not Diagnosis( patient == $p )
>
> *then*
>
> p.setAdvice("Stop eating brains, or at least, try to cut
> down");
>
> insertLogical( new Diagnosis( $p ) );
>
> *end*
>
>
>
> *rule* "Zombie exception to brain eating advice"
>
> *salience* -50
>
> *when*
>
> p : Patient(eatsBrains == *true*, isZombie == *true*)
>
> not Diagnosis( patient == $p )
>
> *then*
>
> p.setAdvice("Evidence suggests that the undead cannot
> contract Kuru or that the effects are irellevant given the " +
>
> "patient's current zombified state.\nSuggest
> euthenasing patient lest he/she eat your (or someone " +
>
> "else's) brains");
>
> insertLogical( new Diagnosis( $p ) );
>
>
>
> *end*
>
> As David states, more specific rules should have higher salience than the
> more general that should have lower. Salience controls conflict resolution,
> which is the order in which activations on the agenda are evaluated, it does
> not control which rules are evaluated - which happens as facts are inserted
> into working memory and not when fireAllRules( ) invoked.
>
> With kind regards,
>
> Mike
>
> 2011/3/9 Peter Ashford <petera at bestpractice.org.nz<http://mc/compose?to=petera@bestpractice.org.nz>
> >
>
> Thanks for the ideas, David.
>
>
>
> What I ultimately want to achieve is to have the individual rules
> independent of each other to the maximal degree to which that is possible.
> That’s why I didn’ t want to have isZombie==false in the general rule – I
> wanted the general case to be unaware of the exceptions. The field in which
> I’m working is clinical decision support where there might be a number of
> exceptions and corner cases. I’d like to be able to express the core logic
> without reference to the corner cases and then deal with the exceptions
> separately.
>
>
>
> I think your idea of using salience but only adding advice if it hasn’t
> already been given fits the bill – that way the general case can be simple
> and not have to explicitly exclude all the exception cases.
>
>
>
> Thanks very much for the feedback – it’s really valuable to get an idea
> about what options are available and what’s considered best practice.
>
>
>
> Cheers!
>
>
>
> Peter.
>
>
>
>
>
> *From:* rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>[mailto:
> rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>]
> *On Behalf Of *David Faulkner
> *Sent:* Wednesday, 9 March 2011 4:51 p.m.
>
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Misunderstanding salience?
>
>
>
> Peter,
>
>
>
> The EXACT way to accomplish the functionality that you are looking for is
> “activation-group”; if two rules are in the same activation group, only one
> of them will fire. Note that the rule with HIGHER salience will fire first;
> to accomplish what you are looking for you’d have to give the exception rule
> a higher salience.
>
>
>
> I would also note that although there are specific instances where
> activation-group has a strong need, many in the community find that the most
> power and flexibility from the rule engine comes from “letting go” of trying
> to exactly order your rule execution, and instead letting the rule engine
> decide what would happen here. One way to accomplish this in your case would
> be to simply add (isZombie == false) to your constraint on the general rule.
> Another way that involves salience but NOT agenda groups is to set a high
> salience on your exception rule, but only add advice if advice is null. The
> possibilities are endless.
>
>
>
> With kind regards,
>
> David Faulkner
>
> david.faulkner at amentra.com<http://mc/compose?to=david.faulkner@amentra.com>
>
>
>
> *From:* rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>[mailto:
> rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>]
> *On Behalf Of *Peter Ashford
> *Sent:* Wednesday, March 09, 2011 7:24 AM
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Misunderstanding salience?
>
>
>
> Actually, I think I’ve figured this one out : in the Zombie case, it’s
> firing both rules and it’s just that with the negative salience, the zombie
> exception rule is the last rule fired, therefore, the last thing written
> into advice.
>
>
>
> So... what would be the correct way to do what I’m trying to do here? The
> idea is that the Zombie exception rule should fire in preference to the
> general rule and that none of the general processing should occur at all
> (imaging that these rules had side-effects for the rest of the system
> they’re attached to, we don’t want all the general rule side effects to
> apply and then all the exception case side effects)
>
>
>
> Thanks in advance!
>
>
>
> Peter.
>
>
>
> *From:* rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>[mailto:
> rules-users-bounces at lists.jboss.org<http://mc/compose?to=rules-users-bounces@lists.jboss.org>]
> *On Behalf Of *Peter Ashford
> *Sent:* Wednesday, 9 March 2011 1:31 p.m.
> *To:* rules-users at lists.jboss.org<http://mc/compose?to=rules-users@lists.jboss.org>
> *Subject:* [rules-users] Misunderstanding salience?
>
>
>
> Hi There
>
>
>
> I’m new to drools. I’ve just set up the Drools-Server and it is (finally!)
> working and serving my test rule-set. The one thing that’s not working as I
> expect it is the rule ordering via salience. This is my simple test rule
> set:
>
>
>
> *rule* "General brain eating advice"
>
> *when*
>
> p : Patient(eatsBrains == *true*)
>
> *then*
>
> p.setAdvice("Stop eating brains, or at least, try to cut
> down");
>
> *end*
>
>
>
> *rule* "Zombie exception to brain eating advice"
>
> *salience* -50
>
> *when*
>
> p : Patient(eatsBrains == *true*, isZombie == *true*)
>
> *then*
>
> p.setAdvice("Evidence suggests that the undead cannot
> contract Kuru or that the effects are irellevant given the " +
>
> "patient's current zombified state.\nSuggest
> euthenasing patient lest he/she eat your (or someone " +
>
> "else's) brains");
>
> *end*
>
>
>
>
>
> The idea is that the first rule fires all the time unless the patient
> happens to be a zombie, in which case the exception rule (the second rule)
> kicks in. Now, as I have it here, with the exception at salience at -50 it
> actually works, which is the opposite of what I was expecting. I’d thought
> that I would have had to have the exception at a higher salience to fire
> first. That was what I tried first but that didn’t work – everyone got the
> general advice, zombies included.
>
>
>
> What am I misunderstanding here?
>
>
>
> Thanks!
>
>
>
> Peter.
>
>
>
> ---
>
> “It is very difficult to get a man to understand something when his tribal
> identity depends on his not understanding it” - Michael Bérubé on
> Republican climate change denial.
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<http://mc/compose?to=rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> ------------------------------
>
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster at nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes. To protect the environment please do not
> print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
> 4EX, United Kingdom. A company registered in England and Wales. Registered
> no. 3080780. VAT no. GB 603 8808 40-00
>
> **************************************************************************************
>
>
>
> -----Inline Attachment Follows-----
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org<http://mc/compose?to=rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110310/9cfc0880/attachment.html
More information about the rules-users
mailing list