W3C home > Mailing lists > Public > public-rif-wg@w3.org > October 2008

[RIF] Action-624 (Review UCR)

From: Stella Mitchell <cleo@us.ibm.com>
Date: Tue, 28 Oct 2008 20:46:59 -0400
To: "RIF WG" <public-rif-wg@w3.org>
Message-ID: <OF9974E75F.205DAEE3-ON852574EF.0068AFDD-852574F1.00044D24@us.ibm.com>
Dear WG,

These comments are on the 10/28 version of UCR.


    Section 2 - Goals:

         Section 2.2
               I'd put this as the first goal. 

               I think the information in the sub-bullets would be better 
               in the introduction. Here, maybe, could be a brief 
               discussion of the intra-rule-family  vs. inter-rule-family
               distinction. That topic is briefly touched on in 
               5.1.6 and discussed in the conclusion, but not before.
               (see also comment for item 3 in section 2.4)

         Section 2.4 - Critical Success Factors
               I think this section would be better deleted. Most of 
               the items are already listed as a goal or a requirement.
               Requirements support goals in the same way that CSFs
               do. Without the whole original scheme and explanation, 
               this section doesn't seem so useful and may just add 
               clutter. In substitution for this section, there could
               optionally be a little more explanation under certain 
               requirements explaining how they relate to the goals.
               (e.g. could say for req 5.1.1 that this will support the 
                of widespread adoption) 

                   1.  Same as goal 2.1
                   2.  Same as requirement 5.1.6
                   3. This one seems to be talking about inter-dialect
                        interoperability (as opposed to intra-dialect)? 
                        distinction is made explicitly in the conclusion 
                        it says that inter-dialect interoperability is not 
                        by the current phase of  the working group. Maybe 
                        should be a requirement about maximum overlap 
                   4. requirements 5.1.2, 5.2.2 ?
                   5. requirement 5.1.3
                   7. requirements 5.1.1, 5.1.4, and 5.1.5 

    Section 3 - Structure of RIF
         I don't think this section fits well in this document.  Could
         there be some short separate "Note" that is a document
         roadmap for RIF?

    Section 4 - Use Cases
      last para (before 4.1):
             This paragraph doesn't sound quite right, isn't PS a formal
              notation?  These 2 sentences could be moved above
              the show/hide buttons and merged with the sentence
              there to be something like:
                 "The rules in the use cases are expressed in English,
                   and also, where possible,  in the Presentation Syntax
                   of RIF dialects"
    UC 4.1
       Replace "slotted" terminology with "named argument" 
       (for uniterms) (several places) 

       use "subtract-dateTimes" instead of "numeric-subtract" 
       (applies to multiple examples in this UC)

       If there is a style recommendation for the use of guard 
       predicates, then add them to make sure ?deliverydate and
       ?scheduledate are of the correct type. (applies to multiple)
    UC 4.2
      BLD examples: 
           Some of the frame slot values are frames, and this is not
            valid BLD syntax.

       "Meta-interpretation" is mentioned (xor) in this use case, but not 
        mentioned in any of the others where it might also be used.
        I'm not sure if the use of meta-interpretation was supposed to
        be removed from the use cases.

        What is  http://www.w3.org/2007/rif-builtin-operators#" ?

        Unused & unecessary prefix declarations pred and func
        (check all the examples for this, applies to a number of 
          the following ones also)

    UC 4.3
       2nd  & 3rd rules:
           The BLD version of the rule doesn't read the same
           as the English version 
                 (if no energy detected, then no device is using band 
                 if energy detected, then device is using band) 

           Missing 'And' wrapper in body
           leftover "." at end of rule (3rd example)

           style: use guard predicate to make sure ?level is
      Paragraph following the 2nd rule: (about energy detection function)
            I think this paragraph is incorrect. Isn't that what
            external frames are for?
    UC 4.4
        For the rule in this UC,  and for the 1st rule in UC 4.3, there 
        is no BLD example and there is an explanation of why the rule
        cannot be expressed in BLD. But for other later UCs, there are 
        sometimes  no BLD version and no explanation (eg UC 4.5,
        2nd rule of UC 4.6, etc)
    UC 4.6
       ineffective, hasDiesease, etc look like predicates,  but that would
       mean this example has a predicate as an argument to a predicate, 
       which is not allowed in BLD.

       The body needs to be wrapped in an 'And'

    UC 4.9
       The BLD examples are missing 'forall', 'and', use "<", and
       have "."  at the end of rules, and use non-existent 

    UC 4.10
        The examples are still all in Abridged presentation syntax.

        The 1st movie BLD example has a membership term in the
        object position of a frame,  which is not  allowed.

        The 2nd movie BLD example uses a "not" predicate without 
        explanation, and has a predicate as an argument to a 
        predicate, which is not allowed.

        why use:
            ?Movie#ex:Movie :- ?Movie#ex:ScienceFictionMovie. 
        instead of 
             ex:ScienceFictionMovie ## ex:Movie ?

        In the Charlie examples:
           getEventData (and sysTime?) should be written as  External
           I'm not sure if <rdf:type> is valid syntax.?

    Section 5 - requirements
         2nd paragraph:
             The last sentence (that level of fulfillment is discussed) is 

              not true (I think).

              What about removing the "General" and "Basic" classification
              of requirements, and just saying that if a requirement is 
              by  particular use cases,  then links to the use cases are 

         3rd paragraph:
              1st sentence:
                    Why have hidden requirements (ones that are not
                     mentioned here, and are not  based on either the 
                     charter, goals or use cases)? There should at least 
                     a reason given for not including them, and some 
                     of what their nature is.  Also, why not include or 
point to the 
                     the requirements from the Charter here, or add an 
                     explanation why they are not included?

         Sections 5.1 (General requirements) and 5.2 (Basic requirements)

                   Is it really true that only one use case calls for RIF 
to have
                   clear conformance criteria?  This seems (General).

                   I think this one could use more explanation about what 
                   requirement is.

                5.2.4 and 5.2.5
                    Can these be merged because comments are 
                    a kind of metadata?

                    Why does use case "Ruleset Integration for Medical 
                    Decision Support" require Embedded metadata, and 
                    use case  "Collaborative Policy Development for 
                    Spectrum Access" not require Embedded metadata?

                    (I think this type of question could be asked for a
                     number of the "motivated by" assignments)

                   Why does use case "Negotiating eCommerce Transactions
                   Through Disclosure of Buyer and Seller Policies and 
                   Preferences"  require that RIF have a limited number of 
                   and use case "Negotiating eBusiness Contracts across 
                   Platforms" not require it?
                   Similarly for (e.g.) requirement 5.2.9. It's not clear 
(to me)
                   why UC 4.2 out of all the use cases needs the semantics
                   of a RIF document to be determined by the content of 
                   document, while none of the other use cases do.

                5.2.7, 5.2.8. 5.2.14:
                   These also support goal 2.1. (Would that make them 

                   I'd put 5.2.14 next to the other two, just to group 

                  This is in the Basic (motivated by use case) section, 
but there 
                  are no links to motivating use cases.

    Section 6 - conclusion
          Inter-dialect interoperability is discussed here for the first 

   Section 7 - References
         Add BLD, DTB, SWC, PRD (because code examples depend
         on them),  and the charter ?
Received on Wednesday, 29 October 2008 00:47:43 UTC

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