This is one of the possible Use Cases.
1. Abstract
This use case illustrates several issues, including the need to access several different knowledge bases, scoped default negation, modularization, etc.
2. Status
Originally proposed by: MichaelKifer
This is a simplified version of the kind of systems that can be supported with FLORA-2 (http://flora.sourceforge.net)
3. Links to Related Use Cases
Internet_search%3a_combining_query_language,_rule_languages__and_scoped_negation
- This use case is also about scoped negation and rules.
Refund_Policies_in_E-Commerce and Credit_Card_Transaction_Authorization
- These use cases requires default negation and can be represented in FLORA-2. They use priorities among rules to simplify specification. Although priorities are not part of FLORA-2, the formalisms underlying FLORA-2 can be easily extended.
Information_Integration_with_Rules_and_Taxonomies
- This use case is related because its key requirements (integration of different sources) can be satisfied using the encapsulation mechanism of FLORA-2, which is based on the idea of scoped inference.
Situation_Assessment_and_Adaptation
- This case is related because it has some of the same requirements. Furthermore, requirements 1-4 and 6 of the above use case are supported by the FLORA-2 system.
4. Relationship to OWL/RDF Compatibility
FLORA-2 is based on F-logic (http://flora.sourceforge.net/aboutFlogic.php), which extends the RDF triples model.
5. Examples of Rule Platforms Supporting this Use Case
FLORA-2 (http://flora.sourceforge.net) is an example of a platform that supports scoped negation and encapsulation.
- This use case is easy to represent in FLORA-2.
6. Benefits of Interchange
- Different reasoners are possibly involved. They need to be able to understand each other.
7. Requirements on the RIF
- Need to be able to access remote knowledge bases.
- Different knowledge bases should be encapsulated so that their rules will not interfere with each other.
- Need for default negation.
8. Breakdown
8.1. Actors and their Goals
smartcard * A patient interacts by providing a smartcard
- Doctor's rule-based reasoner
- A reasoner (or reasoners) at remote sites.
9. Narratives
9.1. Jim goes to a doctor
Jim goes to his physician, Dr. Heal, and the latter prescribes a certain drug (say, phenolphthalein). The doctor wants to verify that this drug doesn't have adverse interactions with other drugs and/or other medical smartcards that Jim has. To verify that, a nurse inserts Jim's medical smartcard, which contains all of his medical history, into a reader connected to the Web.
A rule-based reasoner, which is running at the doctor's office, contacts various knowledge sources, including phenolphthalein.AllAbout.example.net, that provides authoritative information about the prescribed drug. phenolphthalein.AllAbout.example.net is powered by a rule knowledge base, which can answer queries about known interactions of phenolphthalein.
If phenolphthalein.AllAbout.example.net doesn't establish that phenolphthalein is known to have adverse effects given Jim's medical history, then our reasoner concludes that phenolphthalein is safe and will not have unintended effects on Jim.
10. Commentary
- Doctor's reasoner needs to be able to access different remote knowledge
- bases.
- There should be no unintended interactions between the rules
- comprising the doctor's reasoner and the reasoners at the external knowledge sources (encapsulation)
- Doctor's reasoner is using default negation with explicit scope
(phenolphthalein.AllAbout.example.net), i.e., SNAF.
- In a more general case, the doctor's reasoner might have to construct a
- query to multiple sites in order to determine if there might be an adverse effect on Jim. The scope of SNAF then extends to a union of several knowledge sources.