W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2006

Re: Append solution using pure production rules

From: Francois Bry <bry@ifi.lmu.de>
Date: Mon, 20 Mar 2006 09:42:12 +0100
Message-ID: <441E6AE4.6030804@ifi.lmu.de>
To: public-rif-wg@w3.org

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.

Received on Monday, 20 March 2006 08:42:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:37 UTC