6:28 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users