- From: Paula-Lavinia Patranjan <paula.patranjan@ifi.lmu.de>
- Date: Thu, 13 Apr 2006 16:24:32 +0200
- To: jos.deroo@agfa.com
- CC: public-rif-wg@w3.org
- Message-ID: <443E5F20.60809@ifi.lmu.de>
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. > >
Received on Thursday, 13 April 2006 14:24:48 UTC