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

I guess that if you abstract the scenarios enough, they will all look
the same!

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 09:56:18 UTC