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

This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways:

The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise.

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, as are the consulting companies CarWise and AutoLaw.

EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.

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

A business policy, stating that every car rental must be insured for damages to third parties.
A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this 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 tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager.

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 subsequently 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, to ensure that it can never 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), including the basic policy and the supporting rule set
The rule set for electronic compliance documentation (also from CarWise)
Its own rule set for building insurance into the 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 large 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, each of whom covers at least 25% of the risk.

A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary 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. To ensure that this dispensation is temporary, it adds a new rule:

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

EU-Rent HQ is also 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 rule is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently 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.

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:

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:

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