1. NOTICE : Narratives updated / in progress

This is one of the possible Generalised Use Cases.

1.1. Abstract

A common use case for rule technologies is that an user organisation needs to switch rules from one rule product to another, and does not want to re-develop their rules. This requires rule interchange in a common format.

Another common use case is when two or more users/organisations need to interchange rules, for execution or further development, while remaining independent in the choice of the rule platform. A typical illustration of that use case is policy or regulatory compliance, where rules representing policies or regulations are developed or imposed by one user/organisation and applied by other ones, and the organisation owning the rules or requiring their application does not or cannot impose a (vendor) specific execution platform. A particular case is the rule-based implementation of a contract (where the rules are owned not by one but by all the parties, and are applied by all as well).

As far as rule interchange is concerned, these use cases have the common characteristic that the form of the rules and how they are used are known to all the parties in the interchange and common to all the rule systems involved. That is, all the rule systems involved share a common meta-model of the rules, and all their implementation-specific rule languages share a common abstract syntax.

1.2. Status

This generalized use case is supported by vendors (e.g. for production rules, Fair Isaac, Ilog, IBM, LibRT, PegaSystems and Corticon who are already participating in PRR for standardising at the modeling level) and users who will also want to support rule interchange into and out of their proprietary rule formats, or who want rules to be portable without wanting or being in a postion to impose a specific implementation (e.g. industry consortia, policy-setting bodies etc).

1.3. Links to Related Use Cases

This generalized use case is based on:

The Portability use case, proposed by SandroHowke and supported by a request from an ILOG prospect;
The Transfer of rules between different vendor products use case proposed by Paul Vincent of Fair Isaac.
The Real-time contract exchange use case, proposed by Paul Vincent of Fair Isaac
The Rule-Based Email Manipulation use case, proposed by the REWERSE consortium
The Operationally Equivalent Translations use case, proposed by Allen Ginsberg of MITRE

The Rule Interchange Through Test-Driven Verification and Validation use case actually proposes a method to guarantee that requirement of operational equivalence (see below) set by this use case is satisfied.

Use Cases shared with other categories:

Importing rules to check data compliance
(To be completed)

1.4. Relationship to OWL/RDF Compatibility

See requirement nb. 2

1.5. Examples of Rule Platforms Supporting this Use Case

Example rule engine vendors' (languages) include Fair Isaac Blaze Advisor (SRL Structured Rule Language); ILOG JRules (IRL Ilog Rule Language); (to be completed);
Domain XML standards that embed contractual terms into data streams such as the ACORD/SPX insurance example. In this case the buyer and seller are to do with insurance;
Email clients such as Microsoft Outlook or Mozilla, that embed a rule module for rule-based message processing/filtering

NOTE: The ACORD/SPX model today uses XPATH expressions to represent rules; this use case in no way implies any policy change by ACORD in supporting RIF instead of XPATH. Fair Isaac is a member of but does not represent ACORD.

1.6. Benefits of Interchange

The use case is about interchange (no interchange, no use case).

For the use case, the benefit of a standard RIF are

Making rules developed in any vendor- or implementation-specific rule language portable across platforms in a standard way lessens the risk of vendor lock-in and helps protect an user's investment in a rule base or a rule-based application;
It enables the "write once, run everywhere" paradigm (and increases the value of the rules, as a consequence);
It increases the appeal of rule-based implementation and application of constraints, policies, regulations etc.
It increase the efficiency of processes based or dependent on external constraints, policies, regulations etc (ability to check compliance locally, always up-to-date, etc)

NB: this generalised use case does not illustrate the "rule-set execution comparison" and "graceful degradation" benefits from the Operationally Equivalent Translations use case

1.7. Requirements on the RIF

The RIF must support the rule meta-models and include a concrete (XML) syntax for the abstract syntaxes shared by the parties involved in the use case scenarios. This includes at least: production rules (and derivative technologies, such as decision table processors); to be completed. (Vendors) specific implementations may have many proprietary extensions to basic features (e.g. event rules, exclusive tables, rule priorities, ...). RIF may support some extensions and may delegate others to simple textual notation (eg for manual update);
Rules, eg production rules, are defined against a data / object model. This is typically an in-memory model like Java objects, but for W3C work could be represented as either XML, RDF, OWL or an XML metamodel of the data model. The data / object model may be called the Business Object Model for PRs representing business rules. This needs to be either identified or communicated with the rules in RIF;
The RIF must guarantee the operational equivalence of the RIF: the same rules applied to the same input must produce the same behaviour whatever the rule systems on which they are executed. Use cases Operationally Equivalent Translations and Rule Interchange Through Test-Driven Verification and Validation propose ways to approach that requirement;
The RIF must be able to accomodate real-time performance requirements: in some scenarii, rules need be retrieved and executed in real-time, and, thus be inexpensive in representation (cost of transfer and cost of transformation).

1.8. Breakdown

1.8.1. Actors and their Goals

RuleDeveloper: Wants to publish rules to one or more consumers independently of what specific rule engine they use
RuleConsumer: Wants to use rules for further development and/or execution independently of what specific product they where develop on/for
RuleProductDeveloper: Wants rule product user to be able to switch product easily
RuleBasedApplicationDeveloper: Wants to be able to switch rule product with minimum impact on other developments

1.8.2. Main Sequence

RuleProductDeveloperA, B, C develop translators between their specific rule language and the standard RIF
RuleBasedApplicationDeveloperA, B, C develop applications embedding rule product from RuleProductDeveloperA, B, C
RuleDeveloper develops rules using rule product from RuleProductDeveloperX and exports them into a RIF package or stream
RuleConsumer uses application from RuleBasedApplicationDeveloperX and imports rules developed by RuleDeveloper from a RIF package or stream (import may need to be in real-time)

1.8.2.1. Pure rule product/application switching scenario

RuleProductDeveloperA, B, C develop translators between their specific rule language and the standard RIF
RuleBasedApplicationDeveloper develop application embedding rule product from RuleProductDeveloperA
RuleDeveloper develops rules using rule product from RuleProductDeveloperA
RuleConsumer uses application from RuleBasedApplicationDeveloperA
RuleBasedApplicationDeveloper decides to switch rule product from RuleProductDeveloperA to RuleProductDeveloperB in the application
RuleDeveloper exports rules into a RIF package
RuleBasedApplicationDeveloper delivers application embedding rule product from RuleProductDeveloperB
RuleConsumer imports rules from the RIF package (RuleDeveloper is a RuleConsumer for that step's purpose)

From a rule interchange point of view, the scenario is the same if RuleDeveloper/Consumer decide to switch rule-based application from RuleBasedApplicationDeveloperA to RuleBasedDeveloperB.

1.8.2.1.1. Variant: Rules persisted in RIF

Alternatively, the rules are persisted in the RIF and the rule product/application switching steps are transparent for RuleDeveloper and RuleConsumer. The sequence above then reduces to the main sequence, where the rules are exported to/imported from RIF package.

1.8.2.2. Using several Rule products

RuleConsumer may want, for the same rules, to use multiple rule products/applications for different purposes, because they have somewhat different features (e.g. for rule develoment, validation, execution in different contexts). Or RuleConsumerA, B, C use different rule-based applications but need to apply the same rules, developed by RuleDeveloperX, Y, Z.

The sequence is the main sequence.

1.9. Narratives

1.9.1. B2B Rule exchange as part of some Contract

CompanyA using RuleVendorA sets up an electronic business contract involving data AND rules with a supplier CompanyB. CompanyB however uses a different rule language by RuleVendorB in its IT operations. Both agree on a standard Business Object Model / data model (aka vocabulary / ontology) for the goods and services involved. CompanyA defines its purchase orders in terms of an XML description of goods, packaging, and delivery location and date, with delivery and payment rules: if goods.type = "foodstuff" and delivery.date > order.deliverydate + 10 days then goods.rejected = true. CompanyB replies with some suggested rule changes: if goods.type = "foodstuff" and delivery.date > order.deliverydate + 7 days and delivery.date < order.deliverydate + 14 days then goods.orderdiscount = 18.7%. CompanyA considers this and agrees it with CompanyB. Both organisations utilize these rules in their operational systems using disparate rule representations (from RuleVendorA and RuleVendorB) internally to compute prices etc for this order.

1.9.2. B2B Rule exchange across parts of some Organization

Consider the above narrative where CompanyA and CompanyB is replaced with DepartmentA and DepartmentB, who may be using different rule vendors / technologies but need to use / execute rules from each other. For example, the rules could be to assess metadata completeness for general processes (all relevant fields are completed): they are defined by the Compliance Department using RuleVendorA but needs to be executed as a task/process in amongst other rules in Manufacturing Department who use RuleVendorB to provide their embedded rule engine.

1.10. Commentary

As far as the Web effect is concerned, this is a boring use case that does not consider (even reject, I would say), unexpected usages. On the other hand, from the viewpoint of RIF adoption, this is probably the most fundamental use case. (csma, Friday the 13th)

Response by author: I agree! There is nothing sexy or advanced about extending common IT data interchange to IT rule interchange, and certainly this is little to do with extending the use of the semantic web (although if the semantic web was to be applied for B2B operations, the same considerations and use case would apply). PaulV, 14feb