• RIFUCR - List of Requirements (as Found in the Initial Use Cases)

Status

The list of requirements reflects the status of the use cases on Friday, February 10, 2006.

List of requirements

• Requires that rule bases use a shared (or mergeable) ontology and can then be merged themselves (from Product Compatibility)

• Requires that RIF support the intersection of features found in competing products (from Portability)

• RIF should be able to reference ontologies in which rule content is defined.
• 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, classical negation.
• RIF should provide representation for closed-world assumption with some situation-assessment rules.
• RIF should support the ability to manage rule sets dynamically under changing conditions.
• RIF should include representation for uncertainty.
• RIF should provide for identifying a query language appropriate to the rule(s) type.

(from Situation Assessment and Adaptation)

• 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.
• 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.
• Because person-centric rules need closed negative conditions, which cannot be proved in the open web, (scoped) negation as failure is required.
• 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)

• In addition to providing a rule interchange format, the RIF must also provide
  • A standard format for specifying the inference procedure (inference engine) that can be applied to a set of rules. For the sake of brevity we refer to this as the IPIF (Inference Procedure Interchange Format).
  • A standard format for specifying the intended interpretation (semantics) of a set of RIF rules with accompanying IPIF inference procedure. For the sake of brevity we refer to this as the SIF (Semantics Interchange Format). Note that the SIF is where a formal characterization of the possible inputs to a rule-set is provided.

• 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)

• 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.
• The rule language should at the same time be the query language.
• Extensibility in the sense that users can add customized functionality (data transformations, access to new data sources).
• Access to data sources requires transport of meta data (datatype, name in external data source, ?).
• There needs to be an identified set of ?features? which can be implemented efficiently and allow for high-performance data access.
• For a query execution/inferencing engine on a consolidated view, it has to be possible to consider performance, i.e. the execution has to take different access characteristcs to external data sources into account (subject: query optimization).

(from Enterprise Information Integration)

• For negotiation, it should be able to export the policies in a format that can be understood by the other parties engaged in the negotiation.

(from Automated Trust Establishment for eCommerce, Automated Trust Establishment for Accessing Medical Records)

• 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)

• Functionalities that go beyond Microsoft Outlook are desirable:
  • user-defined functions for conditions, e.g. for deleting emails which are recognized as spam (by some user-defined, external function) with a probability; an important role would play procedural attachments for e.g. information retrieval services
  • user-defined actions that need to be interchanged between systems

  • conflict resolution, e.g. one rule matching for sender containing string 'Paula' and another matching domain '@ifi.lmu.de', each with different actions; how to react to an incoming message from 'Paula.Patranjan@ifi.lmu.de'?

  • access to persistent data, e.g. vacation calendars.

(from Rule-Based Email Manipulation)

• Rules require access to data contained both in events and stored persistently.

(from Rule-Based Reactive Organizer)

• The RIF Core language should provide well-defined extensions that are intended in representing uncertain and imprecise knowledge, such as degrees of truth (partial truth) of propositions.
• The RIF should have proper extensions for exchanging rules that represent uncertain knowledge, like rules with different confidences and/or atoms with different importance in the rule.
• The RIF should have compatibility with OWL.

(from Fuzzy Reasoning with Brain Anatomical Structures)

• Intimate and well-understood compatibility with OWL-DL; possibility to integrate rules with other ontological knowledge bases.
• Expressiveness that is superiour to OWL-DL.
• Decidability or possibility to automatically restrict to an expressive decidable fragment.
• Support for scalable reasoning on large amounts of instances (ABox).

(from Ontology Mapping with OWL and Rules)

• RIF must support the representation/tagging of various rule dialects/semantics (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), i.e., we probably need an ontology of RIF semantics (formally represented in a standard ontology language)

• RIF rules should be appropriate for distributed inferencing
• 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)

• Need to be able to access remote knowledge bases.
• Different knowledge bases should be encapsulated so that their rules will not interfere with each other.
• Need for default negation.

(from Scoped negation, Encapsulation)

• Support for nonmonotonic inheritance
• Semistructured data
• Support for frames
• Support for reification

(from Frame-based representation, Inheritance of defaults, Reification)

• Representation of RDF transformation rules
• Support for object introduction ("gensym" of URI's, bNodes in conclusions)
• Quantification over RDF predicates
• Negation over extensional data

(from Message Transformation)

• Expression of deductive closure rules.
• Compability with base semantic web languages - RDF, OWL.
• An human legible syntax (in addition to the machine processable syntax)

(from Publication of semantics (e.g. SKOS, RDFS))

• The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to add new rules, e.g., that represent special cases / exceptions.
• The prioritized defaults here involve in particular an integrity constraint that one should conclude at most one value of the refund percentage for a given item.

(from Refund Policies in E-Commerce)

• The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to merge/add new rules, e.g., that represent the bank's policies or how to handle special-cases/exceptions.
• The prioritized defaults here involve in particular an integrity
  • constraint that one should not conclude that the same request is both allowed (authorized) and disallowed. This is represented elegantly using the strong-negation connective (and associated implicit mutex) that Courteous LP features.

(from Credit Card Transaction Authorization)

• The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to add new rules, e.g., that represent special cases / exceptions.
• The prioritized defaults here involve in particular an integrity constraint that one should conclude at most one value of the ordering lead time for a given item.
• The use case, in its further extended/longer version (in a referenced paper) shows the desirability of representing action rules in a declarative, easily-combined fashion -- in the manner of Situated (or, a bit more generally, Production) Logic Programs.

(from Supply Chain Ordering Lead Time)

• The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to add new rules, e.g., that represent special cases / exceptions.
• The prioritized defaults here involve in particular an integrity constraint that one should conclude at most one value of the discount percentage for a given item.

(from Price Discounting)

• The policies and preferences should be written in a compatible format as well as in semantically compatible vocabularies. Sometimes, the commitment checking mechanism itself might be implemented in rules, so it should be possible to mix all the three knowledge bases and to perform inferencing.

(from Policy - Preference Computing)

• 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.
• As most of the ontologies use union or existential in rhs, OWL-DLP expressiveness is not enough.
• OWL DL expressiveness is required.
• OWL DL reasoning services (consistency checking, classification) are crucial for the quality assurance of such large-scale biomedical ontologies.

In conclusion, many biomedical ontologies are represented in OWL DL, so a Web rule language should be compatible with OWL DL.

(from SW rules for Health Care and Life Sciences)

• Support scoped rules and scoped negation
• We expect a rule interchange format which integrates query and rule language, just as datalog does for common query languages

• We expect the rule interchange format to be (partially?) mappable from to SPARQL

(from Internet search: combining query language, rule languages and scoped negation)

• Rule-based combined access to both XML and RDF data is needed.

(from Rule-Based Combined Access to XML and RDF Data)

An instantiation of this use case was implemented with POSL rules as NBBizKB and tested in OO jDREW. 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)

SLA systems such as the one we implemented for this scenario require not only various types of rules but also rules that can be either static or dynamic.

• expressive power of the interchange format to match the capabilities required by SLAs
• Support for the both the static and dynamic aspects of SLAs
• Support for the functionality and requirements of Web Services and distributed architectures

(from Rule-based Service Level Agreements (SLA) and Web Services)

• RIF is defined to and from common rule engine implementations (ie rule formats)

• 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.

• 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.
• Rule transfers may be transaction-based events and as such are supported by RIF.

(from Transfer of rules between different vendor products)

To be effective in handling contracts, RIF must

• Handle executable rules that operate against operational (W3C) data systems
• Provide sufficient structure to represent (rules of) the parties involved and the data they deal with
• 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)

• A clear definition of the semantics of the rules to be interchanged.

• We do not propose to stick to a unique semantics, but we propose to clarify and formalise all the different semantics that may be of interest to users and implementors.

(from Managing incomplete information)

• At the representation level, a single rule language, independent of the rule role, and compatible with OWL
• 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)

• Compatibility with OWL
• Reasoning with ontologies and rules

(from Decision making in Health Care)

• Reasoning support to reason over a knowledge base composed of ontology and rules
• Clear semantics that enables OWL DL and rules to safely interoperate (decidable, sound and complete reasoning)
• 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)

• Support for basic numeric computations and aggregate functions.
• Declarative as well as operational semantics. A language without an actual reasoner can only be exchanged and appreciated by humans, but not executed by machines.
• Human readable syntax for inspection and evaluation.
• Meta-reasoning capabilities. It is advantageous if the same language can be used to specify not only rules themselves, but also rule mappings and rule manipulation (e.g., updates, incremental modifications).
• Representation of probabilistic and uncertain information would be beneficial.

(from Automatically generated rules)

• Various rule types such as ECA rules, derivation rules, normative rules etc.
• Expressive power of the interchange format to represent complex SLA rules, e.g. rule priorities, defeasible rules, temporal reasoning, event algebras for complex event processing, etc.
• Typed Logic and Mode declarations e.g. Java type system, Semantic Web taxonomies, Input/Output modes.
• Integration of external fact bases, e.g. databases, Web sources, data warehouses etc.
• (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.
• Semantic annotations to support transformation of the normalized interchange format into different execution syntaxes and enable execution in different rule engines with different (logic programming) semantics.
• Rule sets/modules, e.g. defining different contract modules in a hierarchical contract structure (terms and condition module, master SLA, standard SLAs, OLAs).
• Meta rules for meta reasoning.
• Verification and validation support.
• 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)

• Test cases should be written in the same language as the rules or logic program that is to be tested.

• 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)

• Datatype built-in predicates and functions

(from Representing some levels of fuzzy rules with the help of datatype built-ins)

• Rich Knowledge Representation allowing invocation of classes as individuals
• RIF should incorporate the ability to describe differences across rules and rule-sets
• 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
• RIF should support a rich set of meta-operations upon rules and rule sets in order to capture the subtleties of inter-rule relationships

(from Supporting the Reuse of Rules)