- From: Axel Polleres <axel.polleres@uibk.ac.at>
- Date: Mon, 20 Feb 2006 15:50:38 +0100
- To: public-rif-wg@w3.org
- Message-ID: <43F9D73E.5000806@uibk.ac.at>
Boley, Harold wrote: >>- DRAFT - >>RIF Working group minutes >>14 Feb 2006 > > >>[NEW] ACTION: Axel, Dieter, Jos and Harold: to review the Requirements >>(http://www.w3.org/2005/rules/wg/wiki/UCR/Requirements) and comment > > them. Find my comments attached. I hope we can discuss them alltogether in Cannes latest. The comments are structured as follows per requirement: AP> comment: general comments questions and suggestions on the AP> requirement AP> merge/split: should this requirement be merged with another AP> requirement or actually split to several requirements? AP> phase: proposal to which phase does this requirement belong AP> according to the charter. best, axel -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/
Before commenting the list compiled by Paua, I derive the following overall
requirements from the charter, which should maybe be referenced in this document:
Requirements from the use cases in the charter:
==============================
- there is a requirement that RIF allows defining mapping rules for handling
structural variations between data sources.
- rules shall be sharable
(comment: this might involve authentication needs!)
- rules shall be mergable from multiple sources
(comment: avoid ambiguity by e.g.namespaces)
(comment: this might still include to deal with conflicting
rules, handling preferences)
- combination of own business rules with legal rules, rules of partners
(comment: this might include the need for notions of trust)
Explicitly mentioned requirements in the charter:
=============================
- must make use XML data
- must use RDF semantics
- extension mechanism must be compatible with SPARQL
- must interop with OWL
- must support XML Schema and XQuery dataypes, a minimal set defined for phase 1
Addressing of requirements in the two phases according to charter:
Phase 1:
- defines core based on Horn Logic plus an extensability mechanism
- extensability: define behavior for unsupported features:
(comment: the charter mentiones levels like in DOM/CSS, but probably
semantic features supported by a ruleset/rule engine are better.
This features shall distinguish betwen reuired (like SOAP
mustunderstand), or oprional, e.g. only issue a warning)
- The support of one specified format for data is enough in phase 1.
Phase 2:
- Active rules only in phase 2.
- notion of ruleset
- language levels (similar DOM,CSS) for extensions.
- Negation, classical, default.
(comment: a problem here is that classical negation is already in OWL and
NAF is already in SPQARQL. So, if we want OWL/SPARQL interop in phase 1,
we need to make some decisions here in pahse 1 already!)
- Lloyd-Topor
(comment: one of the use cases (franconi/tessaris) already shows
that Lloyd-Topor wih disjunctive rule bodies plus OWL union might
cause problems).
- Reification/metareasoning over rules
(comment: in my interpretation this includes e.g. support for: trust,
authentication of rules, preferences among rules/rulesets).
- Several supported data formats, interop with several formats.
FIND BELOW THE NUMBERED AND PRE-CLASSIFIED LIST OF REQUIRMENTS BY PAULA
WITH MY DETAILED COMMENTS PER USE CASE:
=====================================================
RIFUCR - List of Classified Requirements (with Duplicate Elimination)
Status
Requirements on RIF
I. General
AP> comment: What makes these requirements more general than the others?
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)
AP> merge/split: this one could go into V.
AP> phase: 1
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)
AP> comment: This is basically declaring the semantic features mentioned in
AP> the extensability mechnism for pahse 1 in the charter.
AP> merge/split: this one could go into III.
AP> phase: 1
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)
AP> comment: This should be further specified.
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)
AP> comment: This should be further specified. Not clear what is meant here.
AP> Is this a syntactical or a semantic discrimination?
5) RIF should incorporate the ability to describe differences across rules and rule-sets (from Supporting the Reuse of Rules)
AP> comment: How? If this is about equivalences differences of rulesets, this is
AP> undecidable for very simple rule sets already
AP> merge/split: this one could go into IX.
AP> phase: 2 (not sure whether this is in the scope of the charter)
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)
AP> comment: see commment I.5
7) Different knowledge bases should be encapsulated so that their rules will not interfere with each other. (from Scoped negation, Encapsulation)
AP> comment: this is about defining the context of a rule. I would rewrite
AP> "rules will not interfer" to "rules interact in a controlled and
AP> predictable manner". Are namespaces suficient for this?
AP> merge/split: maybe context/provenance of rules should be an own category
AP at the moment this is related to XI.
AP> phase: 1
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)
AP> comment: Horn is a subset of FOL and not an extension? What is the point here.
AP> merge/split: Negation is covered in X.
AP> phase: 2
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)
AP> merge/split: I don't see the difference between II.1 and II.2 couldn't these
AP> be merged?
AP> phase: 1
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)
AP> merge/split: I don't see the difference between II.1 and II.2 couldn't these
AP> be merged?
AP> phase: 1
3) Requires that rule bases use a shared (or mergeable) ontology and can then be merged themselves (from Product Compatibility)
AP> phase: 1
4) RIF should be able to reference ontologies in which rule content is defined.(from Situation Assessment and Adaptation)
AP> phase: 1
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)
AP> comment: There should be a general mechanism to represent/use RDF
AP> facts in a given RDF vocabulary in Rule bodies (and heads?),
AP> why restrict to FOAF?
AP> phase: 1
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)
AP> comment: not only this, mapping classes to instances, attributes to classes,
AP> etc. might all be use cases for mappings. Probably Jos could
AP> comment more on this, he worked on ontology mapping in the
AP> SEKT project.
AP> phase: 1/2 depending on what features are necessary for the mappings
7) Access to data sources requires transport of meta data (datatype, name in external data source, ?). (from Enterprise Information Integration)
AP> merge/split: Why is this in OWL/RDF compatibility? Shouldn't this go to IX?
8) Representation of RDF transformation rules (from Message Transformation)
AP> merge/split: is subsumed or could be merged with II.6 in one
AP> mapping/transformation rules requirement
AP> phase: 1/2 depending on what features are necessary for the mappings
9) Support for object introduction ("gensym" of URI's, bNodes in conclusions) (from Message Transformation)
AP> phase: 2 (depends on what degree we decide to be compatible with RDF
AP> in phase 1 already)
10) Quantification over RDF predicates (from Message Transformation)
AP> comment: Clarify.
AP> merge/split: if you mean universal quantification in rule bodies, this
AP> needs a defined context/scope and should go in the same
AP> category as scoped negation or other context/provenance
AP> related issues (X, XI).
AP> phase: 2
11) Guidance on how OWL/RDF triples are associated to the patterns in rules. (OWL/RDF compatibility issue?) (from Filling the holes of OWL)
AP> merge/split: very unspecific, probably subsumed by II.1, II.2
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)
AP> merge/split: if this is about specifying mappings, already covered by II.6/7,
AP> apart from that overlap with II.1, II.2
AP> phase: 1/2 depending on what features are necessary for the mappings
13) Rich Knowledge Representation allowing invocation of classes as individuals (from Supporting the Reuse of Rules)
AP> commment: Is this about metareasoning? Could be combined with II.17
AP> phase: 2
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)
AP> phase: 1 (if this is about using OWL features in rule bodies)
15) Support for nonmonotonic inheritance (from Frame-based representation, Inheritance of defaults, Reification)
AP> merge/split: I don't see why this is specifically about OWL/RDF
compatibility. MAybe there's a better category.
AP> phase: 2
16) Support for frames (from Frame-based representation, Inheritance of defaults, Reification)
AP> phase: 1
17) Support for reification (from Frame-based representation, Inheritance of defaults, Reification)
AP> commment: Could be combined with II.13
AP> phase: 2
18) Expression of deductive closure rules. (from Publication of semantics (e.g. SKOS, RDFS))
AP> phase: 1
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)
AP> comment: Specify whya you mean by rhs, I assume rule head. OWL-DL should be
AP> OWL DLP.
20) OWL DL expressiveness is required.(from SW rules for Health Care and Life Sciences)
AP> phase: 1 (affects how far we commit/how we interop with OWL DL in the core lang.)
21) Expressiveness that is superiour to OWL-DL. (from Ontology Mapping with OWL and Rules)
AP> phase: 1 (affects how far we commit/how we interop with OWL DL in the core lang.)
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)
AP> merge/split: group with requirement II.20
AP> phase: 1 (affects how far we commit/how we interop with OWL DL in the core lang.)
23) RIF should be (partially?) mappable from/to [WWW] SPARQL (from Internet search: combining query language, rule languages and scoped negation)
AP> phase: 1
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)
AP> comment: yes, one should be able to express the semantic features of the rules
AP> in metastatements about the rules.
AP> phase: 1
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)
AP> comment: this is basically the requirement for core semantics and
AP> extensability meachanism from the charter.
AP> phase: 1
3) Declarative as well as operational semantics.(from Automatically generated rules)
AP> comment: What is meant here exactly? Be precise: Do you mean
AP> algorithms, decidability? Executions semantics for reactive rules?
AP> Checking the original requirement I would interpret it like this.
AP> I am not sure whether decidability is always necessary, sound but
AP> incomplete might be ok in some cases except for the core language
AP> When defining extensions in phase 2, the extensions should be
AP> carefuly chosen and we should provide which combination of semantic
AP> extensions/features have decidable algorithms
AP> phase: 1/2
4) Probably need an ontology of RIF semantics (formally represented in a standard ontology language) (from Distributed e-Learning)
AP> phase: 1/2 (could specify the extensability features for phase 2)
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)
AP> comment: Do we specify/classify declarative semantics or implementation
AP> algorithms. In favor of the former, I'd drop this requirement
AP> or merge it into III.6/III.2
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)
AP> comment: this is basically the requirement for core semantics and
AP> extensability meachanism from the charter.
AP> spilt/merge: III.2
AP> phase: 1
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)
AP> comment: just to recap the discussion in some mails again: What is called
AP> "normative rules" here are basically integrity constraints, often
AP> represented as rules with empty head.
AP> phase: 2 (at least (re)active rules are out of scope of phase 1 accord. to
AP> charter)
V. Syntax(es)
1) A human legible syntax and a machine processable syntax. (from Publication of semantics (e.g. SKOS, RDFS), Automatically generated rules)
AP> phase: 1
2) Provide sufficient structure to represent (rules of) the parties involved and the data they deal with (from Real-time contract exchange)
AP> comment: this is vague/unclear. not a concrete requirement.
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)
AP> comment: here is a suggestion to refine this: Reactive rules should support events
and queries in rule bodies.
AP> phase: 2
2) Support for semistructured data (from Frame-based representation, Inheritance of defaults, Reification)
AP> comment: clarify.
AP> merge/split: if this is about different data syntaxes supported,
AP> then it should go to V.
AP> phase: 2
VII. Basic numeric computations & aggregations
1) Support for basic numeric computations and aggregate functions.(from Automatically generated rules)
AP> comment: aggregates require a specified context for evaluating the context.
AP> split/merge: this requirement mixes two issues: support for numeric built-ins
AP> and support for aggregates. Furthermore, I suggest to merge the
AP> categrories VII and VIII.
AP> phase: 1 (basic set of numerical built-ins, extendability mechanism for built-ins)
AP> phase: 2 (aggregates and more built-ins)
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)
AP> split/merge: I suggest to merge the categrories VII and VIII. Both
AP> are about procedural attachments and aggregates.
AP> phase: 1 (basic set of numerical built-ins, extendability mechanism for built-ins)
AP> phase: 2 (aggregates and more built-ins)
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)
AP> merge/split: This also seems to be related to categtory XXI.
AP> phase: 2 (Actually, I do not see the real-time requirement in the charter at all
AP> but maybe an issue for an extended/restricted version of RIF to be
AP> defined as a parallel effort)
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)
AP> phase: ?
3) Rule transfers may be transaction-based events and as such are supported by RIF. (from Transfer of rules between different vendor products)
AP> phase: ?
X. Negation
AP> phase: 1/2 As already mentioned in the general comments on the charter,
AP> a problem here is that classical negation is already in OWL and
AP> NAF is already in SPQARQL. So, if we want OWL/SPARQL interop in phase 1,
AP> we need to make some decisions here in pahse 1 already!)
1) Negation over extensional data. (from Message Transformation)
AP> comment: This sounds like input negation for factual data for me.
AP> This is more restricted than stratified negation even,
AP> Anyway, for both we need defined scope/context of over what range
AP> negation applies
AP> merge/split: related to XI as well
AP> phase: see general comment on category X.
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)
AP> comment: negation as failure must be always scoped, IMO.
AP> merge/split: related to XI as well
AP> phase: see general comment on category X.
3) Classical negation (from Situation Assessment and Adaptation, Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting)
AP> phase: see general comment on category X.
XI. Closed world assumption scoped to data sets (this is also implied by the requirement on scoped negation)
AP> comment: I would tend to add a requirement to define what
AP> "context of ruleset" means
1. RIF should provide representation for closed-world assumption with some rules. (from Situation Assessment and Adaptation)
AP> phase: see general comment on category X.
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)
AP> phase: 2
2) RIF should include representation for probabilistic information. (from Situation Assessment and Adaptation, Automatically generated rules)
AP> phase: 2
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)
AP> phase: 2
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)
AP> phase: 2
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)
AP> phase: 2
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)
AP> phase: 2
XV. Datatype support
1) Datatype built-in predicates and functions (from Representing some levels of fuzzy rules with the help of datatype built-ins)
AP> split/merge: I suggest to merge into categrories VII and VIII. Both
AP> are about procedural attachments, built-ins and aggregates.
AP> phase: 1 (basic set of numerical built-ins, extendability mechanism for built-ins)
AP> phase: 2 (aggregates and more built-ins)
XVI. Query language
AP> comment: To be clarified what interaction we allow with the query language,
AP> I.e. do we allow recursive affection of rule heads with the queried
AP> context?
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)
AP> phase: 1
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)
AP> comment: Not entirely clear to me.
3) Extensibility in the sense that users can add customized functionality (data transformations, access to new data sources). (from Enterprise Information Integration)
AP> comment: Not entirely clear to me, why is this in XVI?
4) RIF should provide for identifying a query language appropriate to the rule(s) type. (from Situation Assessment and Adaptation)
AP> comment: The charter at the moment only covers SPARQL, what else is
meant here? Clarify!
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)
AP> comment: overall requirement, not necessarily assognable to a phase/feature.
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)
AP> comment: overall requirement, not necessarily assognable to a phase/feature.
AP> phase: if this about data FORMATS, then phase 1 of the charter says
AP> that only one data format needs to be supported in phase 1.
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)
AP> phase: 2?
XVII. Validation & verification
1) Verification and validation support. (from Rule Based Service Level Management and SLAs for Service Oriented Computing)
AP> comment: I don't see this covered by the charter upfront, but important.
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)
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)
AP> merge/split: This seems to me close to III.5/6
AP> phase: 1
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)
AP> phase: 2
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)
AP> phase: 2
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)
AP> merge/split: what is the difference/overlap with II/XV here? I.e. support of
AP> ontologies and datatypes.
XXI. Distribution & Scalability
1) Support for scalable reasoning on large amounts of instances (ABox). (from Ontology Mapping with OWL and Rules)
AP> phase: 1 (probably a requirement for the core lang)
2) RIF rules should be appropriate for distributed inferencing (from Distributed e-Learning)
AP> comment: concrete algorithms out of the scope of RIF, probably,
AP> but support by provision of a unified exchange format
AP> for (modules of) rulesets.
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)
AP> merge/split: related to II.6?
4) Support for the functionality and requirements of Web Services and distributed architectures (from Rule-based Service Level Agreements (SLA) and Web Services)
AP> phase: Do we want to address this in phase 1? At least we should carefully monitor
AP> concrete requirements from Web services, although this needs clarifiation.
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)
AP> merge/split: classify in III?
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)
AP> merge/split: classify in XI (if this category is extended to define
AP> what context/scope of a rule means?
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)
AP> merge/split: to category II?
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)
AP> merge/split: classify in IX?
5) Decidability or possibility to automatically restrict to an expressive decidable fragment.(from Ontology Mapping with OWL and Rules)
AP> merge/split: classify in III?
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)
AP> comment: what are executable rules? Is this the same as (re)active rules? clarify.
Received on Monday, 20 February 2006 14:50:55 UTC