JESS: Fw: backward chaining (part 2)

[Sidney Bailin]

Here is some discussion of the backchaining issues recently raised on this list. Hope it's of interest!   Sidney Bailin Knowledge Evolution, Inc.     ----- Original Message ----- From: Hotmail To: Sidney Bailin Sent: Thursday, May 24, 2001 2:37 AM Subject: Re: backward chaining (part 2) Hi Sidney,   Thanks. I'll have a look on that.   BTW: Would you mind making our latest remarks available to the jess list? I think the way you have put things can help others to understand what I mean.   Cheers, Shlomo   ----- Original Message ----- From: Sidney Bailin To: hotmail Sent: Wednesday, May 23, 2001 6:05 PM Subject: Re: backward chaining (part 2) Marc -   Thanks for the info - I must have missed the bit about 'explicit'. So I gather you're saying you wanted (not (foo)) to mean "foo isn't true even after trying to make it true via backchaining"? And in the message at the bottom of this mail, you were saying that Jess did in fact behave that way, by virtue of activating the (need-foo) rule first - but you didn't see where this was guaranteed.   I'd have to agree with you that if the behavior is guaranteed, it should be documented; and if not, then some standard way to achieve what you what, e.g., with salience, would be a good thing.   None of this directly bears on backtracking, but I've attached the generator and a sample input and output file in case it's of use at some point.   Cheers, Sidney ----- Original Message ----- From: hotmail To: Sidney Bailin Sent: Wednesday, May 23, 2001 10:51 AM Subject: Re: backward chaining (part 2)  Hi Sidney,  Thank you for the mail. I was impressed by your work. I have to think a bit about the problems you describe. At some point I was considering using an actual Java implementation of a Prolog engine. I'll happy to see your generator in action. BTW: There is a special conditional element, (explicit), which you can wrap around a pattern to inhibit backwards chaining on an otherwise reactive pattern. I wrote rules like: (do-backward-chaining foo) (defrule r1     (not (foo))     =>     ...) (defrule r2     (need-foo)     (foo1)     =>     (assert (foo))     do something...)   I wanted rule r1 to succeed if (foo1) does not exist. But Jess behaved as if I had written (not (explicit (foo))) and no need-foo was generated, so the rule r2 was not 'backward chained' so to say. (see also my previous messages on the list)   Cheers, Marc Hronec. ----- Original Message ----- From: Sidney Bailin To: Hotmail Sent: Wednesday, May 23, 2001 7:43 AM Subject: Re: backward chaining (part 2) Hi -   I've been having trouble understanding what you want to do, and what you want Jess to do (in particular, I don't understand what you mean when you talk about "not (explicit) xxx"), but since you mentioned Prolog in this message, I though I'd let you know that I've developed an approach to doing backchaining *with backtracking* in Jess. The built-in backchaining in Jess does not do backtracking. Controlling the "rate" of execution and cleaning up "need" facts is a big aspect of this. What I have is a mock-Prolog like language for specifying what one wants, and then a code generator that generates the needed Jess rules. The generated rules do not use built-in Jess backchaining.   I'm attaching a paper that contains the rules (see Section 7). I haven't made the generator available to the mail list because the generated rules are only minimally tested. However, I did post an initial special case, from which I then generalized. I posted it on the mail list sometime last year (in the spring or summer, I think).   I have no idea whether this is what you're looking for, but if it is, I can send you a copy of the generator.   Cheers, Sidney Bailin Knowledge Evolution, Inc.     ----- Original Message ----- From: Hotmail To: [EMAIL PROTECTED] Sent: Wednesday, May 23, 2001 2:26 AM Subject: JESS: backward chaining (part 2) Hi all,    1.      As some of the problems  related to backward chaining that I described earlier turned out to be bugs, although there are possible workarounds, I�d like to ask: could bug fixes/patches be made available even before a next major version release?   (BTW, when is one due?)      Following is a rather lenghty discussion of a few specific issues related to backward chaining in Jess, so if you are not an 'old Prolog fan' that really can't do without it you'd rather want to skip this...;-) Now here are also some interesting side effects , that I found and I�d like to share with you:  2.      Cleaning up the automatically created need-foo facts: I wished there was some build in support for getting rid of these need-xy facts somehow in an organized manner. What is the problem: a.      The most straight forward method would be to retract them in the RHS of  the rule that 'consumes' them. But if the rule does not fire this does not help. If you try to make a global rule for clean up there is another problem: b.      If the need-xy rule fired, and you have a foo fact as a result, so you can�t just collect the need-xy facts in a rule/query since there is a hidden condition inserted by Jess saying (not (foo)) preventing the rule from activation. Ok, so let�s first clean up the foo facts in a separate rule? Unfortunately that doesn�t work either. When you retract the foo fact the hidden (not (foo)) activates the need-xy rule and you are caught in an endless loop!         I solved this by inserting ugly �done� flags in the need-xy rules to prevent them from looping.  3.      Some more about (not (foo)) and backward chaining:         I assumed that this wouldn�t work without using salience. When you check if foo is not there, one reason for it not to be there is obviously, that it is NOT YET there. So the rule containin (not (foo) [r1] gets really activated together with the rule need-foo [r2] that is  producing foo. To my surprise I found that in all cases that I tried the need-foo rule [r2] fired before the rule containing (not (foo)) [r1] deactivating it even without specifying the salience explicitly. Remember that in the current implementation  the �not� CE implies the �explicit� CE. I didn�t succeed to find the proof that it would work always, would it?      Is there an implicit conflict resolution/salience mechanism? This would actually be nice.  4.      a) I�d like to suggest to make it possible to override the default implicit �explicit� CE when using �not� in backward chaining.         b) I think it also makes sense to make it then consistent with the automatic conflict resolution (if any?). That should be enforced only when the �explicit� CE is disabled and you expect it to �backward chain�.   Thanks to all, but especially to Ernest for his really great support for this mail list, Marc