- From: Axel Polleres <axel.polleres@uibk.ac.at>
- Date: Wed, 15 Mar 2006 12:16:19 +0100
- To: "Vincent, Paul D" <PaulVincent@fairisaac.com>
- CC: public-rif-wg@w3.org
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:16:36 UTC