- From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
- Date: Mon, 20 Feb 2006 09:37:59 -0500
- To: <public-rif-wg@w3.org>
> - 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. > [recorded in http://www.w3.org/2006/02/14-rif-minutes.html#action15] Axel numbered the requirements and classifications from Paula's document, which I employed here to make a start by inserting review comments inline, using ". . ." for large omissions and "..." for small omissions. (*) (I first refined NRC's XXII.6) into XXII.6a) - XXII.6c), because these were three reqs.) -- Harold ------- (*) This is one way to do it in plain ASCII, although the Wiki supports numbering -- with " 1." instead of " *". (I don't know if it would also support Annotea-style 'yellow sticky' annotation.) ===================================================== 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) > comment: Very general; 'import' may be added. 'understood' could be > qualified. > merge/split: See also I.2), I.4). > phase proposal: Phase 1 and Phase 2. 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) > comment: 'dialects'='sublanguages'? Partial order of expressiveness? > merge/split: See also I.1). See particularly I.3). Merge with I.5). > phase proposal: Phase 1 and Phase 2. 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) > comment: An *integrated* (rather than *interfaced*) ontology would > go beyond RIF. A KR framework should span the entire SemWeb activity. > merge/split: See particularly I.2). > phase proposal: Phase 1 and Phase 2. 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) > comment: Interchange on higher layer, implementation on lower layer; > but implementation-relevant annotations (e.g. forward/backward) may > already exist as (pragmatic) attributes on interchange layer. > merge/split: See also I.1). > phase proposal: Phase 1 and Phase 2. 5) RIF should incorporate the ability to describe differences across rules and rule-sets (from Supporting the Reuse of Rules) > comment: The level of rulesets may be of more immediate use. > merge/split: Merge with I.2). > phase proposal: Phase 1 and Phase 2. 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) > comment: Two-level invocation (select ruleset, then rules) may be > another good use of modules/scopes (besides Scoped NAF). But this > looks more like an extended scope feature than like a req. > merge/split: Proposed technical feature. Merge with I.7) and XVII. > phase proposal: Phase 1 and Phase 2. 7) Different knowledge bases should be encapsulated so that their rules will not interfere with each other. (from Scoped negation, Encapsulation) > comment: Also relevant for "Load-and-Query Rule Engine". But this > again looks more like an extended scope feature than like a req. > merge/split: Merge with I.6) and XVII. > phase proposal: 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) > comment: May need rewording (FOL extension, function-free Horn, NAF). > merge/split: Seems already clear from charter. > phase proposal: Phase 1 (function-free Horn rules) and Phase 2 (NAF). . . . V. Syntax(es) 1) An human legible syntax and a machine processable syntax. (from Publication of semantics (e.g. SKOS, RDFS), Automatically generated rules) > comment: Machine processable syntax must be uniform; from it, one > or more human legible syntax(es) could be generated. > merge/split: Merge with XXII.6a). > phase proposal: Phase 1. 2) Provide sufficient structure to represent (rules of) the parties involved and the data they deal with (from Real-time contract exchange) > comment: Very general, because hard to predict 'parties involved'. > How do we delineate RIF facts from external data that RIF deals with? > merge/split: Omit general part. Merge data part into VI. > phase proposal: Phase 1 and Phase 2. VI. Data model / Type of data . . . 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) 3) Classical negation (from Situation Assessment and Adaptation, Refund Policies in E-Commerce, Credit Card Transaction Authorization, Supply Chain Ordering Lead Time, Price Discounting) . . . 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) > comment: This again looks more like an extended scope feature than > like a req. > merge/split: Merge with I.6) and I.7). See also X.2). > phase proposal: Phase 1 and Phase 2. . . . XXII. The rest of the initial requirements list (not yet classified requirements) ... 6a) 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. (from Information Integration with Rules and Taxonomies) > comment: Parsers from one or more human legible syntax(es) could map > into one uniform machine processable syntax. > merge/split: Merge with V.1). > phase proposal: Phase 1. 6b) 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. (from Information Integration with Rules and Taxonomies) 6c) 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) ...
Received on Monday, 20 February 2006 14:39:33 UTC