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

Hi Paula,

> I propose to change the rules in 2.8 so as to have uniform 
> descriptions of the use cases.

I agree that they're inconsistent with the others, but I suppose the
argument could be made that they're for mapping between information
models, which aren't normally written in English. Let's discuss on the
call.

If the rules in 2.8 are changed, we should probably also changed the
rule in 2.7:
"If MAE X is bounded by Z and MAE Y is also bounded by Z then X is
connected to Y."

DavidH

> -----Original Message-----
> From: Paula-Lavinia Patranjan [mailto:paula.patranjan@ifi.lmu.de] 
> Sent: Tuesday, June 27, 2006 11:53 AM
> To: Hirtle, David
> Cc: Dave Reynolds; public-rif-wg@w3.org
> Subject: Re: Editor's Draft of UCR (more or less) ready
> 
> Hi,
> 
> Regarding the structure of the rules, as far as I remember we 
> decided at the F2F in Cannes to have the rules described in 
> natural language. The rules of use case 2.2 were first given 
> in a manner similar to those in
> 2.8 but then I changed them; one of the reasons were that 
> same rule can be implemented e.g. as a deductive or as a 
> reactive rule and it's better to leave this open (at least for now).
> 
> I propose to change the rules in 2.8 so as to have uniform 
> descriptions of the use cases.
> 
> Regards,
> Paula
> 
> Hirtle, David wrote:
> > 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 15:22:36 UTC