Re: Editor's Draft of UCR (more or less) ready

Sandro Hawke wrote:
> I've combined the wiki pages to make a new editor's draft of UCR
> for discussion tomorrow and an expected decision a week from tomorrow.
> 
>    http://www.w3.org/2005/rules/wg/ucr/draft-20060626
> 
> There's a formatting glitch where the sub-headings are not numbered (for
> instance, "Compliance Model" should be "4.1.1 Compliance Model") which
> I'll fix in place soon, but otherwise I think the document is stable and
> ready for review.  (If I've missed something that one of the editors is
> doing, please speak up.)

Thanks for this. Here's my comments at this stage:

** Issues that should be addressed before publication

1. The separation of alignment CSFs into two "alignment with .." buckets 
with only one linked to wide-scale deployment is not helpful and can be 
misread in several ways.

The easiest solution would be to adopt DavidH's suggestion (see thread 
started by Peter) of merging these two, for now at a least.

2. As also pointed out by pfps the "motivates" links are rather 
inconsistent. By having general requirements like "semantic precision" 
in some use cases and not in others it implies there is no need for 
semantic precision in those other use cases which is not correct.

We either need an agreed set or we should omit the links for this draft.

3. The example rules do not word-wrap, making the document unreadable in 
printed form.

[Sorry to put a trivial formatting thing in this category but it came up 
on the last draft and it can't be that hard to fix :-)]


** Less critical comments
[Though it'd be nice to address some of them.]

* Intro

o It'd help to have a description in the introduction of how the 
document is structured and how the use cases help to motivate RIF which 
we then break down into specific goals and requirements.

* Use cases

o 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".

o The last para of 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).

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

* Goals

o The phrasing of the "alignment with semantic web" CSF doesn't work for 
me but I'm suggesting a merge anyway (see 1 above).

* Requirements

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

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

o 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:
http://lists.w3.org/Archives/Public/public-rif-wg/2006Jun/0128.html
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"

o Missing requirement on external call out and SPARQL (see same message 
thread quoted above). How about:
    "RIF should support an extensible mechanism by which rules can 
consult external "blackbox" information sources or query processors such 
as SPARQL data sources."  ?

* RIFRAF

o Drop SeS 7.2 as too special a case of Ses9 (isn't that what was 
decided at the f2f?)

o Drop Prag 3.2 - it is hard to read "test cases" as a discriminator 
dimension for rule systems.


** Trivial nits

o s/eight/ten/ (section 2, para 1)

o In 2.4 the paras 3 and 8 both seem to be saying the same thing (two 
integration modalities), suggest dropping 3.

o In 2.5 should expand the SBVR reference.

o Suggest dropping para 2 of section 3, this reads more like an advert 
for the methodology and isn't helped by use of the term "project".

Dave

Received on Tuesday, 27 June 2006 13:26:51 UTC