Colleen McClintock

(ff. are some key points from her presentation)

25 commercial and 18 open source in the Java rule engines space alone

features wanted: retract and modify in action part of rules

want one uniform way to represent assertions

want languages specific to classes of rule/inference engines
to specify how engine executes and performs inference

%%%

Discussion on second session:

Benjamin:  
Representing assertions, and also queries/answers (+ later proofs) which
are the conclusions from those assertions, 
in terms of external-to-engine behavior of what's inferred, 
is low hanging fruit.
Want to standardize the basic behavior, in a way where can treat 
in terms of data not procedural aspects in depth.

Ed B., Colleen, Christian:
yes, agree with that.  

Benjamin: 
Also, it's desirable to have languages for particular families of 
rule systems, e.g., production rules, that have 
additional features/restrictions as compared to overall standard.   
But the execution layer of engine is really procedural, without well
established available theory as there is for declarative knowledge
representation, and thus seems fairly difficult to standardize on anytime soon.
In light of this, how should we proceed in standardization? 

Colleen:
We're basically pointing out a problem/challenge wrt achieving 
interoperability.  Differences in the engine behavior such as
rule priority/sequencing and refraction may affect what actions get 
performed.

Benjamin:
Rather than trying to describe these internal variants of the engine
behavior, usually simpler is to standardly define the behavior expected,
and the engine should then (be developed so as to) support the standard,
e.g., with some expressive restrictions on when it does.   

Ed:
Yes, that makes sense.

Ed:
However, when RuleML starts tackling aspects of action, as it has
recently, it's not clear to me that approach will handle enough of the
execution level considerations I talked about.