• Towards a Rule Interchange Format: Goals, Critical Success Factors, Requirements

Towards a Rule Interchange Format: Goals, Critical Success Factors, Requirements

Status

Draft based on the following previous work: Allen's, Paula's,Francois' vision for RIF (part of it), F2F2 list of requirements (part of it) and takes also the existing proposed design constraints for RIF into account. The current status of each of the stated design constraints is a proposal one.

Each of the following sections has the following form Goal - Critical Success Factor(s) - Requirement(s) on RIF. DEFINITION OF GOAL, CRITICAL SUCCESS FACTOR, REQUIREMENT HERE. Their order in this document doesn't mirror their importance for RIF.

Notes:

• No distinction between Phase 1/ Phase 2.
• This document doesn't propose solutions to meet the stated requirements; the section on comments give some references to proposal to meet some of the stated design constraints (actually for requirements).
• (Some of) the requirements' descriptions are at a rather high-level, that is why requirements that belong to one requirement are stated as desiderata for the particular requirement.
• At this point, some of the design constraints (e.g. requirements) might overlap with or even contradict some other, also stated, requirements. It might be the case that such contradicting requirements will correspond to different RIF extensions.

• This draft contains also short comments on the relationship to Dave's proposal for a hierarchy of same kind

Author: PaulaLaviniaPatranjan

1. Goal: Rules as subject of interchange

Description of goal: RIF must be a format for interchanging rules, i.e. DEFINITION OF RULE HERE. Rules are of different types and access (query), reason with and construct data. Thus, critical success factors for this goal concern types of rules, data to be worked with and means for bringing these together in a uniform framework.

Critical success factors for this goal:

• CSF 1: RIF should support different types of rules

  • Requirement 1: RIF should support deductive rules

    • Desideratum 1: Condition language (body)
    • Desideratum 2: Construction language (head)

  • Requirement 2: RIF should support normative rules

    • Desideratum 1: ??

  • Requirement 3: RIF should support reactive (ECA) rules

    • Desideratum 1: (Composite) event processing (E part)
    • Desideratum 2: Conditions (C part) given in the condition language
    • Desideratum 3: Actions (A part)

• CSF 2: RIF rules are made of RIF component languages, each of them having a clear design goal

  • Requirement 1: Single mechanism for communicating data between rule parts, e.g. substitutions sets for the variables with at least one defining occurrence

  • Requirement 2: Component languages follow same paradigms (for gaining a uniform and easy to understand and use RIF)

  • Requirement 3: Condition language same for the body of deductive rules and the C part of reactive rules

  • Requirement 4: Clear and stated compatibilities and incompatibilities between RIF components/extensions

• CSF 3: RIF should provide access to, representation of, and arithmetical operations on (shortly support) different kinds of data sources

  • Requirement 1: Support for XML data

  • Requirement 2: Support for RDF data

    • Desideratum 1: RIF should accept RDF triples as data
    • Desideratum 2: RIF should express RDF deduction rules

  • Requirement 3: Support for OWL data

    • Desideratum 1: RIF should accept OWL KBs as data

  • Requirement 4: Support degrees of truth (partial truth) of propositions, uncertain and probabilistic information

  • Requirement 5: Basic numeric computations, aggregate functions, procedural attachments

  • Requirement 6: Type system / Datatype built-in predicates and functions

• CSF 4: (Inexpensive) representation of rules to be interchanged

  • Requirement 1: An human legible syntax

  • Requirement 2: A syntax for exchange (e.g. XML or RDF)

  • Requirement 3: Support for modules and other structuring/abstraction mechanisms (Different knowledge bases should be encapsulated so that their rules will interact in a controlled and predictable manner)

  • Requirement 4: Meta rules for meta reasoning

Comments

Use case support:

• Use cases supporting CSF 1: 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

• Use cases supporting CSF 3

  • Requirement 1: Rule-Based Combined Access to XML and RDF Data

  • Requirement 2: RIF RuleML FOAF

  • Requirement 3: 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

  • Requirement 5: Rule-Based Email Manipulation, Rule Based Service Level Management and SLAs for Service Oriented Computing, Automatically generated rules

  • Requirement 6: Representing some levels of fuzzy rules with the help of datatype built-ins, Rule Based Service Level Management and SLAs for Service Oriented Computing

• Use cases supporting CSF 4: Real-time contract exchange

  • Requirement 1 & 2: Publication of semantics (e.g. SKOS, RDFS), Automatically generated rules

  • Requirement 3: Scoped negation, Encapsulation

  • Requirement 4: Rule Based Service Level Management and SLAs for Service Oriented Computing, Supporting the Reuse of Rules, Automatically generated rules

Proposals to meet the above stated design constraints:

• RDF compatibility

• OWL compatibility

Comparison to Dave's proposal:

• This goal is similar to G1 and G3; the titles of this goal and G1 differ just in the absence/presence of 'effective', however the critical success factors associated with them are different
• The issue of meaning preserving in G1 is not part of this goal, but part of the next goal in this proposal
• C3.2 and C3.3 are in Dave's hierarchy critical success factors for foundations for a semantic web rule language, here they refer to the data that is supported by RIF
• C3.4 of Dave's proposal is not considered here, since SPARQL is a concrete example that should be taken into account for the level of expressiveness, but its place is not on this abstraction level

2. Goal: Semantics- and conformance-aware exchange

Description of goal: RIF should be able to allow the semantics- and conformance-aware exchange of rules between different rule systems, that is EXPLANATION HERE.

Critical success factors for this goal:

• CSF 1: RIF must carry information about the rules' semantics

  • Requirement 1: Format for specifying the intended interpretation (semantics interchange format)

  • Requirement 2: Format for specifying the inference procedure (inference procedure interchange format) that can be applied to a set of rules

  • Requirement 3: Definition of the semantics of RIF rules to be interchanged

  • Requirement 4: Declarative semantics as must, operational semantics optional.

• CSF 2: RIF must carry information about conformance

  • Requirement 1: Definition of default behavior(s)

  • Requirement 2: Tagging of various RIF extensions (in a way that rule engines can announce their capabilities in these terms and compatibility between a rule set and a rule engine can easily be determined)

Comments

Use case support:

• Use cases supporting the goal: Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records

• Use cases supporting CSF 1

  • Requirement 1: Operationally Equivalent Translations, Rule Based Service Level Management and SLAs for Service Oriented Computing

  • Requirement 2: Operationally Equivalent Translations, Rule Based Service Level Management and SLAs for Service Oriented Computing

  • Requirement 3: Managing incomplete information, ["Labeling

  Brain Anatomical Structures in Digital Images"], Automatically generated rules

• Use cases supporting CSF 2

  • Requirement 2: Distributed e-Learning

Proposals to meet the above stated design constraints:

• The charter mentions the conformance issue and gives also a reference for information on how to specify conformance.

Comparison to Dave's proposal:

• Semantics-aware interchange is part of goal G1, namely the critical success factor C1.2
• Perhaps it is a good idea to have the semantics- and conformance-aware interchange as a critical success factor and not as a goal

3. Goal: Level of expressiveness

Description of goal: RIF should be expressive enough to cover features that mostly used rule languages and systems have, but also features that will probably be incorporated in future developments of these and which are motivated by usage scenarios.

Critical success factors for this goal:

• CSF 1: RIF must be extensible wrt. expressive power

  • Requirement 1: Horn Logic

    • Desideratum 1: Function-free Horn logic/ Datalog
    • Desideratum 2: Full Horn Logic

  • Requirement 2: FOL

  • Requirement 3: Support for negation

    • Desideratum 1: Negation over extensional data
    • Desideratum 2: (Scoped) negation as failure is required
    • Desideratum 3: Classical negation

• CSF 2: Preferences and priorities

  • Requirement 1: Priorities in the manner of Courteous Logic Programs

  • Requirement 2: Preferences (such as rule order, rete vs. sequential execution)

Comments

Use case support:

• Use cases supporting this goal: Portability, Transfer of rules between different vendor products

• Use cases supporting CSF 1

  • Requirement 2: Labeling Brain Anatomical Structures in Digital Images

• Use cases supporting requirement 3

  • Desideratum 1: Message Transformation

  • Desideratum 2: RIF RuleML FOAF, Internet search: combining query language, rule languages and scoped negation, Labeling Brain Anatomical Structures in Digital Images, Scoped negation, Encapsulation

  • Desideratum 3: Situation Assessment and Adaptation, Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting

  • Desideratum 4: Situation Assessment and Adaptation

• Use cases supporting CSF 2

  • Requirement 1: Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting

Proposals to meet the above stated design constraints:

• Proposal for a bottom up approach to get at least a rough estimation on the needed level of expressiveness and hints towards the conformance and extensibility mechanisms for existing rule systems: Hassan's proposal.

Comparison to Dave's proposal:

• One can consider that this goal can entail the widespread adoption of RIF, which in Dave's proposal is considered as a separate goal, G2
• This proposal doesn't say anything about Dave's C3.1 on the webized nature of RIF; it might be a good idea to find a place in this hierarchy for something on this