On Aug 26, 2008, at 11:55 AM, Marcin Krol wrote:
I have to say that daisy-chained backward-chaining rules are decidedly
non-trivial (and therefore harder to write and debug), while
forward-chaining rules are very easy to understand (at least for me).
I'm writing about Jess in my thesis on AI techniques, and so I wanted to
ask you a few questions - is backward-chaining is really valuable in
practice, outside of subjects like calling queries to databases (like in
the example you give in "Jess in Action")?
If so, where do you think it is most useful? Are there any problems that
are awkward to code using forward-chaining while they are more natural
to code using backward-chaining rules?
I think the most important applications have been the query-like ones. There
are certainly
plenty of techniques that work well with classical backward-chaining rules,
but really can't be
implemented using Jess's restricted form of backward chaining
.
How do you think backward-chaining adds to the expressive power of Jess
understood as language? Is it worth the effort, both for rule engine
developer and for the rule engine user?
I think it *could* add tremendously to the expressiveness of the language if
it were carried
further. There are a lot of problems that can be expressed elegantly with
backtracking, for example.
There have been some user-modified versions of Jess that implement
backtracking concepts, but none of them
in an elegant way, AFAIK. Right now I think the truth is that beyond the
query-like applications (which are
equivalent in many ways to "finders" in JRules), Jess's backward chaining
hasn't seen widespread use.
I have sort of stumbled on one limitation of backward-chaining in Jess:
constraints on slots, I found I couldn't call a function on slot:
Jess> Jess reported an error in routine ReteCompiler.addRule.
Message: Can't use funcalls in backchained patterns __data.
Is there a way around that? Or am I misunderstanding the problem,
because one perhaps doesn't want to constrain slots in backward-chained
rules as finding their values is the goal of this part of rule engine
operation (as constraints would simply prevent firing one of b-c rules
in the chain of reasoning in some cases, like it happened in my
uncorrected example)?
There's no way around it in the current version of Jess. As you know, goals
are represented
as regular facts, and stored in regular working memory. For anything other
than literal constraints to
be usable in goals, there would need to be a way of representing the
constraint in the fact itself, and
storing that representation in working memory. While not impossible to
implement, this would impact many parts
of the Jess codebase.
Another approach would be to store goals not in working memory, but in a
different
structure altogether, one designed from the beginning to accommodate their
requirements.
In retrospect this is probably how Jess's backward chaining should have been
implemented
in the first place.
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences, Sandia National Laboratories
PO Box 969, MS 9012, Livermore, CA 94550
http://www.jessrules.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]
