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

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

Paul Vincent
Fair Isaac Blaze Advisor --- Business Rule Management
OMG PRR and W3C RIF for rule standards
 

-----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 11:56:03 UTC