Re: a thought w.r.t. Standard_RIF_must_support_normative_rules

Paula, it indeed feels so good when it works out! I like test cases and 
running code :)

btw, the constraint is now a bit stronger as to avoid mixing diagnoses of 
different patients
p:isPrescribed(W,M), p:excludedFor(M,D), not(rpo:mu(W,D,_)) => bottom.

Also my very best wishes for a happy Easter!

Regards,
Jos

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




Paula-Lavinia Patranjan <paula.patranjan@ifi.lmu.de>
13/04/2006 18:09
 
        To:     Jos De Roo/AMDUS/AGFA@AGFA
        cc:     public-rif-wg@w3.org
        Subject:        Re: a thought w.r.t. 
Standard_RIF_must_support_normative_rules


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.
>>> 
>
>