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

The primary goals of the RIF are to build a rules interchange format that is an effective means of exchanging rules, that has the potential to be widely adopted in industry, and that is consistent with existing W3C technologies and specifications.

A critical factors analysis is an analysis of the key properties of a project (in this case the RIF). A CFA is analysed in terms of the goals of the project, the critical factors that will lead to its success and the measurable requirements of the project implementation that support the goals of the project. This methodology is further explained in the CFA Methodology.

The main goals, critical success factors and requirements of the Rules Interchange Format are illustrated in

This diagram is not intended as a complete description of the goals, critical success factors and requirements. It's primary benefit is to provide a rapidly assimilated visual map of the text itself.

1. Goals

1.1. Exchange of Rules

The primary goal of the RIF is to facilitate the exchange of rules. This mission is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

  1. Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the RuleML Initiative and elsewhere.
  2. Rules provide a powerful business logic representation, as business rules, in many modern information systems.
  3. Rules are often the technology of choice for creating maintainable adapters between information systems.
  4. As part of the Semantic Web architecture, rules can extend or complement the OWL Web Ontology Language to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

The critical success factors for the exchange of rules are coverage and soundness. I.e., any means of exchanging rules must be broad enough to cover the technical requirements and it must be a stable platform for the exchange of rules.

  1. No Surprises (Soundness)
    • The RIF must be a sound basis for exchanging rules; i.e., it must be predictable what is exchanged when a ruleset is exchanged between partners and/or tools.
    1. Formal semantics
      • Where rules are interchanged between different tools and across language boundaries, assumptions about the meaning of the rules can be dangerous and difficult. A formal semantics framework will reduce the potential for error in the exchange of rules in such and may other situations.
    2. Interchange of rule sets will often involve different semantic environments, sometimes interchange will be attempted after the original rulesets are developed. Therefore, it should be possible to have RIF rule sets with different semantics.
      • Editor's note: no specific requirements for formal semantics have been submitted by group members.
    3. Markup of semantics
      • A 'no surprises' rule interchange is only possible if the original semantics of the rule sets to be interchanged is specified. Thus, a means is needed for specifying which formal semantics the rule set to be interchanged has.
    4. Meta language features
      • RIF should support meta language features such as priorities and preferences, and meta rules for meta reasoning.
  2. Coverage
    • The RIF should cover the major classes of rule formalisms that are in widespread use.

    1. The RIF should support first order deductive rules. See RIF Core must support deduction rules, RIF Core must cover pure Prolog and Extended RIF must cover FOL.

    2. The RIF should support Prolog-like rulesets. See Standard RIF should be Prolog-like but not Prolog-compatible.

    3. The RIF should support normative rules. See Standard RIF must support normative rules

    4. The RIF should support production rules. This includes all the major classes of production rule-like systems such as RETE-based systems and Event Condition Action rule-based systems. See Extended RIF must support production rules.and Standard RIF must support reactive rules

    5. Combined rulesets
      1. The RIF should support rule sets that are combinations of different kinds of rules (i.e., a mixture of deductive, normative, ECA rules and so on.) This may affect the semantic integrity of the ruleset language: restricting the kinds of semantics that can be ascribed to such combined ruleset.
      2. The RIF should support rule sets where rules are composed of features from multiple rule languages. For example, a condition in a RIF rule may be a SPARQL query.
    6. RIF should support uncertain and probabilistic information.

    7. All requirements that are under the CSF 'Alignment with Semantic Web'

  3. Extensibility
    • Given that rule languages are expected to continue to evolve, it is important that the RIF is able to incorporate rule languages not currently envisaged.
    1. Support typed languages (optional)
      • RIF should be designed in such a way that it permits the incorporation of type system(s).
    2. Support oracular models
      • RIF should offer support for models that are oracular, that is one needs to ask (a kind of) oracle for finding what the interpretation of RIF parts is. E.g. procedural attachments, aggregate functions are to be found in this category.
    3. Markup of semantics
    4. Conformance model

1.2. Widescale Adoption

It is an explicit goal of the W3C that the Rules Interchange Format will have the maximum potential for widescale adoption. Rules interchange becomes more effective the wider adoption there is of the specification -- the so-called network effect.

  1. No Surprises

  2. Coverage

  3. Low cost of implementation
    • The cost of supporting the RIF will have a direct impact on the extent of its deployability. This applies not only to any execution costs of employing the RIF but also to the design-time costs associated with it. For example, a RIF that requires expensive theorem provers to process the interchange, or requires highly complex implementation techniques, will be less likely to be deployed than one that is less demanding of technology and people.
    • It should be possible to build reasoners for intended ruleset languages without unnecessary burden.
    • Reasoners for RIF should make use of well understood implementation techniques.
    • It should be possible for a RIF reasoner to make use of standard support technologies such as XML parsers and other parser generators.
    • Low transfer costs (real-time requirements). Be inexpensive in representation (cost of transfer and cost of transformation) - RIF must be able to accomodate real-time performance requirements.

1.3. Consistency with W3C specifications

  1. Alignment with Semantic Web
    1. Support RDF

      1. RIF should accept RDF triples as data. See The RIF Core must be able to accept RDF triples as data

      2. RIF should express RDF deduction rules.See Standard RIF must be able to express RDF deduction rules

      3. Permit SPARQL queries to be used in rules.
    2. Support OWL

      1. RIF should accept OWL knowledgebases as data. The RIF Core must be able to accept OWL KBs as data

  2. Alignment with key W3C specifications

    1. Support XML See The RIF Core must be able to accept XML elements as data

    2. Permit XML information types (where appropriate) to be expressed using XML Schema

2. Open Issues

UCR/Critical Factors Analysis/Open Issues