W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2007


From: Adrian Giurca <giurca@tu-cottbus.de>
Date: Fri, 23 Feb 2007 16:18:56 +0100
Message-ID: <45DF05E0.6000609@tu-cottbus.de>
To: "'Public-Rif-Wg (E-mail)'" <public-rif-wg@w3.org>
CC: Adrian Giurca <giurca@tu-cottbus.de>

RIF UCR REVIEW (Editor's Working Draft of "RIF Use Cases and 

*General Comments:*

    * Not too many differences between this draft and the previous one.
    * I believe that the UCR document needs to contain rule examples in
      different rule languages and not just a natural language rule
      text. This will help to better understanding the RIF requirements.
    * The document is edited by 4 people and contains 10 use cases. I
      guess that is not to much for each editor to take care about 2-3
      use cases and develop them. As a general principle, use cases
      discuss different interchange/interoperability issues then we need
      to have:
          o rule examples in concrete languages
          o vocabulary examples (where is the case)

*Comments on Use Cases*
1. Negotiating eBusiness Contracts Across Rule Platforms.
This use case is introduced to motivate: Compliance model, XML syntax, 
XML types, Coverage. Is a general agreement that RIF must use XML syntax 
and XML datatypes. The Coverage requirement is suggested by using a 
scenario involving Prolog rules and production rules. I recommend that 
the rules examples from the use case to be represented both in Prolog 
and in a production rule system. Concrete languages can be choose from 
RIF/RAF questionnaire.

2. Negotiating eCommerce Transactions Through Disclosure of Buyer and 
Seller Policies and Preferences.
This use case is provided to motivate a large number of requirements but 
there are no concrete examples. For example the rules:
"Never disclose two different credit cards to the same online shop."
"For anonymity reasons, never provide both her birth date and postal code."
seems to be integrity constraints, so examples in concrete languages 
need to be provided (using Protune ?).

3. Collaborative Policy Development for Dynamic Spectrum Access.
More explanations how rules use OWL data must be provided.
There is a  request  for an imperative semantics (together with 
declarative semantics) but the requirement states: "RIF must cover rule 
languages having different semantics."

4. Access to Business Rules of Supply Chain Partners.
This use case contains just one rule example but claim a number of 
requirements like Limited Number of dialects, OWL data, RDF data etc
The argumentations of these requirements are very poor. I don't see any 
justification regarding the distinction between OWL data and RDF data as 
well as Different semantics.
This use case needs rewriting to justify the claimed requirements.

5. Managing Inter-Organizational Business Policies and Practices.
This use case contains different types of rules examples. I believe that 
these rules need to be classified (i.e. constraints, derivation rules, 
production rules etc). This is important to illustrate the capabilities 
of RIF to handle different types of rules. Of course, at least one 
example in a concrete rule language is desirable.

6. Ruleset Integration for Medical Decision Support.
I believe that this use case illustrate the XML Types requirement too. 
Again, examples in a concrete rule language are desirable.

7.Interchanging Rule Extensions to OWL.
Expressing the example rule  in SWRL can be a good example motivating 
the requirements of OWL data, XML datatypes, as well as for Coverage.

8. Vocabulary Mapping for Data Integration.
I believe that the rules examples does not illustrate the proposed 
scenario. This is an interesting use case but needs rewriting. It is 
necessary to provide at least one example of information from the 
"report on application services", one from "the maintenance contracts 
database" and another one for the "registry of BP and IT services". 
After that try to write rules using these information. Examples in a 
concrete language is desirable.

9. BPEL Orchestration of Rule-Based Web Services.
There are 6 categories of rules which are provided in the use case. I 
recommend examples in a concrete rule language at least one for each 
category. Provided examples ("rules to increment a credit score 
variable") seems to be too simpler and incomplete. We don't write rules 
"to increment a variable".

2.10 Publishing Rules for Interlinked Metadata.
Examples of FOAF are desirable. Then Jena 2 rules can be provided as 

*Comments on the new Section, 2.11. Usage Scenarios and Processing Models.*
I believe that the picture explaining the interchange process open a new 
issue of interchanging the data models of the rules systems. A 
translator must be able to obtain a "shared data model" from a specific 
data model. May be this Section should also contain a collected list of 
requirements together with references to use cases which illustrate 
them. It will be easy for readers to focus on requirements/use cases.

*Comments on Chapter 3, Goals: *
I please readers of this email to read once again these sentences:

"A goal is an overall target that you are trying to reach with the 
project. Typically, goals are hard to measure by themselves. Goals are 
often directed at the potential consumer of the product rather than the 
technology developer."

"A critical success factor (CSF) is a property, sub-goal that directly 
supports a goal and there is strong belief that without it the goal is 
unattainable. CSFs themselves are not necessarily measurable in themselves."

It is hard to believe that an external reader of such sentences 
understands what is the relationship between these sentences and the UCR 
for RIF

Other concepts that are self-explained:
"Widescale Adoption       It is an explicit goal of the W3C that the 
Rules Interchange Format will have the maximum potential for widescale 
adoption. ...."

Words which are not suitable for clear explanations:
" RIF SHOULD FIT WELL with key existing W3C specifications such as XML.?!"

*Comments on Chapter 4, Requirements*
Each requirement must contain references to the use cases which 
introduce it. This will clarify which requirements are justified and 
which are not. Then all requirements must be sufficiently detailed. For 
example Embedded Metadata ("RIF must support metadata such as author and 
rule name.") . Here is supposed that a rule have a name and an author. 
Is this the case? Which use cases exemplify this?
I believe that the requirement concerning XML Types must be XML Datatypes.
Comments on Chapter  6 RIF/RAF*
This section does not have any meaning if the results of the 
questionnaire are presented and processed. Some of us spent some time to 
complete that questionnaire which was supposed to help in a better image 
about  concrete languages on the market. Just list of these criteria 
(called "discriminators", "Pragmatic Discriminators" etc) is not useful. 
I don't see how this section contribute to the document.
Some of the criteria have references who try to justify their adoption. 
Some other do not have.  I suggest that they  must be justified in the 

I please people to read this paragraph:
"Values of Semantic and Pragmatic Discriminators, stated by Rulebase 
authors or found by Static Analysis, can of course still be marked up 
syntactically, e.g. via Semantic/Pragmatic (XML) Attributes on 
Rulebases, Rules, ..., via (RDF) metadata annotations, etc. In each 
group, Discriminators, and possibly subgroups of Discriminators, are 
listed (cf. rdf:subPropertyOf). The numberings of the Discriminators do 
not reflect priority orderings but are there for ease of reference such 
as "Syn 1.2" for the Range-restrictedness Discriminator (however, new 
subgroups may emerge from subsequences of neighboring Discriminators)."

For me is very hard to understand ... is an amazing sentence ... Why we 
want to use each time difficult words? I guess that these documents are 
supposed to be read by external people and they need to easy understand 
them. This section needs hard rewriting using the RIF/RAF questionnaire 

Received on Friday, 23 February 2007 15:19:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:42 UTC