W3C

RIF Use Cases and Requirements

W3C Editor's Draft TBD

This version:
(not published)
Latest version:
http://www.w3.org/TR/rif-ucr
Editors:
Allen Ginsberg (Mitre)
David Hirtle (NRC)
Frank McCabe (Fujitsu)
Paula-Lavinia Patranjan (REWERSE)

Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies use cases and requirements for a format that allows rules to be translated between rule languages and thus transferred between rule systems.

The Phase 1 version of this document presents use cases for RIF in general, but requirements primarily for Phase 1. The Phase 1 deliverables will provide an extensible base with which the use cases can be addressed, but it will not be until Phase 2 that most of these use cases are directly addressed by the Working Group.

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Please Comment By TBD

The Rule Interchange Format (RIF) Working Group seeks public feedback on this draft. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text which will address your concern.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.


Table of Contents

1. Introduction

(Editor's Note: This text is maintained on wiki page Introduction).

Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.

Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling exisiting rule-based technologies to interoperate according to standards-based methodologies and processes. The basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies.

The purpose of this document is to provide a structured context for formulating future technical specifications for RIF. We start by presenting a set of use cases that are representative of the types of application scenarios that RIF is intended to support (Section 2). Besides providing concrete examples for analysis, these use cases also represent a kind of committment, since it is expected that the relevant functionality specified in the use cases will ultimately be enabled by applications or systems that incorporate RIF technical specifications. Section 2 concludes with a high-level general analysis of the basic rule interchange process as exemplified in the use cases.

Additionally, the use cases illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Last, but not least, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.

Section 3 of this document begins with a brief explanation of Critical Factors Analysis, which is the methodology we are using to drive the process of capturing requirements RIF. This section enumerates the main goals of the RIF working group activity and relates them to what we believe are the key factors that are critical to attainment of those goals. Requirements, in turn, are measurable properties that directly support one or more of these critical success factors. This section includes diagrams that show the relationships among the goals, critical success factors, and requirements. Section 4 is basically a list and brief description of the requirements on RIF as of the current working draft.

It is important to understand that not all of these requirements are directly generated by functionality described in one or more of the use cases presented in section 2. Some of the requirements, e.g. "XML syntax" for RIF, are directly stated or implied by the working group charter. Some requirements are generated by the desire to guarantee that certain types of rule languages are within the scope of the RIF, e.g., the "RDF data" requirement. Some requirements, e.g., "Implementability," are general requirements on RIF as a whole, and do not need to be motivated by use cases. Such requirements are similar to what are called "non-functional" requirements in software engineering, since they are not connected with specific functionality delivered by incorporation of RIF within a system or application.

One of the critical factors for a successful RIF is that it be useful for interchange of rules among the set of rule languages it is intended to cover. Section 5, Coverage, deals with the issue of how to characterize the space of rule languages in such a way that clear and principled decisions as to what the RIF will (and will not) cover can be made. We note that in this document we deliberately refrain from defining the notion of "coverage" in a rigorous manner, since precisely what it means for diverse rule languages to be "covered" by RIF may vary from case to case. Intuitively, when we say that "RIF covers rule language L" we mean that there is at least one standard dialect of RIF into which rules written in L can be translated and vice versa.

2. Use Cases

(Editor's Note: This text is maintained on wiki page Use Cases).

Nearly fifty use cases documenting the need for a RIF were originally submitted. These were grouped into eight general categories and then synthesized as much as possible. In the second round, two new use cases were added. The following use case descriptions, guided by this synthesis, provide scenarios that motivate the need and explain the benefits of a RIF. They are also intended to provide an ongoing reference point for the working group in its goal of providing a precise set of requirements for a RIF.

In order to enhance readability and avoid the appearance of syntactic prejudice, we have deliberately avoided the use of formal notation in representing rules in these use cases except where doing so might introduce ambiguity. However, this informality may lead readers to the conclusion that rules can perform arbitrary actions in the real world. This is not the case; the RIF WG has not yet decided on the ultimate power that rules will have.

2.1. Negotiating eBusiness Contracts Across Rule Platforms

(Editor's Note: This text is maintained on wiki page Negotiating eBusiness 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 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.

Motivates:

  • Compliance model -- An obvious constraint on the rule languages used in John's and Jane's applications is that they must support a RIF class of expressiveness that is sufficient to express the rules they need to interchange. Although this is obviously true whether they use RIF for the interchange or not, in the RIF case, the applications may need to be aware of the RIF expressiveness class of the other part. In that sense, it motivates the "compliance model" requirement.

  • XML syntax -- the use case explicitely states that rules are interchanged as an XML document.

  • XML types -- the use case motivates the "XML types" requirement, since the agreed exchange data model in terms of which the rules are specified is an XML schema: for example if the rules are going to do tests and arithmetic on values transmitted over that XML then the semantics of those tests ought to be compatible with the corresponding XML datatypes - including all the annoying corner cases of NaNs, treatment of equality in floats/doubles, type promotion etc. If either end use different representations for the concrete types internally then the RIF "translators" are going to have to compensate.

  • Coverage -- suppose that Jane's company uses a Prolog-like rule language, and John's company uses a production rule language. To exchange rules, it must be possible to translate between rule language dialects. For example, prolog rule bodies map to production rule conditions and prolog rule heads map to production rule actions, all the while preserving the intended meaning.

2.2. Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences

(Editor's Note: This text is maintained on wiki page Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences).

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 credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.

Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/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).

Rules express compactly possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In our example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials to disclose. Note, however, that this is a deliberately simplified example in which credentials' requests can be handled more directly.

For determining whether Venditor's request for information is consistent with Alice's policy, 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 constraints as rules; choosing the type of rules for implementing policies depends also on the capabilities of the Emptor system.

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.


Motivates:

Default behavior

The rule systems employed by the agents involved in a negotiation, Emptor and Venditor here, might have different capabilities. Thus, situations may occur where an agent does not understand (part of) the rules received from the other agent, even though they were interchanged through RIF. In such cases, a way to specify the default behavior would at least ease the understanding of the reasons why the negotiation failed or entailed just partial results, such as access to part of the data or services.

Limited number of dialects

Because of the rich diversity of agents in the setting of automatically establishing trust through negotiations, a limited number of RIF dialects would decrease the number of negotiations that failed because of incompatible dialects.

Rule language coverage

Intuitively, it is clear that RIF should cover features found in most of the existing policy languages. A more detailed discussion on the rule language coverage follows.

Syn 1.7 Means to access data in Web formats

Policies frequently contain simple ontologies; means to access and reason with OWL data is needed for applications involving such policies.

SeS 2.9 Priority

A conflict resolution mechanism is needed e.g. in situations where different policies may apply; prioritizing policies would be useful in such cases.

ECA 5.1 General

Policies may need support for event detection, event communication, and execution of actions; thus, support for reactive behaviour is needed.

ECA 5.4 Actions

Different kinds of actions are needed, such as updates to data, sending events, procedural attachments, etc.

Types 6

Support for datatypes is needed; the kinds of datatypes depend on the considered application.

Dialect Identification

The dialect specification of the interchanged rules together with information on the compatibility between the (standard) RIF dialects used by the parties, which need to establish trust by interchanging rules, can be used in this setting for deciding to continue the negotiation or not. Incompatible (standard) RIF dialects do not support the negotiation of the parties involved.

Merge Rule Sets

Often, agent softwares need to adopt existing policies, such as rules regulating some application domain, which might be written in other rule languages than the one used by the agent. In such cases, these existing policies need to be merged with agent's own policies, i.e. there is a need for merging rule sets.


Concrete examples given in Protune


2.3. Collaborative Policy Development for Dynamic Spectrum Access

(Editor's Note: This text is maintained on wiki page Collaborative Policy Development for Dynamic Spectrum Access).

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.

This use case concerns Dynamic Spectrum Access for wireless communication devices. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, 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.

Motivates:

Default Behavior

The regulatory policies specify certain constraints, e.g., "if radar is sensed on a channel in use, the channel must be evacuated within 10 seconds," which can be viewed as a default for a device to be in compliance. However, the RIF-based specifications promulgated by the consortium will not simply state the constraint, but rather contain a set of implementable rules that make it possible for a suitably configured device to meet this constraint. For some configurations and device types these rules may go beyond simply ceasing transmission on the channel, e.g., the device might send a control message to a master device (an access point) asking if an alternate channel is available, etc. As long as these additional steps do not prevent devices from vacating the channel within 10 seconds (and do not violate any other constraints) they are allowed. So, it would be worthwhile to allow the RIF-based specifications to "point" to a RIF-based version of the general 10-second constraint as a default behavior if the more detailed rules cannot be applied.

Different semantics

Depending upon the needs of an application, there are a number of ways that a formal representation of a policy can be achieved. A device may need to reason about what a policy requires and it may also need to allow its behavior to be guided by the policy. In the former case, deductive logic can be used to formulate statements and draw valid inferences as to what the policy entails. For example, relative to the 10 second channel evacuation requirement mentioned above, it turns out that if a device (or its associated master) checks for radar every 9 seconds then there will be enough time to evacuate the channel if needed. So a RIF-based specification might contain a declarative rule that states "if a channel is in use, and it's last radar check was 9 seconds ago, then a radar check on that channel is due." The important thing to note here is that the rule is a statement (capable of being true or false) of what the implementation requires. In order to utilize such statements to guide the behavior of a device, connections must be forged between conclusions reached and actions to be taken. Production rules, specifically, ECA rules can be used to establish those connections. For example, "if it has been concluded that a radar check for a channel is due, then do <action>!" Since this use case envisions devices that are both capable of reasoning about policy requirements and being guided by them, we expect that these RIF-based specifications will require rules having both declarative and imperative semantics.

Limited Number of Dialects

As the use case states, RIF-based specifications are beneficial because they allow a group of interested parties (the consortium) to write machine-usable specifications that can be deployed to a wide variety of devices provided the device manufacturer, or other party, writes a "RIF-compiler," i.e., translator, for the given device platform. If RIF-based specifications were themselves allowed to take on many different forms in a non-cohesive fashion, and specifications using them were generated, it is possible that this benefit would be compromised. In other words, a manufacturer or third party might find it necessary to invest too much time in maintaining translators to make use of the RIF worthwhile.

OWL data

The rules in these applications will utilize concepts that are defined in accordance with the definitions devised by standard organizations. The use of OWL ontologies is likely for that task. Moreover it is possible that future protocol message payloads might contain OWL data.

Coverage

The rules require support for negation. The rules react to changes in the environment. Features from production rules and ECA rules such as forward chaining, events, and actions will be useful.

2.4. Access to Business Rules of Supply Chain Partners

(Editor's Note: This text is maintained on wiki page Access to Business Rules of Supply Chain Partners).

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.

How such a unifed view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, 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.

Motivates

Default behavior

The rule systems employed by the supply chain partners might have different capabilities. Thus, situations may occur where interchanged process rules cannot be (safely) executed. In such cases, a default to revert to manual processing, or rejection of the process definition, may be required.

Different semantics

Business logic implemented in Business Processes (eg in BPM environments) may be expected to be used in different semantic environments. An example of this would be simple interchangeable business logic that is executed in BPM environment #1 using an inference rule engine, and passed to a BPM environment #2 using an "script" (rule) engine (without inferencing). In this case if inferencing rules are detected in the supply chain process being interchanged, and the receiver only has scripted engine support, then the default behavior may be invoked.

Embedded Comments

Additional information may be required by supply chain partners if their default behavior is to NOT automate the rule execution, whereas the originator's rules were automated.

Embedded Metadata

Metadata that is appropriate to the supply chain interchange of rules may include applicability of the ruleset(s) (aka preconditions), compliance regulations affected, cost per use, etc.

Implementation of supply chain policies and practices as business rules is considered "well established". Implementability of supply chain partner rules as (for example) production rules will support this motivation.

Limited Number of Dialects

Minimizing the number of RIF dialects (aka rule semantics supported) will maximize the applicability and usability of rules in supply chain scenarios.

OWL Data

For those industries that utilize OWL (eg pharma, healthcare, academia), the representation of supply chain data in OWL and their subsequent references in supply chain intra-business rulesets will be required.

RDF Data

For those industries that utilize RDF (eg content management, academia), the representation of supply chain data in RDF and their subsequent references in supply chain intra-business rulesets will be required.

XML Types, XML Syntax

Much supply chain information (data) is transported as XML, which is replacing EDI. Therefore support for XML is critical for the supply chain use case.

2.5. Managing Inter-Organizational Business Policies and Practices

(Editor's Note: This text is maintained on wiki page Managing Inter-Organizational Business Policies and Practices).

This use case is about organizations that acquire rules sets from external sources and have to integrate them into their existing rule bases. Acquisition of such rule sets includes:

  • Buying rule sets from expert sources

  • Using rule sets from shared interest groups such as trade associations

  • Propagating rule sets across a distributed organization, with different localization requirements in different regions and locations

This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the Semantics of Business Vocabulary and Business Rules Specification. The EU legislation discussed is also fictitious.

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.

An EU regulator issues a directive dealing with insurance for vehicles owned by companies. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with:

A business policy: Every car rental must be insured for damages to third parties.
A supporting rule set, addressing levels of cover required, tax calculation in different EU countries, liabilities in rentals that span multiple countries, reporting of compliance with the business policy.

EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as:

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

Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases.

EU-Rent corporate HQ then decides that the cost of third-party insurance will be built into the basic cost of each rental, and not shown as a separate item on the rental contract, so that there is no possibility that it can be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU:

The rule set for car rental insurance (from CarWise)
The rule set for electronic compliance documentation (also from CarWise)
Its own rule set for building insurance into basic rental cost.

The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for fleets with more than one insurer in order to spread the risk, for example:

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.

EU-Rent UK also has a timing issue. It has some existing insurance policies in place, which provide third-party insurance as an explicit item, and EU-Rent UK cannot get refunds on early termination. It asks corporate HQ for a dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules.

EU-Rent HQ permits this, not just for the UK, but for any of its operating companies that have similar insurance arrangements. It also adds a new rule:

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

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.

Implication for Requirements

Many of the rules and rule sets interchanged via the RIF will be directly executable. Some will need human intervention, which is likely to be of two kinds. First, rule sets (especially general rule sets from external sources) may need to be localized before being used or further distributed within an organization, e.g.

  • Connected to relevant data sets

  • Irrelevant rules excluded

  • Local rules added

Second, during execution, some rules may need an input from a person, such as a decision or some data.

Motivates:

Embedded metadata

Metadata, applicable to both rules and rule sets, will be needed for:

  • “not immediately processable” indicators

  • "from" and "to" effective dates

Embedded comments

Comments will be needed for guidance on what intervention is needed before rules can be executed automatically (or should this be considered as metadata?).

Different semantics

Rule sets acquired from third parties may be presented in rule languages with different semantics.

OWL data

Part of user intervention may be to indicate which knowledge base(s) need to be referenced for localization of reusable rule sets.

Default behavior

Requires default behavior:

  • not to try to execute marked rules or rule sets;

  • to inform RIF Client owner that marked rules and rule sets cannot be automatically processed without some intervention beforehand.

Merge rule sets

This is a central requirement of this use case (although it’s possible it could be done in tools outside the RIF).

Identification of rule sets

This is important for replacement of acquired rulesets with updated versions or alternative rulesets.

XML syntax

Required for compatibility with developments taking place in parallel with RIF (e.g. in OMG, OASIS, XBRL).

2.6. Ruleset Integration for Medical Decision Support

(Editor's Note: This text is maintained on wiki page Ruleset Integration for Medical Decision Support).

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected 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 databases, 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, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated HbA1c level. 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 databases, which gives the patient record, including the medications a patient is currently taking

  • the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures

In this case, MEDIC uses all three sources, and pulls up the following information:

  • Metformin is contraindicated with contrast dye.

  • Metformin is the generic form of Glucophage.

  • Bob is taking Glucophage.

  • The contrast MRI requires as one of its steps injecting the patient with contrast dye.

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

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

Motivates:

Embedded comments

Note that this requirement isn't entirely clear. The requirement reads "RIF must be able to pass comments." Are these comments about the rules themselves, or explanations for the rules (which might be used, say, by a human user to explain policy to a consumer), or advice about how to handle rules which conflict?

Suppose it is the second. Let us assume also that there are comments/explanations for the rules from the pharmaceutical knowledge based used by MEDIC. Then there is a link between this requirement and UCR Case 6. One would want the comments from the pharmaceutical KB passed on to MEDIC.

Embedded metadata

Suppose MEDIC has the following method for dealing with contradictions: If a rule set is inconsistent, it attempts to find a maximally consistent subset (MCS) of the rule set. Since there will always be muliple MCS. it needs to find a way, based on some preference criteria, to calculate a preferred MCS, or to choose among multiple MCS's. One preference criterion could be assigning a low priority to rules from the medical event data base, which could lead to the event being rescheduled. Another preference criterion could assign a low priority to the rules from the patient data base, which might lead to a patient’s medications being temporarily changed. In order to implement this preference criterion, MEDIC needs to know the source/author of each rule.

OWL data

Suppose at least one of the knowledge bases or data bases above is written in OWL. A likely candidate would be the pharmaceutical knowledge base, due to the highly taxonomic structure of such knowledge bases. Then clearly the RIF will need to be able to cover OWL knowledge bases.

RDF data

Again, assume one of the data bases above contains RDF data. Then clearly, the RIF will need to be able to cover RDF data.

Coverage

This needs more analysis and more detailed specification of the types of rules that will be used.

2.7. Interchanging Rule Extensions to OWL

(Editor's Note: This text is maintained on wiki page Interchanging Rule Extensions to OWL).

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

Motivates:

  • Coverage, especially

    • Syn5: slotted arguments are a good fit for RDF/OWL properties

    • Syn6: webized names

    • Ses1: hybrid rules so OWL predicates can be used in rules

  • Limited number of dialects because OWL has a limited number of dialects

  • OWL data because this extends OWL

  • RDF data because this extends OWL and OWL supports RDF data

  • XML syntax because this extends OWL and OWL has an XML syntax

  • XML types because this extends OWL and OWL supports XML types

2.8. Vocabulary Mapping for Data Integration

(Editor's Note: This text is maintained on wiki page Vocabulary Mapping for Data Integration).

This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models.

Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management and customer information management. The following scenario comes from the world of IT systems management.

Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine:

  • a report on application services and associated servers, databases and networks (from the IT department)

  • a maintenance contracts database (from the finance department)

  • a registry indicating which business processes use which IT services (from the business planning group)

Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, BusinessProcess and Dependency. This involves rules such as:

If x is a ComputeNode in Rack r
   and Rack r is in Cage c
   and mc is a MaintenanceContract for Cage c
      then x is a Server with MaintenanceContract mc

If x is a ComputeNode with a NetworkInterface with Port p
   and app is an Application running on Port p
      then x is a Server that hosts app

If bp is a BusinessProcess that uses Application app
      then bp has a Dependency on app

He then creates rules that combine the data across his now simplified data sources, e.g.

If bp is a BusinessProcess that has a Dependency on Application app
   and x is a Server with MaintenanceContract mc that hosts Application app
      then bp has a Dependency on mc

This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views.

Motivates:

  • Embedded comments, Comments might be helpful when integrating diverse sources

  • Coverage

    • Syn5: slotted arguments are a good fit for RDF/OWL properties

  • Limited number of dialects the value of RIF in this use case (reusability of the rules across the enterprise) is only realised if there is a good chance that the dialect Vlad uses is supported widely by the tools other users might have access to

  • RDF data, Sources can be mapped into RDF

2.9. BPEL Orchestration of Rule-Based Web Services

(Editor's Note: This text is maintained on wiki page BPEL Orchestration of Rule-Based Web Services).

Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.

An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.

The credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as:

  • number of times a payment was 60 days late

  • debt-to-income ratio

  • number of foreclosures or repossessions

  • number of garnishments

  • number of liens

  • bankruptcy

A red flag above the threshold results in denial of credit.

Rules in the second ruleset increment a credit score variable. For example:

If applicant owns residence then add 40.

If applicant rents then add 30.

If applicant has lived at current address 2 to 4 years then add 20.

If applicant's income is under 20000 then add 10.

If applicant's income is between 40000 and 50000 then add 40.

The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

Motivates:

Coverage

  • The scoring rules express actions and not logical conclusions. Therefore production rules are required. These additional RAF discriminants are also relevent:

    • Syn 5: Slotted (Keyed, Role-Named) Arguments, since they directly correspond to attributes in Web service descriptions

    • Syn 6: Webized Names, since URIs are fundamental to Web service descriptions

    • SeS 9: Priority, since conflicts between credit evaluation rules can often be solved based on relative rule importance

    • Sem 2: Decidable, since there must be a definitive answer for every credit request

    • Sem 3: Finite-Model Rulebases, because of the reason given for Sem 2

    • Prag 2: Computational complexity should be tractable, since response time should be acceptable

    • Prag 3: Interoperability Annotations should use Controlled English, since justifications/explanations of decisions should be understandable without formal training

XML data

  • Web services depend on XML request and response formats.

XML types

  • Rule variables must be bound to fields from the XML request and response formats.

2.10. Publishing Rules for Interlinked Metadata

(Editor's Note: This text is maintained on wiki page Publishing Rules for Interlinked Metadata).

The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that capture implicit knowledge. To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary.

One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at http://imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following:

Every science fiction movie is a movie.

Every movie produced before 1930 is black and white.

Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify the maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements.

Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at http://altmd.example.org. In addition to metadata, it again publishes its own rules:

All movies listed at http://altmd.example.org but not listed at http://imd.example.org are independent movies.

All movies with budgets below 5 million USD are low-budget movies.

Publication of rules with explicit references to other rulesets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified scope is important in the Web environment, since it can reduce the danger of unintended interference from rules published at other remote sources, which may be exporting their own predicates.

Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being used to specify how to use other metadata, e.g. in the form of a widespread vocabulary such as FOAF or a standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule:

If Charlie is currently attending a public talk according to http://charlie.example.org/calender.ical
    then leave him a voicemail message

If Charlie is currently in a meeting according to http://charlie.example.org/calender.ical
  and the importance is high
    then call his cell number

If Charlie currently has no appointments according to http://charlie.example.org/calender.ical
    then call his office number

RIF should allow extending current standards for metadata publication by enabling such implicit knowledge to be captured via rules and allowing metadata and rules distributed over different sources to be interlinked. In a manner similar to how HTML links human-readable Web pages, RIF should permit linking metadata on the Web to support new kinds of "intelligent" crawling and search.


Motivates:

Coverage

The following discriminators in the Rule Arrangement Framework are particularly relevant for this use case:

Syn 1.4 Explicit vs. Implicit Rule Scope

  • Scoped inference and Scoped NAF are needed to model the rules in this use case

Syn1.6 Webized Names:

  • HTML and RDF use IRIs to link data and metadata on the web, and so rules which define implicit interlinked metadata.

Syn1.7 Means to access data in Web formats:

  • access of data in RDF, and other XML based data, respecting ontologies in OWL are essential for this use case.

SeS2.2 Fact-and-Rule Bases:

  • This use case needs mixed fact and rule bases.

SeS2.8 Certain vs. Uncertain Clauses and Atoms:

  • Default rules to specify default, implicitly defined metadata which may be overridden by more specific facts are an issue in this use case.

Sem3.2 Finite-Model vs. Infinite-Model Rulebases:

  • The models of RDF alone are infinite already by the infinite number of axiomatic triples. On the contrary finite models are desirable for the evaluation of the consequences of rule sets.

RDF data (OWL data)

The described rules shall take metadata in the form of RDF facts as a basis. As a possible extension additional inferences over OWL ontologies shall be taken into account, see also Semantic tagging below.

Semantic tagging

A layered approach such as taken in SPARQL (or allowing SPARQL queries in rule bodies) which decouples the adopted entailment regime (simple, RDF(S), OWL, etc. entaiment) from the semantics of such rules is possible, which requires semantic tagging of rulesets.

2.11. Analysis of Usage Scenarios and Their Processing Models

(Editor's Note: This text is maintained on wiki page Analysis of Usage Scenarios and Their Processing Models).

Usage Scenarios and Processing Models

The basic usage scenario for RIF is that a producer agent produces a set of rules in some rule language, serializes it in RIF and publishes the resulting RIF document; and that a consumer agent gets the RIF document, deserializes it into some rule language and processes it for some purpose.

In the use case Negotiating eBusiness Contracts Across Rule Platforms (UC1), for instance, both actors, John the buyer and Jane the supplier, use a rule-based application to compute the price of requested or supplied items under various conditions (real or hypothetical). They interchange the pricing rules that are specific to a supply contract, e.g. specifying how the actual price is to be computed from the list price under specific circumstances. In the use case scenario, the processing of rules goes as follows:

  1. John writes the pricing conditions he wants for a requested supply;

  2. John issues a RFP, including the rules;

  3. The RFP is serialized in XML according to an agreed-on XML schema, the serialization of the rules in compliance with RIF;

  4. The XML documents, including a RIF document, are sent to Jane;

  5. The RIF document is translated back into a set of rules;

  6. Jane executes the rules to compute the revenue for her company under various hypotheses (some where the rules impact the revenue, e.g. shipping delays etc);

  7. Jane modifies some of the rules (and execute them to analyse other hypotheses);

  8. Jane prepares an answer to John's RFP, including the rules, some of which having been modified, and send it to John (the rules are translated into a RIF document on Jane's side, whci is translated back into a set of rules on John's side);

  9. John executes the rules to compute the cost for his company under various hypotheses (where the rules impact the cost, such as shipping delays etc);

  10. And so on, until they agree on a contract (or not).

Notice that steps 7-9 are the same as step 1-6, only in the other direction: initially, John (more precisely, John's application) is the producer agent and Jane's application is the consumer agent; at the next stage of the contract's negociation, they swap roles and Jane's application becomes the producer and John's application the consumer. So, that, from a rule processing point of view, the architecture/processing model for the use case looks basically like the picture below, where Application A is the producer of the rules (and of the RIF document), and Application B : the consumer. We call the applications that produce a RIF document from rules or rules from a RIF document "translators" (represented by the "maps" arrows in the figure).

Usage scenarios may vary in many ways with respect to the basic scenario and the example above. One is the precise interchange model:

  • it may be point-to-point, as in the example above, one-to-many, many-to-one;

  • another dimension is whether the interchange works in push mode (send/receive or broadcast/receive) or in pull mode (publish/retrieve).

The table below shows how the use cases compare with respect to the interchange model (UC7 does not describe a specific interchange model and is not included in the table):

Point-to-point

One-to-many

Many-to-one

Push

UC1, UC2 (1)

UC5 (2)

Pull

UC3 (3), UC8, UC9 (4), UC10

UC4, UC6

(1) The use case describes an interaction in "push" mode. Notice, however, that it could work in "pull" mode as well.

(2) Between EU-Rent and its affiliates.

(3) Between the 3rd party that produces the RIF rules to the devices that execute them.

(4) Where the credit histories vendor publishes its history evaluation rules.

The main impact of the interchange model on RIF is that the interchange may require more interaction in push mode, as the producer may need to know, beyond the "expected behaviour" requirement, whether or not the consumer was able to process the rules.

Usage scenarios may vary in other ways, such as the kind of processing to which the rules are subjected on the consumer's end: They can be exploited by a rule engine for the purpose of inference, but that can also be processed as data by other types of applications (e.g. a rule editor, a rule verification or validation tool...): e.g. UC1 and UC9 mention modifying or editing received or retrieved rules; UC10 also involves editing, verifying and localising rulesets.

The scenarios where the consumer uses the rules to draw inferences, require that the rule engine accesses a data source where it finds the facts on which the rules apply. In some cases, such as in UC1 (see the above figure), the producer and the consumer share the same data source, which they interchange along with the rules; in other cases, such as in UC10, the rules are explicitly scoped for use with specified data sources; in yet other cases, the interchanged rules apply to the consumer's own data source.

The basic processing model, as described above, has the producer translating the rules from the rule language it uses into a RIF document and the consumer translating them back from the RIF document into the rule language used by its own application. For the consumer to be able to use the rules for inference, the translation must, in particular, map elements of the RIF rules onto the data model of the consumer's data source. That is, the parties in a RIF-based interchange of rules must agree on a data model for use in RIF rules from and into which they can map their own application's data model: in UC1, the agreed-on data model on which the RIF rules are based is shared as an XML schema; in UC8, it is shared as an OWL ontology; in UC10, as RDF vocabularies.

The general architecture for a RIF-based interchange can thus be represented as in the picture below.

One important variant of the basic usage scenario is the roundtrip, where the producer and the consumer are the same application. In the simplest case, the roundtrip involves only translating rules from the application rule language into RIF and back: e.g. if RIF is used as a persistence format, or for interchange between applications using the same rule language and data model. In the general case, the roundtrip involves the rules being translated from one rule language and data model into RIF, from RIF into another rule language and data model, back into RIF, and then back into the original rule language and data model: this is the case in UC1, where the rules are interchanged back and forth between John's and Jane's application, and possibly modified by each side.

3. Goals

(Editor's Note: This text is maintained on wiki page Goals).

A critical factors analysis (CFA) is an analysis of the key properties of a project (in this case the RIF). A CFA is analyzed in terms of the goals of the project, the critical factors that will lead to its success and the measurable requirements of the project implementation that support the goals of the project.

  • Goals

    • A goal is an overall target that you are trying to reach with the project. Typically, goals are hard to measure by themselves. Goals are often directed at the potential consumer of the product rather than the technology developer.

  • Critical Success Factors

    • A critical success factor (CSF) is a property, sub-goal that directly supports a goal and there is strong belief that without it the goal is unattainable. CSFs themselves are not necessarily measurable in themselves.

  • Requirements

    • A requirement is a specific measurable property that directly supports a CSF. The key here is measurability: it should be possible to unambiguously determine if a requirement has been met. While goals are typically directed at consumers of the specification, requirements are focused on technical aspects of the specification.

  • CFA Diagram

    • It can often be helpful to illustrate graphically the key concepts and relationships between them. Such diagrams can act as effective indices into the written descriptions of goals etc., but is not intended to replace the text.

      The legend:

      illustrates the key elements of the graphical notation. Goals are written in round ovals, critical success factors are written in round-ended rectangles and requirements are written using open-ended rectangles. The arrows show whether a CSF/goal/requirement is supported by another element or opposed by it. This highlights the potential for conflict in requirements.

Description of Goals

The primary goal of the RIF is to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.

Consistency with W3C specifications
  • This is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with the RIF.

    CSFs directly supporting this goal: Alignment with Key W3C Specifications

Exchange of Rules
  • The primary goal of the RIF is to facilitate the exchange of rules. This mission is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

    1. Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the RuleML Initiative and elsewhere.

    2. Rules provide a powerful business logic representation, as business rules, in many modern information systems.

    3. Rules are often the technology of choice for creating maintainable adapters between information systems.

    4. As part of the Semantic Web architecture, rules can extend or complement the OWL Web Ontology Language to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

    CSFs directly supporting this goal: Coverage, Extensibility, Predictability

Widescale Adoption

Critical Success Factors

Alignment with Key W3C Specifications
Coverage
Encouragement of Interoperability
  • RIF will encourage interoperability, e.g., overlap between dialects and distinguished dialects with maximum overlap.

    Goals that are supported by this CSF: Widescale Adoption

    A compliance model supports interoperability in that a formal understanding of what it means to comply to the RIF is essential to the succesful use of RIF, and hence to interoperability. The alternative to a formal compliance model is an informal one: i.e., that defined by what popular tools support.

    Requirements supporting this CSF: Limited number of dialects, Compliance model

Extensibility
  • Given that rule languages are expected to continue to evolve, it is important that the RIF is able to incorporate rule languages not currently envisaged.

    Goals that are supported by this CSF: Exchange of Rules

    CSFs opposing this CSF: Low cost of implementation

    Requirements supporting this CSF: Default behavior

Low Cost of Implementation
  • The cost of supporting the RIF will have a direct impact on the extent of its deployability. This applies not only to any execution costs of employing the RIF but also to the design-time costs associated with it. For example, a RIF that requires expensive theorem provers to process the interchange or requires highly complex implementation techniques will be less likely to be deployed than one that is less demanding of technology and people.

    Goals that are supported by this CSF: Widescale Adoption

    CSFs opposing this CSF: Coverage, Extensibility

    Requirements supporting this CSF: Compliance model, Implementability, Standard components, Translators

Predictability

4. Requirements

(Editor's Note: This text is maintained on wiki page Requirements).

The Working Group has currently approved the following requirements. This list is a work in progress and may change in future drafts, especially for Phase 2.

Note that certain requirements, including some of those specified in the charter (e.g. named arguments and Horn Logic as a semantics) are not explicitly mentioned in the list below. It is intended that these requirements will be incorporated via the Rulesystem Arrangement Framework (RIFRAF). The umbrella requirement, Rule language coverage, will thus entail the entire set of requirements implicit in the RIFRAF.

Note also that a language is said to be 'covered' by RIF if RIF can be used to interchange rulesets written in that language. The Working Group expects to provide a precise framework for talking about coverage and interoperability in a later draft.

General

Implementability

RIF must be implementable using well understood techniques, and should not require new research in e.g. algorithms or semantics in order to implement translators.

Semantic precision

RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extends RIF core.

Extensible Format

It must be possible to create new dialects of RIF and extend existing ones upwardly compatible.

Translators

For every standard RIF dialect it must be possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language.

Standard components

RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators, and should not require special purpose implementations when reuse is possible.

Phase 1

Compliance model

RIF must define a compliance model that will identify required/optional features.

Default behavior

RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior.

Different semantics

RIF must cover rule languages having different semantics.

Embedded comments

RIF must be able to pass comments.

Embedded metadata

RIF must support metadata such as author and rule name.

Limited number of dialects

RIF must have a standard core and a limited number of standard dialects based upon that core.

OWL data

RIF must cover OWL knowledge bases as data where compatible with Phase 1 semantics.

RDF data

RIF must cover RDF triples as data where compatible with Phase 1 semantics.

Rule language coverage

RIF must cover the set of languages identified in the Rulesystem Arrangement Framework. See the Coverage section.

Dialect Identification

RIF must have a standard way to specify the dialect of the interchanged rule set in a RIF document.

XML syntax

RIF must have an XML syntax as its primary normative syntax.

XML types

RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications. See the charter on Datatype support.

Merge Rule Sets

RIF should support the ability to merge rule sets

Identify Rule Sets

RIF will support the identification of rule sets.

Phase 2

XML data

RIF must be able to accept XML elements as data.

5. Coverage

(Editor's Note: This text is maintained on wiki page Coverage).

The RIF Rulesystems Arrangement Framework (RIFRAF) is meant to define a description space for existing (or potential) rule languages (rule systems). Each criterion defines an axis with two or more values that can be used to discriminate between, or at least characterize, rule languages.

The idea is not that every criterion used in the RIFRAF should be reflected in a coverage requirement: on the contrary, the RIFRAF will be used to identify and to prioritize features and to abstract classes of rule languages/systems that need to be covered by RIF.

The Working Group is currently working to populate the RIFRAF description space with the specific rule languages/systems that need be covered by RIF.

The starting point for the RIFRAF was a set of criteria deemed especially relevant for Phase 1 of RIF. It has and will continue to evolve as it is populated: the description of additional rule languages/systems may require the addition of new criteria (descriptors/discriminators). Phasing is not a limitation, since the anaysis of the populated RIFRAF will also be used to prioritize requirements with respect to phases.

The set of criteria described below is the current state of the RIFRAF. It is included to provide the reader with a snapshot of the work in progress at the time this working draft is released and with a concrete idea of the meaning of the coverage requirement. It should not be construed as a list of requirements for RIF coverage, nor as a representation of how the Working Group views the space of rule languages and systems at this time.

RIFRAF

Expressive Discriminators (or Dimensions) are collected here into four groups:

  • Purely-Syntactic

  • Syntactic-entailing-Semantic

  • Semantic

  • Pragmatic

Values of Semantic and Pragmatic Discriminators, stated by Rulebase authors or found by Static Analysis, can of course still be marked up syntactically, e.g. via Semantic/Pragmatic (XML) Attributes on Rulebases, Rules, ..., via (RDF) metadata annotations, etc. In each group, Discriminators, and possibly subgroups of Discriminators, are listed (cf. rdf:subPropertyOf). The numberings of the Discriminators do not reflect priority orderings but are there for ease of reference such as "Syn 1.2" for the Range-restrictedness Discriminator (however, new subgroups may emerge from subsequences of neighboring Discriminators).

For most Discriminators there exists a lot of literature, under various names. For example, Discriminator SeS 1 on "Homogeneous vs. Hybrid Rules" is discussed, under this name, in Combining Rules and Ontologies. A survey. That paper provides various Subdiscriminators useful for OWL Compatibility. The Hybrid approach is further described in A Realistic Architecture for the Semantic Web.

The RIF-crucial Interoperability Discriminators are regarded here as Pragmatic Discriminators, and grouped under Prag 3.

Syn: Syntactic Discriminators
  1. Restricted vs. Unrestricted Use of Logic Variables

    1. Single-occurrence variables (no implicit variable equality) vs. Multiple-occurrence variables (implicit variable equality; if an equality predicate is available, this can be made explicit via tests in the body; e.g., using an 'equal' predicate, the multiple-occurrence p(?x,?y,?x) :- q(?y) can be transformed into the single-occurrence p(?x1,?y,?x2) :- equal(?x1,?x2), q(?y))

    2. Range-restricted Rules (No Head-Only Variables) vs. non-Range-restricted Rules

    3. (Further Restrictions from Static Analysis Research)

  2. Predicate Variables Permitted vs. Not Permitted

  3. Monotonic Lloyd-Topor Extensions Allowed vs. not Allowed

  4. Explicit vs. Implicit Rule Scope

  5. Slotted (Keyed, Role-Named) vs. Positional Arguments

    • Allowing n-ary atoms with a set of n 'attribute=value' pairs as in RDF/OWL properties, F-logic methods, and object-oriented systems http://www.ruleml.org/indoo

  6. Webized vs. non-Webized Names

SeS: Syntactic-entailing-Semantic Discriminators
  1. Homogeneous (Body has Single Expressiveness Class) vs. Hybrid (Body has Two Expressiveness Classes) Rules

  2. Fact-only (Database Tables) vs. Rule-only vs. Fact-and-Rule Bases

    1. Variable-ful (Non-Ground) vs. Variable-free (Ground) Facts (also under "Variable-ful vs. ... Clauses")

  3. Function-ful (FO Horn Logic) vs. Function-free (FO Datalog)

    1. Function Arity/Arities

    2. Fixed vs. Unfixed Function Nesting Depth

    3. Uninterpreted vs. Interpreted Functions

  4. Variable-ful (Non-Ground) vs. Variable-free (Ground) Clauses

    1. Variable-ful (Non-Ground) vs. Variable-free (Ground) Facts (also under "Fact-only ... Bases")

  5. Predicate Arity/Arities

  6. Number of Premises in Rules

  7. Labeled (Anchored, OIDed) vs. Unlabeled Clauses

    1. Labels Allowed vs. not Allowed as Arguments of User Predicates and/or System Predicates (such as in SCLP's priority-giving 'overrides' predicate, cf. SeS 9)

  8. Certain vs. Uncertain Clauses and Atoms

  9. Priority

    1. Static vs. Dynamic: Static priority does not change. It could be specified using a numeric constant, a list of rule (labels) with lesser (or greater) priority, or the position of rules within a ruleset document could be significant. Dynamic priority can change during rule execution.

    2. Rule ordering vs. rule selection: All applicable rules are tried in priority order, or only the highest priority rule is tried.

Sem: Semantic Discriminators
  1. Turing-complete vs. not Turing-complete

  2. Decidable vs. semi-decidable vs. undecidable

  3. Finite-Model vs. Infinite-Model Rulebases (cf. decidability)

  4. Modality allowed or not (beyond FOL)

Prag: Pragmatic Discriminators
  1. Inference control

    1. No chaining (only 'one-shot' rules) vs. forward chaining vs. backward chaining vs. bidirectional chaining

    2. Incremental (one solution at a time) vs. exhaustive (all solutions at once)

  2. Computational complexity (the complexity class of the inference procedures; generally this is the worst-case complexity, however most algorithms can be optimized for certain cases; rule systems can be classified by their complexity classes)

  3. Interoperability Annotations

    1. Controlled English

    2. Mappings

      1. Within Expressive Equivalence Classes ("clusters")

      2. Between Expressive Equivalence Classes (imperfect or "lossy")

    3. (Further Interoperability Discriminators should go here)

6. Conclusion

(Editor's Note: This text is maintained on wiki page Conclusion).

"The Semantic Web is about two things. It is about common formats for integration and combination of data drawn from diverse sources, where the original Web mainly concentrated on the interchange of documents. It is also about language for recording how the data relates to real world objects. That allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing."(From http://www.w3.org/2001/sw/, italics added)

The paragraph above characterizes in a very high-level fashion how Semantic Web technologies are supposed to provide a path towards web-wide interoperability. Clearly, getting data to be couched in standard formats and allowing the relationship of data to the “real world” to be represented in a precise fashion are necessary conditions for turning “data” into machine-processable information having an invariant meaning across platforms (and to humans). However, we have italicised the phrase “move through” in the last sentence of the quotation to direct attention to the fact that when machines “move through” the semantic web they will typically be processing the information they encounter in some way. Thus, another aspect of the drive towards web-wide interoperability is the challenge of representing the processing that machines perform in a way that is invariant across platforms. The goal of this working group is to provide such representational formats for processes based on the use of rules and rule-based systems.

As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks, and, therefore, rule-based systems are not monolithic. Rules have been used to perform or validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real-time, determine the need for human intervention, and so on.

In light of this diversity the working group expects that RIF, rather than being a single all-encompassing format, will consist of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) within each dialect. This should allow the main benefits of RIF to be realized. For example, the invariant meaning of a set of integrity-constraint-enforcing rules would be represented within the appropriate RIF dialect and could then be translated into the native format of any of the formalisms capable of representing such rules.

Each RIF dialect will be built upon the same common core. RIF must be designed in such a way that it is possible to create new dialects based upon the core, as well as update existing dialects (upwardly compatible). This is in keeping with the working group charter’s call for an “extensible format.” Other requirements on the core, and RIF as a whole, are included in this document in the section Requirements. Work on the technical specification of RIF core is presented in the document Core.

Achieving inter-dialect interoperability is, by its very nature, an ill-constrained problem since, by definition, 100% meaning-preserving translations between dialects with different semantics are not likely to exist in most cases. That is not to say that useful inter-dialect “translation” is impossible, only that additional criteria are required in order to formulate precise notions of what satisfactory translation (via interchange of RIF rules) amounts to in such cases. Developing criteria for understanding and managing RIF inter-dialect translations is not within the current phase of RIF working group activity.


END OF DOCUMENT. WIKI-TR diagnostics:

WARNING: missing previousVersion
WARNING: missing otherStatus
retreiving 'Introduction'...
Done.
retreiving 'Use_Cases'...
Done.
retreiving 'Negotiating_eBusiness_Contracts_Across_Rule_Platforms'...
Done.
retreiving 'Negotiating_eCommerce_Transactions_Through_Disclosure_of_Buyer_and_Seller_Policies_and_Preferences'...
ERROR: SGML2PL(sgml): []:6: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:6: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:6: Syntax error: Bad attribute list, found "/"
Done.
retreiving 'Collaborative_Policy_Development_for_Dynamic_Spectrum_Access'...
Done.
retreiving 'Access_to_Business_Rules_of_Supply_Chain_Partners'...
Done.
retreiving 'Managing_Inter-Organizational_Business_Policies_and_Practices'...
Done.
retreiving 'Ruleset_Integration_for_Medical_Decision_Support'...
Done.
retreiving 'Interchanging_Rule_Extensions_to_OWL'...
Done.
retreiving 'Vocabulary_Mapping_for_Data_Integration'...
Done.
retreiving 'BPEL_Orchestration_of_Rule-Based_Web_Services'...
Done.
retreiving 'Publishing_Rules_for_Interlinked_Metadata'...
ERROR: SGML2PL(sgml): []:17: Syntax error: Bad attribute list, found "/"
Done.
retreiving 'Usage_Scenarios_and_Processing_Models'...
ERROR: SGML2PL(sgml): []:4: entity "rename" does not exist
ERROR: SGML2PL(sgml): []:4: entity "drawing" does not exist
ERROR: SGML2PL(sgml): []:4: Syntax error: Bad attribute list, found "/"
Warning: SGML2PL(sgml): []:9: Element "span" not allowed here
Warning: SGML2PL(sgml): []:14: Element "span" not allowed here
Warning: SGML2PL(sgml): []:19: Element "span" not allowed here
ERROR: SGML2PL(sgml): []:19: entity "rename" does not exist
ERROR: SGML2PL(sgml): []:19: entity "drawing" does not exist
ERROR: SGML2PL(sgml): []:19: Syntax error: Bad attribute list, found "/"
Done.
retreiving 'Goals'...
ERROR: SGML2PL(sgml): []:2: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:4: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:14: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:16: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:18: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:20: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:22: Syntax error: Bad attribute list, found "/"
ERROR: SGML2PL(sgml): []:24: Syntax error: Bad attribute list, found "/"
Done.
retreiving 'Requirements'...
Done.
retreiving 'Coverage'...
Done.
retreiving 'Conclusion'...
Done.