[rules-users] Better way to run each rule once?

[James Owen]

Greetings:

I have watched this thread with interest as person after person had  
another solution.  Perhaps mine would be the simplest.  If we stop to  
think about what IS a rulebase and remember that it is part of the AI  
approach and originally intended to solve extremely complex problems  
then the answer (OK, the answer to me without sufficient information)  
is that this is not a rulebase problem. The whole thing "sounds like"  
a procedural problem where values are modified and rules are fired  
only once.  (Remember - I don't have the whole project requirements  
nor what was really needed in front of me.)  This is not a rulebase  
(think AI, complex) problem at all.  That, together with the  
revelation that there are no Thing objects asserted on the RHS (and  
probably not any objects at all) means that this is not a forward nor  
backward chaining problem.  It is procedural and should have been  
solved with Java, C, C++ or something of that nature.

OK, preaching time is over.  Back to work, Serfs!!  :-)

One last thing.  Considering that the quality of the October Rules  
Fest went WAY up (the best, maybe, since the Dartmouth Conference in  
1956) and the registrations went down, I get the feeling that geeks  
either are not interested in this kind of thing OR that the geeks can  
not get the money to go to a conference.  The money for going to a  
conference seems to go to the Marketing departments and Business  
Analysts, not geeks.  After all, we (the geeks, techies, IT guys,  
whatever the nomenclature is in your particular company) are supposed  
to learn this stuff on our own.  In my opinion, it can be done that  
way with 10 to 15 years devotion to the art and science of AI in  
general and RBS in particular.  Now, all that being said, maybe you  
(the geek) need to take a weeks vacation, spend your own money and  
come to ORF 2009.  It could jolly well be the last one for a while.   
So, like Woodstock, if you missed it, you missed it.  There never was  
another one of the quality and magnitude.  And only those who were  
there could talk about what happened and why it was so totally awesome.

SDG
James Owen
Founder October Rules Fest
Senior Consultant / Architect KBSC
http://www.kbsc.com
http://www.OctoberRulesFest.org
Twitter: OctRulesFest
Blogs:
http://JavaRules.blogspot.com [Rulebased Systems Blog]
http://ORF2009.blogspot.com [October Rules Fest Blog]
http://exscg.blogspot.com/ [Expert Systems Consulting Group Blog]

"If I have seen a little further it is by standing on the shoulders of  
giants."
Sir Isaac Newton in a letter to Robert Hooke, 5 Feb 1676

Come to October Rules Fest and stand on the shoulders of the Giants of  
the industry; if only for a week.



On Oct 9, 2009, at 4:46 PM, Dave Schweisguth wrote:

> Fellow Droolers,
>
> On Fri, Oct 09, 2009 at 09:33:38AM +0100, Anstis, Michael (M.) wrote:
>> From: Dave Schweisguth <dave at schweisguth.org>
>>> Each of our rules modifies the fact it matches. We'd like to run  
>>> each of
>>> those rules exactly once, not reactivating them when a fact changes.
>>> [...]
>>
>> You could look into using a sequential RETE network
>>
>> http://blog.athico.com/2007/07/sequential-rete.html
>>
>> http://www.redhat.com/docs/manuals/jboss/jboss-soa-4.2/html/JBoss_Rules_
>> Manual/ch02s05s10.html
>>
>> But as Greg suggests, better understanding your use-case might  
>> furnish
>> other ideas.
>
> First, SequentialOption seems to be exactly what I was looking for;  
> many
> thanks. I set it and removed my AgendaFilter and my tests all pass,  
> and
> faster.
>
> Nonetheless here's the use case for those interested: My principal  
> facts are
> objects which I'll call Things which have an ID, a bunch of properties
> (unmodifiable fields), and a bunch of named numeric attributes which  
> to keep
> things simple I'll treat as a Map<String, Long>. The goal of the  
> rules is to
> calculate the attributes.
>
> A typical rule looks like
>
>    when thing: Thing(description matches ".*leaves.*")
>    then modify (thing) { attributes.green = 100 }
>
> Clearly one wants a rule like this to run only once. Since in a  
> given rules
> session there are multiple rules like this, no-loop wasn't  
> sufficient; after
> one rule fired it would activate another already-run rule on the  
> same Thing,
> and then vice versa, forever. With all the rules in the same  
> ruleflow group
> lock-on-active was too much in that it allowed only one rule to run.  
> (It
> occurs to me now that I might have made each rule no-loop and run it  
> in a
> new session; fortunately I don't seem to have to try that now.)
> SequentialOption seems to fit this use case perfectly. Of course  
> I'll be
> interested if anyone has a still better way to address it.
>
> Side note: Wolfgang, you were wondering why my AgendaFilter needed the
> Identifiable interface. You can see from the above that if I wanted to
> prevent a rule from firing more than once on the same Thing, I'd  
> need to
> recognize the Thing after the rule fired and its attributes (which  
> affect
> .equals and .hashCode) changed. It occurs to me now that I could  
> just have
> used object identity (==), since rules don't assert new Things. A  
> form of
> equals which considered only Thing's ID would also have been more  
> correct
> than my hashCode-like solution. Fortunately I no longer need this  
> approach
> at all.
>
> Thanks all for your interest and support!
>
> Cheers,
>
> -- 
> | Dave Schweisguth                           http://schweisguth.org/~dave/ 
>  |
> | Home: dave at schweisguth.org            Work: http://www.nileguide.com/ 
>  |
> | For compliance with the NJ Right to Know Act: Contents partially  
> unknown |
> _______________________________________________
> 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/20091009/2594c24c/attachment.html