|
UDDI Spec TC |
UDDI Core v2 and v2/v3 Utility Classification Schemes, Taxonomies, Identifier Systems, and Relationships
15 August 2004
Document identifier:
UDDI_Taxonomy_tModels
Location:
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm
Editors:
Luc Clément, Systinet
Andrew Hately, IBM
Claus von
Riegen, SAP AG
Abstract:
This document contains the UDDI core tModels that represent categorization schemes such as taxonomies, identifier systems, and relationships used by the Version 2.0.4 specification and for use with the UDDI V3 implementations.
Status:
This document is updated periodically on no particular schedule.
Committee members should send comments on this technical to the uddi-spec@lists.oasis-open.org list. Others should comment at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=uddi-spec.
For information on whether any intellectual property claims have been disclosed that may be essential to implementing this change request, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/ipr.php).
Copyrights
Copyright © 2001-2002 by Accenture, Ariba,
Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2
Technologies, Inc., Intel Corporation, International Business Machines
Corporation, Microsoft Corporation, Oracle Corporation,
Copyright © OASIS Open 2004. All Rights Reserved.
Table of Contents
UDDI v2 Core
Classification and Identifier Systems
UDDI v2 General Keywords Category System
UDDI v2 OwningBusiness Category System
UDDI v2 Relationships Category System
UDDI v2 Operators Category System
UDDI v2 IsReplacedBy Identifier System
UDDI v2 and v2/v3
Utility UDDI Business Registry Category Systems
North American Industry Classification System (NAICS) 1997
Release
North American Industry Classification System (NAICS) 2002
Release
ECCMA Product and Service Code System: UNSPSC Version 7.3
United Nations Standard Products and Services Code System (UNSPSC) Version 6.0501
United Nations Standard Products and Services Code System (UNSPSC) Version 3.1
ISO 3166 Geographic Code System
UDDI Business Registry Postal Address Structure
Dun & Bradstreet D-U-N-S® Number Identifier System
Thomas Register Supplier Identifier Code System
ISO 6523 International Code Designator (ICD) System
In UDDI, tModels are used to establish the existence of a variety
of concepts and to point to their technical definitions. To distinguish among
various types of concepts, UDDI has established this types taxonomy. tModel
publishers should categorize the tModels they publish using values from
uddi-org:types to make them easy to find. Categorization is done using the
usual UDDI categorization mechanism. See UDDI Version 2
UDDI v3 Note: The uddi-org:types category system has been evolved and made integral to the UDDI v3 specification. It is defined at http://uddi.org/pubs/uddi_v3.htm#UDDITypes.
The goal of the UDDI Types taxonomy is to establish an unambiguous, simple UDDI-compatible taxonomy that distinguishes the kinds of concepts that tModels can represent.
Name: uddi-org:types
Description: UDDI Type Taxonomy
tModel UUID: uuid:c1acf26d-9672-4404-9d70-39b756e62ab4
Categorization: categorization
Checked: Yes
<tModel
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4">
<name>uddi-org:types</name>
<description xml:lang="en">UDDI Type Taxonomy</description>
<overviewDoc>
<description xml:lang="en">
Taxonomy used to categorize Service Descriptions.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UDDItypes
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
The following constitute the identifier space for this taxonomy. The valid values are those IDs marked as being "allowed" for UDDI v2.
ID |
ParentID |
Allowed |
Description |
tModel |
|
no |
These types are used for tModels |
identifier |
tModel |
yes |
Unique identifier system |
namespace |
tModel |
yes |
Namespace |
categorization |
tModel |
yes |
Categorization (taxonomy) |
relationship |
namespace |
yes |
Relationship namespace |
postalAddress |
tModel |
yes |
Postal address format |
specification |
tModel |
yes |
Specification for a Web Service |
xmlSpec |
specification |
yes |
Specification for a Web Service using XML messages |
soapSpec |
xmlSpec |
yes |
Specification for interaction with a Web Service using |
wsdlSpec |
specification |
yes |
Specification for a Web Service described in WSDL |
protocol |
tModel |
yes |
Protocol |
transport |
protocol |
yes |
Wire/transport protocol |
signatureComponent |
tModel |
yes |
Signature component |
unvalidatable |
tModel |
yes |
Prevents a checked value set from being used |
checked |
tModel |
yes |
Checked value set |
unchecked |
tModel |
yes |
Unchecked value set |
· tModel: The UDDI type taxonomy is structured to allow for categorization of registry entries other than tModels. This key is the root of the branch of the taxonomy that is intended for use in categorization of tModels within the UDDI registry. Categorization is not allowed with this key.
· identifier: An identifier tModel represents a specific set of values used to uniquely identify information. Identifier tModels are intended to be used in keyedReferences inside of identifierBags. For example, a Dun & Bradstreet D-U-N-S® Number uniquely identifies companies globally. The D-U-N-S® Number taxonomy is an identifier taxonomy.
· namespace: A namespace tModel represents a scoping constraint or domain for a set of information. In contrast to an identifier, a namespace does not have a predefined set of values within the domain, but acts to avoid collisions. It is similar to the namespace functionality used for XML. For example, the uddi-org:relationships tModel, which is used to assert relationships between businessEntities is a namespace tModel.
· categorization: A categorization tModel is used for information taxonomies within the UDDI registry. NAICS and UNSPSC are examples of categorization tModels.
· relationship: A relationship tModel is used for relationship categorizations within the UDDI registry. relationship tModels are typically used in connection with publisher relationship assertions.
· postalAddress: A postalAddress tModel is used to identify different forms of postal address within the UDDI registry. postalAddress tModels may be used with the address element to distinguish different forms of postal address.
· specification: A specification tModel is used for tModels that define interactions with a web service. These interactions typically include the definition of the set of requests and responses or other types of interaction that are prescribed by the service. tModels describing XML, COM, CORBA, or any other services are specification tModels.
·
xmlSpec: An xmlSpec tModel is a
refinement of the specification tModel type. It is used to indicate that the
interaction with the service is via XML. The UDDI
·
soapSpec: Further refining the xmlSpec
tModel type, a soapSpec is used to indicate that the interaction with the
service is via
· wsdlSpec: A tModel for a web service described using WSDL is categorized as a wsdlSpec.
· protocol: A tModel describing a protocol of any sort.
· transport: A transport tModel is a specific type of protocol. HTTP, FTP, and SMTP are types of transport tModels.
· signatureComponent: A signature component is used for cases where a single tModel cannot represent a complete specification for a web service. This is the case for specifications like RosettaNet, where implementation requires the composition of three tModels to be complete - a general tModel indicating RNIF, one for the specific PIP, and one for the error handling services. Each of these tModels would be of type signature component, in addition to any others as appropriate.
·
unvalidatable: Used to mark a
categorization or identifier tModel as unavailable for use. tModels
representing checked value sets are marked unvalidatable as they are brought on
line and to retire them. (See UDDI Version 2.0
· checked: Marking a tModel with this classification asserts that it represents a categorization, identifier, or namespace tModel that has a properly registered validation service per the UDDI Version 2.0 Operators Specificaiton Appendix A..
· unchecked: Marking a tModel with this classification asserts that it represents a categorization, identifier, or namespace tModel that does not have a validation service.
The following demonstrates how to classify a tModel as representing a checked taxonomy. The NAICS taxonomy, for example, is classified this way.
<tModel tModelKey=...
...
<categoryBag>
<!--Specify that this is a taxonomy tModel by classifying it as "categorization"
under the uddi-org:types taxonomy -->
<keyedReference keyName="uddi-org:types" keyValue="categorization"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
<keyedReference keyName="uddi-org:types" keyValue="checked"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
</categoryBag>
...
</tModel>
Usually, taxonomies in UDDI are defined by registering a new tModel to represent the taxonomy, but sometimes such formality is overkill. The UDDI General Keywords Taxonomy provides a way of informally defining any number of unchecked taxonomies each consisting of a namespace identifier and an associated set of category values.
UDDI v3 Note: The UDDI General Keywords category system has been evolved and made integral to the UDDI v3 specification. It is defined at http://uddi.org/pubs/uddi_v3.htm#GenKW.
Provide a simple, lightweight means for establishing and using unchecked UDDI taxonomies. Such taxonomies are generally fairly simple and often of interest only to a small number of people. Checked taxonomies must and complex taxonomies or broadly interesting taxonomies should be defined by registering a new tModel which is the formal means of documenting the meaning and intended use of your taxonomy.
Name: uddi-org:general_keywords
Description: Special taxonomy consisting of namespace identifiers and the keywords associated with the namespaces
tModel UUID: uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4
Categorization: categorization
Checked: Yes
<tModel tModelKey="uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4">
<name>uddi-org:general_keywords</name>
<description xml:lang="en">Special taxonomy consisting of namespace identifiers and the keywords associated with the namespaces</description>
<overviewDoc>
<description xml:lang="en">
This tModel defines an unidentified taxonomy.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#GenKW
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
The General Keywords taxonomy in UDDI behaves differently than do any of the other taxonomies. Like other taxonomies, the General Keyword taxonomy is used in keyedReference elements to categorize the entities. Unlike other taxonomies, in the General Keyword taxonomy both the keyName and the keyValue attributes of keyedReference elements are semantically meaningful. The keyName identifies a particular value set and the keyValue specifies the value within that value set. With other taxonomies, the keyName plays no semantic role -- it is essentially commentary. This difference is reflected in the UDDI inquiry APIs: When a keyedReference containing a reference to the General Keyword taxonomy appears in an inquiry, the keyNames count.
Although UDDI puts no limitations on the value of keyName attributes, keyNames used with the General Keywords taxonomy should be URNs -- with what the W3C calls "an institutional commitment to persistence" -- in a domain name space you own. Following this convention will help avoid name collisions.
UDDI places no limitations on the value of keyValue attributes. keyValues may be whatever set of values you choose for your General Keywords taxonomy.
Checking for this category system consists of ensuring that keyName is not omitted or specified as the zero-length string; UDDI registries MUST fail save operations that contain keyedReferences that involve uddi-org:general_keywords and that do not specify a non-empty keyName.
In The Analytical Language of John Wilkins (translated from the Spanish El idioma analítico de John Wilkins by Lilia Graciela Vázquez; edited by Jan Frederik Solem with assistance from Bjørn Are Davidsen and Rolf Andersen) Jorge Luis Borges discusses the problems inherent to any system of classification. The "ambiguities, redundancies and deficiencies remind us of those which doctor Franz Kuhn attributes to a certain Chinese encyclopedia entitled Celestial Empire of Benevolent Knowledge. In its remote pages it is written that the animals are divided into: (a) belonging to the emperor, (b) embalmed, (c) tame, (d) sucking pigs, (e) sirens, (f) fabulous, (g) stray dogs, (h) included in the present classification, (i) frenzied, (j) innumerable, (k) drawn with a very fine camelhair brush, (l) et cetera, (m) having just broken the water pitcher, (n) that from a long way off look like flies."
While this taxonomy has been widely referred to, it turns out that Borges probably made the whole thing up. Legitimate or bogus, the taxonomy certainly makes his point: "[I]t is clear that there is no classification of the Universe not being arbitrary and full of conjectures."
For some unknowable reason, Island Trading
(islandtrading.example, a completely fictitious outfit) is organized internally
using this category system, one division per classification. (Division
"m" is very small.) It wishes to categorize the businessServices it
offers according to the division that offers it, and, of course, it wants to
use the
<businessServices>
<businessService>
<name>
Island Trading Tame Animal Catalog Service
</name>
<description xml:lang="en">
Search our tame animals catalog online
</description>
<bindingTemplates>
<bindingTemplate>
<accessPoint URLType="https">
https://islandtrading.example/tame/catalog.html
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="UUID:68DE9E80-AD09-469D-8A37-088422BFBC36">
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384"
keyName="UNSPSC: Livestock" keyValue="101015"/>
<keyedReference
tModelKey="Uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"
keyName="islandtrading.example:taxonomies:animals"
keyValue="c"/>
</categoryBag>
</businessService>
<businessService>
<name>
Celestial Animals Fabulous Animal Books Catalog Service
</name>
<description xml:lang="en">
Celestial Animals Fabulous Animal Books Catalog Service
</description>
<bindingTemplates>
<bindingTemplate>
<accessPoint URLType="https">
https://islandtrading.example/fabulous/catalog.html
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="UUID:68DE9E80-AD09-469D-8A37-088422BFBC36">
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384"
keyName="UNSPSC: Picture or drawing or coloring books for children"
keyValue="55101507"/>
<keyedReference
tModelKey="Uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4"
keyName="islandtrading.example:taxonomies:animals"
keyValue="f"/>
</categoryBag>
</businessService>
</businessServices>
UDDI provides a mechanism by which a categorization may be used
by a publisher to tag a tModel with information that associates it with a
businessEntity that “owns” it. (See UDDI Version 2
UDDI v3 Note: The owningBusiness category system has been evolved and made integral to the UDDI v3 specification. It is defined at http://uddi.org/pubs/uddi_v3.htm#owningBusiness.
It is often desirable to be able to discover who the publisher of a given tModel is. When choosing among similar web service definitions, for example, it is useful to be able to determine which one of them is published by an organization you know. The UDDI OwningBusiness categorization system fills this need by allowing a tModel to be associated with the businessEntity of a publisher.
Name: uddi-org:owningBusiness
Description: A pointer to a businessEntity that owns the tagged data.
tModel UUID: uuid:4064C064-6D14-4F35-8953-9652106476A9
Categorization: categorization
Checked: Yes
<tModel tModelKey="uuid:4064C064-6D14-4F35-8953-9652106476A9">
<name>uddi-org:owningBusiness</name>
<description xml:lang="en">
A pointer to a businessEntity that owns the tagged data.
</description>
<overviewDoc>
<description xml:lang="en">
This tModel indicates the businessEntity that published or owns the tagged tModel. Used with tModels to establish an “owned” relationship with a registered businessEntity.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#owningBusiness
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
The value set of this taxonomy is the set of businessKeys. It is used to specify that the businessEntity whose businessKey is the keyValue in a keyedReference "owns" the tagged tModel. The entity tagged must be a tModel, the referred-to businessEntity must exist, and it must have been published by the publisher that publishes the tagged information.
The uddi-org:publication_v2 tModel was published by uddi.org. To indicate that this is so, the uddi-org:publication_v2 has a keyedReference in its categoryBag that uses uddi-org:owningBusiness to point the uddi.org businessEntity.
<tModel tModelKey=uuid:A15063AD-EDAA-427F-AF08-218A53DD24D9>
...
<categoryBag>
<keyedReference keyName="uddi-org:owningBusiness:uddi-org"
keyValue="xsomexxx-xxxx-xxxx-xxxx-xbusinesskey"
tModelKey="uuid:4064C064-6D14-4F35-8953-9652106476A9"/>
</categoryBag>
...
</tModel>
In this example, the keyName field serves to help readability but is not necessary.
UDDI provides a mechanism that may be used by publishers to
assert relationships between businessEntities they publish and other
businessEntities according to any number of relationship classification
schemes. (See UDDI Version 2
UDDI v3 Note: The relationships category system has been evolved and made integral to the UDDI v3 specification. It is defined at http://uddi.org/pubs/uddi_v3.htm#Relationships.
While UDDI provides for any number of classification schemes to be used in relating businessEntities to one another, it is useful to define a "starter set" of classifications that publishers may use without needing to define their own. The uddi-org:relationships category system is such a starter set that covers a number of common relationships.
Name: uddi-org:relationships
Description: Starter set classifications of businessEntity relationships
tModel UUID: uuid:807A2C6A-EE22-470D-
Categorization: relationship
Checked: No
<tModel tModelKey="uuid:807A2C6A-EE22-470D-
<name>uddi-org:relationships</name>
<description xml:lang="en">Starter set classifications of businessEntity relationships</description>
<overviewDoc>
<description xml:lang="en">
This tModel is used to describe business relationships. Used in the publisher
assertion messages.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Relationships
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="relationship"/>
</categoryBag>
</tModel>
The following constitute the identifier space for this unchecked taxonomy. The valid values are those IDs marked as being allowed.
ID |
ParentID |
Allowed |
Description |
Relationship |
|
No |
The root of the relationships classification scheme. |
peer-peer |
Relationship |
Yes |
Indicates that the two businessEntities are related as peers. |
parent-child |
Relationship |
Yes |
Indicates that the businessEntity referred to by the fromKey is in some sense the parent of the businessEntity referred to by the toKey. |
identity |
Relationship |
Yes |
Indicates that the businessEntity referred to by the fromKey represents the same organization as the businessEntity referred to by the toKey. |
Tokyo Traders has a subsidiary, Mayumi's, and wishes to assert that Mayumi's is, indeed, its subsidiary. It wishes to use the uddi-org:relationships classification scheme to assert that the businessEntity for Tokyo Traders is related via the parent-child subsidiary relationship to Mayumi's. To do so it sends an add_publisherAssertions message to the operator site at which it published its businessEntity. The new assertion contained in the message looks as follows:
<publisherAssertion>
<!-- Specify Tokyo Traders' businessKey as fromKey-->
<fromKey>
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
</fromKey>
<!-- Specify Mayumi's businessKey as toKey-->
<toKey>
yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
</toKey>
<!--Specify a parent-child relationship using uddi-org:relationships taxonomy-->
<keyedReference keyName="subsidiary"
keyValue="parent-child"
tModelKey="uuid:807A2C62-EE22-470D-
</publisherAssertion>
In the example above, the keyName is used to qualify the parent-child relationship.
Once Tokyo Traders has added this assertion and Mayumi's has done the same, a relationship is formed. The find_related_businesses message may then be used to, for example, find Tokyo Traders' subsidiaries. The result would include Mayumi's.
Note: A relationship between two businessEntities will be formed using the publisherAssertion mechanism only if the publisher of each of the businessEntities involved asserts an identical publisherAssertion. In particular, this means that the keyedReferences must match exactly on keyName, keyValue, and tModelKey.
UDDI provides a mechanism that may be used by publishers to
categorize businessEntities according to any number of category systems.
(See UDDI Version 2
UDDI v3 Note: The operators category system has been evolved and renamed in UDDI v3 as the uddi-org:nodes category system. It is integral to the UDDI v3 specification and defined at http://uddi.org/pubs/uddi_v3.htm#Nodes.
Each UDDI registry -- e.g., the public UDDI Business Registry -- consists of a number of operator nodes. Each operator in a registry has a special businessEntity associated with it, called its "operational businessEntity". The businessServices in this businessEntity represent web services that relate to the operator's role as one of the operators in the registry. The validate_values services used with checked taxonomies and identifier systems, for example, are located in the operational businessEntity of the registry node operator who has custody of them.
The uddi:operators category system is designed to allow reliable categorization of the registry's “operational businessEntities” so that operators and others can locate the businessServices associated with the operators of the registry.
This checked value set is used to categorize the businessEntity of a UDDI operator. Each such businessEntity SHOULD be categorized with the uddi-org:operators taxonomy.
Name: uddi-org:operators
Description: Taxonomy for categorizing the businessEntity of an operator of a registry
tModel UUID: uuid:327A56F0-3299-4461-BC23-5CD513E95C55
Categorization: categorization
Checked: Yes
<tModel tModelKey="uuid:327A56F0-3299-4461-BC23-5CD513E95C55">
<name>uddi-org:operators</name>
<description xml:lang="en">
Taxonomy for categorizing the businessEntity of an operator of a registry.
</description>
<overviewDoc>
<description xml:lang="en">
This checked value set is used to identify UDDI operators.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Operators
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
The only valid value in this taxonomy is “node”. An operator site MUST NOT allow a businessEntity other than its operator businessEntity to be categorized using this taxonomy.
Consolidated Holdings (consolidatedholdings.example, a fictitious company) has become a UDDI node operator of a private market exchange. When it sets itself up, it identifies its operational businessEntity with the uddi:-org:operators identifier system in the folllowing way:
<businessEntity businessKey="zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz"
...
<categoryBag>
<!-- Classify this businessEntity as an “operational businessEntity” -->
<keyedReference keyName="uddi-org:operators:Consolidated Holdings"
keyValue="node"
tModelKey = "uuid:327A56F0-3299-4461-BC23-5CD513E95C55"/>
</categoryBag>
...
</businessEntity>
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities and tModels with information that identifies them
according to any number of identification systems. (See UDDI Version 2
UDDI v3 Note: The IsReplacedBy identifier system has been evolved and made integral to the UDDI v3 specification. It is defined at http://uddi.org/pubs/uddi_v3.htm#IsReplacedBy.
It is often desirable to gracefully retire a tModel in favor of a replacement. For example, when a web service definition is replaced by an incompatible version, the publisher of the specification may wish to leave the tModel for the existing definition in place so that existing uses will not be disturbed, while at the same time, making it clear that there is a replacement available. The UDDI IsReplacedBy identifier system, coupled with the behavior of UDDI with respect deleting tModels, fills this need by allowing the obsolescent tModel to point to its replacement.
Name: uddi-org:isReplacedBy
Description: An identifier system used to point (using UDDI keys) to the tModel (or businessEntity) that is the logical replacement for the one in which isReplacedBy is used.
tModel UUID: uuid:E59AE320-77A5-11D5-B898-0004AC49CC1E
Categorization: identifier
Checked: Yes
<tModel tModelKey="uuid:E59AE320-77A5-11D5-B898-0004AC49CC1E">
<name>uddi-org:isReplacedBy</name>
<description xml:lang="en">
An identifier system used to point (using UDDI keys) to the
tModel (or businessEntity) that is the logical replacement for
the one in which isReplacedBy is used.</description>
<overviewDoc>
<description xml:lang="en">
This is a checked value set.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#IsReplacedBy
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="identifier"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
The keyValues in keyedReferences that refer to this tModel must be tModelKeys or businessKeys. Such a keyValue specifies the entity that is the replacement for the entity in which the keyedReference appears.
In UDDI version 2, the uddi-org:publication tModel has been replaced by the uddi:publication_v2. To indicate this, the uddi-org:isReplacedBy identifier system is used to point from uddi-org:publication to uddi-org:publication_v2. To do this the uddi-org:publication tModel has a keyedReference added to its identifierBag, as follows:
<tModel
tModelKey=uuid:64C756D1-3374-4E00-AE83-EE12E38FAE63>
...
<name>uddi-org:publication</name>
...
<identifierBag>
<!-- Use uddi-org:IsReplacedBy to indicate that this tModel (the uddi V1 publication tModel) is
logically replaced by the V2 publication tModel. -->
<keyedReference keyName="uddi-org:publication_v2"
keyValue="uuid:A2F33B65-2D66-4088-ABC7-914D0E05EB9E"
tModelKey="uuid:E59AE320-77A5-11D5-B898-0004AC49CC1E"/>
</identifierBag>
...
</tModel>
Here the keyName attribute is commentary serving to help readability. The keyValue specifies which tModel replaces this one -- the publication_v2 tModel in this case. And the tModelKey specifies that the keyedReference is using the uddi-org:IsReplacedBy identifier system.
The categorization systems that follow apply to both UDDI v2 and v3. Readers should note however that the structured return may vary depending whether they are returned by a v2 or a v3 UDDI node. When a V2 find_tModel or get_tModelDetail inquiry is made to a v3 node for evolved (to v3) v2 defined tModels, the structure returned by a v3 node will be based on the tModel definitions specified in Chapter 11 of the UDDI v3 specification. The specific difference in the tModels when a V2 client queries a multi-version V3 registry for the evolved V2 tModels are that the tModel overviewURL and keyedReference elements in the categoryBag will be those defined by the V3 specification. Section 10 of the UDDI v3 specification defines the expected behavior of a multi-version v3 node.
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities, businessServices, and tModels with information that
categorizes them according to any number of category systems. (See UDDI Version
2
This section defines the tModel that represents the North American Industry Classification System (NAICS) taxonomy, 1997 version. The ntis-gov:naics:1997 tModel is intended to be used in connection with the UDDI categorization mechanism to categorize businessEntities, businessServices, and tModels with NAICS industry classification codes.
See http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system.
Name: ntis-gov:naics:1997
Description: Industry Category System: NAICS (1997 Release)
UDDI Key (V3): uddi:uddi.org:ubr:categorization:naics:1997
Evolved V1, V2 format key: uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2
Categorization: categorization
Checked: Yes
<tModel tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2">
<name>ntis-gov:naics:1997</name>
<description xml:lang="en">Business Taxonomy: NAICS (1997 Release)</description>
<overviewDoc>
<description xml:lang="en">
This tModel defines the NAICS industry taxonomy.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
This tModel is represented with the following structure
<tModel
tModelKey=“uddi:uddi.org:ubr:categorization:naics:1997”>
<name>ntis-gov:naics:1997</name>
<description
xml:lang="en">Industry Category System: NAICS (1997
release)</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
keyValue attributes that contain one of the NAICS 1997 release codes are valid. No contextual checks are performed. The list of valid codes are contained in this document on the US Census Bureau web site: http://www.census.gov/epcd/naics/naicscod.txt
The following is a typical UDDI v2 use of the NAICS taxonomy to classify a businessEntity
<businessEntity businessKey=...
...
<categoryBag>
<!-- Classify this businessEntity using the NAICS taxonomy -->
<keyedReference keyName="naics:1997:Non-scheduled chartered freight air transportation"
keyValue="481212"
tModelKey="uuid:C0B9FE13-179F-413d-8A5B-5004DB8E5BB2"/>
</categoryBag>
...
</businessEntity>
The following is a typical UDDI v3 use of the NAICS category system to categorize a businessEntity
<businessEntity businessKey=“uddi:...”>
...
<categoryBag>
<keyedReference
keyName="naics:1997:Non-scheduled chartered freight air
transportation"
keyValue="481212"
tModelKey="uddi:uddi.org:ubr:categorization:naics:1997"/>
</categoryBag>
...
</businessEntity>
Note that the use of keyName aids in readability but is not
required. It is the keyValue that specifies the category.
This section defines the tModel that represents the North American Industry Classification System (NAICS) category system, 2002 version. The ntis-gov:naics:2002 tModel is intended to be used in connection with the UDDI categorization mechanism to categorize UDDI entities with NAICS industry categories.
See http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system.
Name: ntis-gov:naics:2002
Description: Business Taxonomy: NAICS (2002 Release)
UDDI Key (V3): uddi:uddi.org:ubr:categorization:naics:2002
Evolved V1, V2 format key: uuid:1ff729f2-1948-46cf-b660-31ec107f1663
Categorization: categorization
Checked: Yes
This tModel is represented with the following v2 structure
<tModel
tModelKey="uuid:1ff729f2-1948-46cf-b660-31ec107f1663">
<name>ntis-gov:naics:2002</name>
<description xml:lang="en">Business Taxonomy: NAICS
(2002 Release)</description>
<overviewDoc>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS2002
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4”/>
<keyedReference keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4”/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel
tModelKey="uddi:uddi.org:ubr:categorization:naics:2002">
<name>ntis-gov:naics:2002</name>
<description xml:lang="en">Business Taxonomy: NAICS
(2002 Release)</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS2002
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
keyValue attributes that contain one of the NAICS 2002 release codes are valid. No contextual checks are performed. The list of valid codes are contained in this document on the US Census Bureau web site: http://www.census.gov/epcd/naics02/naicod02.txt
The following is a typical use of the NAICS category system to categorize a businessEntity
<businessEntity businessKey=“uddi:...”>
...
<categoryBag>
<keyedReference
keyName="naics:2002:Non-scheduled chartered freight air
transportation"
keyValue="481212"
tModelKey="uddi:uddi.org:ubr:categorization:naics:2002"/>
</categoryBag>
...
</businessEntity>
Note that the use of keyName aids in readability but is not required. It is the keyValue that specifies the category.
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities, businessServices, and tModels with information that
categorizes them according to any number of category systems. (See UDDI Version
2
This section defines the tModel that represents the UNSPSC goods and services category system, version 7.3 managed by ECCMA. The unspsc-org:unspsc tModel is intended to be used in connection with the UDDI categorization mechanism to categorize UDDI entities with UNSPSC goods and services categories.
See http://www.eccma.org/unspsc for more information on the UNSPSC goods and services code system. Note that UNSPSC Version 7.3 codes are formatted in two digit pairs, separated by periods.
Name: unspsc-org:unspsc
Description: ECCMA Product and Service Category Code System: UNSPSC Version 7.3.
UDDI Key (V3): uddi:cd153257-086a-4237-b336-6bdcbdcc6634
Evolved V1, V2 format key: uuid:cd153257-086a-4237-b336-6bdcbdcc6634
Categorization: categorization
Checked: Yes
This tModel is represented with the following v2 structure
<tModel tModelKey="uddi:cd153257-086a-4237-b336-6bdcbdcc6634">
<name>unspsc-org:unspsc</name>
<description xml:lang="en"> ECCMA Product and Service Category Code System: UNSPSC Version 7.3.</description>
<overviewDoc>
<description xml:lang="en">
This tModel defines Version 7.3 of the UNSPSC product taxonomy.</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSC
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel tModelKey=“uddi:cd153257-086a-4237-b336-6bdcbdcc6634”>
<name>unspsc-org:unspsc</name>
<description
xml:lang="en”>ECCMA Product and Service Category Code System: UNSPSC
Version 7.3.</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSC
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
keyValue attributes that contain one of the UNSPSC Version 7.3 are valid. The list of values for this version of UNSPSC is managed by ECCMA at http://www.eccma.org/unspsc. No contextual checks are performed. Note that the format of valid UNSPSC values is a series of two digit numbers that are separated by periods.
A UDDI v2 example:
<businessEntity businessKey=...
...
<categoryBag>
<keyedReference keyName="unspsc-org:unspsc:Domestic Air Cargo Transport"
keyValue="78.10.15.01.00"
tModelKey="uuid:CD153257-086A-4237-B336-6BDCBDCC6634"/>
</categoryBag>
...
</businessEntity>
A UDDI v3 example:
<businessEntity businessKey=“uddi:...”>
...
<categoryBag>
<!-- Classify this businessEntity
using the UNSPSC category
system -->
<keyedReference
keyName="unspsc:Domestic Air
Cargo Transport"
keyValue="78.10.15.01.00"
tModelKey="
uddi:cd153257-086a-4237-b336-6bdcbdcc6634"/>
</categoryBag>
...
</businessEntity>
This section defines the tModel that represents the unified version of the UNSPSC goods and services category system (the unified version contains contributions from UNSPSC lists produced by UNDP and ECCMA). The unspsc-org:unspsc:v6.0501 tModel is intended to be used in connection with the UDDI categorization mechanism to categorize UDDI entities with UNSPSC goods and services categories.
See http://www.unspsc.org/for more information on the UNSPSC goods and services code system. Note that UNSPSC Version 6.0501 codes are formatted as eight digit numeric codes.
Name: unspsc-org:unspsc:v6.0501
Description: Product and Service Category System: United Nations Standard Products and Services Code (UNSPSC)
UDDI Key (V3): uddi:uddi.org:ubr:categorization:unspsc
Evolved V1, V2 format key: uuid:4614c240-b483-11d7-8be8-000629dc0a53
Categorization: categorization
Checked: Yes
This tModel is represented with the following v2 structure
<tModel
tModelKey=“uuid:4614c240-b483-11d7-8be8-000629dc0a53”>
<name>
unspsc-org:unspsc:v6.0501</name>
<description xml:lang="en”>
Product and Service Category System: United Nations Standard Products and
Services Code (UNSPSC)</description>
<overviewDoc>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSCv60501
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="checked"/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel
tModelKey=“uddi:uddi.org:ubr:categorization:unspsc”>
<name>
unspsc-org:unspsc:v6.0501</name>
<description xml:lang="en”>
Product and Service Category System: United Nations Standard Products and
Services Code (UNSPSC)</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSCv60501
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
keyValue attributes that contain one of the UNSPSC v6.0501 are valid. The list of valid values for this version of UNSPSC is available at http://www.unspsc.org/ No contextual checks are performed. Note that the format of valid UNSPSC values is a series of 8 digits.
A UDDI v3 example:
<businessEntity businessKey=“uddi:...”>
...
<categoryBag>
<!-- Classify this businessEntity
using the UNSPSC category
system -->
<keyedReference
keyName="unspsc:Domestic Air
Cargo Transport"
keyValue="78101501"
tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/>
</categoryBag>
...
</businessEntity>
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities, businessServices, and tModels with information that
categorizes them according to any number of category systems. (See UDDI Version
2
See http://www.un-spsc.net for more information on the UNSPSC version 3.1 goods and services code system. Codes from UNSPSC Version 3.1 are no longer checked for validity by UDDI.
Name: unspsc-org:unspsc:3-1
Description: Product Taxonomy: UNSPSC (Version 3.1)
tModel UUID: uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384
Categorization: categorization
Checked: No
<tModel tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384">
<name>unspsc-org:unspsc:3-1</name>
<description xml:lang="en">Product Taxonomy: UNSPSC (Version 3.1)</description>
<overviewDoc>
<description xml:lang="en">
This tModel defines the UNSPSC product taxonomy.</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UNSPSC31
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
</categoryBag>
</tModel>
See http://www.un-spsc.net for a list of acceptable values. UDDI no longer checks to ensure validity.
A UDDI v2 example:
<businessEntity businessKey=...
...
<categoryBag>
<keyedReference keyName="unspsc-org:unspsc:3-1:Domestic Air Cargo Transport"
keyValue="78101501"
tModelKey = "uuid:DB77450D-9FA8-45d4-A7BC-04411D14E384"/>
</categoryBag>
...
</businessEntity>
This section defines the tModel that represents the ISO 3166 geographic code system, a domain of values used to provide geographic categorization of UDDI entities. This categorization scheme assists in supporting UDDI inquiries for businesses or services that serve specific geographic areas.
The design goal for this tModel is to provide a standards-based, large-grained category system to represent geographical locations for the purpose of indicating that businesses or services serve particular geographic areas.
The values in this geographic code system are defined in ISO specifications 3166-1 and 3166-2. Also included are contents from update newsletters that have been distributed as additions to the set of values described in the original specifications. From the value set, a simple hierarchy is derived for use in conjunction with UDDI registries. The following releases have been included in the data set:
· ISO 3166-1: Country names and alpha-2 (two letter code) element of ISO 3166-1
·
ISO 3166-1 Newsletter V-1: Update for
·
ISO 3166-1 Newsletter V-2: Update for
· ISO 3166-1 Newsletter V-3:
· ISO 3166-1 Newsletter V-4:
· ISO 3166-1 Newsletter V-5:
· ISO 3166-1 Newsletter V-6:
· ISO 3166-1 Newsletter V-7:
· ISO 3166-2 Country subdivision codes
· ISO 3166-2 Newsletter I-1: Updates for country subdivision codes.
· ISO 3166-2 Newsletter I-2: Updates for country subdivision codes.
· ISO 3166-2 Newsletter I-3: Updates for country subdivision codes.
· ISO 3166-2 Newsletter I-4: Updates for country subdivision codes.
Name: ubr-uddi-org:iso-ch:3166-2003
Description: ISO 3166 Codes for names of countries or regions. Updated with newsletters ISO 3166-1 V-1, V-2, V-3, V-4, V-5, V-6, V-7, ISO 3166-2 I-1, I-2, I-3, I-4.
UDDI Key (V3): uddi:uddi.org:ubr:categorization:iso3166
Evolved V1,V2 format key: uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88
Categorization: categorization, valueSet
Checked: Yes
<tModel tModelKey="uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88">
<name> ubr-uddi-org:iso-ch:3166-2003</name>
<description xml:lang="en"> ISO 3166 Codes for names of countries or regions. Updated with newsletters ISO 3166-1 V-1, V-2, V-3, V-4, V-5, V-6, V-7, ISO 3166-2 I-1, I-2, I-3, I-4.</description>
<overviewDoc>
<description xml:lang="en">Taxonomy used to categorize entries by geographic location.</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#ISO3166
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4
keyName="types"
keyValue="checked""/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel tModelKey=“
uddi:uddi.org:ubr:categorization:iso3166”>
<name>ubr-uddi-org:iso-ch:3166-2003</name>
<description xml:lang"EN">ISO
3166 Codes for names of countries or regions. Updated with newsletters ISO
3166-1 V-1, V-2, V-3, V-4, V-5, V-6, V-7, ISO 3166-2 I-1, I-2, I-3,
I-4.</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#ISO3166
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:categorization”
keyValue="categorization"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:checked”
keyValue="checked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:cacheable”
keyValue="cacheable"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:valueSet”
keyValue="valueSet"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
keyValue attributes that contain one of the ISO 3166 codes are valid. The lists of ISO 3166-1 and ISO 3166-2 codes are available from the ISO 3166 Maintenance Agency database and newsletter updates at the following web site: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html.
The following is a typical business registration referencing the
uddi-org:iso3166 tModel. The
businessEntity categorization means that the business offers its services in
A UDDI v2 example:
<businessEntity businessKey=...
...
<categoryBag>
<!--
Categorize this businessEntity as serving
taxonomy -->
<keyedReference keyName="iso-ch:3155-1999:
keyValue="US-CA"
tModelKey="uuid:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88"/>
</categoryBag>
...
</businessEntity>
A UDDI v3 example:
<businessEntity businessKey=“uddi:...”>
...
<categoryBag>
<keyedReference
keyName="iso3166:
keyValue="US-CA"
tModelKey="uddi:uddi.org:ubr:categorization:iso3166”>
</categoryBag>
...
</businessEntity>
In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the postalAddress sort are referenced by address and addressLine structures to describe the pieces of a postal address. This postal address structure tModel is provided as a starting point. It reflects the requirements of many known international postal addresses.
The postalAddress structure tModel is provided to be able to programmatically discern the parts of an address that are captured in a series of addressLine elements in a UDDI address structure. The more this tModel is used in structuring postal addresses, the more consistent the address contents will be and thus greater programmatic interoperability will be achieved. The use of this address structure is recommended, but not required. No attempt has been made to create a new "standard address structure". Instead, this general structure borrows from many of the known existing and emerging standards.
This tModel is used to describe the contents of addressLines in a postal address.
Name: ubr-uddi-org:postalAddress
Description: Postal address structure
UDDI Key (V3): uddi:uddi.org:ubr:postaladdress
Derived V1,V2 format key: uuid:48eb2518-c1bd-354f-92c9-21a53b0ff2b1
Categorization: postalAddress
Checked: no
This tModel is represented with the following v2 structure
<tModel
tModelKey=“uuid:48eb2518-c1bd-354f-92c9-21a53b0ff2b1”>
<name>ubr-uddi-org:postalAddress</name>
<description
xml:lang="EN">Postal address structure</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#postal
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="categorization"/>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4
keyName="types"
keyValue="checked""/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel
tModelKey=“uddi:uddi.org:ubr:postaladdress”>
<name>ubr-uddi-org:postalAddress</name>
<description xml:lang="EN">Postal
address structure</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#postal
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:postalAddress”
keyValue="postalAddress"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:unchecked”
keyValue="unchecked"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
addressLine elements in address structures that are associated with this tModel, that have keyValues containing one of the codes listed below are valid. The addressLine keyName attributes are those in the ElementName column. The Description column is provided for clarity.
Code |
Element Name |
Description |
10 |
Name |
Name |
20 |
Country |
Country code |
30 |
Region |
Region code (e.g. state, province, county) |
40 |
City |
Name of city |
50 |
District |
Name of district (city subdivision) |
60 |
Street |
Name of street |
70 |
HouseNumber |
House number |
80 |
BuildingName |
Building name |
90 |
BuildingNumber |
Building number |
100 |
FloorNumber |
Floor number |
110 |
UnitNumber |
Number of room or appartment |
120 |
CityPostalCode |
City-specific postal code |
130 |
POBoxPostalCode |
PO box-specific postal code |
140 |
CompanyPostalCode |
Company-specific postal code |
150 |
POBoxNumber |
|
160 |
POBoxCity |
PO box city |
170 |
StreetPrefix1 |
First text line before street name |
180 |
StreetPrefix2 |
Second text line before street name |
190 |
StreetSuffix1 |
First text line after street name |
200 |
StreetSuffix2 |
Second text line after street name |
210 |
HomeCity |
City (different from postal city) |
220 |
POBoxWithoutNumber |
Flag: PO box without number |
230 |
POBoxCountry |
PO box country |
240 |
POBoxRegion |
Region for |
250 |
TimeZone |
Address time zone |
The following v3 example is a typical address that references the Postal Address tModel to regularize the contained addressLine elements:
<address useType="Sales office"
tModelKey="ubr-uddi-org:postaladdress">
<addressLine
keyName="Street" keyValue="60">
Some street name
</addressLine>
<addressLine keyName="House"
keyValue="70">
12
</addressLine>
. . .
<addressLine
keyName="Country" keyValue="20">
US
</addressLine>
</address>
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities and tModels with information that identifies them
according to any number of identifier systems. (See UDDI Version 2
This section defines the tModel that represents the Dun & Bradstreet D-U-N-S® Number identifier system. The Dun & Bradstreet D-U-N-S® Number tModel is intended to be used in connection with the UDDI identification mechanism to identify businessEntities and tModels with Dun & Bradstreet D-U-N-S® numbers.
Note that this tModel is initially registered as part of the UDDI v2 core tModels. At some point custody of this tModel is expected to be transferred to the Dun & Bradstreet publisher account.
For businesses to be recognizable, particularly electronically, there needs to be a common and acceptable way of identifying them. The Dun & Bradstreet D-U-N-S® Number identifier system is both well known and widely used. For more information on the Dun & Bradstreet D-U-N-S® Number identifier system, see http://www.dnb.com.
Name: dnb-com:D-U-N-S
Description: Dun & Bradstreet D-U-N-S® Number
UDDI Key (V3): uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s
Evolved V1, V2 format key: uuid:8609c81e-ee1f-4d5a-b202-3eb13ad01823
Categorization: identifier
Checked: No
This tModel is represented with the following v2 structure
<tModel tModelKey="uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823">
<name>dnb-com:D-U-N-S</name>
<description xml:lang="en">Dun&Bradstreet D-U-N-S® Number</description>
<overviewDoc>
<description xml:lang="en">
This tModel is used for the Dun&Bradstreet D-U-N-S® Number identifier.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#D-U-N-S
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="identifier"/>
</categoryBag>
</tModel>
This tModel is represented with the following v3 structure
<tModel
tModelKey=“uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s”>
<name>dnb-com:D-U-N-S</name>
<description>Dun & Bradstreet
D-U-N-S Number</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#D-U-N-S
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:identifier”
keyValue="identifier"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:unchecked”
keyValue="unchecked"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference keyName="D-U-N-S"
keyValue="0060"
tModelKey="uddi:uddi.org:ubr:identifier:iso6523icd"/>
</categoryBag>
</tModel>
The value of keyValue in a keyedReference that refers to this tModel should be a valid Dun & Bradstreet D-U-N-S® Number issued by Dun & Bradstreet to the company represented by the businessEntity in question. Dun & Bradstreet D-U-N-S® Numbers are assigned by Dun & Bradstreet. See http://www.dnb.com.
Identify the
A v2 example:
<businessEntity businessKey=...
...
<identifierBag>
<keyedReference
keyName="dnb-com:D-U-N-S:
keyValue="00-136-8083"
tModelKey="uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823"/>
...
</identifierBag>
...
</businessEntity>
A v3 example:
<businessEntity businessKey=...
...
<identifierBag>
<keyedReference keyName="IBM Corporation"
keyValue="00-136-8083"
tModelKey="uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s"/>
...
</identifierBag>
...
</businessEntity>
UDDI provides a mechanism that may be used by publishers to tag
their businessEntities and tModels with information that identifies them
according to any number of identification systems. (See UDDI Version 2
This tModel represents the Thomas Register supplier identifier code system for use with that mechanism.
Note that this tModel is initially registered as part of the UDDI core tModels. At some point custody of this tModel is expected to be transferred to the Thomas Register publisher account.
For businesses to be recognizable, particularly electronically,
there needs to be a common and acceptable way of identifying them. The Thomas Register Supplier identifier
system is both well known and widely used in
Name: thomasregister-com:supplierID
Description: Thomas Registry Suppliers
UDDI Key (V3): uddi:uddi.org:ubr:identifier:thomasregister.com:supplierid
Evolved V1,V2 format key: uuid:63f5fa1a-ef86-32d9-8bef-5890bac8f378
Categorization: identifier
Checked: No
<tModel
tModelKey="uuid:B1B1BAF5-2329-43E6-AE13-BA8E97195039">
<name>thomasregister-com:supplierID</name>
<description xml:lang="en">Thomas Registry Suppliers</description>
<overviewDoc>
<description xml:lang="en">
This tModel is used for the Thomas Register supplier identifier codes.
</description>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Thomas
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="identifier"/>
</categoryBag>
</tModel>
This tModel is represented with the following structure
<tModel
tModelKey=“uddi:uddi.org:ubr:identifier:thomasregister.com:supplierid”>
<name>thomasregister-com:supplierID</name>
<description
xml:lang="EN">Thomas Registry Suppliers</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Thomas
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName=“uddi-org:types:identifier”
keyValue="identifier"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:unchecked”
keyValue="unchecked"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
The value of keyValue in a keyedReference that refers to this tModel should be a valid Thomas Register supplier ID number issued to the company that represents the businessEntity in question. See http://www.thomasregister.com.
In the example that follows the businessEntity for Microsoft is identified with the Microsoft Business Solutions Group Thomas Register supplier ID, 43038249.
A v2 example:
<businessEntity businessKey=...
...
<identifierBag>
<keyedReference keyName="thomasregister-com:supplierID:Microsoft Business Solutions Group"
keyValue="43038249"
tModelKey="uuid:B1B1BAF5-2329-43E6-AE13-BA8E97195039"/>
...
</identifierBag>
...
</businessEntity>
A v3 example:
<businessEntity businessKey=...
...
<identifierBag>
<keyedReference
keyName="thomasregister-com:supplierID:
Microsoft Business Solutions Group"
keyValue="43038249"
tModelKey="uddi:uddi.org:ubr:identifier:thomasregister.com:
supplierid"/>
...
</identifierBag>
...
</businessEntity>
This tModel represents the ISO 6523 ICD (International Code Designator) which indicates the particular organization identifier system for use with that mechanism. ICD can be called an identifier of identifiers.
Since it is recognized that a single method for identifying all organizations on an international basis is neither feasible nor practical, SIO (Structure for Identification of Organizations), which provides a means for systematically incorporating existing methods of identification in a uniform structure, is often used to identify organizations for the purpose of data interchange. SIO consists of three components: an ICD, an organization code, and an optional organization name. The ICD tModel is intended to be used in conjunction with the UDDI identifier mechanism to tag identifier tModels with an ICD number so that a human or an application program can reconstruct a SIO for an organization from the data within a UDDI registry. For more information on ISO 6523, see http://www.iso.org or http://www.nic.it/NA/iso6523.txt
Name: ubr-uddi-org:iso-ch:6523-1998:icd
Description: ISO 6523 International Code Designator (ICD) System
UDDI Key (V3): uddi:uddi.org:ubr:identifier:iso6523icd
Derived V1,V2 format key: uuid:f1b347da-6cbb-3a10-93e7-7cd4328b88d3
Categorization: identifier
Checked: No
This tModel is represented with the following structure
<tModel
tModelKey=“
uuid:f1b347da-6cbb-3a10-93e7-7cd4328b88d3
<name>ubr-uddi-org:iso-ch:1998:icd</name>
<description
xml:lang="EN">ISO 6523 International Code Designator (ICD) System
</description>
<overviewDoc>
<overviewURL>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#ISO6523Code
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="types"
keyValue="identifier"/>
</categoryBag>
</tModel>
This tModel is represented with the following structure
<tModel
tModelKey=“uddi:uddi.org:ubr:identifier:iso6523icd”>
<name>ubr-uddi-org:iso-ch:1998:icd</name>
<description
xml:lang="EN">ISO 6523 International Code Designator (ICD) System
</description>
<overviewDoc>
<overviewURL useType=“text”>
http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#ISO6523Code
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName=“uddi-org:types:identifier”
keyValue="identifier"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference
keyName=“uddi-org:types:unchecked”
keyValue="unchecked"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>
Each ICD number is assigned by ISO/TC154-UN/CEFACT Joint Syntax Working Group (JSWG) as an identification code qualifier in EDIFACT Syntax Version 4. See http://metadata-stds.org/Document-library/Draft-standards/6523-Identification-of-Organizations/ICD_list.htm. keyValue attributes used in keyedReference elements that reference this identifier system should contain such an ICD number.
The following is an example an ISO 6523 ICD identification applied to the tModel of the Dun & Bradstreet D-U-N-S® Number tModel. The ISO 6523 code “0001” represents the Dun & Bradsreet D-U-N-S® system.
A v3 example:
<tModel tModelKey="uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s">
<name>dnb.com:D-U-N-S</name>
...
<identifierBag>
<!-- identify this tModel using ICD -->
<keyedReference keyName="D-U-N-S"
keyValue="0060"
tModelKey="uddi:uddi.org:ubr:identifier:iso6523:icd"/>
...
</identifierBag>
...
</tModel>
If an inquirer seeks a Structure for Identification of Organizations (SIO) of an organization, it can be constructed from the identification information in the businessEntity and information in the identifier tModel itself. For instance, if the D-U-N-S number is "00-136-8083", the SIO could be reconstructed as "00060/00-136-8083//". The first part of this SIO describes which identifier system is in use and the second part contains the actual identification in that identifier system.
[1] "UDDI Version 2.0
[2] "UDDI 2.0 Data Structure Reference ", http://uddi.org/pubs/DataStructure_v2.htm
[3] ISO 3166 Maintenance Agency Web Site: http://www.din.de/gremien/nas/nabd/iso3166ma/
Rev |
Date |
By Whom |
What |
2.0.4 |
11 Dec 2002 |
Original version Boubez and Clément |
|
3 |
15 Aug 2004 |
Clément / Hately |
Updates adding v3 derived and evolved keys; updates to tModel definitions; and new definitions |
|
|
|
|
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2004. All Rights
Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on
an “AS IS” basis and OASIS DISCLAIMS