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