RE: [RIF] Reaction to the proposal by Boley, Kifer et al --> ECA vs PR

Gerd - I think you will find that many rule engine vendors provide
execution mechanisms for multiple rule types. In Blaze Advisor, for
example, we support:
- Production rules (with semantics for RETE and sequential)
- Event rules* (with semantics for either UI events or process events,
including pre- and post-event state consideration if desired)
- Functions / procedures

[* = Note that Event rules are a superset of what are often described as
ECA rules - effectively the "condition" is optional - and are only
called event rules because they predate the more common use of ECA
rules]

I agree that state change is a different (and necessarily runtime)
semantic to a state condition, but they are both attributes of state
(event or value). Indeed, it would be a mistake to assume rules about
events are solely about instantaneous actions based on some event
occurring: often event processing is about correlation, in which case
the event is reduced to a fact that some event has occurred at time t.
And of course, you are then back into regular, boring old production
rules! 

[And, of course, you are right that I tend to view everything through PR
spectacles!]

However, I would be interested to know what ECA-specific rule vendors
are present in RIF, and whether they have an agreed description for ECA.
As you know, we are planning an ECA metamodel in PRR as a non-normative
example of how PRR could be extended to include other rule types. 

Cheers,
Paul Vincent
...for Fair Isaac Blaze Advisor / W3C RIF

> -----Original Message-----
> From: Gerd Wagner [mailto:wagnerg@tu-cottbus.de]
> Sent: Wednesday, May 03, 2006 9:15 PM
> To: Vincent, Paul D; 'Alex Kozlenkov'; 'Dave Reynolds'
> Cc: public-rif-wg@w3.org
> Subject: RE: [RIF] Reaction to the proposal by Boley, Kifer et al -->
ECA
> vs PR
> 
> > Alex: just some views on ECA from a vendor in this space...
> 
> Paul, you mean from a production rule vendor's
> point of view, right :-?
> 
> > > various events, not just data changed.
> >
> > [PV>] Note that this is (mostly) an execution aspect. If I have an
ECA
> > rule that occurs on event A, it looks very similar to a PRule with a
> > condition of the type "event A occurred".
> 
> I guess, ECA rule vendors would not agree with your
> attempt to neglect the specific semantics of events.
> 
> It's not an execution aspect, it's a question of the
> right semantics. Normally, "condition" (in the sense
> of "logical condition") means "state condition", where
> "state" may refer to the state of a system, or to the
> "state of affairs".
> 
> Now, an event corresponds to a state change and is
> therefore a completely different kind of thing that
> cannot be subsumed under the concept of a state condition.
> A complex logical condition formula is formed with the
> help of logical connectives, while a complex event
> expression is formed with the help of a different set
> of (event composition) operators.
> 
> It's true that logical conditions and events are all
> mixed up in production rules. Semantically, this is
> a mess (and typically production rules do not have
> much support for event composition). But you may
> consider it a strength, making production rules
> a versatile programming paradigm (however, without
> a clear formal semantics).
> 
> -Gerd

This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.

Received on Wednesday, 3 May 2006 21:49:46 UTC