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

Processing Models

(In what ways do we foresee RIF being used)

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 from the UCR document [Ref], 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 translators the applications that produce a RIF document from rules or rules from a RIF document (represented by the "maps" arrows in the figure).

Discussion_of_UC1_-_Negotiating_eBusiness_Contracts_Across_Rule_Platforms/ArchitectureUC1

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

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 wihch the rules apply. In some cases, such as in UC1 (and the ficgre above), 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 explicitely scoped for use with specified data sources; in yet other cases, the interchanged rules apply to the consumer own data source.

The basic processing model, as described above, has the producer translate the rules from the rule language it uses into a RIF document and the consumer translate 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.

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: it is for instance 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.

Deployment Models

TBC (Who will adopt RIF, when and why?)

Test Cases

TBC (What RIF test cases will look like)