Status
This part lists the requirements on RIF implied by the submitted use cases (cf. Use Cases) and the analysis of the use case categories (cf. General Use Case Categories). Duplicates were eliminated as much as possible and classes of requirements were introduced so as to improve readability.
Note that the order of stated (classes of) requirements doesn't mirror their relevance to the RIF or to the phases stated in the charter.
The list of requirements reflects the status of the use cases on Friday, February 10, 2006.
Requirements on RIF
General
It should be able to export rules in a format that can be understood by the other parties. (from Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records)
RIF should support the representation/tagging of various rule dialects (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). (from Distributed e-Learning)
Needs of an integrated framework. For example in data integration, mapping rules, querying rules, and ontology, should be integrated in a uniform framework. (from Classification of Rules w.r.t. their role)
Support for different roles, i.e. different abstraction layers, e.g. model layer (e.g. UML, MDA PIM), if-then related layer, XML-based layer, logical layer (e.g. Prolog) (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
RIF should incorporate the ability to describe differences across rules and rule-sets (from Supporting the Reuse of Rules)
RIF should have a broader notion of matching, that is, it should have the ability to do richer types of matching than invocation of rules. It should be able to match on rule sets as well as on rules (from Supporting the Reuse of Rules)
Different knowledge bases should be encapsulated so that their rules will not interfere with each other. (from Scoped negation, Encapsulation)
Although it should be more carefully investigated, the rule language required might be a FOL extension with function-free Horn rules (with negation as failure). (from Labeling Brain Anatomical Structures in Digital Images)
Compatibility with RDF & OWL
Compability with base semantic web languages - RDF, OWL. (from Publication of semantics (e.g. SKOS, RDFS), Fuzzy Reasoning with Brain Anatomical Structures,Classification of Rules w.r.t. their role, Decision making in Health Care) / RIF should be compatible with OWL-DL. (from SW rules for Health Care and Life Sciences, Ontology Mapping with OWL and Rules)
Reasoning with ontologies and rules (from Decision making in Health Care, Labeling Brain Anatomical Structures in Digital Images, Ontology Mapping with OWL and Rules) / * Enabling ontologies and rules to safely interoperate (decidable, sound and complete reasoning) (from Labeling Brain Anatomical Structures in Digital Images) / Different kinds of semantically compatible vocabularies should be mixed for inference. (from Policy - Preference Computing)
Requires that rule bases use a shared (or mergeable) ontology and can then be merged themselves (from Product Compatibility)
RIF should be able to reference ontologies in which rule content is defined.(from Situation Assessment and Adaptation)
Since the current FOAF is based on RDF, it is required that the FOAF subset of RDF be also expressible as facts of the rule language, that the rules are able to cope with such facts, and that the rule-derived facts can be (XSLT-)translated back to RDF. (from RIF RuleML FOAF)
Rules need to describe some mappings between ontology entities. Mappings are not only one-to-one and might also need to do transformations on values. (from Enterprise Information Integration)
Access to data sources requires transport of meta data (datatype, name in external data source, ?). (from Enterprise Information Integration)
Representation of RDF transformation rules (from Message Transformation)
Support for object introduction ("gensym" of URI's, bNodes in conclusions) (from Message Transformation)
Quantification over RDF predicates (from Message Transformation)
Guidance on how OWL/RDF triples are associated to the patterns in rules. (OWL/RDF compatibility issue?) (from Filling the holes of OWL)
Interoperability between ontologies through OWL standard is necessary to allow reasoning across connected domains e.g. pathology, genes, anatomy. (from SW rules for Health Care and Life Sciences)
Rich Knowledge Representation allowing invocation of classes as individuals (from Supporting the Reuse of Rules)
RIF should include representation for logical information encoded in ontologies from which rule content is derived; e.g., cardinality constraints, existential quantification, equivalent classes, disjointness. (from Situation Assessment and Adaptation)
Support for nonmonotonic inheritance (from Frame-based representation, Inheritance of defaults, Reification)
Support for frames (from Frame-based representation, Inheritance of defaults, Reification)
Support for reification (from Frame-based representation, Inheritance of defaults, Reification)
Expression of deductive closure rules. (from Publication of semantics (e.g. SKOS, RDFS))
As most of the ontologies use union or existential in rhs, OWL-DL expressiveness is not enough.(from SW rules for Health Care and Life Sciences)
OWL DL expressiveness is required.(from SW rules for Health Care and Life Sciences)
Expressiveness that is superiour to OWL-DL. (from Ontology Mapping with OWL and Rules)
OWL DL reasoning services (consistency checking, classification) are crucial for the quality assurance of such large-scale biomedical ontologies.(from SW rules for Health Care and Life Sciences)
RIF should be (partially?) mappable from/to SPARQL (from Internet search: combining query language, rule languages and scoped negation)
Semantics
A clear definition of the semantics of the rules to be interchanged. (from Managing incomplete information, Labeling Brain Anatomical Structures in Digital Images)
Not a unique semantics, but clarify and formalise all the different semantics that may be of interest to users and implementors. (from Managing incomplete information)
Declarative as well as operational semantics.(from Automatically generated rules)
Probably need an ontology of RIF semantics (formally represented in a standard ontology language) (from Distributed e-Learning)
Standard format for specifying the inference procedure (inference procedure interchange format) that can be applied to a set of rules. (from Operationally Equivalent Translations, Rule Based Service Level Management and SLAs for Service Oriented Computing)
Standard format for specifying the intended interpretation (semantics interchange format) of a set of RIF rules with accompanying inference procedure. (from Operationally Equivalent Translations, Rule Based Service Level Management and SLAs for Service Oriented Computing)
Different kinds of rules (deductive, normative, reactive)
Different kinds of rules (deductive, normative, and reactive rules) should be supported. (from 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)
Syntax(es)
An human legible syntax and a machine processable syntax. (from Publication of semantics (e.g. SKOS, RDFS), Automatically generated rules)
Provide sufficient structure to represent (rules of) the parties involved and the data they deal with (from Real-time contract exchange)
Data model / Type of data
Rules require access to data contained both in events and stored persistently. (from Rule-Based Reactive Organizer, Rule-Based Email Manipulation)
Support for semistructured data (from Frame-based representation, Inheritance of defaults, Reification)
Basic numeric computations & aggregations
Support for basic numeric computations and aggregate functions.(from Automatically generated rules)
Procedural attachements
(Re)use of (existing) external functions or methods, e.g. SQL aggregations, mathematical functions implemented in Java, EJBs, event driven architectures, system/network mgt. tools, messaging capabilities, etc. (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
Use-defined procedural attachments. (from Rule-Based Email Manipulation)
Transfer of rules
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.(from Real-time contract exchange)
Rule transfers may be 1-time type events and as such are supported by RIF. Examples are: (i) CompanyA using VendorF acquires CompanyB using VendorI and transfers rules from VendorI to VendorF to standardise on vendor environments (or just to share the rules). (ii) CompanyA using VendorJ determines that VendorF provides better runtime performance for certain rule services, and wishes to pass rules to that vendor's environment for execution. (from Transfer of rules between different vendor products)
Rule transfers may be transaction-based events and as such are supported by RIF. (from Transfer of rules between different vendor products)
Negation
Negation over extensional data. (from Message Transformation)
Scoped negation as failure is required. (from RIF RuleML FOAF, Internet search: combining query language, rule languages and scoped negation) / Negation as failure required. (from Labeling Brain Anatomical Structures in Digital Images) / Need for default negation. (from Scoped negation, Encapsulation)
Classical negation (from Situation Assessment and Adaptation, Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting)
Closed world assumption scoped to data sets (this is also implied by the requirement on scoped negation)
RIF should provide representation for closed-world assumption with some rules. (from Situation Assessment and Adaptation)
Representation of probabilistic, uncertain information and degrees of truth
RIF should include representation for uncertain information. (from Situation Assessment and Adaptation, Automatically generated rules, Fuzzy Reasoning with Brain Anatomical Structures)
RIF should include representation for probabilistic information. (from Situation Assessment and Adaptation, Automatically generated rules)
The RIF Core language should provide well-defined extensions for representing degrees of truth (partial truth) of propositions. (from Fuzzy Reasoning with Brain Anatomical Structures)
Meta-reasoning / Evolution of rule sets
RIF should support the ability to manage rule sets dynamically under changing conditions. (from Situation Assessment and Adaptation, Rule-based Service Level Agreements (SLA) and Web Services)
Meta rules for meta reasoning. (from Rule Based Service Level Management and SLAs for Service Oriented Computing, Supporting the Reuse of Rules, Automatically generated rules)
Complex event processing
Expressive power of the interchange format to represent temporal reasoning, event algebras for complex event processing (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
Datatype support
Datatype built-in predicates and functions (from Representing some levels of fuzzy rules with the help of datatype built-ins)
Query language
The rule language should at the same time be the query language. (from Enterprise Information Integration) / RIF should integrate query and rule language. (from Internet search: combining query language, rule languages and scoped negation)
There needs to be an identified set of features which can be implemented efficiently and allow for high-performance data access.(from Enterprise Information Integration) / The query execution has to take different access characteristcs to external data sources into account (subject: query optimization).(from Enterprise Information Integration)
Extensibility in the sense that users can add customized functionality (data transformations, access to new data sources). (from Enterprise Information Integration)
RIF should provide for identifying a query language appropriate to the rule(s) type. (from Situation Assessment and Adaptation)
Need to be able to access/integrate remote knowledge bases.(from Scoped negation, Encapsulation, Rule Based Service Level Management and SLAs for Service Oriented Computing)
Rule-based combined access to different kinds of data (such as XML and RDF data) is needed. (from Rule-Based Combined Access to XML and RDF Data)
Modules of rules
Rule sets/modules, e.g. defining different contract modules in a hierarchical contract structure. (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
Validation & verification
Verification and validation support. (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
Test cases should be written in the same language as the rules or logic program that is to be tested. (from Rule Interchange Through Test-Driven Verification and Validation)
Test cases as well as rule sets (and rule engines) should be annotated with meta information about their semantics (cf. "semantic attributes" in RuleML). (from Rule Interchange Through Test-Driven Verification and Validation)
Priorities and preferences
Declarative prioritized defaults in the manner of Courteous Logic Programs are desirable. The advantages include modularity to add/merge new rules. (from Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting)
RIF should offer means for representing rule priorities. (from Rule Based Service Level Management and SLAs for Service Oriented Computing, Rule-Based Email Manipulation)
Type system / Mode declarations
Typed Logic and Mode declarations e.g. Java type system, Semantic Web taxonomies, Input/Output modes are needed. (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
Distribution & Scalability
Support for scalable reasoning on large amounts of instances (ABox). (from Ontology Mapping with OWL and Rules)
RIF rules should be appropriate for distributed inferencing (from Distributed e-Learning)
RIF rules should be represented in a way that other RIF rules can transform them, e.g., for ontology mapping, transforming rules (e.g., for distributed inferencing), etc. (from Distributed e-Learning)
Support for the functionality and requirements of Web Services and distributed architectures (from Rule-based Service Level Agreements (SLA) and Web Services)
The rest of the initial requirements list (not yet classified requirements)
Requires that RIF support the intersection of features found in competing products (from Portability)
Person-centric, local rules imply the requirement of a scoping construct also for positive queries. For more and more global rules, an increasing number of such scopes need to be merged, so there is the requirement of unlimited import of local rulebases into a new scope. (from RIF RuleML FOAF)
As information/knowledge can sometimes be better represented in a (shared) ontology and sometimes better be realised in (person-centric) rules, integrating ontologies and rules via hybrid rules is a main requirement. (from RIF RuleML FOAF)
Given a rule-set R written in the RIF together with an inference procedure P specified in the IPIF and an intended interpretation S specified in the SIM, it must be possible to construct a virtual machine that uses P to execute R for any input allowed by S. (from Operationally Equivalent Translations)
Decidability or possibility to automatically restrict to an expressive decidable fragment.(from Ontology Mapping with OWL and Rules)
An instantiation of this use case was implemented with POSL rules as NBBizKB and tested in OOjDREW. The need to construct such integration rules through iterative refinement with human experts implies the requirement of a human-readable syntax.
In this use case, the identity criterion for businesses across the Web sources is a problem if no URI is provided or URI normalization cannot be done: normalized phone numbers needed to be used in NBBizKB. This implies the requirement to 'webize' the language with URIs and interface it to the newest official URI normalization algorithm.
Given that the same business can be identified in both sources, and assuming it is correctly classified w.r.t. their respective taxonomies, an alignment between the two taxonomic classes can be hypothetically established, which becomes the stronger the more such business-occurrence pairs can be found in both sources. This implies the requirement to combine rules with taxonomies and to permit uncertainty handling, as explored in Fuzzy RuleML.
(from Information Integration with Rules and Taxonomies)
- In addition to providing a format for interpreted regulations, the RIF must provide formats for:
- Compliance action, with discrimination between minimum mandatory requirements and recommended good practice
- Compliance objectives and goals agreed with regulators
- Concept definitions and a default (English) vocabulary for regulation and compliance.
- The RIF format needs to support the expressiveness required for the representation of regulations (both conditions and actions)
(from Interpretation and Interchange of Regulations)
RIF is defined to and from common rule engine implementations (ie rule formats)(from Transfer of rules between different vendor products)
Vendors (for example Fair Isaac, Ilog, IBM, LibRT, PegaSystems and Corticon who are already participating in PRR for standardising at the modeling level) have customers who will also want to support rule interchange into and outof their proprietary (production) rule formats.(from Transfer of rules between different vendor products)
Handle executable rules that operate against operational (W3C) data systems (from Real-time contract exchange)