- From: Paula-Lavinia Patranjan <paula.patranjan@ifi.lmu.de>
- Date: Thu, 13 Apr 2006 18:09:25 +0200
- To: jos.deroo@agfa.com
- CC: public-rif-wg@w3.org
- Message-ID: <443E77B5.8030903@ifi.lmu.de>
Dear Jos, Thank you for your time in trying this out. It's great when everything works :) My best wishes for a happy Easter! Regards, Paula jos.deroo@agfa.com wrote: > [a bit more after some more testing with normative rules..] > > Adding an additional normative rule > p:excludedFor(_,D), not(rpo:mu(_,D,_)) => bottom. > to the example > http://eulersharp.sourceforge.net/2006/02swap/medic.pl > seems to be fine indeed; waw.. > > [putting my name in the requirement too] > > > Hi Paula, > > Agreed, fully agreed; sorry if my point wasn't clear - am quite > often too implicit and assuming too much about the context :-) > Maybe it is resolved when there is a way to do that prescription > example with normative rules, and making sure what Michael said in > http://lists.w3.org/Archives/Public/public-rule-workshop-discuss/2005Aug/0107.html > [[ > in prescribing medicine a (good) doctor might first want to > establish that there are no complications with ulcer, etc. > ]] > well, if you don't mind.. > > Thanks, > Jos > > >> 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 16:09:43 UTC