- From: Ginsberg, Allen <AGINSBERG@imc.mitre.org>
- Date: Sun, 10 Sep 2006 21:27:29 -0400
- To: <public-rif-wg@w3.org>
This is in regard to ACTION-101 "deal with ISSUE-5." "Issue-5" involved a number of comments on the 2nd UCR draft raised by Dave Reynolds. (See http://www.w3.org/2005/rules/wg/track/issues/5) Dave raised 5 points (shown below). #2 and #5 I dealt with. I agree with #4 but that use case was written by Frank McCabe, so I thought he should look at it first. #3 should be reviewed by John Hall and Donald Chapin. #1 should be reviewed by Paula P. Here are the 5 points, together with my remarks. >> 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". I don't see how this uc requires that the buyer/seller software uses an agreed upon RIF dialect. In fact the the uc text says: "The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges." Paula-Lavinia Patranjan should take a look at this one. >> 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). Dropped that paragraph. >> 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. I agree: the use of tagging is not illustrated. I believe it was in another version of the text, but then was removed. John Hall and Donald Chapin should look at this one. >> 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. Agree there is repetition here. Simply removing para 3 wouldn't flow well. Frank should look at this one. >> 5. In 2.5 should expand the SBVR reference. Added reference and expanded SBVR acronym
Received on Monday, 11 September 2006 01:28:25 UTC