RIF Use Cases and Requirements

This use case illustrates a fundamental use of the RIF: to supply a 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 that a business partner does not have the same vendor technology. It also illustrates the fact that the RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.

John is negotiating an electronic business contract regarding the supply of various types of 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 the 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 rule languages, they interchange the rules using the RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description 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 is delivered more than 10 days after the scheduled delivery date
then the item will be rejected.

Jane replies with some suggested rule changes:

If an item is perishable and it is delivered more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to this delivery.

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

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of 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 by the policy. Utilization of the RIF in this use case 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 at an 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 the credentials Emptor and Venditor have, they 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/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the 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:

A buyer must provide credit card information together with delivery information (address, postal code, city, and country).

For determining whether Venditor's request for information is consistent with Alice's policy, the Emptor takes its rules into account, which state for example:

Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.

By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:

Never disclose two different credit cards to the same online shop.

For anonymity reasons, never provide both her birth date and postal code.

Different choices exist for implementing the above given constraints as rules the Emptor has; choosing the type of rules for implementing policies depends also on the capabilities the Emptor system has.

For this purchase, anonymity is no issue and only information on one credit card is requested. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor. Venditor checks that Alice is not on eShop's blacklist, then confirms the purchase transaction.

Companies that provide software such as Venditor and Emptor would make use of the RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in 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 of their respective clients they would use the RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses the RIF. Emptor takes that policy and translates it from the RIF to its internal representation in order to determine what it needs to do.

This use case demonstrates how the 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. The 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. There are at least two broad areas in which such third-party services could be deployed.

One area is 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, or the 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 opportunistically use 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 - See http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf.)

Suppose the policy states:

A wireless device can transmit on a 5 GHz band if no priority user is currently using that 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 is receiving on that band. That is, it might employ the rule:

If no energy is detected on a desired band then assume no other device is using the band.

A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:

If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.

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 designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.

Enter the RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into the 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 for 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 only needs to develop such a compiler once for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.

This arrangement also allows the 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 (the RIF); knowledge about how to translate from the 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.

Web Services and Service Oriented Architectures is another broad area in which third party rule interchange services would be enabled by the RIF. Web-based service architectures offer a dynamic and flexible approach in which differentiated Service Level Agreements (SLAs) can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. SLAs written in the RIF could be automatically translated into appropriately customized agreements by a third party service provider.

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 repair otherwise process as total loss.

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

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

When a business process is deployed, the engine running the BP may dynamically import the business rule logic of multiple departments when they are in the same organization; or, if that is not permitted, then a query-style access to partners' business rules may be used. In this way, the 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.

This use case is about the management of rules representing business policies and practices in cases involving multiple organizations and/or multiple units within a single organization. One of the key challenges in dealing with such domains is that some rules that support business policies and practices might not be directly executable by a machine, whereas others, even those dealing with the same situation, are machine executable. Rules that are not directly executable might need something from a person, e.g. a decision or confirmation of an action, at which point the rule execution system might be able to use the rule in a reasoning process. The RIF can help to make such domains more tractable and amenable to machine processing by allowing rules to be labelled with tags that express the necessary meta-level information required to make a reasoned determination as to the intended status of a given rule.

This scenario uses the (fictitious) car rental company, EU-Rent, used as the SBVR case study. The EU legislation discussed is also fictitious.

EU-Rent’s corporate HQ deals with CarWise, a consultancy company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulation. It provides both interpreted regulation for EU-Rent as an organization, and rules that can be directly used by IT rules systems.

An EU regulator issues a directive dealing with insurance for vehicles owned by companies. One of the interpretations relevant to EU-Rent is:

Every car rental must be insured for damages to third parties.

EU-Rent receives this and accepts that it must comply. It also decides that it will maintain its compliance documentation electronically. CarWise provides EU-Rent with rules for electronic signatures for insurance schedules, which can be directly used in EU-Rent’s IT systems, e.g.

Each schedule must have electronic signatures from two EU-Rent employees of at least manager grade.

EU-Rent corporate HQ decides that

Cost of third-party insurance will be built into the basic cost of each rental.

so that there is no possibility that it can be omitted from rentals. It provides this rule to its companies in each of the EU countries in which it operates. EU-Rent operating companies also use consulting companies like CarWise for national level expertise. In the UK AutoLaw advises EU-Rent of rules for placing aggregate insurance for fleets with more than one insurer in order to spread the risk:

For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers where at least 25% of the risk is with each insurer.

AutoLaw also provides the rules for calculating tax liability for aggregated insurance for direct use by EU-Rent’s IT systems. These include, e.g.

For an individual rental, the tax on aggregated insurance is 1.5% of the simple cost of the rental

Simple cost of rental is the cost for use of the car, excluding extra equipment, additional drivers and VAT.

EU-Rent UK has some existing insurance policies in place. They provide third-party insurance as an explicit item, and EU-Rent UK cannot get refunds on early termination. It asks corporate HQ for rule:

Insurance policies that provide separate third-party cover must not be renewed.

EU-Rent HQ permits this, not just for UK, but for all its operating companies, and disseminates it.

EU-Rent HQ is concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:

Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.

This means that if '48 hours before filing deadline' occurs and the electronic signatures are not present, an operating company's rules system must report the out-of-compliance situation, and then wait for the responsible managers to provide the signatures.

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 that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. 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.

Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient data bases, and medical ontologies. For 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 prescriptions for a patient, and to assess the effectiveness of a treatment.

The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:

• Improving situation assessment, e.g., determining when a 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 a patient can be scheduled for a procedure given the medication that he is 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 for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to the RIF. Here are two specific examples of such synergistic effects.

This scenario discusses the fictitious expert 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, a 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. The 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.

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 the following 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 be replaced by an oral bitherapy.

Based on the recommendation from AutoDoc, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol 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 went to 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/or drugs (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 data bases, 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, the rules from these different sources must be mapped to a unified interchange format.

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and 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, on the 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 both rules and ontologies are often needed in domains such as medicine, biology, e-Science and 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 a domain model in an application that aims at assisting the labelling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.

For example, a rule is used to 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:

If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.

Benefits of interchange include the ability to collaboratively develop and share valuable knowledge, the 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. Requirements on the rule interchange format include semantic compatibility with OWL-DL and RDF, and the ability to provide reasoning support over combined ontology and rule bases.

Note: This is a synthetic use case, used as an example in the charter. The Working Group expects to replace this use case with a real-world data integration use case in a future version of this document.

Jackson is trying to find someone: he needs at least one more client before the end of the quarter. He has access over the web to dozens of databases, some public, some licensed, and some maintained within his company. Together, they contain millions of potential candidates, but how is he going to narrow the field to the five or ten leads he should seriously pursue?

He thinks for a minute, then constructs a new query. He clicks on interesting properties, sees their values, and locks in the ones he thinks will act as useful filters. After a few minutes he gets frustrated, because the same concepts seem to have different names in different databases. Worse, the same idea is sometimes expressed in different structures; one database follows the the model of having "name of assistant" and "phone number of assistant" properties, while another simply has an "assistant" property, which links to another person. Trying to handle structural variations like this in his query is becoming impossible.

Fortunately, Jackson's system supports a rule language. The query construction interface helps him construct mapping rules between different constructs which seem equivalent to him, letting him infer new information that is customized to his needs, so he can query over a virtual unified database with a structure that seems to him to be simple and straightforward.

In fact, these rules were already being used; the data views Jackson saw were in many cases constructed by rules other people had written. His own rules will be available to his department (because he stored them in department workspace), allowing his co-workers to use the unified view he finds so useful.