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