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:
- 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.
- Rules provide a powerful business logic representation, as business rules, in many modern information systems.
- Rules are often the technology of choice for creating maintainable adapters between information systems.
- 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.
- 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.
- 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.
- 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.
- 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.
- Meta language features
- RIF should support meta language features such as priorities and preferences, and meta rules for meta reasoning.
- 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.
- Support typed languages (optional)
- RIF should be designed in such a way that it permits the incorporation of type system(s).
- 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.
- Markup of semantics
The semantics of a RIF ruleset must be specifiable in a way that permits the incorporation of new rule languages and language features. See Sound reasoning with unknown dialects
- Conformance model
It must be clear what the conformance profile of a given RIF ruleset is and what default processing is implied. See RIF must define expected default behaviour
- Coverage
- The RIF should cover the major classes of rule formalisms that are in widespread use.
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.
The RIF should support Prolog-like rulesets. See Standard RIF should be Prolog-like but not Prolog-compatible.
The RIF should support normative rules. See Standard RIF must support normative rules
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
- Combined rulesets
- 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.
- 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.
- RIF should support uncertain and probabilistic information.
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.
- 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
- This is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. That implies that existing W3C technologies, such as RDF, OWL and XML, should fit well with the RIF. Furthermore, the RIF should be appropriately consistent with non-semantic web technologies, such as Web Services technologies, an Web technologies.
- Alignment with Semantic Web
- Support RDF
RIF should accept RDF triples as data. See The RIF Core must be able to accept RDF triples as data
RIF should express RDF deduction rules.See Standard RIF must be able to express RDF deduction rules
- Permit SPARQL queries to be used in rules.
- Support OWL
RIF should accept OWL knowledgebases as data. The RIF Core must be able to accept OWL KBs as data
This is supported by the use case UCR/Interchanging Rule Extensions to OWL
- Support RDF
- Alignment with key W3C specifications
Support XML See The RIF Core must be able to accept XML elements as data
- Permit XML information types (where appropriate) to be expressed using XML Schema
2. Open Issues
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.
- Syntax
- An human legible syntax
- A syntax for exchange (e.g. XML or RDF)
- An abstract syntax
- 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)
- 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
coverage of different types of rules (deductive, normative, reactive rules): Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records, Organizing a Vacation with Friends, Rule-Based Intelligent Guiding, Rule-Based Email Manipulation, Rule-Based Reactive Organizer, Rule-based Service Level Agreements (SLA) and Web Services, Rule Based Service Level Management and SLAs for Service Oriented Computing, Supply Chain Ordering Lead Time
alignment with Semantic Web and key W3C specs: Rule-Based Combined Access to XML and RDF Data, RIF RuleML FOAF, Fuzzy Reasoning with Brain Anatomical Structures, Situation Assessment and Adaptation, Automatically generated rules, Decision making in Health Care, Ontology Mapping with OWL and Rules, Labeling Brain Anatomical Structures in Digital Images, Policy - Preference Computing, Publication of semantics (e.g. SKOS, RDFS),Classification of Rules w.r.t. their role, Decision making in Health Care, SW rules for Health Care and Life Sciences
oracular models: Rule-Based Email Manipulation, Rule Based Service Level Management and SLAs for Service Oriented Computing, Automatically generated rules
oracular models (preferences and priorities): Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting
typed languages: Personalisation and Uncertainty -- Representing some levels of fuzzy rules with the help of datatype built-ins, Rule Based Service Level Management and SLAs for Service Oriented Computing
meta language (meta rules for meta reasoning): Rule Based Service Level Management and SLAs for Service Oriented Computing, Supporting the Reuse of Rules, Automatically generated rules
no surprises: Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records, Operationally Equivalent Translations, Rule Based Service Level Management and SLAs for Service Oriented Computing, Managing incomplete information, Labeling Brain Anatomical Structures in Digital Images, Automatically generated rules
conformance model: Distributed e-Learning
extensibility wrt. expressive power: Portability, Transfer of rules between different vendor products
negation: Message Transformation, RIF RuleML FOAF, Internet search: combining query language, rule languages and scoped negation, Labeling Brain Anatomical Structures in Digital Images, Scoped negation, Encapsulation, Situation Assessment and Adaptation, Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting
Use cases supporting RIF's design principles:
syntax: Publication of semantics (e.g. SKOS, RDFS), Automatically generated rules
abstractions for reusability and maintainability: Scoped negation, Encapsulation
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
- A goal (not to be confused with a predication ;-)) is an overall target that you are trying to reach with the project. Typically, goals are hard to measure by themselves. Goals are often directed at the potential consumer of the product rather than the technology developer.
5.2. Critical Success Factors
- A CSF is a property, sub-goal that directly supports a goal and there is strong belief that without it the goal is unattainable. CSFs themselves are not necessarily measurable in themselves. For example, a CSF for "widescale adoption" can be "low cost of entry". Without a low cost of entry, you can argue that you will not get widescale adoption.
5.3. Requirements
- A requirement is a specific measurable property that directly supports a CSF. The key here is measurability: it should be possible to unambiguously determine if a requirement has been met. While Goals are typically directed at consumers of the specification, requirements are focused on technical aspects of the specification. For example, we might have a requirement that the RIF supports RETE-style PRLs as well as Prolog-style RLs. Such a requirement speaks to the "support production rule languages" CSF, which in turn supports the "widescale adoption" goal.
5.4. CFA Diagram
The diagram uses a notation that supports the rapid comprehension of the goals, critical success factors and requirements. This diagram can act as an effective index into the written descriptions of goals etc., but is not intended to replace the text. The legend:
illustrates the key elements of the graphical notation. Goals are written in round ovals, critical sucess factors are written in round-ended rectangles and requirements are written using open ended rectangles. The arrows show whether a csf/goal/requirement is supported by another element or opposed by it. This highlights the potential for conflict in requirements.
5.5. Design Principles
TO DO