Next in thread →
Next in month →
RE: [uddi-spec] CR-010: isReplacedBy tModel
Title: Message
I
think the cardinality tModels would be redundant, since the information they
convey can be obtained by a simple examination of the identifierBag.
Because of the redundancy, the client would have two sources for the same
information, without clear guidance on which takes precedence in case of
conflict.
Nor do
I think a strong case for the use of cardinality in inquiries exists. In
the case of isReplacedBy, the object of inquiry is the old entity, not the
new. Therefore how many replacements exist (if any) is irrelevant to the
party issuing the query at the time it is made.
Daniel
-----Original Message-----
From: Anne Thomas
Manes [mailto:]
Sent: Wednesday, February 12, 2003
11:38 PM
To: Rogers, Tony; Andrew Hately
Cc:
Subject: RE: [uddi-spec] CR-010:
isReplacedBy tModel
As I
said, the keyValue specifies the identifier in the
identifierBag.
Let
me give you an example. Let's say that tModel A has been replaced by two
tModels (B and C).
<tModel
tModelKey=uddi:tModelA>
<name>tModelA</name>
...
<identifierBag>
<keyedReference
tModelKey="uddi:isReplacedBy"
keyName="replaced by
tModelB"
keyValue="uddi:tModelB"
</keyedReference>
<keyedReference
tModelKey="uddi:isReplacedBy"
keyName="replaced by
tModelC"
keyValue="uddi:tModelC"
</keyedReference>
</identifierBag>
<categoryBag>
<keyedReference
tModelKey="uddi:oneToManyCardinality"
keyName="is replaced
by many"
keyValue="uddi:isReplacedBy"
</keyedReference>
...
</categoryBag
</tModel>
But again,
I want to hear a use case why we need this information. It strikes me
as obvious (by the fact that the same identifier is specified twice) that this
identifier is being used in a one-to-many relationship. Whould anyone need to
search based on cardinality?
Anne
-----Original Message-----
From: Rogers, Tony
[mailto:]
Sent: Wednesday, February 12, 2003
3:13 PM
To: Anne Thomas Manes; Andrew Hately
Cc:
Subject: RE: [uddi-spec] CR-010:
isReplacedBy tModel
That's a really valuable generalisation, but I have a
problem, which may be a simple misunderstanding.
If we want to associate a cardinality with the use of the
tModel, rather than with the tModel itself, then I have trouble
understanding how we do it. If an object has two keyed references in its
identifier bag, how do we indicate which keyed reference is being annotated
by the categorisation keyed reference? I'm not about to suggest that a keyed
reference should have its own category bag - that would be an ugly
solution.
One solution is to say that we limit the cardinality tModel
to a specific identifier tModel (shame - I'd rather a more general
solution), and further we limit the occurrence of that identifier tModel to
one per identifier bag - that's awfully limiting.
Can someone enlighten me if I'm misunderstanding?
Tony R.
-----Original Message-----
From:
Anne Thomas Manes
To: Rogers, Tony; Andrew
Hately
Cc:
Sent: 13/02/2003 4:00 AM
Subject:
RE: [uddi-spec] CR-010: isReplacedBy tModel
Actually, I think it would be very useful to produce a
Technical Note
that talks about best practices when
using identifier and category bags.
I have no objection to creating a cardinality tModel. I'm
sure that
people will find it useful beyond just as
a way to classify identifier
tModels.
Do you envision it being
used on the identifier tModel, or on an entity
being
identified using the identifier tModel. I'm sure that there are
some identifier schemes that always require one-to-one
relationships,
but I suspect that there are many
than can support a variety of
relationships (such as
isReplacedBy). Therefore I think it would be more
useful when used with entities rather than identifier tModels. In
that
case you'd probably want to create a set of
tModels to represent the
various types of
relationships (1-to-1, 1-to-many, etc), and the the
KeyValue would specify the identifier tModelKey.
But I have to ask, what are the use
cases for these tModels?
Anne
-----Original Message-----
From:
Rogers, Tony [mailto:]
Sent: Wednesday, February 12, 2003 10:14 AM
To: Anne Thomas Manes; Andrew Hately
Cc:
Subject:
RE: [uddi-spec] CR-010: isReplacedBy tModel
Now that the question of cardinality has been resolved in
the negative -
identifiers are NOT one-to-one - the
only difference between the
identifier and category
bags comes down to searching: the default
combination of identifiers is OR, the default combination of
categories
is AND (also, categories offer the
findqualifier options of searching
services as well
as or instead of the businesses) - this is something
that deserves a bit of a write-up, but I doubt there's enough
material
for a TechNote (maybe a Tech
PostIt?)
I've suggested adding a categorisation tModel that
categorises
identifier tModels on the basis of their
cardinality - I guess there'd
be four possible
categories: one-to-one, one-to-many, many-to-one, and
many-to-many. It was suggested that this tModel could be enforced by
the
server (there's an interesting possibility...).
I think this could be
useful.
Tony Rogers
-----Original Message-----
From:
Anne Thomas Manes
To: Andrew Hately
Cc:
Sent:
13/02/2003 12:17 AM
Subject: RE: [uddi-spec] CR-010:
isReplacedBy tModel
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: <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
<file:///C:/Documents#CatSys
<file:///C:/Documents#CatSys> >
category system.
Category
system: Any <file:///C:/Documents#ValueSet
<file:///C:/Documents#ValueSet>
> value set intended
to be used to
<file:///C:/Documents#Categorize
<file:///C:/Documents#Categorize>
> categorize the
<file:///C:/Documents#Entity
> > entities in
which it is referenced. A
category system is
distinct from an identifier system in that many
entities in the same <file:///C:/Documents#Registry
<file:///C:/Documents#Registry>
> registry can be
<file:///C:/Documents#Categorize
> >
categorized with the same
<file:///C:/Documents#Category
> >
category.
Identifier: A value from a specified
<file:///C:/Documents#IDSys
<file:///C:/Documents#IDSys> >
identifier system.
Identifier system: Any <file:///C:/Documents#ValueSet
<file:///C:/Documents#ValueSet>
> value set
intended to be used to
<file:///C:/Documents#Id1
<file:///C:/Documents#Id1> >
identify the
<file:///C:/Documents#Entity
> > entities in
which it is referenced. An
identifier system
is distinct from a <file:///C:/Documents#CatSys
<file:///C:/Documents#CatSys> >
category system in that only one
<file:///C:/Documents#Entity
<file:///C:/Documents#Entity> >
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
<file:///C:/Documents#CatSys
<file:///C:/Documents#CatSys> >
category system.
Category system: Any
<file:///C:/Documents#ValueSet
<file:///C:/Documents#ValueSet>
> value set intended
to be used to
<file:///C:/Documents#Categorize
<file:///C:/Documents#Categorize>
> categorize the
<file:///C:/Documents#Entity
> > 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
<file:///C:/Documents#IDSys
<file:///C:/Documents#IDSys> >
identifier system.
Identifier system:
Any <file:///C:/Documents#ValueSet
<file:///C:/Documents#ValueSet>
> value set
intended to be used to
<file:///C:/Documents#Id1
<file:///C:/Documents#Id1> >
identify the
<file:///C:/Documents#Entity
> > 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:
<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:
<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:
<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:
<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:
<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:
<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:
<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
<http://lists.oasis-open.org/ob/adm.pl>
>
Next in thread →
Next in month →