Re: [UCR] List of requirements on RIF added (1st draft)

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