[rules-users] How to track constraint truth [was: Non short circuit ANDing]

[Davide Sottara]

Let me add 2 more cents to the discussion :)

I am still convinced that there should be better ways for the engine to
provide argumentation
facilities to the users. It's an open topic, we're working on it (better
TMS, defeasible logic, new RETE
algorithm, strong negation, etc..), but right now we have to live with what
5.x provides... at 
least until 6.x becomes a reality...

The usecase here can be divided in two parts: 
- evaluate a chain of constraints, tracing which one(s) are satisfied and
which ones are not
- evaluate the overall formula, deciding whether an overall consequence
should be fired or not.

Wolfgang's suggestion, as usual, is correct: the constraints have to be
broken apart. The alpha network
evaluates them in a chain and does not notify the results of the
evaluations. However, the proposed
solution (extending a base rule) has a couple of problems
- it relies heavily on (self) joins 
- it only handles the positive cases, e.g. color == "red", so that either a
second rule (color != "red")
  has to be written, or later one will have to look for the absence of the
"success" fact derived from that
  constraint.

So, I'll follow up on my previous suggestion with this proposal:

rule "car" 
when 
  $car: Car( abs == true ) 
  	if ( colour == "red" ) 
		do[red] 
		else do[notRed]	// vs break[notRed]
then[red]
  System.out.println( ">>> Car is red " + $car ); 
then[notRed]
  System.out.println( ">>> Car is NOT red " + $car ); 
then
  System.out.println( "The best Car is in " + $car ); 
end

The pattern Car( abs == true ) is a normal pattern: it's the same as the
"base" rule and would 
filter objects (@Stephen) which are not relevant for discussion.
The "if/else" structure follows the chain (no joins), but branches depending
on result of the 
constraint. Both branches are linked to both a RHS (with an activation
pushed into the agenda)
AND the following patterns in the rule. This means that, using "do" as
opposed to "break", one can
still have a non-blocking sequence of evaluations with partial side effects,
terminating with the
"main" consequence. Each partial consequence can now be logged and possibly
generate intermediate,
control facts as suggested by Wolfgang. 
Let me name them "Fulfillment" and "Violation", following on a previous
experiment we did a couple of 
years ago.

At the moment, these facts have to be managed explicitly, but it would be
great if the engine could
provide more declarative ways to handle these use cases.
I.e., something like the following rule allows a great deal of
customization, but the "default" behaviour -
dos insert Fulfillments, elses insert Violations - should probably be
provided by the engine using some keyword ...

rule "car" 
when 
  $car: Car( abs == true ) 
  	if ( colour == "red" ) 
		do[red] 
		else do[notRed]	// vs break[notRed]
  Success( $car; )
then[red]
  System.out.println( ">>> Car is red " + $car ); 
  insert( new Fulfillment( $car, "red" ); )
then[notRed]
  System.out.println( ">>> Car is NOT red " + $car ); 
  insert( new Violation( $car, "red" ); )
then
  System.out.println( "The best Car is in " + $car ); 
end

The logic for creating the "Success" fact which unblocks the final
consequence is another matter...
should we require all Fulfills with no Viols? More Fulfills than Viols? The
interesting thing is that now
the "analysis" rules can be decoupled from the basic rule (again somehting
we'd need to improve
and provide out of the box)

However, notice that this syntax is already PARTIALLY working... and while
it is semantically designed 
to be *equivalent* to a chain of extended rules, the internal implementation
is (supposedly) more efficient.

UNFORTUNATELY:
@Mario: I tried to use more than one "if" in a rule:

  $car: Car( abs == true ) 
  	if ( colour == "red" ) do[red] else do[notRed]
        if ( price < 1000 ) do[cheap] else do[notCheap]

but I get a compilation error	... is this a bug or simply the feature has
not been fully implemented yet?

Best
Davide




--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-truth-was-Non-short-circuit-ANDing-tp4022021p4022028.html
Sent from the Drools: User forum mailing list archive at Nabble.com.