This is an archive of an inactive wiki and cannot be modified.

1. NOTICE : Narratives still missing

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 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:

1.4. Relationship to OWL/RDF Compatibility

See requirement nb. 2

1.5. Examples of Rule Platforms Supporting this Use Case

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

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

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

  2. 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;
  3. 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;

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

1.8.2. Main Sequence

  1. RuleProductDeveloperA, B, C develop translators between their specific rule language and the standard RIF
  2. RuleBasedApplicationDeveloperA, B, C develop applications embedding rule product from RuleProductDeveloperA, B, C
  3. RuleDeveloper develops rules using rule product from RuleProductDeveloperX and exports them into a RIF package or stream

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

  1. RuleProductDeveloperA, B, C develop translators between their specific rule language and the standard RIF
  2. RuleBasedApplicationDeveloper develop application embedding rule product from RuleProductDeveloperA

  3. RuleDeveloper develops rules using rule product from RuleProductDeveloperA

  4. RuleConsumer uses application from RuleBasedApplicationDeveloperA

  5. RuleBasedApplicationDeveloper decides to switch rule product from RuleProductDeveloperA to RuleProductDeveloperB in the application

  6. RuleDeveloper exports rules into a RIF package

  7. RuleBasedApplicationDeveloper delivers application embedding rule product from RuleProductDeveloperB

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

Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.

1.9.1. (Title of Narrative)

Describe an individual scenario. Samples rules and other test data may be optionally included.

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)