[RIF]: Append solution using pure production rules

> This is especially true in the business rule market, where far more
> users are likely to write a rule like
> "if an employee earns more than 50000 then give a 10% raise"
> that refires endlessly than there are users seeking to write a
> recursive ruleset to do appends.

Just to clarify Gary's comment here: most PR engines (including AFAIK
the ones represented in RIF) will NOT fire endlessly given this rule.
Although, for example, Rete-based PR engines support non-monotonic
reasoning, they usually require some kind of self-triggering pairs of
rules to set up a circularity chain (which is probably the closest you
normally can get to "recursion", intentional or otherwise, in rules). 
eg
"if an employee earns more than 50000 then set their earnings to 48000"
"if an employee earns less than 50000 then set their earnings to 52000"
[Note from a business rule perspective, the above would usually be
caught as a logical inconsistency].


Paul Vincent
Fair Isaac Blaze Advisor --- Business Rule Management
OMG PRR and W3C RIF for rule standards
 -----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Francois Bry
Sent: Monday, March 20, 2006 8:42 AM
To: public-rif-wg@w3.org
Subject: Re: Append solution using pure production rules


Gary Hallmark wrote:
> Francois Bry wrote:
>
>> Some brands of production rule languages, as they have been described
in
>> the literature over the last 2 to 3 decades, significantly restrict
the
>> re-firing of a rule that has already fired. In extreme cases, a rule
can
>> only fire once.  
>>
> This is especially true in the business rule market, where far more
> users are likely to write a rule like
> "if an employee earns more than 50000 then give a 10% raise"
> that refires endlessly than there are users seeking to write a
> recursive ruleset to do appends.
>
> However, a tool or language that supports a "fire at most once" rule
> could use a "control fact" to implement the desired behavior.  It's
> not necessarily the case that the RIF needs to support "fire at most
> once".

I am pleased that an experienced practitioner confirms my statement
above.

I feel uneasy about the RIF forcing to use "control facts" for
preventing an active rule to re-fire: this would be, I think, a rather
nasty hack, i.e. not much in the spirit of a high-level language like
RIF should be.

In my opinion, the fact that production rules come in two flavours
(allowing re-firing instances vs. not allowing re-firing instances)
should be expressible in RIF. In my opinion, annotations to a set of RIF
reactive rules should make it possible to state which of these two
flavours is considered -- among other things.

This is one more example of the need for "usage annotations", which I
maybe misleadingly called "different kinds of reasoning". Another
example would be a set of declarative, first-order-like formulas, be
annoted as "integrity constraints".

My belief is that practice requires suh annotations and not supporting
them would considerably reduce the RIF's applicability.

Francois

Received on Monday, 20 March 2006 15:16:40 UTC