- From: Jos de Bruijn <jos.debruijn@deri.org>
- Date: Tue, 21 Feb 2006 09:29:14 +0000
- To: public-rif-wg@w3.org
Dear Paula, all,
Please find below my comments on the list of requirements. I used Axel's
numbering of the requirements.
Best, Jos
JB> comment: general comments questions and suggestions on the
requirement
JB> merge/split: proposal to merge several requirements
JB> split: proposal to split the requirement
JB> redundant: requirements seems redundant and should be removed
JB> move: proposal to move the requirement to the indicated category
JB> rename: proposal to rename the category or requirement
JB> First of all, I propose to create a new category "Interchange" which
captures all requirements on the interchange of rules
=====================================================
RIFUCR - List of Classified Requirements (with Duplicate Elimination)
Status
Requirements on RIF
I. General
1) 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)
JB> move: to new category "interchange"
2) 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)
JB> move: to category "different kinds of rules"
3) 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)
JB> comment: It is not clear what is meant with "integrated framework".
Please clarify.
4) 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)
5) RIF should incorporate the ability to describe differences across
rules and rule-sets (from Supporting the Reuse of Rules)
JB> comment: it is not clear what differences are suppose to be
described. Does this refer to semantic differences? In this case, the
requirement can be moved to "different kinds of rules".
6) 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)
JB> comment: not clear what is meant with "matching"
7) Different knowledge bases should be encapsulated so that their rules
will not interfere with each other. (from Scoped negation,
Encapsulation)
JB> move: to "modules of rules"
8) 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)
JB> comment: it is not clear here what the requirement is; this seems to
be rather a proposal for a language. I propose to remove it.
II. Compatibility with RDF & OWL
1) 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)
2) 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)
JB> redundant: with previous requirement
3) Requires that rule bases use a shared (or mergeable) ontology and can
then be merged themselves (from Product Compatibility)
JB> comment: this needs to be clarified. Probably, merging of rule bases
should go to the general requirements.
4) RIF should be able to reference ontologies in which rule content is
defined.(from Situation Assessment and Adaptation)
JB> comment: please elaborate: are ontologies supposed to define RIF
rules?
5) 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)
JB> rename: "It should be possible to use RDF statements as facts in RIF
and transform derived facts to RDF."
6) 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)
JB> split: I see two requirements: (a) It should be possible to describe
mappings between OWL entities and (b) RIF needs to be able to describe
value transformations. (a) can stay here and (b) should be moved to
"datatype support".
7) Access to data sources requires transport of meta data (datatype,
name in external data source, ?). (from Enterprise Information
Integration)
JB> move: to general requirements; this seems to be a requirement on the
annotation of RIF entities.
8) Representation of RDF transformation rules (from Message
Transformation)
JB> comment: please clarify what RDF transformation rules are
9) Support for object introduction ("gensym" of URI's, bNodes in
conclusions) (from Message Transformation)
JB> comment: mentioning bNodes here is misleading, because bNodes behave
like existentially quantified variables.
10) Quantification over RDF predicates (from Message Transformation)
JB> comment: This seems a feature. Where is the requirement it comes
from?
11) Guidance on how OWL/RDF triples are associated to the patterns in
rules. (OWL/RDF compatibility issue?) (from Filling the holes of OWL)
JB> comment: please clarify what is meant with "patterns in rules"
12) 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)
JB> redundant: with earlier requirement on mapping OWL ontologies
13) Rich Knowledge Representation allowing invocation of classes as
individuals (from Supporting the Reuse of Rules)
JB> rename: "modeling classes as individuals"; the term "invocation" is
not clear
14) 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)
JB> comment: it is not clear what is meant with "from which rule content
is derived". Apart from that, this requirement seems redundant with
later requirements on expressiveness compared to OWL DL.
15) Support for nonmonotonic inheritance (from Frame-based
representation, Inheritance of defaults, Reification)
JB> move: to "interchange", since it seems to be the case that this
feature is a requirement for RIF because existing rule engines have this
feature
16) Support for frames (from Frame-based representation, Inheritance of
defaults, Reification)
JB> move: to "interchange", since it seems to be the case that this
feature is a requirement for RIF because existing rule engines have this
feature
17) Support for reification (from Frame-based representation,
Inheritance of defaults, Reification)
JB> move: to "interchange", since it seems to be the case that this
feature is a requirement for RIF because existing rule engines have this
feature
18) Expression of deductive closure rules. (from Publication of
semantics (e.g. SKOS, RDFS))
JB> comment: not sure what is meant with "deductive closure rules". Did
you mean "deductive closure OF rules"? Anyway, this looks like a general
requirement.
19) 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)
JB> comment: requirement is not really clear and seems to be redundant
with following two requirements
20) OWL DL expressiveness is required.(from SW rules for Health Care and
Life Sciences)
JB> move: to "interchange", since OWL DL expressiveness seems to be a
feature of some rule engines. It can probably be merged with other
requirements to form some requirement such as "exchange of rules which
are based on expressive subsets of first-order logic". The following
requirement could be captured under this heading as well, if you
interpret "superior" and "superset".
21) Expressiveness that is superiour to OWL-DL. (from Ontology Mapping
with OWL and Rules)
JB> comment: see previous comment
22) 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)
JB> redundant: does not seem to be a requirement, but rather the
motivation for requirement 20
23) RIF should be (partially?) mappable from/to [WWW] SPARQL (from
Internet search: combining query language, rule languages and scoped
negation)
III. Semantics
1) A clear definition of the semantics of the rules to be interchanged.
(from Managing incomplete information, Labeling Brain Anatomical
Structures in Digital Images)
2) 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)
JB> comment: I do not agree with Axel's comment on the core language
with extensions. The core language of phase I will probably already have
three different semantics: minimal model, FOL, and production rule,
since these are mutually incompatible.
3) Declarative as well as operational semantics.(from Automatically
generated rules)
4) Probably need an ontology of RIF semantics (formally represented in a
standard ontology language) (from Distributed e-Learning)
JB> comment: I don't understand this requirement; what could be gained
with the formal representation of an ontology of RIF semantics?
5) 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)
6) 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)
JB> redundant with III.1 and III.5
IV. Different kinds of rules (deductive, normative, reactive)
1) 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)
JB> move: to "interchange"; these seem to be types of rules which need
to be interchanged
V. Syntax(es)
1) A human legible syntax and a machine processable syntax. (from
Publication of semantics (e.g. SKOS, RDFS), Automatically generated
rules)
JB> comment: not sure what the difference is between "human legible" and
"machine processable"; I expect that with "machine processable" was
actually meant "exchange"
2) Provide sufficient structure to represent (rules of) the parties
involved and the data they deal with (from Real-time contract exchange)
JB> comment: not really a requirement, it seems
VI. Data model / Type of data
1) Rules require access to data contained both in events and stored
persistently. (from Rule-Based Reactive Organizer, Rule-Based Email
Manipulation)
2) Support for semistructured data (from Frame-based representation,
Inheritance of defaults, Reification)
JB> comment: probably in the category of RDF?
VII. Basic numeric computations & aggregations
1) Support for basic numeric computations and aggregate functions.(from
Automatically generated rules)
JB> move: to "datatype support"; probably also split the issues of
numeric built-ins and aggregates.
VIII. Procedural attachements
1) (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)
2) User-defined procedural attachments. (from Rule-Based Email
Manipulation)
IX. Transfer of rules
1) 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)
JB> move: to syntax
2) 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)
3) Rule transfers may be transaction-based events and as such are
supported by RIF. (from Transfer of rules between different vendor
products)
JB> comment: this seems to be related to the earlier requirements on
annotation
X. Negation
1) Negation over extensional data. (from Message Transformation)
2) 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)
JB> comment: negation as failure is always scoped; I guess what is meant
here is that the scope is made explicit.
3) Classical negation (from Situation Assessment and Adaptation, Refund
Policies in E-Commerce, Credit Card Transaction Authorization, Supply
Chain Ordering Lead Time, Price Discounting)
XI. Closed world assumption scoped to data sets (this is also implied by
the requirement on scoped negation)
1. RIF should provide representation for closed-world assumption with
some rules. (from Situation Assessment and Adaptation)
JB> redundant: with X.2
XII. Representation of probabilistic, uncertain information and degrees
of truth
1) RIF should include representation for uncertain information. (from
Situation Assessment and Adaptation, Automatically generated rules,
Fuzzy Reasoning with Brain Anatomical Structures)
2) RIF should include representation for probabilistic information.
(from Situation Assessment and Adaptation, Automatically generated
rules)
3) 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)
JB> merge: I don't really see the difference between these three
requirements; it seems to me that they can be merged.
XIII. Meta-reasoning / Evolution of rule sets
1) 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)
2) 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)
XIV. Complex event processing
1) 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)
XV. Datatype support
1) Datatype built-in predicates and functions (from Representing some
levels of fuzzy rules with the help of datatype built-ins)
XVI. Query language
1) 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)
JB> comment: seems more like a feature than a requirement
2) 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)
JB> comment: should probably me merged with earlier requirements on
subsets
3) Extensibility in the sense that users can add customized
functionality (data transformations, access to new data sources). (from
Enterprise Information Integration)
JB> redundant: with earlier requirements on data transformation
4) RIF should provide for identifying a query language appropriate to
the rule(s) type. (from Situation Assessment and Adaptation)
5) 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)
JB> move: to general requirements
6) 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)
JB> merge: with previous requirement
XVII. Modules of rules
1) 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)
XVII. Validation & verification
1) Verification and validation support. (from Rule Based Service Level
Management and SLAs for Service Oriented Computing)
2) 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)
JB> comment: not clear what is meant with "test cases"
3) 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)
JB> redundant: with earlier requirements in the category "semantics"
XIX. Priorities and preferences
1) 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)
JB> comment: seems more like a feature than a requirement
2) RIF should offer means for representing rule priorities. (from Rule
Based Service Level Management and SLAs for Service Oriented Computing,
Rule-Based Email Manipulation)
XX. Type system / Mode declarations
1) 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)
JB> comment: this requirement largely overlaps with the requirements on
using ontology (especially OWL); I guess this requirement is really "use
non-OWL ontologies"
XXI. Distribution & Scalability
1) Support for scalable reasoning on large amounts of instances (ABox).
(from Ontology Mapping with OWL and Rules)
2) RIF rules should be appropriate for distributed inferencing (from
Distributed e-Learning)
3) 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)
JB> comment: seems more like a general requirement, but I'm not sure
whether we want to allow the manipulation of RIF rules by RIF rules;
sounds very messy,
4) Support for the functionality and requirements of Web Services and
distributed architectures (from Rule-based Service Level Agreements
(SLA) and Web Services)
JB> comment: requirement is very vague; please elaborate
XXII. The rest of the initial requirements list (not yet classified
requirements)
1) Requires that RIF support the intersection of features found in
competing products (from Portability)
JB> comment: seems a general requirement
2) 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)
JB> move: to "modules of rules"
3) 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)
JB> move: to OWL/RDF compatibility
4) 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)
JB> comment: seems more like a feature; what is really the requirement?
5) Decidability or possibility to automatically restrict to an
expressive decidable fragment.(from Ontology Mapping with OWL and Rules)
JB> redundant: with earlier requirements on subsets
6) An instantiation of this use case was implemented with [WWW] POSL
rules as [WWW] NBBizKB and tested in [WWW] 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 [WWW] NBBizKB.
This implies the requirement to 'webize' the language with URIs and
interface it to the newest official [WWW] 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 [WWW] combine rules with taxonomies and to permit
uncertainty handling, as explored in [WWW] Fuzzy RuleML.
(from Information Integration with Rules and Taxonomies)
AP> comment: concrete requirements need to be extracted here.
7) In addition to providing a format for interpreted regulations, the
RIF must provide formats for:
o Compliance action, with discrimination between minimum
mandatory requirements and recommended good practice
o 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)
8) RIF is defined to and from common rule engine implementations (ie
rule formats)(from Transfer of rules between different vendor products)
9) 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)
10) Handle executable rules that operate against operational (W3C) data
systems (from Real-time contract exchange)
--
Jos de Bruijn, http://www.debruijn.net/
+43 512 507 6475 jos.debruijn@deri.org
DERI http://www.deri.org/
----------------------------------------------
Everyone thinks of changing the world, but no one thinks of
changing himself.
- Leo Tolstoy
Received on Tuesday, 21 February 2006 09:29:47 UTC