This is an archive of an inactive wiki and cannot be modified.

This page is dedicated to issues "to be considered" for the UCR.

To set priorities, we could use the following icons from MoinMoin (but there are only 3):

For Working Draft 3

  1. Which CSFs (other than Alignment) does the XML syntax requirement support?

  2. Should the Compliance Model requirement also support the Interoperability CSF? (It was removed from diagram pending discussion.)

  3. From DaveR's email:

    1. Use cases

      1. Use case 2.2 still isn't that convincing for me, though I'm happy to leave it in there. To make that vision work you need not just RIF but an agreed RIF dialect which every buyer/seller software works within (i.e. basically an agreed rule language). At a minimum the "motivates" list should include "limited number of dialects".

      2. The last para of [use case] 2.3 seems somewhat out of place and could be dropped. (I remember how we ended up with it in there and I know we went round this loop before but can't remember what the outcome was).

      3. [Use cases] 2.5 and 2.4 overlap considerably. The justification for having both was that in 2.5 the rules may not be executable and may need to be tagged with status information (as described in the first para). However, the rest of the use case doesn't make it clear which rules are executable and makes no reference to such tagging. Either drop this use case or make the example more clearly consistent with the first para.

      4. In [use case] 2.4 the paras 3 and 8 both seem to be saying the same thing (two integration modalities), suggest dropping 3.

      5. In 2.5 should expand the SBVR reference.

    2. Requirements

      1. Requirements "compliance model" and "default behaviour" should be combined I think.

      2. Similarly, "implementability" and "standard components" could be merged.

      3. Requirement "XML types" needs rephrasing, I think this is supposed to specifically refer to XML Schema datatypes, "information types" is too ambiguous for me. I suggested a phrasing in: However, I guess that's a bit long compared to the other entries in section 4. How about: "RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications" ? or just " ... operations as defined in appropriate W3C specifications"

  4. From F2F3 (moved from the bottom of WD-DC):

    1. Critical success factors

      1. Efficient implementation is possible
        • Comment: new CSF to be considered for the next Working Draft
      2. RIF should be usable as the basis for a Semantic Web rule language
        • Comment: maybe a Goal
    2. Requirements

      1. RIF representation of XML is XML (perhaps similar requirements for RDF and OWL)
        • Phase 2
      2. RIF should support meta-data for currency of rules
        • Comment: perhaps part of the requirement on meta-data support
      3. RIF should support meta-data indicating the executability of rules
        • Comment: perhaps in the next versions of the WD
      4. RIF should support external calls (e.g. to query processors)
        • DaveR's suggestion: RIF should support an extensible mechanism by which rules can consult external "blackbox" information sources or query processors such as SPARQL data sources.

        • RIF should permit SPARQL queries to be used in rules
        • RIF should permit SQL queries to be used in rules
      5. RIF should accept UML instances as data
        • Phase 2
      6. RIF should accept ORM Fact Model populations as data
        • Phase 2
      7. RIF should support uncertain and probabilistic information
        • Phase 2
      8. RIF must cover RDF.
        • Phase 2
      9. RIF must cover OWL.
        • Phase 2
  5. From Sven Groppe's email:

    1. If you start reading, it is not clear what is RIF about. Give a more proper introduction.

    2. There are also no references (e.g. to resources of the real-world examples).

  6. Perhaps should consider immanent as well as transcendent ontologies (from Bob Colomb's email)

  7. Table of contents is inconsistent: some subsections are included, while others are not. Should probably be:
    •      * 1. Introduction
           * 2. Use Cases
                 o 2.1. Negotiating eBusiness Contracts Across Rule Platforms
                 o 2.2. Negotiating eCommerce Transactions Through Disclosure ...
                 o 2.3. Collaborative Policy Development for Dynamic Spectrum Access
                 o 2.4. Access to Business Rules of Supply Chain Partners
                 o 2.5. Managing Inter-Organizational Business Policies and Practices
                 o 2.6. Ruleset Integration for Medical Decision Support
                 o 2.7. Interchanging Rule Extensions to OWL
                 o 2.8. Vocabulary Mapping for Data Integration
                 o 2.9. BPEL Orchestration of Rule-Based Web Services
                 o 2.10. Publishing Rules for Interlinked Metadata
           * 3. Goals
                 o 3.1. Process and terminology
                 o 3.2. CFA Diagram
                 o 3.3. Goals
                 o 3.4. Critical Success Factors
           * 4. Requirements
                 o 4.1. Phase 1
                 o 4.2. Phase 2
           * 5. Coverage
                 o 5.1. RIFRAF
  8. Structure of section 3 can be improved. For example, 3.1 "Process and terminology" probably doesn't need to be an actual subsection (just an intro to the section). Also, there's a section and subsection both titled "Goals".
  9. WD-only issues (no problem on wiki)

    • Note: corrections have been sent, but are not yet visible.

    • 2nd snippet in 2.8 should be class="nowrap":
      If bp is a BusinessProcess that has a Dependency on Application app
        and x is a Server with MaintenanceContract mc that hosts Application app
           then bp has a Dependency on mc
    • all snippets in 2.10 should be class="nowrap"
    • in Firefox, 3rd snippet in 2.10 extends beyond the blue border, and in IE 6.0 the next paragraph is somehow displayed within the border (as if part of the <pre>), causing the page to extend horizontally (see also 2.9)