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

The Working Group is to specify a format for rules, so they can be used across diverse systems. This format (or language) will function as an interlingua into which established and new rule languages can be mapped, allowing rules written for one application to be published, shared, and re-used in other applications and other rule engines. (See http://www.w3.org/2005/rules/wg/charter)

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.

The main goals, critical success factors and requirements are illustrated in

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. 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
  3. 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'

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

  1. Allen's last proposal (http://lists.w3.org/Archives/Public/public-rif-wg/2006May/0209.html) based on the notion of rule language families

3. Design Principles

Design principles are not requirements on RIF, they aim just at guiding the development of the RIF.

  1. Syntax
    1. An human legible syntax
    2. A syntax for exchange (e.g. XML or RDF)
    3. An abstract syntax
  2. Abstractions for reusability and maintainability
    • Support for modules and other structuring/abstraction mechanisms (e.g. capability to bundle actions that are complex or used frequently into procedures -- in case of reactive or ECA rules)
  3. Language coherency
    • Coherency refers to a couple of sub-principles to be followed so as to obtain a uniform and easy to use RIF. Rules are made of components such as the body and head of deductive rules and the event part, condition part and action part of ECA rules; to gain coherency, these rule components should follow same paradigms. Moreover, some components (such as the body of deductive rules and the condition part of ECA rules) have same design goals and thus they shouldn't be specified by using different RIF component languages.

4. Use Case Support for Design Constraints and Principles

The use cases submitted by the RIF Working Group members offer solid grounds for considering the above given critical success factors and requirements as design constraints for RIF.

Use cases supporting

Use cases supporting RIF's design principles:

5. Methodology

This analysis is based on the Goals, Critical Success Factors and Requirements methodogy. This is intended to be a rational basis for deriving the final requirements for the RIF.

5.1. Goals

5.2. Critical Success Factors

5.3. Requirements

5.4. CFA Diagram

5.5. Design Principles

TO DO