Re: JESS: Using a rule engine for plan recognition

[Jonathan Sewall]

Back to a month-old topic, herewith some more information.  Back then I asked   1) whether others have suggestions for implementing backtracking in Jess and   2) whether it would be appropriate to make Activation.setInactive() public. Thanks again for your replies so far.  Anyone who reads all the rest of this has my sympathies. Jonathan Sewall __________________ Our application is a toolkit for writing intelligent  tutoring systems.  Our users are tutor authors who   1) create a student interface that exposes the individual steps in the task to be tutored, and then   2) write rules in Jess to model the individual steps or substeps in the task and check whether a student entry matches a step. That is, authors write a cognitive model that will simulate a human tutor looking over the student's shoulder at runtime.  When the student enters a value on the interface (that is, attempts a step in the task), our toolkit runs a depth-limited search that fires rules to generate the proper next steps until it either finds the student's entry or gives up and calls the entry incorrect. We have a depth-limited search because a logical chain of several rules is often needed to model a single step, and typically the student's entry can't be fully checked until the last rule in the chain.  We inherit this depth-limited search and style of rule-writing from a previous production rule system we used for tutors: we are trying to replace that system with Jess.  Each activation is a node in the search tree; each rule firing deepens the search by one level.  The new activations triggered by a single firing are the activation's child nodes, each representing an alternative path in the search space--that is, an alternative possible path toward finding the student's entry.  For reasons that have to do with the capability to generate hints (that is, to formulate an answer when the student asks "what do I do next?" instead of attempting a step), our authors check the student input on the RHS side of their rules, not on the LHS.  Hence when a path ends with failure to match the student input, we backtrack to try an alternative path.  We currently use (bsave) and (bload) for backtracking, but we ask whether there are faster alternatives.  We use Activation.setInactive() to explore sibling paths upon backtracking. To make this concrete, here is a trace of what our algorithm does now for a simple task:  the rules are from a tutor for multicolumn addition for a child.  Each step in the task is to write a single digit of the sum (in the ones, tens, ... place) or to write a carry digit.  The author intends to permit the student to write a sum digit or a carry digit in either order.  This fine-grained cognitive model uses several substeps for each step:  it first fires a rule to choose the next column (ones, tens, ...) of digits to work on, then a rule to add the digits in that column, then a rule to determine whether a carry is needed,.then either a rule to actually write the carry digit or to write the sum digit.  At the substep where the model must determine whether a carry is needed, we have (bold insertions are comments): Jess> (agenda) [Activation: MAIN::must-carry :  f-39, f-40,,, f-37, f-38, f-32, f-4 ; time=47 ; salience=0] Jess> (run 1) 1 Jess> (agenda)  ; must-carry found a carry needed, so activates both write-carry and write-sum [Activation: MAIN::write-carry  f-39, f-42, f-32, f-28, f-38, f-37, f-36, f-4 ; time=57 ; salience=0] [Activation: MAIN::write-sum  f-39, f-40,, f-37, f-36, f-4 ; time=57 ; salience=0] For a total of 2 activations in module MAIN. Jess> (bsave before-write.rete)  ;  2 activations created,  so bsave to permit  backtracking TRUE Jess> (run 1) ;  run the write-carry activation 1 Jess> (bload before-write.rete)  ;  found that write-carry fails to match student's input, so backtrack TRUE Jess> (agenda)  ; now must search alternative path by firing write-sum, not write-carry [Activation: MAIN::write-carry  f-39, f-42, f-32, f-28, f-38, f-37, f-36, f-4 ; time=57 ; salience=0] [Activation: MAIN::write-sum  f-39, f-40,, f-37, f-36, f-4 ; time=57 ; salience=0] For a total of 2 activations in module MAIN. Jess> (bind ?it (call (engine) listActivations))  ; use Activation.setInactive() to skip write-carry <Java-Object:jess.HeapPriorityQueue$1>  ; (see next several steps) Jess> (bind ?wc (call ?it next)) <Java-Object:jess.Activation> Jess> (call jess.JessPrivateAccess setActivationInactive ?wc) Jess> (agenda) [Activation: MAIN::write-sum  f-39, f-40,, f-37, f-36, f-4 ; time=57 ; salience=0] For a total of 1 activations in module MAIN. Jess> (run 1)  ; now fire write-sum 1 Jess> (agenda) [Activation: MAIN::write-carry  f-39, f-42, f-32, f-28, f-38, f-37, f-36, f-4 ; time=64 ; salience=0] For a total of 1 activations in module MAIN. Jess> (run 1) 1 [EMAIL PROTECTED] wrote: I think Jonathan Sewall wrote: 1. I'd be interested in others' experience with this use of Jess, esp. strategies for backtracking. 2. I'd ask that jess.Activation.setInactive(boolean) be made public. We currently use selective firing of Activation instances from the agenda. For that I employ Rete.run(1) to fire one Activation at a time and Activation.setInactive() to deactivate those agenda entries listed prior to the one I want to fire at a given point. I haven't figured out how to fit my selection process into the way I think a Strategy implementation would work. I'd rather use only the public API to Jess, but I have to put in a package-private class to give me access to Activation.setInactive(). Although I wouldn't word my response as strongly as Martijn's, I have similar concerns. At the very least, I'm interested to hear about the logic that chooses which activations to fire, and why it's outside the rule engine proper, rather than being implemented as part of the rulebase. Can you describe in a little more detail what you're doing? --------------------------------------------------------- Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- 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]. --------------------------------------------------------------------