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

Proposals for RIF's design goals contains views on the design goals to be followed in developing a rule interchange format; these proposals are to be presented at F2F2 so as to initiate discussions for refining the following text.

Design Goal Categories

Here are five categories of design goals: 1) design goals concerning rule interchange, 2) design goals concerning rule-system interoperability, 3) design goals pertaining to the specification of the set of rule languages that are covered by the RIF, 4) design goals pertaining to RIF supported metadata features, 5) design goals pertaining to RDF/OWL compatibility.

Design Goals Concerning Rule Interchange

By the term "rule-interchange" we mean to include situations in which formal rule specifications are literally transferred among application environments or systems. The transfer typically involves some degree of processing/translation of the specifications and typically occurs prior to or independent of runtime.

In order to facilitate this discussion of rule interchange design goals consider [Figure-1].

The "Target Rule Languages" ovals represent rule languages, RL-1 through RL-n, that are within the scope of the RIF. How this target set is determined is discussed in the consideration of design goals pertaining to that question (see below).

For each rule-language in the target set a "To-RIF Translator" and a "From-RIF Translator" rectangle is shown (or implied by the ellipses in the figure). Rule-interchange is accomplished by 1) applying an appropriate To-RIF translator to the input rule specifications to yield a RIF-specification and then 2) applying an appropriate From-RIF translator to the RIF-specification to yield a rule-specification in the desired target rule-language.

Not-A-Design-Goal List

  1. The RIF does not provide any explicit goals or specifications on the design and implementation of the "To-RIF" and "From-RIF" translators for specific rule-languages.


    • There are a number of interesting points regarding translation to and from the RIF. First, it is conceivable that one and the same rule set might be translated into two or more non-equivalent RIF specifications by two or more different translator programs. It is even conceivable that all these translations are "good" (acceptable) under differing points of view or interpretations. Using the "right" From-RIF translator for each of these resulting RIF-specifications might yield good interpretations of the original rule-set from the appropriate point of view. So if the RIF were to have any design goals pertaining to the translators, they most likely should be stated in terms of corresponding pairs of <To-RIF, From-RIF> translators.

List of Possible Rule-Interchange Design Goals

  1. Enable fully automated interchange of rules defined in disparate rule-platforms (within the target set) yielding completely equivalent rule sets whenever possible.
  2. In cases where complete equivalence is not a reasonable expectation, the RIF should enable fully automated interchange of rules defined in disparate rule-platforms (within the target set) yielding rule-sets that represent a "best effort" at providing as good a translation as can be achieved.

    Commentary - Here are some relevant questions:

    • What does "complete equivalence" amount to? Does the RIF provide any guidance to help determining when complete equivalence is possible? Does the RIF ever make any guarantees about this process? If so, what are they and what are there conditions? In cases where the RIF cannot provide complete equivalence, should it provide explanations or reasons for the failure to do so?

Design Goals Concerning Rule-Interoperability

The term "rule-interoperability" refers to situations in which two or more disparate rule-based systems need to work together in "real time" to achieve some goal.

Rule-interchange may sometimes be a way of enabling interoperability, but that is certainly not the only use of rule-interchange. Moreover, interoperability of disparate rule-system does not necessarily require an underlying rule-interchange.

In order to facilitate this discussion of rule interoperability design goals consider [Figure-2].

The figure shows a way in which the RIF could enable interoperability. The boxes with ovals on the left of the figure represent processes that are 1) executing a particular rule-system process or program (represented by "RL-n"), 2) configured as "RIF Clients" that can issue "RIF RPC" calls to a server. The box with an oval on the right represents a process that is 1) configured as a "RIF-server" capable of handling RIF-RPC, and 2) executing a "RIF-based" rule-system process or program (represented by the oval with the "RIF"). So, for example, the process using RL-1 might execute a rule that causes a RIF-RPC call to be generated. Presumably this request contains information in RIF-format. The RIF-server gets the request and hands it off to the native RIF-based rule-system for processing. The results are then returned to the RIF-client.

List of Possible Rule-Interoperability Design Goals

  1. RIF-rule specifications should be executable as rules of inference. Therefore,
  2. One or more native RIF rule-engines is desirable and should be supported by the RIF specification.

Design Goals Concerning the RIF Target Set of Rule-Languages

The RIF WG charter divides the work of the group into two phases. In part, these phases are distinguished by the character of the rule-languages to be considered. For example, in phase 1, the working group is limited to considering rule-languages whose semantics is subsumed by Horn Logic semantics. This does consitute a constraint on the target set of rule-languages.

There are, however, many rule languages that meet this constraint, or that have well-defined subsets that meet this constraint. Are there are design considerations that would help to generate a more detailed understanding of the languages in the target set? Here are some possibilities.

List of Possible Design Goals Concerning the RIF Target Set

  1. The RIF should admit integrated ontology+rule languages into its target set.
  2. The RIF should admit rule-languages that allow for disjunctive heads in rules into its target set.
  3. The specification of the RIF target set is not really a specification at a "full language" level, rather it is done on a feature-by-feature basis. That is, the RIF specifies or defines a set of language features. A rule-language vendor or designer may combine these features into a what is intended to be a unified specification. Features that are mutually exclusive should obviously not be combined into a single rule-language, but the RIF does not explicitly say what should or should not be put together.
  4. The RIF should allow for or specify a feature corresponding to Integrity Constraints as used in database systems.
  5. The RIF should define at least one rule-language standard with a well-defined syntax and a well-defined semantics.
  6. The RIF should define or allow a set of rule-language features that approximates to a good degree the common feature-set of currently used rule-languages. Every feature supported by the RIF should be a feature that is in currently in common use.

Design Goals Concerning RIF Supported Metadata Features

  1. The RIF should ensure that the provenance of a translated rule-set or rule-query is maintained; enabling a recipient of a translated rule-set to be aware of the original rule language and of the semantic basis of that rule-language. [Added by FrankMcCabe]

  2. The RIF should support meta-level or metadata features which make it possible to create rule "templates" that capture patterns of semantic and/or syntactic structures common accross two or more rules.

Design Goals Concerning RDF/OWL Compatibility