This document is also available in these non-normative formats: PDF version.
This document, developed by the Rule Interchange Format (RIF) Working Group, specifies use cases and requirements for the W3C Rule Interchange Format, a family of rule interchange dialects that allows rules to be translated between rule languages and thus transferred between rule systems.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is being published as one of a set of
changes are relatively localized, and are visible in
the color-coded "diff" . Please Comment by 23 January 2009the
Rule Interchange Format (RIF) Working Group seeks public feedback on these Working Drafts.
your comments to email@example.com
archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted whichmay address your concerns.
Publication as a Working
Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.
Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling existing rule-based technologies to interoperate according to standards-based methodologies and processes. The
basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies. This mission of RIFis part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:
The purpose of this RIF-UCR document is to
provide a reference to the design of RIF and a guide for users and implementersto the current technical specifications of RIF dialects. RIF-UCR also delivers a structured context for formulating future technical specifications of further RIF dialects. Each dialect targets ata cluster of similar rule languages and enables platform-independent interoperation between them (via interchange of RIF rules). The presenteduse cases illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Last, but not least, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.
The RIF-UCR document is structured as follows: Section 2 formulates the overall goals of
RIF and several accordant critical success factors forRIF. Section 3 summarizes the released RIF dialects and the currentstructure of RIF. Section 4 presents a set of use cases that are representative of the types of application scenarios that RIF is intended to support. Besides illustrating the utilization of the current RIF dialects, the functionality specified in the use cases, together with the inferred requirements, acts as input for the technical specification of future RIF dialects and forthe implementation of various variants of these scenarios by applications or systems that incorporate the existing or newly developed RIF technical specifications. In section 5 several important requirements for RIF are inferred from the goalsand use cases.
main all requirements should have a use case or derivation of a use case from which they are derived. in exceptional circumstances requirements may not be derived from a use case, e.g. when they are already defined as constraints in the working group charter. Their fulfillment is discussed with respect to the existing RIF dialects.
RIF is to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.
The primary goal of RIF is to facilitate the exchange of rules.
RIF is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with RIF.
It is an explicit goal of the W3C that
the Rules Interchange Format will have the maximum potential for widescale adoption. Rules interchange becomes more effectiveThe wider adoption there isof the specification -- the so-called"network effect".
along with the use cases in
the next section, these goals motivate the requirements in Section 5.
RIF is described by a set of documents, each fulfilling a different
purpose, and catering to a different audience. Currently the following set of documents has been released: The RIF-FLD (Framework of Logic Dialects) document describes a framework of mechanisms for specifying The syntax and semantics of logic-based RIF dialects through a number of generic concepts.the RIF-RDF+OWL (RIF RDF and OWL Compatibility) document specifies the interoperation between RIF and the data and ontology languages RDF, RDFS, and OWL. The RIF-DTB (Data Types and Builtins) document describes
RIF is designed as a family of RIF dialects as shown in the following Venn diagram:
Each dialect is a collection of components that
works together, forming an interlingua. New dialects are needed when no existing dialect provides the required rule-language features for interchange.
The RIF Framework for Logic-based Dialects (RIF-FLD) describes mechanisms for specifying the syntax and semantics of logic-based RIF dialects through a number of generic concepts.
Every logic-based RIF dialect should specialize these general mechanisms or justify why it does not. This specialization may include leaving out some elements of RIF-FLD, to produce its concrete syntax and model-theoretic semantics. Currently,The first two existingRIF dialects are the RIF Basic Logic Dialect (RIF-BLD) and theRIF Production Rules Dialect (RIF-PRD) which is a partial specialization of FLD.
RIF-BLD (Basic Logic Dialect) is a specialization of RIF-FLD capable of representing definite Horn rules with equality enhanced with a number of syntactic extensions to support expressive features such as objects and frames, internationalized resource identifiers (IRIs) as identifiers for concepts, and XML Schema data types.
RIF-PRD (Production Rules Dialect) specifies a production rules dialect to enable the interchange of production rules. The condition language of
RIF PRD is defined in Core as a common subset of RIF BLD and RIF PRD.
RIF-Core (Core Dialect) specifies a common subset of RIF-BLD and RIF-PRD
which includes RIF-DTB.
The normative syntax for RIF dialects is a concrete XML syntax. A non-normative presentation syntax is additionally specified for each
dialect, to allow a more easily readable and compact presentation of language fragments (such as examples).
use cases a
use case may
considered to be a description of
problem and a solution that utilized an
or requires the specification of a new one.it is intended that the use cases presented here include the widest possible number of requirements using as few use cases as possible. The included usage scenarios are meantto be representative, meaning that the general concepts are common
many possibleuse cases across a broad array of rule-based application domains and industrial sectors. Nearly fifty use cases documenting the need for a RIF were originally submitted by the working group members. These were grouped into general categories and then synthesized as much as possible.
RIF, explainthe benefits of a RIF, and guide users to its currently specified dialects. The use cases are also intended to provide an ongoing reference point for the working group in its goal of providing a precise set of requirements for a RIF and in developing new RIF dialects. Whenever possible, we will give concrete illustrations of how the existing twoRIF dialects (Core, BLD, and PRD) address various aspects of these use cases. The button below can be used to show or hide
examples. Editor's Note: the given examples and used presentation syntax in this version of the UCR working draft are still under development In order to enhance readability and avoid
appearance of syntactic prejudice, we have deliberately avoidedthe use of formal notation in representing rules in these use cases. Instead, we will use the RIF presentation syntax (of the
dialects). 4.1 Negotiating eBusiness Contracts Across rule Platforms This use case illustrates a fundamental use
vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without concern about vendor lock-in, and in particular without concern thata business partner does not have the same vendor technology. It also illustrates the fact that
can be used to foster collaborative work. Each developer
stakeholder can make a contribution to
joint effort without being forced to adopt the tools or platforms of the other contributors. John is negotiating
electronic business contract regarding the supply of various
items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for
goods and services involved - in this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and
document. John's company defines its purchase orders
in terms of
goods, packaging, delivery location and date with delivery and payment rules.a rule proposed by John might be the following: If an item is perishable and it
delivered to John more than 10 days after the scheduled delivery date then
equality in this example. Unordered representation inRIF Core presentation syntax using namened arguments: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) group ( Forall ?item ?deliverydate ?scheduledate ?diffdays ( ex:reject(ex:ware -> ?item ex:receiver -> "John") :- ex:perishable(ex:ware -> ?item) ex:delivered(ex:ware -> ?item ex:datetime -> ?deliverydate ex:receiver -> "John") ex:scheduled(ex:datetime -> ?scheduledate ex:ware -> ?item) ?diffdays = External(func:days-from-duration( External(func:subtract-dateTimes(?deliverydate ?scheduledate)) )) External(pred:numeric-greater-than(?diffdays 10)) ) ) ) Note, The arbitrarily unordered named argument arguments of the user-defined relations, in contrast to external built-in functions and operations, which must have a predefined order. Object-Oriented Representation in RIF Core presentation syntax using frames: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?item ?deliverydate ?scheduledate ?diffdays ( ?item[ex:status -> "rejected"] :- ?item[ex:perishable -> true] ?item[ex:deliveredOn -> ?deliverydate ex:delivered -> "John"] ?item[ex:scheduledOn -> ?scheduledate ex:delivered -> "John"] External(pred:numeric-greater-than( External(func:days-from-duration( External(func:subtract-dateTimes(?deliverydate ?scheduledate)) )) 10 ) ) ) ) Jane replies with some suggested rule changes: If an item is perishable and it is delivered to John more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discountof 18.7% will be applied to the delivered item. Representation in RIF Core presentation syntax using positional relations: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?item ?deliverydate ?scheduledate ?diffdays ( ex:discount("John" ?item 18.7 ) :- ex:perishable(?item) ex:delivered(?item ?deliverydate "John") ex:scheduled(?item ?scheduledate) ?diffdays = External(func:days-from-duration( External(func:subtract-dateTimes(?deliverydate ?scheduledate)) )) External(pred:numeric-greater-than(?diffdays 7)) External(pred:numeric-less-than(?diffdays 14)) ) ) ) The binding of the intermeditate results to The variable "?diffdays" avoids repetition, as it used twice in the subsequent
rule can be given using slots or frames and as a production rule which asserts the conclusion as a new fact. John considers This and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance. Future requests for the supply of items by John's company are defined on their purchasing web site, as the appropriate XML schema and a RIF ruleset (or rulesets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations onthe RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers. 4.2 Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences This use case concernsthe ability of parties involved in formal transactions or procedures, e.g., credit card authorization
a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed bythe policy. Utilization of RIF In this usecase would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work. Alice wants to buy a device atan online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers. Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction. Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/orengines for evaluating (ownand imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling therule interchange betweenthe two systems. When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that: in order to grant access a buyer must provide valid credit card information together with delivery information (address, postal code, city,and country).
belongsto the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy containsa rule stating to release itto any potential purchaser. Hence, Venditor passesthe credential to Emptor. Emptor is now ready to disclose Alice's credit card information
expressing Alice's and/or eShop's policies could be expressedin different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information
respective clients they would use RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses RIF. Emptor takes that policy and translates it from RIF to its internal representation in order to determine what it needs to do. 4.3 Collaborative Policy Development for Dynamic Spectrum Access This use case demonstrates how RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices.RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.
this use case
concerns Dynamic Spectrum Access for wireless communication devices . Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments.
the ability of a
device to absorb The rules defining the policies of a region, orthe operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities. in this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunisticallyuse frequency bands that are normally reserved for certain high-priority users. ( The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example.) Suppose The policy states:
wirelessdevice can transmit on a 5 GHz band if no priority user is currently using that band. Note, since default negation (not) such as negation as failure is not supported by RIF BLD there is no adequate way to represent that "no priority user is currently using
band". How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it
receiving on that band. That is, it might employ the rule: If no energy is detected
desired band then assume no other device is using the band.
priority user is detected then assume the band is available. Representation In RIF BLD Presentation Syntax using relations: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?device ?band ?user ( ex:used(?device ?band) :- ex:detect(ex:signal(?user ?band)) ex:priority(?user,"high"). ) ) ) So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question. Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designingits devices. Each manufacturer needs to write 2 interpretations of thepolicy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained. Enter RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided
the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer
needsto develop such a compiler once for every architecture it owns. Contrast that investment with havingto produce, test, and maintain different versions of various policies over the lifetime of a product. This arrangement also allowsthe overall process to be organized
in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that
labor: The policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.
A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.
A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent.
Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.
Two primary integration modalities are possible: importing the different
rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.
For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical
decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:
If inspector believes vehicle is repairable then process as
repairotherwise process as total loss. Note, belief/uncertainty cannot be specified in BLD and PRD: only true or false Belief/uncertainty cannot be specified in PRD The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.
Even in the case of a single company, which is nominally under a common ownership domain, information and business logic
is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).
should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.
How such a unified view of thebusiness rules can be realizedin a deployed BP will depend on both technical and non-technical factors. Even where all theparties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of therule sets. In the situation where merging of rulesets is not possible, thena query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules. For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less. 4.5 Managing Inter-Organizational Business Policies and Practices This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways: An organization may buy rule sets from expert sources An organization may use rule sets from shared interest groups such as trade associations A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations. The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise. this scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in
the semantics of
Business Vocabulary and Business Rules Specification . The EU legislation discussed is also fictitious, as arethe consulting companies CarWise and AutoLaw. EU-Rent's corporate HQ deals with CarWise,
consulting company with expertise
managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.
EU regulator issuesa directive dealing with insurance for vehicles owned by corporations. CarWise agrees withthe regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules:a business policy, stating
every car rental must be insured for damages to third parties. a supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities
rentals that span multiple countries, and reporting of compliance with this business policy. EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as: Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager. Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases. EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into
basic cost of each rental, and not shown as a separate item on the rental contract, to ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies
EU: the rule set
car rental insurance (from CarWise), including the basic policy and the supporting rule set. the
set for electronic compliance documentation (also from CarWise). Its own rule set for building insurance into the basic rental cost. The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent
risk. A timing issue makes it difficult for EU-Rent UK to strictly comply with
for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules. EU-Rent HQ permits this, not just
UK, but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds
is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the
electronic signatures are
not present, then the operating company's rules system must reportthe out-of-compliance situation, and subsequently wait for
responsible managers to providethe signatures. 4.6 Ruleset Integration for Medical Decision Support Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected
rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. this use case illustrates how 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. Medical decision support systems, such asthe ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases,
example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as SNOMED Clinical Terms®. rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptionsfor a patient, and to assess the effectiveness
a treatment. The following scenario illustrates how rule-interchange wouldbe used in various medical decision support systems to supportthe following functionalities: Improving situation assessment, e.g., determining when
patient needs to be put on medication, or have his medication switched. Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance. Improving event planning, e.g., determining whether
procedure given the medication that he
currently taking. Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the AutoDoc system to help him decide when to switch to medications and which drugs to prescribe. the AutoDoc system uses two sources when making its recommendations: a laboratory knowledge base giving particular results
pharmaceutical knowledge base giving guidelines
use of medications. Automated Reasoning with rules from these combined sourcesis possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects.this scenario discusses the fictitiousexpert systems AutoDoc and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified. Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated HbA1c level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated HbA1c level.
following rule from the laboratory knowledge base suggests that Bob's treatment at that time was not effective: If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective. Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization: Document( Prefix(pred http://www.w3.org/2007/rif-builtin-predicate# ) Prefix(func http://www.w3.org/2007/rif-builtin-function# ) Prefix(ex http://example.org/example#) Group ( Forall ?Patient ?Treatment ?Level ?T ( ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :- ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T) ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T) ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T) ) ) ) Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. KS86 ] The EC axioms can thenbe represented using RIF BLD. to deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the AutoDoc system. The system, based on
guidelines from the pharmaceutical knowledge base , informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy. If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should
to control his
diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection. Fortunately, when Bob wentto the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system,which checks for incompatible medical events and/ordrugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.). MEDIC uses a variety of sources in its reasoning, including: the pharmaceutical knowledge base, described above the patient databases, which gives the patient record, including the medications a patient is currently taking the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures In this case, MEDIC uses all three sources, and pulls up the following information: Metformin is contraindicated with contrast dye. Metformin is the generic form of Glucophage. Bob is taking Glucophage. the contrast MRI requires as one of its steps injecting the patient with contrast dye. MEDIC therefore determines that Bob should not be taking the contrast MRI at this time. For MEDIC to work, therules from these different sources must be mapped to a unified interchange format. 4.7 Interchanging Rule Extensions to OWL Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF
OWL), In order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, onthe other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates. Rich domain models combining bothrules and ontologies are often needed in domains such as medicine, biology, e-Science
Web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. an example is The use of such
capture knowledge about mereological and spatial dependencies between properties. For example, a rule is usedto express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:
MAE X is bounded by Z and MAE Yis also bounded by Zthen X is connected to Y. Benefits of interchange via RIF includethe ability to collaboratively develop and share valuable knowledge,
ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies. 4.8 Vocabulary Mapping for Data Integration This use case concerns the integration of information from multiple data sources.the Semantic Web provides
common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models. Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across
Semantic Web, enabling an enterprise or community to progressively build up
rich network of mappings unifying the information models. Information mapping and integration problems like this arise in many diverse domains
customer information management. the following scenario comes from
job of analyzing how exposed his division's business processes are
changes in their IT maintenance contracts. He has three sources of information to combine: a report on application services and associated servers, databases and networks (from the IT department)a maintenance contracts database (from
finance department) a registry indicating which business processesuse which IT services (from the business planning group) Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. the it report is too fine-grained: it talks about routers
and interface cards whereas Vlad only needs
pick out some generic dependency relations. on the other hand, the finance database models the world
terms of physical assets such as racks, which is too coarse-grained. First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business Process and Dependency. This involvesrules such as: If x is a ComputeNode in Rack r and Rack r is in Cage c and mc is a MaintenanceContract for Cage c then x is a Server with MaintenanceContract mc If x is a ComputeNode with a NetworkInterface with Port p and app is an Application running on Port p then x is
Server that hosts app If bp is a BusinessProcess that uses Application app then bp has a dependency on app Representation in RIF BLD Presentation Syntax using relations: Forall ?X ?MC ?R ?C( ?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And( ?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack ?R[ex:location->?C] ?C#ex:Cage ?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract )) Forall ?X ?Ni ?P ?App ( ?X[rdf:type->ex:Server ex:hosts->?App] :- And( ?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni] ?Ni[ex:port->?P] ?P#ex:Port ?App[rdf:type->ex:Application ex:onPort->?P])) Forall ?App ?BP ( ?BP[ex:dependsOn->?App] :- ?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] )) He then creates rules that combine the data across his now simplified data sources, e.g. If bp is a BusinessProcess that has a Dependency on Application app and
a Server with MaintenanceContract mc that hosts Application appthen bp has a Dependency on mc Representation in RIF BLD Presentation Syntax using relations: Forall ?App ?BP ?App ?MC( ?BP[ex:dependsOn->?MC] :- < ?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application ?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] )) This gives him a uniform view that links from business processes throughto
IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views. 4.9 BPEL Orchestration of Rule-Based Web Services Rule-based Web services depend on the use of XML data for their request and response format.the involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions. An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service
a decision service containing a rules engine. BPEL first passes
credit request document to
decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit historyfrom The history providing service and passes the credit history document to the decision service
evaluated. Based on the evaluation, credit is approved or denied. Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into
credit approval service. The credit evaluation model can be changed easily using GUI tools
rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor The rules to meet specific business objectives. the credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as: number of times
payment was 60 days late debt-to-income ratio number of foreclosures or repossessions number of garnishments number of liens bankruptcy
red flag above the threshold resultsin denial of credit. Rulesin the second ruleset incrementa credit score variable.for example: If applicant owns residence then add 40. If applicant rents then add 30. If applicant has lived at current address 2 to 4 yearsthen add 20.If applicant's incomeis under 20000then add 10.If applicant's incomeis between 40000 and 50000then add 40.
goal-driven solution with makes use of assert and retract (not supported by BLD) to updatea global score value, whichis stored
fact. the third and final ruleset compares the applicant's credit score and income to threshold values,
makes the final decision to approve or deny credit to the applicant.
decision and supporting rationale is returned from The decision
service as an
XML document. This decision document is then used to construct the reply to the original credit approval request. 4.10 Publishing Rules for Interlinked Metadata The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that capture implicit knowledge . To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary. One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at http://imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following: Every science fiction movie is a movie. Every movie produced before 1930 is black and white. Representation in RIF BLD (Abridged) Presentation Syntax using relations: ?Movie#ex:Movie :- ?Movie#ex:ScienceFictionMovie. ?Movie#ex:BlackWhiteMovie :- ?Movie#ex:Movie[ex:date -> ?Date] ?Date < "1930"^^xs:dateTime. Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify
maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements. Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at http://altmd.example.org. In addition to metadata, it again publishes its own rules: All movies listed at http://altmd.example.org but not listed at http://imd.example.org are independent movies. All movies with budgets below 5 million USD are low-budget movies. Representation in RIF BLD (Abridged) Presentation Syntax using relations: ?Movie#ex:IndependentMovie :- listed(?Movie#ex:Movie,<http://altmd.example.org>) not(listed(?Movie#ex:Movie,<http://imd.example.org>)). ?Movie#ex:LowBudgetMovie :- ?Movie#ex:Movie [date -> ?Date, budget -> ?Budget] ?Budget < 5000000^^xs:long. Publication of rules with explicit references to other rulesets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified scope is important in the Web environment, since it can reduce the danger of unintended interference fromrules published at other remote sources, which may be exporting their own predicates. Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being usedto specify how
use other metadata, e.g. in the form
standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule: If Charlie is currently attending
public talk according to http://charlie.example.org/calender.ical
leave him a voicemail messageIf Charlie is currently in a meeting accordingto http://charlie.example.org/calender.ical and the importanceis highthen call his cell numberIf Charlie currently has no appointments according to http://charlie.example.org/calender.icalthen call his office number
Web to support new kinds of "intelligent" crawling and search. 5 Requirements the goals
cases motivate a number of requirements for a Rule Interchange Format. The Working Group has currently approved the following requirements. Requirements listed as "General" are deemed
fundamental properties which need to be fully covered by the currently specified RIF dialects. Basic requirements
Rule Interchange format are motivated by specific use cases. 5.1 General 5.1.1 Implementability RIF must be implementable using well understood techniques, and should not require new research in e.g. algorithms or semantics in order to implement translators. 5.1.2 Semantic precision RIF core must have
clear and precise syntaxand semantics. Each standard
create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility). 5.1.4 Translators For every standard RIF dialect it mustbe possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language. 5.1.5 Standard components
use standard support technologies such as XML parsers andother parser generators, and should not require special purpose implementations when reuse is possible. 5.1.6rule language coverage Because of the great diversity of rule languages, no one interchange language is likely to be able to bridge between all. Instead, RIF provides dialects which are each targeted at a cluster of similar rule languages. RIF must allow intra-dialect interoperation, i.e. interoperability between semantically similar rule languages (via interchange of RIF rules) within one dialect, and it should support inter-dialect interoperation, i.e. interoperation between dialects with maximum overlap. 5.2 Basic Requirements 5.2.1 Compliance model the RIF specifications must provide clear conformance criteria, defining what is or is not a conformant RIF implementation. 5.2.2 Default behavior 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
the rules described in a RIF document, or it must provide a way to specify such default behavior. 5.2.3 Different semantics RIF must cover rule languages having different semantics. 5.2.4 Limited number of dialects RIF must havea standard core and a limited number ofstandard dialects based upon that core. 5.2.5 Embedded comments RIF must be able to pass comments. 5.2.6 Embedded metadata RIF must support metadata such as author and rule name. 5.2.7 OWL data RIF must cover OWL knowledge bases as data where compatible with RIF semantics. 5.2.8 RDF data RIF must cover RDF triples as data where compatible with RIF semantics. 5.2.9 Dialect Identification The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data. 5.2.10 XML syntax RIF must have an XML syntax as its primary normative syntax. 5.2.11 XML types RIF must support an appropriate set of scalar datatypes and associated operations as defined
XML Schema part 2and associated specifications. Seethe charter on Datatype support . 5.2.12 Merge Rule Sets
RIF should be
able to accept XML elements as data. 5.2.15 Internationalized text RIF must support internationalized text — that is, text that additionally conveys information in terms of a language tag.
The goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as
"interlingua" to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages.
As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks,
and, therefore, rule-based systems are not monolithic. Rules have been used to perform or validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real-time, determine the need for human intervention, and so on.
In light of this
diversity the working group expects that RIF, rather than being a single all-encompassing format, will consist of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) within each dialect. This should allow the main benefits of RIF to be realized. For example, the invariant meaning of a set of integrity-constraint-enforcing rules would be represented within the appropriate RIF dialect and could then be translated into the native format of any of the formalisms capable of representing such rules.RIF must be
designed in such a way that it is possible to create new dialects (extensibility) according to the overall goals and the general requirements of RIF, as well as to update existing dialects (upwardly compatible). This is in keeping with the working group charter's call for an extensible format.