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.

(Possible renaming: Accommodating Diverse Interests in Business Process Design)

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. Combining information from multiple sources is also one of the key sources of productivity and value in knowledge workers' activities.

The role of the RIF is to support this integration in the cases where some or all of the information is held in the form of rules: business rules, policies, scientific data and so on. 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.Even 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. Companya single Company, where information is nominally under a common ownership domain but isdomain, in practice information is typically 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 managersFor example, a large company will often have its business logic represented in a distributed fashion -- each subsiduary using different Ontologies and different rule languages to combine multiple sourcesrepresents its business logic (always assuming that they are using some kind of information across different ownership domains: Supposerule language to represent business rule logic).

A Business Process Designer may often need to design processes that span multiple departments and subsiduaries. Where the business logic is represented in different rule languages this presents a product manager wantssignificant burden to predictthe effect of announcingBP designer in designing an integrated process. Business logic is often a new versioncritical aspect of his product. Folklore suggests that as soon as a new product is announced orders fordesigning business processes.

The existing version rapidly dry up as customers wait forRIF could be used in such a scenario to permit the new version. The sizeBP designer a unified view of the gap betweendifferent departments' business rules in designing the announcement and actual availability will haveprocess, while at the same time, permitting the individual departments to continue to leverage their business rules without changing their own technologies.

Apart from combining rules, a marked effect on sales.realistic information integration scenario will normally involve combining information in order to predict this effect, our product manager integratesmultiple forms: regular databases, RDF sets, OWL-based ontologies and so on. Also the current estimatemode of sales -- both actual orders and prospective orders -- together with estimates for manufacturing.access to the information for the sales is heldwill vary: in a database which has an RDF interface;some cases it will be possible to access the sales department has a supporting ontologysource of the knowledge directly, in OWL that allows analysisother cases access will be limited to query-style APIs and aggregation ofservices.

For example, in the raw information (such as what kindscase of customers and orders there are).the supply chainnew Business Process, when the process is composed of a number of contractors anddeployed, the corporate warehousing facilities, together with a shipping agent. Again,engine running the different enterprisesBP may either dynamically import the the business rule logic of multiple departments when they are not owned or controlled by our product manager except for predefined contracts that have been putin place. Those contracts have a representation as a collection of RuleML/OWL/Prolog facts; this enablesthe contract managersame organization. However, for a multi-partner process, partners are more likely to use themrequest a query-style access to incorporate service level predictionstheir business rules. In his automated planning. Finally,this case the product manager has access to a desktop utility called GoPlan that allows himbenefit of the RIF is to preparepermit a plan for the rolloutunified dynamic view of the new version and havebusiness rule logic while the system automatically queryengine supports a dynamic translation between the different stakeholdersinternal BP execution and the external partners' execution. For their information.this is possible because GoPlan is aware of the RIF, as are all the other stakeholders, and is ableto accommodatebe viable from a business perspective it is critical that the differences insemantics of the different sources of information. As a result, the new version is announcedrules and rolled out in a smooth way,query exchange be completely predictable and sales grow!preferably loss-less.

(Possible renaming: Decision Support Systems)

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with these rules are a criticalis an important part of this expert decision making. InterchangeFor complex decision support systems, it is also especially important, sinceexpected that rules will be furnished by a variety of different systems andknowledge bases are often involved (e.g.,and expert systems. For example, medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, hospitaldata bases giving laboratory results, and patient databases, pharmaceutical knowledgedata bases, etc.).among others. Rules interchange is therefore of paramount importance.

The followingfollow scenario illustrates the ways that rules interchange would be used in various medical decision support systems:systems. As explained in more detail below, rules interchange plays an important role for 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.

• Assisting professional education, e.g., determining how to customize training materials for residents with widely different levels of knowledge.

The Scenario:

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 hisHowever, eventually, Bob’s blood glucose became too highlevel began to rise, even under this regimen, he was prescribedregimen. Dr. Rosen used the drug Glucor (50 mg. tid). This helped temporarily. When Bob's blood glucose levels rose, he was switchedAutoDoc system to Hemi-daonil (1.25 mg., tid).help him decide when this no longer sufficed, he was switchedto Diamicron (80 mg., tid), and finallyswitch to Metformin (70 mg., tid), which has thus far controlled Bob's blood glucose level. Bob recently suffered a concussionmedications and has become increasingly forgetful. He wentwhich drugs to seeprescribe. The AutoDoc system uses two sources when making its recommendations: a neurologist, Dr. Cervello, who prescribedlaboratory database and a contrast MRI. When asked about current medication, Bob told Dr.knowledge base giving guidelines for the use of pharmaceuticals.

The laboratory database includes specific results for patients, e.g., such as fasting blood glucose levels for Bob. It also contains rules specifying when test results are outside of the normal range:

IF FastingBloodGlucoseLevel(patient) > 126 mg/dl 
   THEN BloodGlucoseControlled(patient) = false.

The pharmaceutical knowledge base contains comprehensive information about drugs, including dosage, indications, contraindications, side effects, and clearance times. An example of a rule expressing a contradiction for a drug is

IF  ContrastDye(x)  
   THEN Contraindicated(Metformin, x).

AutoDoc uses the rules from these two sources, along with its own rules, such as:

IF  (BloodGlucoseControlled(patient) = false and OnDietExerciseRegimen(patient) = true) 
   THEN NeedPrescribe(GlucoseControlMeds, patient) = true.

(In the sample rules above, knowledge representation concerns are glossed over; there is no attempt, in these examples, to correctly represent time, concepts of obligation or necessity, or other subtleties.)

Other examples of rules: If a patient is on a glucose control medication, and his blood glucose level is uncontrolled, that he needs to be switched; medications with less severe side effects and less frequent side effects are preferred, etc.

These rules are used, together with the rules obtained from the laboratory data base and the pharmaceutical knowledge base, to determine the appropriate course of treatment for Bob.

Rules interchange is a prerequisite for AutoDoc, since it uses rules from two different sources, in addition to its own rules. Reasoning with rules from all sources is enabled if the rules from all sources can be mapped to a RIF.

In this case, AutoDoc alerted Dr. Rosen when diet and exercise were no longer sufficient, and recommend Diamicron (80 mg., tid) for Bob. When that no longer controlled his glucose levels, it recommended switching to Metformin (70 mg., tid).

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 camewent to takethe lab to schedule his MRI, the radiology tech checked the hospital database and found that Bob was taking Metformin rather than Diamicron. The radiology tech put this information intomedical 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.) The rules inetc.).

MEDIC have been automatically generated usinguses a variety of sources in its reasoning, including

• the rules for product andpharmaceutical 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 compatibility from otherprotocol knowledge bases (e.g, more general knowledge about effectsbase, 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.

• Bob is taking Metformin.

• The contrast MRI requires as one of drugs on kidneys, drugs’ clearance time, etc.). After being informed,its steps injecting the radiologist toldpatient with contrast dye.

MEDIC therefore determines that Bob should not be taking the contrast MRI.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

The medical receptionist tells Bob that there is a problem scheduling the MRI. She talks to the radiologist, Dr. Bild, who explains to Bob that he needed to discontinue the Metformin for a few days before taking the MRI. The MRI wasis rescheduled for a few days later, after which time Bob beganbegins taking theMetformin again. The day after the MRI wasis performed, Dr. Bild, a radiologist who specializes in interpreting neurology scans, wentBild goes over the MRI scan. He used the hospital’s new Brain Reasoning System, an expert system that helps interpret brain scans,scan and determineddetermines 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,reasons (missing lectures on brain anatomy due to the flu; transferring from different residency programs; slept through most of medical school), 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,laptop connected to the internet, use the hospital’s new e-learning system TrainADoc to prepare themselves for the next day’s encounter. Each starts the e-learning sessionTrainADoc by answering a short questionnaire that assesses their knowledge or lack thereof of various subareas of neurology. The e-learning systemTrainADoc searches the internet for various learning sources to customize a program for each student based on his profile. Each learning source includes a set of courses, each of which has attached to it rules specifying the prerequisites for the course and the skills/knowledge learned once the course has been completed.

TrainADoc has general rules specifying that a student can take a course only if he has completed the prerequisites or his profile indicates that he already has the requisite knowledge.

Using the rules attached to the various learning sources, the profiles that the students have completed, and its own rules, TrainADoc customizes a set of materials for each student. It then brings back the materials that will fill in their gaps of knowledge. X, Y, and ZThe students each spend several hours going through their customizedmaterials. The next day, they are able to answer Dr. Cervello’s questions.

Having a RIF is a prerequisite for TrainADoc: The rules of each of the learning sources that is found on the internet must map onto the RIF in order for TrainADoc to customize each resident’s learning program.

The RIF is used in this use case to enable interchange between general knowledge bases (pharmaceutical knowledge bases, medical protocol knowledge bases), specific data (patient records, lab results, profiles of medical residents), and decision support systems.

This use case takes place in the medical domain. It should be emphasized, however, that the principles illustrated carry over to many other domains. For example, situation assessment is a critical part of military decision making: one needs to evaluate a specific situation to determine whether reinforcements are needed. It is also important for investment applications, where the first step is determining the financial situation of a customer, and then determining his needs (for investments, for tax relief). The analogies carry over to the other functionalities discussed, including prescribing courses of action, and professional education.

In all these domains, it is to be expected that rules will be culled from a variety of sources. For example, for situation assessment in the military domain, data comes multiple sources, including data bases, human observation, and automated sensors; policies, expressed as rules, come from upper management; operating procedures come from middle management. For situation assessment in the investment banking domain, data comes from records of financial transactions kept in multiple data bases; banking regulations come from individual banks, as well as the government. Having a unified rules interchange format so that a decision support system can reason with rules from these multiple sources is thus a prerequisite for these domains as well.

(Possible renaming: Negotiating e-Business Contracts across Rule Platforms)

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 worrying about being locked into a particular system. 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 contributers.

John is negotiating an electronic business contract regarding the supply of various types of widgets 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. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using the RIF. 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:

IF widget.type = "foodstuff" 
AND delivery.date  >> order.deliverydate + 10 days
THEN goods.rejected = true

Jane replies with some suggested rule changes:

IF widget.type = "foodstuff" 
AND delivery.date  >> order.deliverydate + 7 days
AND delivery.date < order.deliverydate + 14 days
THEN widget.orderdiscount = 18.7%

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.

(Possible renaming: Representing Buyer and Seller Policies and Preferences in eCommerce Transactions)

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 anautomated negotiating agent for buyers. eShop employs software called "Venditor" as anautomated negotiating agent for sellers.

These two systems negotiateAlice'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.

The negotiationPolicies are themselves subject to access control. Thus, rule interchange is basednecessarily done during negotiation and (in general) depends on the policies andcurrent level of trust that the credentialssystems have on each system has. Alice'sother. Since Emptor and eShop's policies describe who they trustVenditor 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 what purposes.enabling the rule interchange between the two systems.

When Alice clicks on a "buy it" button at the eSho'seShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends the relevantparts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that

• "aa buyer must provide credit card information together with delivery information (address, postal code, city, and country)." Emptor now determinescountry).

For determining whether Venditor's request for information is consistent with Alice's policy, the policy Alice has provided. Alice has a credit card but herEmptor policy states that she is not willingtakes its rules into account, which state for example

• to disclose itAlice's credit card information only to online shops belonging to everyone. Since Alice has never bought anything from eShop inthe past,Better Business Bureau.

By disclosing (interchanging) the above given rule, Emptor asks Venditor to establish itsprovide credentials by, for example, provingsaying that it belongs to the Better Business Bureau (BBB),Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy iscontains 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

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

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 eShopseShop'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 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.

(Possible renaming: Tools for Managing Policies and Practices in Large Organizations)

Interchange of Organisation-directed Rules

This use case demonstrates how the RIF could support business people in sharing guidance on how to run their business. The RIF could do this by enabling interchange of rules that are directed at the organization rather than its IT systems (e.g. where “customer” is the real person that buys the business’s goods and services, rather than a row in the business’s database). Some of these rules will not be automatable.

The “rule engine” that deals with such rules is a combination of a tool and a person; that should not make any difference to the RIF. The people using the tools will categorize the rules stored in the tool and decide:

• Which are about real world activity. They will be transformed into procedural guides for people in the business.

• Which are about IT. There are three possibilities (not mutually exclusive):

  • They will be mapped to existing IT rules that will support them

  • They will transformed to new IT rules

  • New IT rules will be acquired from some external provider.

There are many areas of business application for this capability, including:

• Regulatory compliance
  Many businesses are overwhelmed by the volume of regulation they have to comply with, and the number of uncoordinated sources of regulation. They are increasingly dependent on external sources - shared interest groups such as industry associations, and paid advisors such as lawyers and consultants - for guidance on how to comply.
  

• Terms and conditions for outsourcing of business services
  Some companies provide outsourcing of business services, which may be (from their clients’ perspective) outward-facing, such as deliveries to customers, or inward-facing, such as premises maintenance. Contracts usually include rules about how staff will act - for example, how a maintenance crew will deal with building security - as well as how IT systems will interact.
  

• Guidance for business conduct in different countries and regions
  Multinationals need rules for localizing business behaviour. They have a wide range of application - etiquette, advertising, pricing, incentives, contracts, after-sales support, etc. Such rules are likely to require input from local experts, either paid advisors or official sources in the home country and/or the target country.
  

• Operational policy changes in distributed organizations
  When a business decides to change what it is doing - ranging from strategic innovations to continuous improvement - it needs to distribute the rules for the new regime. These kinds of change may originate within the business, or be adopted as a general recommendation from an industry association or an external advisor.
  

• Trading agreements
  Rights and obligations of participants in trading agreements.
  

• Changes to employment terms and conditions
  Examples include: agreements negotiated with unions or staff associations; changes in working practice after outsourcing of services; pension provision; introduction of new work practices such as flexi-time or teleworking.
  

One capability that support tools should have is cross-referencing of rules in different domains; for example, relating employee rights, operational policies, employment regulations and privacy regulations.

Suppose that there are several software vendors that supply support tools of the kind described. They form an agreement to extend their tools with capabilities:

• To accept rules received in the RIF, for integration into their tools’ knowledge bases.

• To generate rules in the RIF from their tools’ knowledge bases, for transmission to others.

Then, as an example of use, think about regulation. Suppose that there are advisors - industry associations, lawyers, consultants, etc. - who provide interpretation of regulations and recommendations on compliance. They negotiate with regulators:

• “If our members/clients took your regulations to mean this … would that adequately capture your intent?”

• “If our members/clients did this … in response to your regulations, would that be acceptable compliance?”

This negotiation may be complex. Regulations from different regulators may interact - for example, there are conflicts between privacy regulations and Sarbanes-Oxley - and regulators don’t often talk to each other. The advisors store their conclusions in support tools that can generate RIF, so they provide guidance to their members/clients in a platform-independent form. They may also provide some pro-bono, for anyone who needs them.

Now consider compliance officers in organizations that are clients/members of these advisors. They have support tools that can accept guidance in the RIF.

They rely on external advisors for general interpretation - what the regulations mean to businesses in their industries, in the countries where they operate, and what rules they should follow for compliance. When new interpretations and recommended compliance appear (because of new regulation or new rulings on existing regulations), the advisors’ support tools prompt the compliance officers’ tools, and deliver the rules in the RIF.

When compliance officers have a general interpretation, they have to relate it specifically to their organizations - how it impacts their policies and operations, including all the guidance (employment, trading, localization etc.) stored in their support tools.

Sometimes, company-specific interpretations are difficult. Obvious courses of action may conflict with what is already in place for other regulations. There may be possibilities for adapting something already in place to serve new regulations in addition to its current purpose, rather than creating a new, specific solution.

Compliance officers may need more help. There are web sites that can provide it - industry groups and paid advisors (in addition to the ones subscribed to), regulators’ advisory services, national advisory services, other companies willing to share their experience. But a compliance officer needing help may not know them by URL.

A support tool should be able to deal with this, finding web sites that can provide relevant content, preferably in directly-usable form in the RIF. Then it should organize the results (by topic, by regulation, by relevance, by reliability of source, whether available in RIF or not, etc) and deliver them to the compliance officer, for local interpretation.

(Possible renaming: Defining Concepts and Relationships for the Semantic Web)

Publication of factual information on the Semantic Web often needs to be complemented by conditional information to communicate precisely what it means and/or how it may be used. Rules are an unambiguous and potentially machine-processable way of providing these extra conditions. Rules with variables also allow to generalize specific cases to (conditional) situation patterns.

A case where rules add clarity and precision to factual information is the publication of a new Semantic Web vocabulary, where the goal is to specify (proof-theoretic) semantics for some of the vocabulary elements with a low barrier to entry. Examples include the RDFS and SKOS specifications. Where appropriate, inference rules are expressed using the Jena 2 rule syntax, or as RDF statements using the OWL vocabulary. They are described in prose when this is not possible 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.

Rules may also be used to precisely communicate how data should be used. For example, a future FOAF user might publish not only unconditional information about their preferences but also conditional information, i.e. a rule set. This would complement their normal FOAF profile, e.g. describing which of their phone numbers should be used at which time of day depending on the day of the week:

Monday to Friday 
      IF 09:00 - 12:00 OR 13:00 - 17:00, THEN call my office number
      IF 12:00 - 13:00 OR 17:00 - 18:00, THEN call my cell number
      IF 18:00 - 21:00, THEN call my home 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

In some cases, the publication of rules may more precisely communicate both what the accompanying information means and how it may be used. For instance, the IDM laboratory wants to publish an ontology of the anatomy of the brain cortex and a vocabulary to describe facts about items on brain images, such as can be provided by computer-assisted or automated image analysis tools. Hospital, medical practices and medical imagery laboratories want to use the ontology and vocabulary to improve and streamline their communication.

To communicate the semantics of the properties defined as part of the ontology and vocabulary in a precise and unambiguous way, IDM publishes a set of rules to capture relationships between ontology and/or vocabulary properties, e.g.:

Two MaterialAnatomicalEntities (MAE) having a shared boundary are connected: 
      isMAEBoundedBy(?x1,?x3) Λ isMAEBoundedBy(?x2,?x3) Λ MAE(?x1) Λ MAE(?x2) Λ GyriConnection(?x3)
       ->->
      isMAEConnectedTo(?x1,?x2)

Two MAE entities having a shared connection are connected:
       connectsMAE(?x3,?x1,?x2) Λ MAE(?x1) Λ MAE(?x2) Λ GyriConnection(?x3)
        ->->
       isMAEConnectedTo(?x1,?x2)

One MRI laboratory uses an automated image analysis tool to extract facts about brain images and wants to use the ontology and the vocabulary to describe items on the images. The rules are retrieved in the RIF and translated into the rule language specific to the engine used by the application. They are executed to automatically label the brain cortex structures - sulci and gyri - in the brain images, based on the facts extracted by the image analysis.

(Possible renaming: Manufacturer and Service Provider Consortiums for Rule-Interchange Services)

This use case demonstrates how the RIF leads to increased flexibility in matching the needs andgoals of end-users of a service or a service-delivery device, such as a cell phone,service/device, with the needs andgoals of providers and/orand regulators of such services.services/devices. The RIF can do that by enablingbecause it enables 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 tothat can generate various suitable interpretations and/or translations of those rules for any consumer process or device interested in usingthe service.sanctioned rules governing a service/device. There are at least two broad areas in which such third-party services could be deployed: Wireless Communications &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 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 processa device to understandabsorb the rules defining and governing differentiated SLAsthe 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 consumer processdevice can use.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 or nationadopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users (e.g. government). Theusers. (The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems ,systems, a band intermittently used by military and weather radar, is a recent example. (Seeexample - See http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf ).)

Suppose the policy states that sucha wireless device can transmit on sucha 5 GHz band if no priority user is currently using that band. From the point of view of the device (and its designers) the question isHow does ita device know that no priority user is currently using a band it wants to use? The answer will generallydepend on the specific capabilities of the device. For example,One type of device may only be able toanswer this question by means ofsensing 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 sophisticatedsecond type of device, may be able toget information from anothera control channel that lets it know whether the desired band is ok to use atbeing used by a given time or not.priority user. So each classtype of device will need to employ different "interpretations" or "operational definitions" of the policy in question.

Now assume that there are 10 manufacturers of thethese 2 different classestypes of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing the "policy engines" ofits devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two classestypes 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 suchregional 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 casecase, 2 RIF versions of the DFS policy are provided for the 2 general classestypes of device - those that only use energy sensing to determine band use versus those that can use the control channel.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 for their device architectures.compilers. 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 andmaintains the natural division of labor andin the corresponding division of artifacts produced by that labor. In other words,labor: the policy and its various interpretations are written and maintained in platform-independent artifacts. Theartifacts (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 artifactsartifact heirarchy where it should be,be; possible operational interpretations of that change are inserted at the next level down, and thendown; 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.

(Possible renaming: Defining Concepts and Relationships in Ontologies)

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 the hasUncle property. He tries to do it anyway by first defining the Uncle class using suitable property restrictions:

ObjectProperty(hasSibling Symmetric) 
ObjectProperty(isUncleOf inverseOf(hasUncle))
Class(Man partial Human)
Class(Parent complete
   Human
   restriction(hasChild someValuesFrom(Human)))
Class(Uncle complete
   Man
   restriction(hasSibling someValuesFrom(Parent)))

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

He is pleased to discover that the above axioms entail that John actually belongs to the Uncle class, since John is a Man and has a sibling Bob who is (implicitly) a Parent (Bob is a Human and has a child, Sam, who is also a Human).

However, the axioms do not entail that "John isUncleOf Sam". After further attempts, the ontology designer finally realizes that it is impossible to describe the desired relationship between the hasSibling, hasChild and hasUncle properties in OWL. Instead of explicitly specifying each and every instance, he would obviously prefer to describe the hasUncle property in a general way so that instances of the property can be derived from Parent-Child and Sibling relationships. This is easily accomplished by extending the web ontology definition with a rule:

ObjectProperty(hasSibling Symmetric) 
ObjectProperty(isUncleOf inverseOf(hasUncle))
Class(Man partial Human)
Class(Parent complete
  Human
  restriction(hasChild someValuesFrom(Human)))
Class(Uncle complete
   Man
   restriction(hasSibling someValuesFrom(Parent)))
(Class(Uncle partial 
  restriction(isUncleOf someValueFrom(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(?x)

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