1. Review of UCR Adrian Giurca

2. General commenst 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. 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)

3. UC1 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.

4. UC2 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 ?)

5. UC3 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."

6. UC4 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

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

8. UC6 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

9. UC7 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

10. UC8 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

11. UC9 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"

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

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

14. 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.?!"

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

16. 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 document. 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 experience.