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
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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users