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, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved.

Table of Contents

UDDI v2 Core Classification and Identifier Systems

UDDI v2 Types Category System

UDDI v2 General Keywords Category System

UDDI v2 OwningBusiness Category System Taxonomy.. 11

UDDI v2 Relationships Category System.. 12

UDDI v2 Operators Category System

UDDI v2 IsReplacedBy Identifier System.. 15

UDDI v2 and v2/v3 Utility UDDI Business Registry Category Systems

North American Industry Classification System (NAICS) 1997 Release. 5

North American Industry Classification System (NAICS) 2002 Release. 5

ECCMA Product and Service Code System: UNSPSC Version 7.3. 6

United Nations Standard Products and Services Code System (UNSPSC) Version 6.0501

United Nations Standard Products and Services Code System (UNSPSC) Version 3.1. 7

ISO 3166 Geographic Code System.. 8

UDDI Business Registry Postal Address Structure

Dun & Bradstreet D-U-N-S^® Number Identifier System.. 16

Thomas Register Supplier Identifier Code System.. 17

ISO 6523 International Code Designator (ICD) System

References. 18

Revision History

Notices. 19

UDDI v2 Core Classification and Identifier Systems

UDDI v2 Types Category 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 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use taxonomies in UDDI.

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.

Design Goals

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.

v2 tModel Definition

Name: uddi-org:types

Description: UDDI Type Taxonomy

tModel UUID: uuid:c1acf26d-9672-4404-9d70-39b756e62ab4

Categorization: categorization

Checked: Yes

v2 tModel Structure

<name>uddi-org:types</name>

<description xml:lang="en">UDDI Type Taxonomy</description>

Taxonomy used to categorize Service Descriptions.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#UDDItypes

</overviewURL>

</overviewDoc>

<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>

v2 Valid Values

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 SOAP messages
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 API tModels are xmlSpec tModels.

· soapSpec: Further refining the xmlSpec tModel type, a soapSpec is used to indicate that the interaction with the service is via SOAP. The UDDI API tModels are soapSpe tModels, in addition to xmlSpec tModels.

· 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 API Specification [1].)

· 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.

Example of Use

The following demonstrates how to classify a tModel as representing a checked taxonomy. The NAICS taxonomy, for example, is classified this way.

<tModel tModelKey=...

...

<!--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>

UDDI General v2 Keywords Category System

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.

Design Goals

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.

V2 tModel Definition

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

V2 tModel Structure

<name>uddi-org:general_keywords</name>

<description xml:lang="en">Special taxonomy consisting of namespace identifiers and the keywords associated with the namespaces</description>

This tModel defines an unidentified taxonomy.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#GenKW

</overviewURL>

</overviewDoc>

<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>

V2 Valid Values

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.

Example of Use

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 Celestial Empire taxonomy to do so. Since the classification is only of interest to Island Trading, it is decided that the General Keyword approach will be used. "islandtrading.example:taxonomies:animals" is chosen to represent the taxonomy. The Tame Division and the Fabulous Division both have catalog browsing businessServices. They appear as follows:

<name>

Island Trading Tame Animal Catalog Service

</name>

Search our tame animals catalog online

</description>

https://islandtrading.example/tame/catalog.html

</accessPoint>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

<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>

<name>

Celestial Animals Fabulous Animal Books Catalog Service

</name>

Celestial Animals Fabulous Animal Books Catalog Service

</description>

https://islandtrading.example/fabulous/catalog.html

</accessPoint>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

<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 v2 OwningBusiness Category System

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 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use categorization systems in UDDI.) This tModel represents a categorization system.

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.

Design Goals

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.

V2 tModel Definition

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

V2 tModel Structure

<name>uddi-org:owningBusiness</name>

A pointer to a businessEntity that owns the tagged data.

</description>

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>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#owningBusiness

</overviewURL>

</overviewDoc>

<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>

V2 Valid Values

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.

Example of Use

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.

...

<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 v2 Relationships Category System

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 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use these classification schemes to relate businessEntities to each other.) This section defines a tModel representing a simple category system for use in describing the way businessEntities relate to one another.

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.

Design Goals

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.

V2 tModel Definition

Name: uddi-org:relationships

Description: Starter set classifications of businessEntity relationships

tModel UUID: uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

Categorization: relationship

Checked: No

V2 tModel Structure

<name>uddi-org:relationships</name>

<description xml:lang="en">Starter set classifications of businessEntity relationships</description>

This tModel is used to describe business relationships. Used in the publisher

assertion messages.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Relationships

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"

keyName="types"

keyValue="relationship"/>

</categoryBag>

</tModel>

V2 Valid Values

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.

Example of Use

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:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

</fromKey>

<toKey>

yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

</toKey>

<keyedReference keyName="subsidiary"

keyValue="parent-child"

tModelKey="uuid:807A2C62-EE22-470D-ADC7-E0424A337C03"/>

</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 v2 Operators Category System

UDDI provides a mechanism that may be used by publishers to categorize businessEntities according to any number of category systems. (See UDDI Version 2 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use category systems in UDDI.) This section defines a tModel used to categorize a businessEntity as belonging to a node operator in a registry in which the businessEntity appears.

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.

Design Goals

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.

tModel Definition

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 Structure

<name>uddi-org:operators</name>

Taxonomy for categorizing the businessEntity of an operator of a registry.

</description>

This checked value set is used to identify UDDI operators.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#Operators

</overviewURL>

</overviewDoc>

<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>

Valid Values

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.

Example of Use

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"

...

<keyedReference keyName="uddi-org:operators:Consolidated Holdings"

keyValue="node"

tModelKey = "uuid:327A56F0-3299-4461-BC23-5CD513E95C55"/>

</categoryBag>

...

</businessEntity>

UDDI v2 IsReplacedBy Identifier System

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 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use identifier systems in UDDI.) This tModel represents an identifier system that may be used to identify the tModel or businessEntity that logically replaces the tModel or businessEntity in which it is used.

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.

Design Goals

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.

tModel Definition

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 Structure

<name>uddi-org:isReplacedBy</name>

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>

This is a checked value set.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#IsReplacedBy

</overviewURL>

</overviewDoc>

<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>

Valid Values

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.

Example of Use

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:

...

<name>uddi-org:publication</name>

...

<!-- 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.

UDDI v2 and v2/v3 Utility UDDI Business Registry Category Systems

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.

North American Industry Classification System (NAICS) 1997 Release

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 API Specification [1] and UDDI Version 2 Data Structure Reference [2] for more information on how to use categorization in UDDI). This tModel is also applicable for use with UDDI v3 registries.

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.

Design Goals

See http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system.

tModel Definition

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

v2 tModel Structure

<name>ntis-gov:naics:1997</name>

<description xml:lang="en">Business Taxonomy: NAICS (1997 Release)</description>

This tModel defines the NAICS industry taxonomy.

</description>

http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#NAICS

</overviewURL>

</overviewDoc>

<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>

v3 tModel Structure

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>

Valid Values

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

Example of Use

The following is a typical UDDI v2 use of the NAICS taxonomy to classify a businessEntity

<businessEntity businessKey=...

...

<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.

North American Industry Classification System (NAICS) 2002 Release

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.

Design Goals

See http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system.

tModel Definition

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

v2 tModel Structure

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>

v3 tModel Structure

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>

Valid Values

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

Example of Use

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.

ECCMA Product and Service Code System: UNSPSC Version 7.3

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.

Design Goals

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.

tModel Definition

Name: