Andrew,
I
think your proposed solution is excellent. When we first started talking about
this issue, I asked what is the expected behavior if someone attempts to use a
previously claimed identifier or if someone attempts to idenitfy an entity with
more than one identitfier from the same identifier system. From what I can tell,
this behavior has not been specified. There is nothing in the spec that enforces
cardinality. I agree with you that we have imposed cardinality on ourselves just
by virtue of our definition. Changing the definition seems to me to be the
simplest and least disruptive solution.
I
suspect that some people might get a bit confused trying to understand the
difference between an identifier system and a category system if we remove the
cardinality qualifier, so we need to be careful with our
definition.
Anne
-----Original Message-----
From: Andrew Hately
[mailto:]
Sent: Tuesday, February 11, 2003 11:36
PM
To:
Cc:
Subject: 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>
