Re: [UCR] Resolving overlaps between use cases 1.1,1.4,1.5

Vincent, Paul D wrote:
>> As I said, I was not necessarily implying that we merge them, but
>> having 3 similar but different scenarios with no reference to each
>> other is not very enlightening for the outside reader I would guess.
> 
> Axel - you make a fair point, although I'm not sure the main focus of
> the UCR doc is the "outside reader". What the "partly-overlapping
> scenarios" emphasizes to me is that this area is both emphasized in RIF
> use cases by RIF members (ie it's a "vote" for the main role of RIF). 

>>Thus my proposal was to align the scenarios on the one hand and carve 
>>out the different adressed aspects per use case clearer.
> 
> This is a notable aim, but I'd have thought the analysis of the
> scenarios to derive requirements will come at the next step. 

Fair enough. My proposal is anyway for the next version of the document, 
which indeed should also have more emphasis on deriving the requirements.

> The fact
> that some are B2B, B2C, involve production rules over XML, constraints
> over medical facts, etc, are all aspects that we want to derive from the
> use cases, not massage the use cases to match...

Sure (and this was definitly not what I wanted to convey).

best,
axel

> -----Original Message-----
> From: Axel Polleres [mailto:axel.polleres@uibk.ac.at] 
> Sent: Wednesday, March 15, 2006 11:16 AM
> To: Vincent, Paul D
> Cc: public-rif-wg@w3.org
> Subject: Re: [UCR] Resolving overlaps between use cases 1.1,1.4,1.5
> 
> Vincent, Paul D wrote:
> 
>>I guess that if you abstract the scenarios enough, they will all look
>>the same!
> 
> 
> As I said, I was not necessarily implying that we merge them, but
> having 3 similar but different scenarios with no reference to each other
> is not very enlightening for the outside reader I would guess.
> 
> Thus my proposal was to align the scenarios on the one hand and carve 
> out the different adressed aspects per use case clearer.
> 
> No hard objection against also aligning scenario 1.2 (although it is 
> more B2C than B2B in my understanding and policy and trust negotiation 
> rules are a separate scenario for my taste, at least I didn't ask myself
> 
> at first reading, what is the distinct aspect addressed here).
> 
> As for your additional remarks:
> Sure, I think it would be nice if the use cases refer to each other and 
> discuss differences and how they relate to each other, maybe in the 
> separate section which extracts the requirements this connection can be 
> made.
> 
> I see the scenario of 1.3 with its probably inherent real-time 
> requirements also in a different overall category.
> 
> Overall, what I propose should not be too much effort, and does not 
> imply that we don't move on, but that we gain better mutual 
> understanding, and also better understanding for the outside reader.
> 
> best,
> Axel
> 
> 
>>Some additional thoughts: 
>>1.2 is also very closely related to 1.1, 1.4 (buyer/seller policies
>>could be viewed as a subset of contracts)
>>1.3 is very similar to 1.5 (technical compliance is a subset of
>>organizational...)
>>1.6 implies human-readable rules which of course was the basis for 1.5
>>(and its basis for being controversial)
>>(and of course 1.7 still looks like an excuse to build an OWL rule
>>language to me, but then I presume the different OWL varieties might
>>want different OWL rules languages to be interchanged...)
>>
>>Naturally, these "scenarios" are just for guidance: they do not
> 
> contain
> 
>>too much detail for extracting requirements.
>>
>>I (would) vote: we leave as is and move on... 
>>
>>Paul Vincent
>>Fair Isaac Blaze Advisor --- Business Rule Management
>>OMG PRR and W3C RIF for rule standards
>> -----Original Message-----
>>From: public-rif-wg-request@w3.org
> 
> [mailto:public-rif-wg-request@w3.org]
> 
>>On Behalf Of Axel Polleres
>>Sent: Wednesday, March 15, 2006 7:45 AM
>>To: public-rif-wg@w3.org
>>Subject: [UCR] Resolving overlaps between use cases 1.1,1.4,1.5
>>
>>
>>
>>
>>
>>As agreed in yesterday's telecon, here a short summary of the issues 
>>around use cases 1.1, 1.4, 1.5 and some suggestions how to resolve 
>>possible overlaps here. Obvously, I was not the only one arguing in
> 
> this
> 
>>direction, since also Dave pointed out that the difference between 1.1
> 
> 
>>and 1.4 is unclear, and Paula agreed that 1.4 and 1.5 are a bit too
>>similar.
>>
>>Summary:
>>At the current stage of the document it is not entirley clear on what
>>criterion these use cases shall be discriminated:
>>a) Different application area/domain.
>>b) Different technical requirements for RIF.
>>
>>a) this is not the case, all these have a similar and partly
> 
> overlapping
> 
>>scenario which can be subsumed under
>>  "Alignement/maintainance of business rules and policies" and could 
>>easily and fruitfully be combined in one scenario.
>>b) might well be the case (I try to make the differences clear below),
> 
> 
>>but needs to be made clearer.
>>
>>While a) would justify merging the use cases into one, b) might
>>justify to keep them separate. However, to this end the differences 
>>should be made clearer (see my last mail on a suggested "template" 
>>structure for each use case, we should try to bring the use cases in a
> 
> 
>>consistent format which gets the gist out of each use case packed in a
> 
> 
>>nice narrative and pointing at requirements already).
>>
>>----------------------------------------------------
>>Specific overlaps/touching points:
>>
>>1.1 is about negotiating business rules as contracts.
>>1.4 is abour executing/processing business rules, the overlap is that 
>>the example rules in 1.1 could be equally seen as the same *kind* of 
>>rules than in 1.4 which are then executed/processed in a colaborative 
>>process or on a single engine.
>>1.5 Is again a similar domain, although it does focus on a different 
>>aspect, namely what Francois often desricbes as normative rules, I
> 
> think
> 
>>this can be also described as rules checking "consistency of the 
>>application of the kind of rules in 1.1/1.5 during the running
> 
> process.
> 
>>Suggested resolution:
>>
>>I think this could be nicely combined into one use case with a
> 
> coherent 
> 
>>single story which outlines the different stages of business rules
>>usage:
>>a) contracting (static and dynamic) business rules  and checking
> 
> static 
> 
>>consistency.
>>b) processing and dynamic integration/update of new rules while 
>>maintaining consistency with the plicy requirements,
>>For all these aspects the requirements in the end of 1.4 hold: "For
> 
> this
> 
>>to be viable from a business perspective it is critical that the 
>>semantics of the rules and query exchange be completely predictable
> 
> and 
> 
>>preferably loss-less."
>>
>>Even if we keep the use cases separate, I would prefer, if they use
> 
> the 
> 
>>same narrative (same fictitious company/ies, similar scenario), but 
>>focus on the different aspects in the way outlined above.
>>
>>
>>  I would also offer help in editing the use case doc next version, if
> 
> 
>>this is appreciated!
>>
>>best,
>>axel
>>
> 
> 
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Wednesday, 15 March 2006 12:13:12 UTC