RE: [uddi-spec] CR-010: isReplacedBy tModel

Anne,

Reading through the CR again, I feel
that the glossary definitions of category and identifier are still the
problem.

Does the suggestion in my note below
address the problem without changing the classification of isReplacedBy?

Andrew Hately

IBM Austin

UDDI Development, Emerging Technologies 

Andrew Hately/Austin/IBM@IBMUS

01/23/2003 12:12 PM

To

Daniel Feygin <>

cc

"'Anne Thomas Manes'"
<>, "'Von Riegen, Claus'" <>,
"'Uddi-Spec'" <>

Subject

RE: [uddi-spec] CR-010: isReplacedBy
tModel

Perhaps a simpler approach is to fix our definition of identifier and identifier
system.  I don't see that there is anything wrong with the isReplacedBy
system other than our inference about cardinality due to the definitions
in our glossary.  Searching through the specification and a bunch
of dictionaries, it appears the only place that restricts identifiers to
a definition of one to one relationship is in our glossary. I'm not sure
why we have included mention of cardinality as the distinguishing characteristic
in our glossary definition as identifiers.   

The existing definitions are as follows: 

Category: A value from a specified category
system. 

Category system: Any value
set intended to be used to categorize
the entities
in which it is referenced. A category system is distinct from an identifier
system in that many entities in the same registry
can be categorized
with the same category.

Identifier: A value from a specified identifier
system. 

Identifier system: Any value
set intended to be used to identify
the entities
in which it is referenced. An identifier system is distinct from a category
system in that only one entity
in a given registry should be associated with a given identifier.

Borrowing more directly from dictionaries, I'd suggest we clarify these
definitions as follows (additions in quotes and note that the second sentence
of each system definition is removed and replaced):

Category: A value "representing a defined division of classification"
from a specified category
system. 

Category system: Any value
set intended to be used to categorize
the entities
in which it is referenced.  The documentation for a category system
should describe the characteristics that mark the divisions, or categories,
in the system.  Each category in a category system typically represents
a means of grouping distinct entities with similar characteristics.

Identifier: A value "representing the distinct identity of
the entity" from a specified identifier
system.  

Identifier system: Any value
set intended to be used to identify
the entities
in which it is referenced.  The documentation for an identifier system
should describe the distinct characteristics of an entity for each value,
or identifier, in the system.  Each identifier in an identifier system
typically represents a unique entity or entities that are considered equivalent.

I'm sure we could argue over the exact definitions used, but I think using
a proper definition of what each system is intending to accomplish is better
than trying to fit value sets into the overly restrictive definition we
may be using today.  In the particular case of isReplacedBy, if a
group of tModels really represents the replacement for one, than I believe
that this is an identity relationship where the replacement is a specific
and unique set as opposed to stating that it is replaced by items in this
general division of entities. 

Andrew Hately

IBM Austin

UDDI Development, Emerging Technologies 

Lotus Notes: Andrew Hately/Austin/IBM@IBMUS

Internet: 

(512) 838-2866,  t/l 678-2866

Daniel Feygin <>

01/23/2003 08:36 AM

To

"'Von Riegen,
Claus'" <>, "'Anne Thomas Manes'"
<>, "'Uddi-Spec'" <>

cc

Subject

RE: [uddi-spec] CR-010: isReplacedBy
tModel

Claus,

I did not realize that the identifiers' uniqueness is scoped to an

entire registry.  I went by the assumption that a given entity could

have only one value for a given identifier (one keydReference of a given

tModelKey in the entity's identifierBag), but that there were no other

requirements on that.  I looked through the spec and found no guidance

as to what the registry is supposed to do when a businessEntity is

published with an identifier that is already "claimed" (perhaps

unjustifiably) by another businessEntity publisher.

V3 definition of an identifier introduces by implication a requirement

that establishes an indirect relationship between potentially unrelated

entities.  Thus registry owners are put in the position of not only

validating publishers' content, which is fine within clearly defined and

reasonable syntactic and semantic bounds, but also policing

publisher-to-publisher relationships, which may be quite tricky in some

circumstances (consider the UBR as an extreme case).  Appendix E,
Using

Identifiers, does not mention the uniqueness requirements of identifier

values, so one might question the suitability of introducing normative

requirements (if my assessment of the definition is correct) in the

glossary appendix of the specification.

Clearly my prior remarks on isReplacedBy capability are inconsistent

with the apparent 'idea' of the identifier in UDDI V3.  I found no

references to the scope of identifier uniqueness in V2 though, so I

wonder if my comments could still apply to V2.  With regard to V3
we

thus have a choice between adopting the solution proposed in Anne's CR

or adopting the alternative she mentioned with the implication that the

definition of the identifier in V3 will have to be revised.  Also
it

would not hurt to add more normative guidance explaining the proper

enforcement of identifiers' uniqueness characteristics.  If this could

be left up to registry policy, then we should probably also specify

that.

Lets try to analyze your point of this being an errata, because it fixes

an inconsistency.  I can identify 4 scenarios relevant to our

discussion:

1. One entity is replaced by one other entity.  This is one-to-one

relationship that is covered under existing specification.

2. One entity is replaced by multiple entities.  This is one-to-many

relationship that cannot be implemented under existing specification and

requires a categorization.  I do not see an inconsistency with the
spec

here, we are extending the spec to cover a new function.

3. Multiple entities are replaced by one other entity.  This is

one-to-many relationship that can be modeled with isReplacedBy, but will

cause the inconsistency which I assume you are referring to, as multiple

entities will become identified by one value.  However, the replacement

entity's identity can be traced to the multiple entities it is

replacing.  Therefore IMHO it would be more consistent with the general

idea of identity to model this relationship with an identifier rather

than with a categorization.  But even if we choose to represent this

scenario with a categorization, this would still be a new capability

which I would therefore favor being implemented with a new tModel (say,

isConsolidatedReplacedBy for the purpose of discussion).

4. Multiple entities are replaced by multiple other entities.  I do
not

have a clue as to how this might be modeled without the use of an

intermediary entity, which would have one-to-many relationships to the

group of multiple entities being replaced and to the group of newly

created entities.  That is covered in (2) and (3).

So I assume it is scenario (3) above you find inconsistent with the

wording of the identifier definition.  I would argue though, that
that

definition is inconsistent with the ability for one-to-many

transformation of an entity's identity.  Thereby the inconsistency
is

only with the V3 definition of identifiers in UDDI.  isReplacedBy
could

be used as identification scheme tModel to model scenario (3).

Alternatively, it is possible to model scenario (3) with a

categorization.  Then we face another choice of either making up another

tModel or redefining isReplacedBy as a categorization scheme, risking to

inflict pain on the users.

Also, I searched through the text of V2 specs and found no reference to

the V3 definition of identifier.  So it is only an inconsistency in
V2

if you consider the general agreement of the Consortium's Working Group

members as to the concept of identifiers.

Regards,

Daniel

> -----Original Message-----

> From: Von Riegen, Claus [mailto:] 

> Sent: Thursday, January 23, 2003 11:31 AM

> To: 'Anne Thomas Manes'; Daniel Feygin; 'Uddi-Spec'

> Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> 

> 

> Anne, Daniel,

> 

> Daniel's proposal to let two businessEntities be "identified"

> by the merged businessEntity (second case from below) seems 

> to be attractive at first view, but it actually contradicts 

> to the idea of an identifier in UDDI.

> 

> An entity's identifierBag contains identifiers (specified as 

> keyValues in keyedReferences) for the entity itself (see 

> section 3.3.2.10 of the UDDI V3 specification). That's why 

> any identifier should be used only once in a UDDI registry - 

> the V3 glossary (see Appendix L of the UDDI V3 specification) 

> defines an identifier system as "Any value set intended to be

> used to identify the entities in which it is referenced. An 

> identifier system is distinct from a category system in that 

> only one entitty in a given registry should be associated 

> with a given identifier." And that's why we changed the 

> categorization of the owningBusiness tModel from "identifier"

> to "categorization" in one of the V2 errata sets. It is
used 

> in a tModel to identify the businessEntity that owns the 

> tModel - but it does not identify the tModel, it categorizes 

> it (and many tModels can carry the same category, i.e. be 

> owned by the same businessEntity).

> 

> Again, the most consistent solution, IMO, would be to change 

> the categorization for the isReplacedBy tModel in both UDDI 

> V2 and V3, if possible at all (in V2). The change can 

> certainly be viewed as a valid errata, since it removes an 

> inconsistency. If the change in V2 is not acceptable, we can 

> start to find the second-best solution.

> 

> Claus

> 

> 

> -----Original Message-----

> From: Anne Thomas Manes [mailto:] 

> Sent: Mittwoch, 22. Januar 2003 17:34

> To: Daniel Feygin; 'Uddi-Spec'; Von Riegen, Claus

> Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> 

> 

> +1

> 

> > -----Original Message-----

> > From: Daniel Feygin [mailto:]

> > Sent: Wednesday, January 22, 2003 11:18 AM

> > To: 'Uddi-Spec'; 'Anne Thomas Manes'; 'Von Riegen, Claus'

> > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> > 

> > 

> > Anne, Claus,

> > 

> > Please see my comments inline.

> > 

> > Thank you,

> > Daniel

> > 

> > 

> > > -----Original Message-----

> > > From: Von Riegen, Claus [mailto:]

> > > Sent: Wednesday, January 22, 2003 5:56 PM

> > > To: 'Anne Thomas Manes'; Uddi-Spec

> > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> > > 

> > > 

> > > Anne,

> > > 

> > > If we have two different tModels for nearly the same concept,

> > > it would complicate the decision for the publisher which

> > > tModel to use, but would of course help the inquirer to
more 

> > > clearly distinguish between the different cases.

> > > 

> > > So, let us assume three cases.

> > > 

> > > First, tModel T1 represents a Web service type for which
a

> > > new version is developed and published as tModel T2. Assuming

> > > that this is a one-to-one relationship (one tModel can be

> > > found by using the key of one tModel it is replaced with),

> > > the publisher of tModel T1 should then add an identifierBag

> > > to T1 that contains a keyedReference isReplaceBy / tModelKey
T2.

> > 

> > That is how I would prefer to see this recommended.

> > 

> > > Second, businessEntities B1 and B2 represent businesses
that

> > > are merged to a business, that is published as businessEntity

> > > B3. This is a many-to-one relationship (many businessEntities

> > > can be found by using the key of one businessEntity they
are 

> > > replaced with), that means the key of B3 is not an 

> > > identifier, neither for B1 nor for B2. Should we recommend
to 

> > > use "isReplacedByMultiple" due to this reason,
that is, the 

> > > publishers of B1 and B2 each add a categoryBag to their

> > > businessEntities that contains a keyedReference 

> > > isReplacedByMultiple / businessKey B3?

> > 

> > No, I would rather see this done by the application of existing

> > identifier isReplacedBy to both B1 and B2.  That is, the

> publishers of 

> > B1 and B2 would each add an identifierBag to their businessEntities

> > that contains a keyedReference isReplacedBy referring to the

> > businessKey of B3.  The use of isReplacedByMultiple would

> apply in the 

> > unlikely event of a businessEntity B selling off all of its 

> > businesses, resulting in a number of identities Bx that are 

> separate 

> > from the original B (perhaps a sad example of this could be the

> > sell-off of some defunct dom-com's assets to different 

> buyers; another 

> > one could have been the court-ordered break up of our good friend

> > Microsoft [no emotion of any kind intended]).  Then the
original B 

> > would add a categoryBag containing several keyedReferences 

> > isReplacedByMultiple enumerating businessKeys of each of resultant

> > businessEntities Bx.  Am I missing something here?

> > 

> > > Third, tModel T1 represents a Web service type for which
a

> > > new version is developed that consists of multiple single
Web 

> > > service types that are published as separate tModels, for

> > > example, T2 - T4. The RosettaNet PIP 3A4 is an example for

> > > this, since up to version 1.4, it consists of messages that

> > > represent a Purchase Order Request, a Purchase Order Change,

> > > a Purchase Order Cancellation, and a Purchase Order 

> > > Acceptance, whereas it is followed by PIP 3A4 2.0 (Purchase

> > > Order Request & Purchase Order Confirmation), PIP 3A8
1.0 

> > > (Purchase Order Change) and PIP 3A9 1.0 (Purchase Order

> > > Cancellation). This is a one-to-many relationship (one 

> > > businessEntity can be found by using one of the keys of
many 

> > > tModels it is replaced with), that means the keys of T2,
T3 

> > > and T4 are identifiers, the all "identify" T1.
Should we 

> > > recommend to use "isReplacedBy" due to this reason,
that is, 

> > > the publisher of T1 adds a categoryBag to A1 that contains

> > > three keyedReferences isReplacedByMultiple / tModelKey T2,

> > > isReplacedByMultiple / tModelKey T3, isReplacedByMultiple
/ 

> > > tModelKey T4?

> > 

> > That is exactly along the lines of what I am thinking.

> > 

> > > I fear that I would have problems to explain this to

> > > publishers so that they make consistent use of the different

> > > isReplacedBy tModels.

> > The publishers shouldn't really care - that would be taken 

> care of by 

> > the software they use.  Their only problem would be if we

> deprecate or 

> > change the definition of existing isReplacedBy tModel that 

> they use. 

> > Guidance to UDDI client implementers is fairly simple too:

> > 1) when an entity is replaced by one other entity, the 

> _preferred_ way 

> > of communicating that is isReplacedBy;

> > 2) when an entity is replaced by more than one other entity,
the 

> > _only_ way of communicating that is isReplacedByMultiple.

> > 

> > Hence my interpretation that we are introducing a new 

> capability and 

> > not fixing a bug.  What am I missing?

> > 

> > > What do you think?

> > > 

> > > Claus

> > > 

> > > -----Original Message-----

> > > From: Anne Thomas Manes [mailto:]

> > > Sent: Mittwoch, 22. Januar 2003 14:25

> > > To: Von Riegen, Claus; Uddi-Spec

> > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> > > 

> > > 

> > > I'm thinking that the better alternative is to create an

> > > isReplacedByMultiple tModel.

> > > 

> > > > -----Original Message-----

> > > > From: Von Riegen, Claus [mailto:]

> > > > Sent: Wednesday, January 22, 2003 7:42 AM

> > > > To: 'Anne Thomas Manes'; Uddi-Spec

> > > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel

> > > >

> > > >

> > > > Anne,

> > > >

> > > > Thanks for the well-prepared change request.

> > > >

> > > > As you note in section 3 (Impact statement), there
is a 

> > > > significant

> > > > impact for UDDI V2 registries if we make the change
for 

> V2 also, 

> > > > especially if the tModel is already used often.

> > > >

> > > > However, there is at least a similar impact for UDDI
V3 

> registries

> > > > that also support UDDI V2 APIs: at the time UDDI V3
is 

> implemented, 

> > > > all keyedReferences to the V2 isReplacedBy identifier

> > > system within an

> > > > identifierBag have to be migrated to then occur within
a

> > > categoryBag.

> > > > Otherwise, the V2/V3 multi-version registry would have
to switch

> > > > between the two personalities of the keyedReference
on the 

> > > fly - and

> > > > would have to support two personalities of the same

> tModel for the

> > > > different UDDI versions as well (note that the key
for the 

> > > > isReplacedBy tModel is not changed).

> > > > But the migration would mean that V2 API call response
messages

> > > > would contain the isReplaceBy tModel as a category
system, which

> > > > is simply wrong per the V2 specification.

> > > > Thus, I have the dim feeling that we have to change
the

> > > > categorization for the isReplacedBy tModel already
in 

> V2 in order

> > > > to prevent problems that can occur later.

> > > >

> > > > An alternative could be to not change the categorization
at all 

> > > > ...

> > > >

> > > > Thoughts?

> > > >

> > > > Claus

> > > >

> > > > -----Original Message-----

> > > > From: Anne Thomas Manes [mailto:]

> > > > Sent: Mittwoch, 22. Januar 2003 00:39

> > > > To: Uddi-Spec

> > > > Subject: [uddi-spec] CR-010: isReplacedBy tModel

> > > >

> > > >

> > > >

> > > >

> > > > Anne Thomas Manes

> > > > 617-497-1748 (land)

> > > > 617-642-3144 (mobile)

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>