[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Updates http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm
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 UDDI v2 Core Classification and Identifier SystemsIn 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. Design GoalsThe 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 DefinitionName: uddi-org:types Description: UDDI Type Taxonomy tModel UUID: uuid:c1acf26d-9672-4404-9d70-39b756e62ab4 Categorization: categorization Checked: Yes v2 tModel Structure<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> v2 Valid ValuesThe following constitute the identifier space for this taxonomy. The valid values are those IDs marked as being "allowed" for UDDI v2.
· 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. Example of UseThe 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> UDDI General v2 Keywords Category SystemUsually, 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 GoalsProvide 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 DefinitionName: 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: No V2 tModel Structure<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"/> </categoryBag> </tModel> V2 Valid ValuesThe 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. Example of UseIn 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 v2 OwningBusiness Category SystemUDDI 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. Design GoalsIt 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 DefinitionName: 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<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> V2 Valid ValuesThe 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 UseThe 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 v2 Relationships Category SystemUDDI 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. Design GoalsWhile 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 DefinitionName: uddi-org:relationships Description: Starter set classifications of businessEntity relationships tModel UUID: uuid:807A2C6A-EE22-470D- Categorization: relationship Checked: No V2 tModel Structure<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> V2 Valid ValuesThe following constitute the identifier space for this unchecked taxonomy. The valid values are those IDs marked as being allowed.
Example of UseTokyo 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 v2 Operators Category SystemUDDI 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. Design GoalsEach 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 DefinitionName: 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<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> Valid ValuesThe 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 UseConsolidated 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 v2 IsReplacedBy Identifier SystemUDDI 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. Design GoalsIt 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 DefinitionName: 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<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>
Valid ValuesThe 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 UseIn 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. UDDI v2 and v2/v3 Utility UDDI Business Registry Category SystemsThe 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. Design GoalsSee http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system. tModel DefinitionName: 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<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> v3 tModel StructureThis tModel is represented with the following structure <tModel Valid ValueskeyValue 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 UseThe 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:...”> </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 ReleaseThis 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 GoalsSee http://www.census.gov/epcd/www/naics.html for more information on the NAICS industry category system. tModel DefinitionName: 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 StructureThis tModel is represented with the following v2 structure <tModel
tModelKey="uuid:1ff729f2-1948-46cf-b660-31ec107f1663"> v3 tModel StructureThis tModel is represented with the following v3 structure <tModel
tModelKey="uddi:uddi.org:ubr:categorization:naics:2002"> Valid ValueskeyValue 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 UseThe following is a typical use of the NAICS category system to categorize a businessEntity <businessEntity businessKey=“uddi:...”> </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. Design GoalsSee 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: 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 v2 tModel StructureThis 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> v3 tModel StructureThis tModel is represented with the following v3 structure <tModel
tModelKey=“uddi:cd153257-086a-4237-b336-6bdcbdcc6634”> Valid ValueskeyValue 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. Example of UseA 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:...”> </businessEntity> United Nations Standard Products and Services Code System (UNSPSC) Version 6.0501This 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. Design GoalsSee 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. tModel
Definition
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 v2 tModel StructureThis tModel is represented with the following v2 structure <tModel <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> v3 tModel StructureThis tModel is represented with the following v3 structure <tModel Valid ValueskeyValue 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. Example of UseA UDDI v3 example: <businessEntity businessKey=“uddi:...”> </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 Design GoalsSee 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. tModel Definition
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 Structure<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> Valid ValuesSee http://www.un-spsc.net for a list of acceptable values. UDDI no longer checks to ensure validity. Example of UseA 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. Design GoalsThe 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. tModel DefinitionThe 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 and their subdivisions. 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 V2 tModel Structure<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 and their subdivisions. 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> V3 tModel StructureThis tModel is represented with the following v3 structure <tModel tModelKey=“
uddi:uddi.org:ubr:categorization:iso3166”> Valid ValueskeyValue 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. Example of UseThe 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:...”> </businessEntity> UDDI Business Registry Postal Address StructureIn 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. Design GoalsThe 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. tModel DefinitionThis 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 v2 tModel StructureThis tModel is represented with the following v2 structure <tModel <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> v3 tModel StructureThis tModel is represented with the following v3 structure <tModel Valid ValuesaddressLine 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.
Example of UseThe following v3 example is a typical address that references the Postal Address tModel to regularize the contained addressLine elements: <address useType="Sales office" 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. Design GoalsFor 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. tModel DefinitionName: 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 v2 tModel StructureThis 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> v3 tModel StructureThis tModel is represented with the following v3 structure <tModel <keyedReference keyName="D-U-N-S" keyValue="0060" tModelKey="uddi:uddi.org:ubr:identifier:iso6523icd"/>
</categoryBag> Valid ValuesThe 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. Example of UseIdentify 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. Design GoalsFor 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 tModel DefinitionName: 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 v2 tModel Structure<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> V3 tModel StructureThis tModel is represented with the following structure <tModel Valid ValuesThe 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. Example of UseIn 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> ISO 6523 International Code Designator (ICD) SystemThis 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. Design GoalsSince 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 tModel DefinitionName: 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 V2 tModel StructureThis tModel is represented with the following structure <tModel
</description> <keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyName="types" keyValue="identifier"/> </categoryBag> V3 tModel StructureThis tModel is represented with the following structure <tModel
</description> Valid ValuesEach 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. Example of UseThe 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/ Revision History
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]