RIF Use Cases and Requirements

As the name implies, a Rule Interchange Format (RIF) should enable interchange of rules. The use cases presented in section 2 of this document illustrate situations in which such interchanges enable some desirable functionality. In this section we attempt to clarify in more general terms what rule interchange is and why it is important.

By "rules" we mean formal entities in some "executable rule-language." An executable rule-language, as we understand that term here, consists of the following elements: 1) a precise syntax and/or effective procedure for determining whether or not any expression is a well-formed formula (wff) of the language, and 2) a derivation procedure, which is defined as a partial function that takes a set of wffs in the language, together with a set of zero or more queries (also wffs), and for each query either returns an answer after some finite time, or terminates without returning an answer. (The notion a "derivation procedure" is in line with the notion of a "load-and-query rule engine" in the RIF charter, section 2.2.3, except that we here explicitly account for the possibility that a bona-fide rule-engine can "go on forever" in certain cases.)

Let r-1 represent a set of wffs in a rule language RL-1, let q-1 represent a set of query wffs in the same language, and let RL-1(r-1,q-1) represent the result of executing the derivation procedure of rule language RL-1 on the given arguments. Let RL-2 represent a rule language distinct from RL-1. Then a fundamental question regarding the possibility of rule-interchange between these two rule-languages for this case is whether there is a mapping M from r-1 and q-1 into RL-2 sets r-2 and q-2 such that r-2 = M(r-1) and q-2 = M(q-2), and such that RL-2(r-2,q-2) = M(RL-1(r-1,q-1)). In words: is there a way to translate the items in r-1 and q-1 into RL-2 such that equivalent results are achieved?

In any particular case there seem to be three possible answers of interest to this question: 1) such a mapping exists, 2) such a mapping does not exist, but a mapping that is "close enough" to make the interchange useful does exist, and 3) such a mapping does not exist and there is also no mapping "close enough" to make the interchange useful.

Let RL-1, RL-2,...RL-n represent n rule-languages. Suppose that for these languages the answer to the fundamental question regarding rule-interchange falls into categories (1) and (2) enough of the time that it is clear that automating interchange of rules among this family of languages is worth the effort. One way to facilitate rule-interchange among these languages would be to design pairwise translation alogrithms for each possible pair in the family. For n languages we need to design n(n-1) algorithms: for each rule-language we have to implement a translation algorithm to each of the other n-1 lanaguages.

An alternative approach is to design one overarching representation mechanism, a RIF, that allows the structure of each language in RL-1, RL-2,...RL-n to be expressed in some standard way. Then for each language one would only have to write two translation algorithms: one from the language to the RIF and vice versa, for a total of 2n.

Besides representing an order of magnitude less effort for the implementation of translation algorithms, the use of a RIF has the potential for additional benefits. For example, in cases where rule-interchange mappings cannot be reliably automated, the information provided by the RIF representation should, at the very least, be useful in automatically constructing explanations of the translation impasse.

It is important to understand, however, that the RIF itself provides neither a translation algorithm nor an explicit mapping between rule languages. Rather the RIF includes a framework of concepts, represented as tags in a markup language, that can be used to provide information about the meaning of wffs in a rule language. For rule authors who wish to make their rules accessible across languages and platforms, the more completely, precisely, and accurately they tag their creations using the RIF, the more likely it is that their rules will be capable of being automatically translated correctly.

Information integration, merging multiple sources of information to allow processing the information in a unified manner, is one of the oldest uses of knowledge based systems. This unified information could be directly displayed to a user or included in business logic deep within an application.

Many sources of heterogeneity can arise in information integration, including:

• multiple ownership domains

• different forms

• conflicting semantic bases or meta models

• physical and/or temporal distribution

Two primary integration techniques 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.

Individuals often have to combine information from multiple sources. For example, a job seeker might use a search engine that supports a unified search for job offers that are published on distributed websites of corporations and universities. If she is unlucky, there will not be a suitable website and she will have to integrate the various sources herself. In the case of job-hunting there are some standard domain-specific ontologies available to help with the integration, but many employers require additional concepts to describe their specific requirements. In order to facilitate searching over their offerings, these employers sometimes supply rule-based descriptions of the relationships between their ontologies and the more general domain ontologies.

Company information is nominally under a common ownership domain but is in practice controlled by multiple stakeholders. A situation that is almost guaranteed to arise in a company is one where different databases and other sources of information are in incompatible forms that need mapping before they can be used.

The following scenario illustrates the enterprise context, where managers often have to combine multiple sources of information across different ownership domains:

Suppose that a product manager wants to predict the effect of announcing a new version of his product. Folklore suggests that as soon as a new product is announced orders for the existing version rapidly dry up as customers wait for the new version. The size of the gap between the announcement and actual availability will have a marked effect on sales. In order to predict this effect, our product manager integrates the current estimate of sales -- both actual orders and prospective orders -- together with estimates for manufacturing. The information for the sales is held in a database which has an RDF interface; the sales department has a supporting ontology in OWL that allows analysis and aggregation of the raw information (such as what kinds of customers and orders there are).

The supply chain is composed of a number of contractors and the corporate warehousing facilities, together with a shipping agent. Again, the different enterprises are not owned or controlled by our product manager except for predefined contracts that have been put in place. Those contracts have a representation as a collection of RuleML/OWL/Prolog facts; this enables the contract manager to use them to incorporate service level predictions in his automated planning.

Finally, the product manager has access to a desktop utility called GoPlan that allows him to prepare a plan for the rollout of the new version and have the system automatically query the different stakeholders for their information. This is possible because GoPlan is aware of the RIF, as are all the other stakeholders, and is able to accommodate the differences in semantics of the different sources of information. As a result, the new version is announced and rolled out in a smooth way, and sales grow!

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Rules are a critical part of this expert decision making. Interchange is also especially important, since different systems and knowledge bases are often involved (e.g., medical knowledge bases, hospital patient databases, pharmaceutical knowledge bases, etc.).

The following scenario illustrates various medical decision support systems:

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. Originally his diabetes was controlled through diet and moderate exercise.

When his blood glucose became too high under this regimen, he was prescribed the drug Glucor (50 mg. tid). This helped temporarily. When Bob's blood glucose levels rose, he was switched to Hemi-daonil (1.25 mg., tid). When this no longer sufficed, he was switched to Diamicron (80 mg., tid), and finally to Metformin (70 mg., tid), which has thus far controlled Bob's blood glucose level.

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI. When asked about current medication, Bob told Dr. Cervello that he was taking Diamicron to control his diabetes, forgetting that he had been switched to Metformin. This was potentially problematic, since Metformin should not be taken close to the administration of a contrast injection.

Fortunately, when Bob came to take the MRI, the radiology tech checked the hospital database and found that Bob was taking Metformin rather than Diamicron. The radiology tech put this information into 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.) The rules in MEDIC have been automatically generated using the rules for product and medical event compatibility from other knowledge bases (e.g, more general knowledge about effects of drugs on kidneys, drugs’ clearance time, etc.).

After being informed, the radiologist told Bob that he needed to discontinue the Metformin for a few days before taking the MRI. The MRI was rescheduled for a few days later, after which time Bob began taking the Metformin again. The day after the MRI was performed, Dr. Bild, a radiologist who specializes in interpreting neurology scans, went over the MRI scan. He used the hospital’s new Brain Reasoning System, an expert system that helps interpret brain scans, and determined that Bob may have suffered some mild damage due to his recent concussion. Unfortunately, the brain anatomical changes that he has seen also indicate that Bob may be suffering from mild Alzheimer’s disease.

Dr. Bild transmits his report to Bob’s neurologist Dr. Cervello. The next morning, Dr. Cervello gives a short summary of his and Dr. Bild’s findings to his fellows and residents and asks them how they would treat Bob. For various reasons, most can’t follow his brief presentation, and can’t respond to Dr. Cervello’s questions. Resident X missed the lecture on brain anatomy last week due to the flu; Resident Y just transferred from a program that emphasized CAT scans rather than MRIs, and fellow Z has focused on traumatic rather than degenerative changes to the brain. None of them are familiar with medical protocols for treating mild Alzheimer’s. Dr. Cervello tells them that they had better be better prepared the next day. That evening, they hunker down in the residents’ lounge and, each on a separate laptop, use the hospital’s new e-learning system to prepare themselves for the next day’s encounter. Each starts the e-learning session by answering a short questionnaire that assesses their knowledge or lack thereof of various subareas of neurology. The e-learning system then brings back materials that will fill in their gaps of knowledge. X, Y, and Z each spend several hours going through their customized materials. The next day, they are able to answer Dr. Cervello’s questions.

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 an automated negotiating agent for buyers. eShop employs software called "Venditor" as an automated negotiating agent for sellers. These two systems negotiate so as to automatically establish trust with the goal of successfully completing the transaction. The negotiation is based on the policies and the credentials each system has. Alice's and eShop's policies describe who they trust and for what purposes.

When Alice clicks on a "buy it" button at the eSho's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends the relevant policy 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)."

Emptor now determines whether Venditor's request for information is consistent with the policy Alice has provided. Alice has a credit card but her Emptor policy states that she is not willing to disclose it to everyone. Since Alice has never bought anything from eShop in the past, Emptor asks Venditor to establish its credentials by, for example, proving it belongs to the Better Business Bureau (BBB), Alice's most trusted source of information on online shops. eShop has such a credential and its policy is 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

• to never disclose two different credit cards to the same online shop and

• for anonymity reasons never to provide both her birth date and postal code.

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

Abstract

This use case is not about interchange of rules between people. It is about interchange of rules between tools that support people, referred to as “rule specification and editing systems” in the discussion below. Its value has two aspects:

• Businesses have to cope with large numbers of rules, originating from many different sources, often with overlapping scope and sometimes with conflicts. They need tools in which rules can be formally defined, analyzed and organized. The tools themselves are outside the scope of the RIF WG, but the RIF WG ought to be concerned with support for interchange of rules between them.

• An important requirement for interchange is that, increasingly, businesses cannot by themselves cope with the volume and scope of the rules that affect them. They rely on shared interest groups and expert advisors, and need to be able to acquire rules from these sources and integrate them into their own rule specification and editing systems.

CLARIFICATION OF SCOPE

Excluded from this General Use Case Category

• Rules that are not formally specified.

• Direct person to person communication of rules independent of rule interchange between rule editing systems.

• All of the rule specification, analysis and management functions in the rules editing systems (tools) for people who run organizations.

• Human processing of rules, i.e. rule interpretation, inference and enforcement actions by people (but not excluding the specification of rules themselves that may be so interpreted by, inferred from, or enforced by people).

• Any form of rules that is not fully declarative including procedural rules or rules containing actions (except that there is a requirement to interface with these types of rules).

• Broad business policies which need to be transformed into actionable rules for implementation.

• The mapping of rule and vocabulary meanings to all the different forms for structuring their meaning, and the definition of such forms for structuring meaning (except, of course, RIF; but not excluding the requirement to be able to be mapped to all these forms of meaning).

• The mapping of all the different rule and vocabulary forms for structuring meaning to the syntax/grammar of natural or artificial languages, and the definitions of any grammars, syntax and notation, including Controlled English.

Included in this General Use Case Category

• The interchange of the structure of the meaning of rules, and the vocabulary (‘terms and facts’) in terms of which the rules are formulated, between:

  • instances of the same or different kinds of rule editing systems/tools for people who run organizations, Rules Systems Supporting Interchange of Human-oriented Business Rules Rules Systems Supporting Business Communication of Rules, that support specification, analysis, verification & validation of rules in business terms using controlled natural language underpinned by formal logic.

  • the above ‘rule editing systems’ and all other types of rule systems, especially rule-enabled IT application development environments for, and/or rule system components of, the IT systems that support the organization’s business processes.

• All the kinds of rules, and the vocabulary (‘terms and facts’) in terms of which the rules are formulated, that are:

  • structured in a way that is interpretable in a formal model theory.

  • In the fully declarative form of rules

  • actionable

  • to be interpreted by, inferred from, or enforced by either people or computers

  • used by people who run organizations:

    • Regulations

    • Definitional Rules

    • Rules governing the operation of the organization (corporate governance, regulatory compliance, organization roles and responsibilities, workflow)

    • Rules specifying rule enforcement declaratively, i.e. the set of conditions required immediately upon completion of the enforcement action

    • Rules specifying products and services

    • Rules governing relationships, transactions and agreements with parties internal or external to the organization

      • Trading Agreements (buy/sell products & physical items)

      • Service Provision Agreements

      • Managed Service Agreements (In-house and/or Outsourced)

        • IT Service Agreements

        • Facilities Management Agreements

        • Call Center Agreements

      • Employment Contracts

      • Professional Service Contracts

      • Rental Agreements

        • Property Rental (e.g. apartment rental, storefront rental

        • Property Leases (e.g. 999 year flat leases in UK)

        • Equipment Rental (e.g. car rentals)

      • Construction/Manufacturing Contracts (e.g. make a dam, an airplane)

      • Partnership and Merger Agreements

      • Regulations imposed on the organization

[ See Interchange of Human-oriented Business Rules among the General Use Case Categories. ]

Detailed Scenario: ...to follow week of January 30th

Publication on the Semantic Web often involves rules in addition to factual information. These rules augment the accompanying information by communicating more precisely what it means and/or how it may be used.

One such case is the publication of a new Semantic Web vocabulary, the goal being to specify (proof-theoretic) semantics for some of the vocabulary elements with a low barrier to entry. The publisher may be any organization that wants to publish a reusable vocabulary, including formal standards bodies. Examples include the RDFS and SKOS specifications: rules are provided when the given semantics is not expressible in OWL or when the expression would be too cumbersome to be a useful communication tool. A RIF provides implementation neutrality whereby the publisher can convey rule-based expression of semantics in implementation-neutral form, leaving the consumer free to choose whatever implementation approach is appropriate.

Another case involves instance data. Here the role of rules is to publish how the data should be used or interpreted. For example, a FOAF user might publish a rule set along with their FOAF record describing which of their phone numbers should be used at which time:

Monday to Friday 
      IF 09:00 - 12:00, THEN call my office number
      IF 13:00 - 17:00, THEN call my office number
      IF 18:00 - 21:00, THEN call my home number
      IF 12:00 - 13:00, THEN call my cell number
      IF 17:00 - 18:00, THEN call my cell number
      IF 21:00 - 09:00, THEN do not call me

Saturday, Sunday and Holidays
      IF 09:00 - 21:00, THEN call my cell number
      IF 21:00 - 09:00, THEN do not call me

The benefits of a RIF in this case include individuals being able to share rules, avoiding the need for multiple copies in a group, and harvesting services being simplified by a uniform format.

This use case demonstrates how the RIF leads to increased flexibility in matching the needs and goals of end-users of a service or a service-delivery device, such as a cell phone, with the needs and goals of providers and/or regulators of such services. The RIF can do that by enabling deployment of third party systems designed to allow service providers and regulatory agencies to write the rules defining and governing their services once, leaving it to the third-party service to generate suitable interpretations and/or translations of those rules for any consumer process or device interested in using the service. There are at least two broad areas in which such third-party services could be deployed:

• Wireless Communications & Dynamic Spectrum Access

  • 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 given 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. This use case is developed in detail below.

• Web Services and Service Oriented Architecture

  • The advent of web-based service architectures offers the possibility of a more dynamic and flexible approach in which differentiated service definitions, or 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. The ability of a consumer process to understand the rules defining and governing differentiated SLAs is contingent upon those rules being in a form that the consumer process can use.

Suppose a region or nation adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users (e.g. government). 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 that such a device can transmit on such a band if no priority user is currently using that band. From the point of view of the device (and its designers) the question is how does it know that no priority user is currently using a band it wants to use? The answer will generally depend on the specific capabilities of the device. For example, one type of device may only be able to answer this question by means of sensing the amount of energy it is receiving on that band. If it senses no energy on the desired band it assumes no other device is using the band. However, a more sophisticated type of device, may be able to get information from another control channel that lets it know whether the desired band is ok to use at a given time or not. So each class of device will need to employ different "interpretations" of the policy in question.

Now assume that there are 10 manufacturers of the these 2 different classes of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing the "policy engines" of its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two classes 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 such 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 general classes of device - those that only use energy sensing to determine band use versus those that can use the control channel. 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 for their device architectures. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment (plus the cost of its membership in the consortium) with having to produce, test, and maintain different versions of various policies over the lifetime of a product. Moreover, this arrangement also allows the overall process to be organized in a fashion that follows and maintains the natural division of labor and the division of artifacts produced by that labor. In other words, the policy and its various interpretations are written and maintained in platform-independent artifacts. The 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 artifacts where it should be, possible operational interpretations of that change are inserted at the next level down, and then the implications for the various device architectures is generated automatically at the lowest level.

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to extend their expressive power. Knowledge representation enriched by rules may involve other expressiveness-enhancing techniques such as fuzziness, incomplete information, semistructured data, reification, and frames. A typical example, as detailed below, is the use of rules to describe complex relationships between binary predicates which cannot be captured in ontology languages alone.

A web ontology designer discovers that it's not easy to come up with a general description of a hasUncle relation. He tries to do it anyway by first defining an Uncle class and putting proper property restrictions on it:

ObjectProperty(hasSibling Symmetric) 
Class(Man partial Human)
Class(Parent partial
   Human
   restriction(hasChild someValuesFrom(Human)))
Class(Uncle partial
   Man
   restriction(hasSibling someValuesFrom(Human)))

Individual(Sam type(Human))
Individual(Bob type(Parent) value(hasChild Sam) value(hasSibling John))
Individual(John type(Man))

With the above axioms, it's possible to discover that John actually belongs to Uncle class as John is a sibling of Bob who has at least one child. However, the fact that John is an uncle of Sam is not available by the above OWL description. After further attempts, the ontology designer finally realizes that he cannot describe in OWL hasUncle relations among individuals without explicitly specifying each and every one of those relations. With rules, it's not difficult to describe hasUncle relation in a general way so that the relation can be derived from Parent-Child and Sibling relations:

ObjectProperty(hasSibling Symmetric) 
Class(Human partial
  restriction(hasSibling allValuesFrom(Human)))
Class(Man partial Human)
Class(Parent partial
  Human
  restriction(hasChild someValuesFrom(Human)))
Individual(Sam type(Human))
Individual(John type(Man))
Individual(Bob type(Human) value(hasChild Sam) value(hasSibling John))

Uncle001: hasUncle(?x,?y) :- hasChild(?z,?x) ^ hasSibling(?z,?y) ^ Man(?y) ^ Person(?z) ^ Person(?y)

Now, anybody who uses this extended ontology doesn't have to enumerate hasUncle relation instances as they are derived by the added rule. The rule, Uncle001, and the ontology may be publicly published in a standard interchangeable format so that many different rule engines can process it.