- From: Leora Morgenstern <leora@us.ibm.com>
- Date: Wed, 28 Jun 2006 17:24:49 -0400
- To: "Peter F. Patel-Schneider" <pfps@inf.unibz.it>
- Cc: public-rif-wg@w3.org
- Message-ID: <OF00EFF537.88005C74-ON8525719B.0075950C-8525719B.0075A1B1@us.ibm.com>
My apologies, Peter. You're right. I had missed the point on this one. "Peter F. Patel-Schneider" <pfps@inf.unibz.it> wrote on 06/28/2006 05:15:39 PM: > The "default behaviour" requirement is not at all about default rules. It > is instead about handling constructs that are not understood. > > For example, one such default behaviour would be to turn any non-strict > rules (default rules, negated rules, or whatever) into strict rules for > systems that only have strict rules. Another default behaviour would be to > just ignore such rules. > > peter > > > > From: Leora Morgenstern <leora@us.ibm.com> > Subject: Re: comments on Editor's Draft of UCR -- motivates links > Date: Wed, 28 Jun 2006 15:48:36 -0400 > > > > > Peter, > > > > > > > > > Default behaviour > > > > > > > > > > RIF must specify at the appropriate level of detail the default > > > > > behavior that is expected from a RIF compliant application that > > > > > does not have the capability to process all or part of the > > rules > > > > > described in a RIF document, or it must provide a way to > > specify > > > > > such default behavior. > > > > > > > > > > not motivated by Use Case 2.2, Use Case 2.4, Use Case > > > > > 2.5, Use Case > > > > > 2.6 > > > > > > > > From use case 2.6: > > > > > > > > "This use case illustrates how the RIF makes it possible to merge > > > > rulesets from diverse sources in diverse formats into one rule-based > > > > system, thereby enabling inferences that might otherwise have > > remained > > > > implicit." > > > > > > > > This rule-based system may get rules that it can't (completely) > > process > > > > and involves important medical decisions so I'd say that default > > > > behavior is motivated. > > > > > > I still don't see this as part of the use case. I don't see how the > > use > > > case speaks to partial understanding of rule sets. On the contrary, I > > > would say that this use case speaks to the necessity of *complete* > > > processing of rule sets, because otherwise some important rule might > > no be > > > processed accurately and someone might die. > > > > > > > I believe the point David is making --- and with which I agree --- is > > that many medical rules are better expressed as default rules than as > > universal rules. For example, in this use case (2.6), the rule > > > > "If an oral monotherapy at recommended doses of a sulfonylurea or > > biguanide, combined with lifestyle changes, is ineffective, then the > > monotherapy should be replaced by an oral bitherapy." > > > > would be better expressed as a default: > > > > "If an oral monotherapy at recommended doses of a sulfonylurea or > > biguanide, combined with lifestyle changes, is ineffective, then the > > monotherapy should *usually* be replaced by an oral bitherapy." > > > > using whatever means you prefer to express defaults (eg., abnormality > > predicates). There are, after all, probably exceptions to this rule: > > there many be another class of drugs worth trying as a monotherapy, or > > the patient's particular medical situation may contradict an oral > > bitherapy and may necessitate insulin injections. And one would want to > > be able to specify these exceptions in the rules. > > > > I agree that slightly modifying this use case would better highlight the > > need for defaults, and I'd be happy to make such a modification for the > > next draft. > > > > By the way, use case 2.10 shows a clear need for defaults. That case > > includes the rule: > > > > "Every movie produced before 1930 is black and white." > > > > Actually, *most* movies were black and white, but some were in color; > > there were different coloring technologies introduced early on, > > including an early version of Technicolor introduced in 1917. Not that > > I'm a movie buff or anything ;) ; the point just is the need for > > defaults. > > > > > > > > > OWL data > > > > > > > > > > RIF must cover OWL knowledge bases as data where compatible > > with > > > > > Phase 1 semantics. > > > > > > > > > > not motivated by Use Case 2.4, Use Case 2.6 > > > > > > > > While 2.6 doesn't specifically mention OWL, it does mention > > ontologies > > > > as a possible data source. I think parts of SNOMED have been > > translated > > > > to OWL, but I'm no expert. > > > > > > Sure, but you can write (very, very, very) simple ontologies in just > > RDFS, > > > so there is no demonstrated need for OWL. > > > > I believe the point is that parts of SNOMED have actually been > > translated to OWL, or that there are intentions to do so. If parts of > > SNOMED are or will be in OWL, then the RIF will have to handle OWL in > > order to use SNOMED. Whether or not these ontologies could have been > > represented in a simpler language is irrelevant. > > > > > > > > > > Note that many of my complaints could be addressed by appropriate > > > modification of the use cases. > > > > Absolutely. > > > > Leora
Received on Wednesday, 28 June 2006 21:25:02 UTC