Re: PRD (Prod Rule Dialect) breakout scribe notes from F2F8 6 Nov 07

Paul Vincent wrote:
>
> PRD BREAKOUT F2F8 Boston - 6Nov07
>
> =================================
>
>  
>
> CSMA: Do we want PRD as simple as possible but missing major features 
> like negation?
>
>  
>
> Gary: Most rules' NOT are simple terms and constants rather than frames.
>
>  
>
> CSMA: Another type of common negation is NOT(pattern).
>
>  
>
> CSMA: Should design for negation.
>
>  
>
> Gary: No model theory for PR.
>
>  
>
> CSMA: Model theory for the operational semantics may be possible.
>
>  
>
> Adrian: Select language based on conditions in BLD.
>
>  
>
> CSMA: PRD needs to re-use as much of BLD as possible.
>
>  
>
> Gary: PRD should reference BLD doc. Rather than repeat it. 1st draft 
> can concentrate on actions rather than extending conditions.
>
>  
>
> Gary: EG PRD Core with BLD Condition Language + Actions.
>
>  
>
> CSMA: Concern: better not to repeat text, but people won't read 2 docs 
> instead of 1. Could do a doc refactoring exercise so BLD and PRD can 
> share elements.
>
>  
>
> Gary: BLD doc is not easy to understand. Its a theoretician point of 
> view rather than end-user or implementor. So comments applies to BLD too.
>
>  
>
> Bob: Model-theory semantics will always be a challenge to read.
>
>  
>
> CSMA: ACTION: to discuss BLD restructure to allow easier re-use / 
> sharing by PRD etc with RIF WG
>
>  
>
>  
>
>  
>
>  
>
> CSMA: Human readable syntax / presentation syntax: not restructured in 
> draft as this is not useful
>
>  
>
> Gary: Presentation syntax = very useful. EG test cases as examples for 
> implementors.
>
>  
>
> Bob: Fundamental is the XML syntax. Reading XML docs is not best for 
> examples. Can manage with informal presentation language with no 
> formal / explained syntax,
>
> provided we include the XML doc
>
>  
>
> Gary: But we already have the presentation syntax in BLD so this is 
> done. No motivation to drop it.
>
>  
>
> CSMA: Do not like a Working Draft defined by reference.
>
>  
>
> Gary: Do not like not repeat-by-copy vs repeat-by-reference.
>
>  
>
>  
>
>  
>
>  
>
> Gary: Can we repeat semantics in operational terms, or do a hybrid 
> approach (model-theory conditions, operational rules and actions)?
>
>  
>
> CSMA: Need operational semantics for conditions as conditions are 
> executed per the instantiated rules.
>
> Instantiating rules is an operational semantics in terms of patter 
> matching.
>
>  
>
> CSMA: Should limit amount of work moving conditions to PRD. But work 
> is already done (conditions in operational semantics).
>
>  
>
> Gary: Issue of differences in behavior: JESS re-fires a rule if a fact 
> in condition changes
>
Jess has two modes. standard and slot-specific. Standard will allow 
propagations of a fact, as long as that pattern is true, regardless of 
whether that pattern filters against changed fields. Slot-specific means 
that for the fact to propagate not only must all the conditions be true, 
but that it must also have a constraint for a changed field.

Clips works like Jess standard mode for templates and Jess slot-specific 
for its COOL OO extensions.
>
>  
>
> Bob: In FIC the change must be in the state of the condition, not the 
> state of the fact / data.
>
>  
>
> CSMA: If JESS does not conform, then the doc needs to change.
>
>  
>
> CSMA: How should PRD handle such "tricks".
>
I see use cases for both modes, sometimes you want to know of changes 
regardless of the constraints, and other times only if the constraints 
are for a changed field.
>
>  
>
> Bob: Real business rule systems rarely have ambiguity or chaining.
>
>  
>
> Gary: Still find need for conflict resolution.
>
>  
>
> CSMA: Problems like configuration still require solutions like 
> inference and chaining.
>
>  
>
> CSMA: In ILOG the resolution strategy is overridable to some extent. 
> So if the interpretation of RIF strategy is an engine command this 
> makes RIF default easier.
>
>  
>
> Gary: JESS / CLIPS: multiple rulesets / stack. Only rulesets in top of 
> stack can fire. Actions can load the stack. Within a ruleset can have 
> priorities.
>
> Can select first or last recent rule in same priority.
>
>  
>
> CSMA: ACTION: All vendors to provide their rule selection strategy and 
> options, in a table set up by Christian on the Wiki.
>
Jess, Clips and Drools all default to a "depth" strategy and behaviour 
is the same (although all also allow custom strategies to be provided), 
this is a very simple form of resolution strategy with a preference to 
Jess/Clips "modules" or Drools"agenda-groups" for rule execution 
orchestration; ilog has something similar called "packets". Basically 
these place the rules in a group and only when that group has the focus 
can those rules fire - the mentioned terms use a push/pop stack to 
manage which group has the focus. In reality no reason why these groups 
should be on a push/pop stack, when their linear relationships can be 
described via process defintion - i.e. Drools ruleflow - however I 
expect this is beyond scope for now, but something to bear in mind.
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Paul Vincent
>
> TIBCO | ETG/Business Rules
>
>  
>


-- 
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)