Re: a thought w.r.t. Standard_RIF_must_support_normative_rules

Hi Jos,

I'm not sure I fully understand your point. However, I think the 
requirement on standard RIF to support normative rules is quite clear 
and is motivated by a range of real applications needing such kind of 
rules. Consider the example of a car company working with a rule system 
R1 and wanting to use as part of its business logic a set of rules 
expressed with a rule system R2. By using RIF, R2 normative rules 
expressed in the rule set should have a representation in RIF, so as to 
be translated into a R1 rule set without loosing their meaning. If a 
rule like NR: 'A customer can rent at most one car at a time' cannot be 
translated from R2 to R1 through RIF, the rental company working with R1 
should at least be aware of the fact that the business logic they want 
is not really the one they get. The proces instances of business 
processes with or without rule NR (a business rule here) might have 
different results in some situations, such as ones when a customer has 
more than one rental request for the same period of time.

The statements above raise actually two requirements on RIF: one 
concerning the support of normative rules and one for a means to specify 
the capabilities of the RIF 'dialect' you use for translating rule sets. 
Also related to these issues is the specification of an expected 
behaviour in case RIF does not support some of your rule 
system's/language's features.

Regards,
Paula



jos.deroo@agfa.com wrote:
> Let me briefly raise a thought w.r.t.
> http://www.w3.org/2005/rules/wg/wiki/Standard_RIF_must_support_normative_rules
>
> This works fine as can be seen from following prolog example
> in which the '=>' is coming from
> http://eulersharp.sourceforge.net/2006/02swap/euler.pl (*)
>
> %=======================================================================
> prefix(rpo,'http://eulersharp.sourceforge.net/2003/03swap/rpo-rules#').
> prefix(p,'http://eulersharp.sourceforge.net/2006/02swap/med#').
> %=======================================================================
> :- dynamic(p:isPrescribed/2).
>
> rpo:mu(p:ann,p:gastroEntritis,0.8).
> rpo:mu(p:ann,p:gastricUlcer,0.006).
> rpo:mu(p:ann,p:postSurgery,0).
>
> p:prescribedFor(p:aspirin,p:gastroEntritis).
>
> p:excludedFor(p:aspirin,p:gastricUlcer).
> p:excludedFor(p:aspirin,p:postSurgery).
>
> p:excludedFor(_,D), rpo:mu(_,D,N), N > 0.01 => bottom.
>
> p:prescribedFor(Med,D), rpo:mu(Who,D,N), N > 0.7 => 
> p:isPrescribed(Who,Med).
> %=======================================================================
>
> and it follows that
> p:isPrescribed(p:ann, p:aspirin).
>
> When we change the case to
> rpo:mu(p:ann,p:gastricUlcer,0.6).
> then the prescription doesn't follow anymore, which is fine.
>
> BUT when we don't have the fact that
> rpo:mu(p:ann,p:gastricUlcer,0.6).
> we still get
> p:isPrescribed(p:ann, p:aspirin).
> which is not so fine!
>
> To cope with that, no integrity constraint is used in
> http://eulersharp.sourceforge.net/2006/02swap/med.pl
> and I believe it is safe in the presence of missing data.
>
>