Re: JESS: Using a rule engine for plan recognition

2006-02-14 Thread 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
  ; (see next several
steps)
Jess> (bind ?wc (call ?it next))

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

Re: JESS: Using a rule engine for plan recognition

2006-01-13 Thread ejfried
I think Jonathan Sewall wrote:
> 
> 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 LabsFAX:   (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]




RE: JESS: Using a rule engine for plan recognition

2006-01-13 Thread Martijn Tromm
Actually, by selecting the activations that you want to fire yourself
makes a rule-engine useless. If you can solve your problem
algorithmically then you don't need a rule-engine. By letting the
rule-engine decide what order to impose on the rule firings you can
dynamically build the search tree. You just have to state the rules that
make up the selection criteria in the selection process. So do not
follow the process but formulate the knowledge that is used in the
process.
I hope this helps. I am not exactly sure what you mean by
plan-recognition. In what context are you doing this?

Cheers,
Martijn


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jonathan Sewall
Sent: donderdag 12 januari 2006 16:54
To: jess-users@sandia.gov
Subject: JESS: Using a rule engine for plan recognition

We're using Jess to implement a plan-recognition program whose heart is 
a pretty ordinary depth-limited search algorithm.  Two matters, one 
general and one specific:

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().

Thanks very much,
Jonathan Sewall


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]




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]