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

Hi Dave,

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

Actually, Sandro updated the draft and this issue is now fixed. Rule
snippets how look just as they do on the wiki.

A related (minor) issue is that rules are structured differently. For
example,

  If an item is perishable and it is delivered more than 10 days after
  the scheduled delivery date then the item will be rejected.

vs.

  If x is a ComputeNode in Rack r
     and Rack r is in Cage c
     and mc is a MaintenanceContract for Cage c
        then x is a Server with MaintenanceContract mc

Should we format them all like the latter for clarity, or is this too
artificial?

On the other hand, this doesn't work so well for policies, e.g.:

  Never disclose two different credit cards to the same online shop.


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

Yes, this req refers to XSD datatypes but also list structures. You're
right that it's a bit confusing; I added the link to the charter to help
clarify, but maybe it's not enough.

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

It's listed under "needs more discussion" in the F2F3 list:
http://www.w3.org/2005/rules/wg/wiki/WD-DC

Maybe there's been enough discussion?

> ** Trivial nits
> 
> o s/eight/ten/ (section 2, para 1)

Fixed on the wiki. I just added "In the second round, two new use cases
were added" after "These were grouped into eight general categories and
then synthesized as much as possible."
 
> 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".

I had that feeling, too. Does anyone object to dropping it?

DavidH


> -----Original Message-----
> From: public-rif-wg-request@w3.org 
> [mailto:public-rif-wg-request@w3.org] On Behalf Of Dave Reynolds
> Sent: Tuesday, June 27, 2006 10:26 AM
> To: public-rif-wg@w3.org
> Subject: 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:56:58 UTC