

Basic RIF Processing Model

Prior to presenting the set of use cases in section 3 it will be helpful to have a more fully fleshed out model of how RIF is intended to function. This presents something of a "chicken and egg" problem, because in order to motivate such a model it is useful to have an illustrative concrete example (basically a use case) at hand. Modern technology, in the form of hypertext, comes to the rescue here: at this point we ask the reader to read at least Negotiating eBusiness Contracts Across Rule Platforms (UC1), and then return to this section.

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. Then 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 sends it to John (the rules are translated into a RIF document on Jane's side, which 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:

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





UC1, UC2 (1)

UC5 (2)


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. ***It is worth noting here that data models based on XML, RDF, and OWL, have special status in RIF, in part because of the RIF charter. Interchange of rules based upon the use of other data modeling formats might therefore require additional machinery beyond RIF-based translation software.***

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.