NISTIR 7647

An Enabler for Supplier Discovery in Virtual Supply Chains: 

A Shared Terminology

Steven J. Fenves 

Mahesh Mani

Eswaran Subrahmanian

Albert T. Jones
NISTIR 7647

An Enabler for Supplier Discovery in Virtual Supply Chains: 

A Shared Terminology

Steven J. Fenves 

Mahesh Mani 

Eswaran Subrahmanian

Albert T. Jones

April 2009

U.S. DEPARTMENT OF COMMERCE

Gary Locke, Secretary

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

Patrick D. Gallagher, Director
ABSTRACT

Rigid supply-chain organizational structures are giving way to highly dynamic collaborative 

partnerships. These partnerships will develop rapidly by composing global manufacturing 

resources in response to open market opportunities; and, they will disband just as rapidly when 

those opportunities disappear. One critical element of these virtual networks is the supplier 

discovery, i.e., the ability of customers to find suppliers that have the capabilities to meet their 

requirements. This initial report explores the communication language between the network 

partners, with particular emphasis on the technical aspects of the transactions. 

Keywords

Supply chains, networking, engineering and business objects, business transaction protocols, 

nomenclatures, product codes, taxonomies, classification systems
TABLE OF CONTENTS

1 Introduction................................................................................................................. 7

1.1 Objective of project.............................................................................................. 7

1.2 Scope of report ..................................................................................................... 7

1.3 Organization of report .......................................................................................... 7

2 Preliminary concepts................................................................................................... 8

3 Initial efforts................................................................................................................ 8

3.1 The “strawman” use case ..................................................................................... 9

3.2 Comparative study of business transaction protocols........................................ 11

3.3 Comparisons....................................................................................................... 13

3.4 Process information sharing............................................................................... 14

4 Towards a shared terminology.................................................................................. 15

4.1 Standard nomenclatures ..................................................................................... 15

4.2 Product codes ..................................................................................................... 16

4.3 Taxonomies........................................................................................................ 18

4.4 Faceted classification systems............................................................................ 19

4.5 Group Technology.............................................................................................. 20

5 Summary of findings................................................................................................. 20

6 References................................................................................................................. 21
LIST OF FIGURES

Table 1: Participants in the strawman................................................................................. 9

Table 2: The transactions between the participants............................................................ 9
LIST OF ACRONYMS

ANSI American National Standards Institute

ASC Accredited Standards Committee 

ASME American Society of Mechanical Engineers

B2B Business to Business

BOM Bill of Materials 

CAD Computer Aided Design

CBP Common Business Process

CICA Context Inspired Component Architecture

CompTIA Computing Technology Industry Association

cXML Commerce Extensible Markup Language

DCOR Design Chain Operations Reference

DISA Data Interchange Standards Association

ebXML Electronic Business Extensible Markup Language

EDI Electronic Data Interchange

EDIFACT Electronic Data Interchange for Administration, Commerce, and 

Transport

EIDX Electronics Industry Data Exchange Group

EPC Electronic Product Code

FDA Food and Drug Administration

GT Group Technology 

GTIN Global Trade Item Number

HSC Harmonized System Codes

IEEE Institute of Electrical & Electronics Engineers

ISDO International Health Terminology Standards Development 

Organization

LOOM Language and environment for constructing intelligent 

applications

NDC National Drug Code

OAGIS Open Applications Group Integration Specification

OEM Original Equipment Manufacturer

PDM Product Data Management

PIP Partner Interface Process

PLM Product Lifecycle Management 

RFI Request for Information

RFP Request for proposals

SCC Supply-Chain Council

SCOR Supply-Chain Operations Reference

SNOMED Systematized Nomenclature of Medicine

X12 ANSI ASC electronic data interchange standard

Xcbl XML Common Business Library

XML Extensible Markup Language
1 Introduction

1.1 Objective of project

Rigid supply chain structures are giving way to virtual supply networks of collaborative 

partnerships. These partnerships will develop rapidly in response to market opportunities 

and they will disband just as quickly when those opportunities disappear. The virtual 

supply chain will encompass designers, engineers, planners, transporters, suppliers, 

fabricators, assemblers, buyers, vendors, and service providers, among others. 

The project addresses a critical element of these virtual networks, namely, supplier 

discovery, the ability of customers to find suppliers that have the capabilities to meet their 

requirements. It is expected that this ability will eventually include standard models for 

representing customer requirements and supplier capabilities, tools that enable customers 

and suppliers to register those requirements and capabilities, and methods and tools that 

assist customers to automatically find potential suppliers with matching capabilities. The 

current planning project will create a technical plan for developing and demonstrating 

such a network.

1.2 Scope of report

While the overall project addresses the complete supplier discovery phase of the 

customer-supplier relationship in a virtual network, this initial report explores only one 

issue: that of the language of communication between the network partners who may 

have never had any business relationships before. 

Furthermore, the report deals only with the technical aspects of the transactions in the 

virtual supply chain, that is, the technical description of what is sought and the technical 

description of what is offered. The report does not address any of the business aspects 

pertaining to cost, price, time to delivery, time/cost tradeoff, volume discounts, 

counteroffers, etc., nor aspects of business ethics, such as the establishment and 

maintenance of trust.

On the other hand, while the project is primarily geared towards the manufacturing of 

products, in this report the design of such products is not excluded. After all, the design 

document describing a product is as much an artifact as the physical product is. There is 

no basic difference between a transaction that says “I need a pump (or 100 pumps) 

manufactured in accordance with the following engineering design description” from one 

that says “I need a design description of a pump designed in accordance with the 

following client requirements description” or even one that says “I need an engineering 

design description of a pump designed in accordance with the following client 

requirements description and a pump (or 100 pumps) manufactured in accordance to that 

design description.”

1.3 Organization of report

The report is organized as follows: Section 2 presents the preliminary concepts on the 

notion of engineering objects as compared to business objects. Section 3 presents the 

initial efforts with a prototype use case followed by a comparison of selected business 

transaction protocols emphasizing a search for comparable communication efforts. 
Section 4 presents the concerns with a literature review on the efforts towards a shared 

terminology. We conclude with Section 5, presenting a summary of our findings. 

2 Preliminary concepts

Srinivasan [1] makes the distinction between engineering objects, the information 

exchanged primarily by the engineering units of enterprises in the design and production 

of products, and business objects, the information exchanged by both engineering and 

business units of enterprises [1,2]. In the early days of manufacturing information 

exchange, the two realms could be kept reasonably separate. However, with tighter 

integration, particularly through Product Data Management (PDM) and even more so 

through Product Lifecycle Management (PLM), there has emerged an increasing need to 

bridge the gap between the two realms. 

Srinivasan refers to business objects as metadata. In this term he includes both (1) the 

traditional metadata, defined as “data describing data,” which cover such information as 

author, approver, supplier, version, change history, authorization, effectivity, provenance, 

etc., and (2) what he calls “aggregate data” such as part number, bill of materials (BOM), 

product assembly structure, etc. The aggregate data – in particular the part number -

provide the link from the business objects to the detailed descriptions that comprise the 

engineering objects. Quoting from [2]: “these are data necessary in communicating about 

products in contexts other than engineering but which are sufficient in themselves for 

communications without the need for a full, detailed product description. If the details 

are needed, as in change management, they can be retrieved via the part number acting 

as the access key (italics added for emphasis).” The paper actually defines 4 fields or 

attributes identifying the part: the part number, a name or brief description, a detailed 

description and a context identification.

The italicized sentence leads to the crux of the issue addressed in this report. When a firm 

business relationship exists between client and supplier, the agreed-upon part number 

fully defines the “language” of communication between the two participants. By 

extension, the BOM defines a broader “language” consisting of a hierarchy of part 

numbers. The business relationship needed for such a concise communication “language” 

may pre-exist through institutional structures or may be established “on the fly” in virtual 

supply chains after the participants have been identified and the scope of their interaction 

defined. 

The question that this report addresses is: “what language about products is needed in a 

virtual supply chain before the concise language of part numbers has been mutually 

agreed upon?”

3 Initial efforts

Initially the project concentrated on three aspects:

• the development of a prototype use case dubbed the “strawman”

• a comparative study of existing business transaction protocols and

• a search for comparable communication efforts.

These three aspects, and a comparison between them, are described below. 
3.1 The “strawman” use case

The initial “strawman” use case is patterned after a conceptually similar interaction 

model developed in a project dealing with healthcare service integration [3].

This use case represents a prototypical situation where a Client engages a Designer to 

design some product. The Designer in turn engages a Manufacturer to produce the 

product. For this use case, it is assumed that the product will consist of parts made to 

order by the Supplier and parts bought from the Warehouse, all to be assembled by the 

Manufacturer. The Manufacturer eventually delivers the product to the Client, who 

accepts it. 

The Locator is an additional participant that records the identities, locations and 

capabilities of the other participants – in the present restricted context dealing only with 

technical aspects; the locator is not a broker that assists in the negotiations. 

A transaction is defined as a two-way communication process between two parties. A 

transaction typically involves the exchange of several messages, such as:

• initial message (query, order, status report, etc.) 

• initial acknowledgement 

• response 

• response acknowledgement.

Error messages, exception reports, etc. are taken to be part of a transaction. Table 1 

presents the participants and Table 2 presents the transactions between the participants.

Table 1: Participants in the strawman

Code Description

S1 Client

S2 Designer

S3 Manufacturer

S4 Locator

Table 2: The transactions between the participants

Code Description From 

participant

To 

participant

Communication

T1 Designer criteria Client Locator

Designer alternatives Locator Client

T2 Client-Designer 

negotiation*

Client Designer “Language I” 

needed

Designer approval Client Locator

T3 Initial client specs Client Designer

Design proposal Designer Client

Design approval* Client Designer Client-designer 
language 

established

T4 Manufacturer criteria Designer Locator

Manufacturer alternatives Locator Designer 

T5 Manufacturer negotiation* Designer Manufacturer “Language II”

needed?

Manufacturer approval Designer Locator

T6 Manufacturing 

specifications

Designer Manufacturer

Manufacturer 

feedback/counterproposal

Manufacturer Designer

Manufacturing approval* Designer Manufacturer Designermanufacturer 

language 

established

T7 Product completion notice Manufacturer Designer

Product approval* Designer Client

T8 Product delivery Manufacturer Client

Product acceptance* Client Manufacturer

*may involve multiple iterations

The “Communication” column in Table 2 identifies the transactions that require a 

communication language to identify the engineering object addressed in the transaction. 

“Language II” may actually be the part number as described by Srinivasan; however, it is 

still problematic whether this is the part number assigned by the customer (as, for 

example, an OEM looking for a supplier of some part) or that assigned by the supplier 

(as, for example, in shopping from a catalog of available parts).

The transactions are modeled as an information flow diagram in Figure 1 and as an 

interaction diagram in Figure 2. In the former, transactions are identified by the 

transaction code in the table above. In the latter, the transactions are categorized as:

• Query/identification of participants

• Contract negotiations leading to participant selection

• Product-centered negotiations moving from requirements to accepted proposal and

• Product-centered negotiations pertaining to the ordering, delivery and acceptance of 

the product.
Client Designer Manufacturer Locator

T2, T3 T4

T1

T8 T5, T6, T7

Figure 1: Strawman use case information diagram

Designer Manufacturer Locator

T1

T2,T3

Client

T8

Query/identification

Requirements/Proposal

Contract negotiation

LEGEND

T4

T6,T7

T5

Figure 2: Strawman use case interaction diagram

3.2 Comparative study of business transaction protocols

A number of supply-chain Common Business Processes (CBPs), information standards, 

messaging standards and reference models have been defined and promulgated by 

various groups of organizations. Some are industry-specific while others are broader in 

scope. CBPs are intended to be industry-neutral business processes and re-usable, so that 
components of a common business process specification can be re-used to create new 

business processes. 

The following business transaction protocols have been reviewed:

ANSI X12 (also known as ANSI ASC X12) is the U.S. national standards body for the 

development and maintenance of Electronic Data Interchange (EDI) standards. X12 has 

an underlying syntax, which is an ANSI standard. Within that syntax, there are directories 

of data elements, composite data elements, segments, and messages. There are 

conventions for placing messages in an "envelope", which identifies the sender and 

receiver and other attributes of a transmission [4].

EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport) 

is the international Electronic Data Interchange developed under the United Nations. 

EDIFACT has an underlying syntax, which is an ISO standard. Within that syntax, there 

are directories of data elements, composite data elements, segments, and messages [5].

EIDX represents the Electronics Industry Data Exchange Group. As part of the 

Computing Technology Industry Association (CompTIA), EIDX provides a unified 

voice, global leadership and strategic direction to further e-business interoperability. 

EIDX is committed to advancing industry growth through the development of standards, 

best practices, accreditations, professional education and development, tools and business 

solutions [6].

RosettaNet is an independent, self-funded, non-profit consortium dedicated to the 

development and deployment of standard electronic business interfaces. These standards 

form a common e-Business language, aligning processes between supply chain partners 

on a global basis. RosettaNet’s Partner Interface Processes (PIP) allow trading partners 

of all sizes to connect electronically to process transactions and move information within 

their extended supply chains [7].

OAGIS (Open Applications Group Integration Specification) is an effort to provide a 

canonical business language for information integration. OAGIS uses XML as the 

common alphabet for defining business messages and for identifying business processes 

(scenarios) that allow businesses and business applications to communicate. OAGIS 

accommodates the additional requirements of specific industries by partnering with 

various vertical industry groups [8].

SCOR (Supply-Chain Operations Reference) is not a business transaction protocol per se 

but a process reference model developed by the Supply-Chain Council (SCC) [9]. The 

SCC is an independent, not-for-profit, global corporation with membership open to all 

companies and organizations interested in applying and advancing the state-of-the-art in 

supply and design chain management systems and practices. SCOR has been adopted as 

the cross-industry de facto standard diagnostic tool for supply chain management. It is a 

hierarchical model that has five major building-block processes: plan, make, source, 

deliver, and return [10].
DCOR (Design Chain Operations Reference) captures the SCC’s view of design chain 

management [11]. The structure is based on the same hierarchical philosophy as SCOR, 

but with five different building-block processes: plan, research, design, integrate, and 

amend.

Other business transaction protocols that have not been reviewed include: B2B, cXML, 

Xcbl, E-business, Enterprise application integration, Standard Carrier Alpha Codes, 

DISA, CICA, ebXML, among others.

3.3 Comparisons

Comparison of the “strawman” use case and the protocols examined shows that 

essentially all “strawman” messages and transactions have equivalents in all of the 

protocols reviewed. On the other hand, where these protocols support alternate 

transactions, the “strawman” transactions invariably map onto the simplest, most basic 

variant of the transactions supported by each of the protocols. 

In general most of “business processes” as depicted in the above protocols, tend to be 

coarser-grained than the “strawman” transactions. However, several protocols present 

detailed diagrams describing each business process in terms of their individual process 

steps. The detailed interaction diagrams identify the business documents exchanged 

between the participants; these correspond directly to the “strawman” messages. In 

comparison to the above protocols, the “strawman” model is highly simplified. 

Essentially the protocols depict a global model that recognizes and implements:

• many more business processes

• several variants (models) of a “generic” business process

• additional/optional steps within one business process variant and

• several implementation options.

More importantly, the existing protocols support only the lowest level of customersupplier interaction, which may be termed the “commodity” level. Even though the 

transaction protocols were developed and are promulgated by organizations dealing with 

technical products, the transactions supported by the protocols could just as well apply to 

sacks of soybeans as to pumps or airplanes (in fairness, it is to be pointed out that the 

transactions of the “strawman” use case do not contain any technical information either). 

Using the distinction introduced in Section 2, the transactions deal entirely with business 

objects and contain no information about engineering objects except as they are 

abstracted into a single item number or designation. What appears to be totally absent in 

the protocols examined is any reference to the engineering objects that underlie many of 

the transactions. This is particularly noticeable in the case in EIDX, which is specifically 

devoted to electronics industry data exchange. It appears that the dichotomy between 

engineering objects and business objects discussed by Srinivasan [2] is complete.

A very preliminary list of transactions between clients and suppliers that involve both 

business and technical objects is shown below. Typical examples are shown for each 

transaction class.

• Client’s inquiry about potential supplier’s capabilities and the supplier’s response

o E.g., supplier’s technical capabilities, backlog, regulations in place, standards 

in use, product data transmission standards available
• Potential supplier’s Request for Information (RFI) to client regarding the Request for 

Proposal (RFP) issued prior to contract award and the client’s response

o E.g., desired product tolerances, options, finishes and colors.

• Potential supplier’s counterproposal to the RFP and the client’s response

o E.g., RFP calls for bolts, supplier offers discount on subassemblies of bolts, 

nuts and washers.

o E.g., RFP calls for forming and welding, supplier only offers forming.

• Supplier’s RFI to client regarding the contract in effect and the client’s response

o E.g., product tolerances, options, finishes, colors not fully specified in the 

contract.

o E.g., request for clarification of CAD or other product data provided in 

contract.

• Supplier’s request for approval of substitutions and the client’s response

o E.g., request to substitute materials and curing or finishing processes.

• Supplier’s submission of alternatives within the contract and the client’s response

o E.g., submission requesting approval of alternate materials and curing or 

finishing processes.

• Supplier’s submission of intermediate process documents, test data or product 

samples for client action or approval and client’s response

o E.g., submission of detailed “shop drawings” for review and approval before 

fabrication can begin.

• Change orders from the client and the supplier’s response

o E.g., order to extend, condense or otherwise modify contract for product.

• Client’s decision concerning acceptance or rejection of delivered products and 

supplier’s response

o E.g., client’s “punch list” of corrective steps the supplier needs to take before 

product is accepted.

o E.g., client’s “rejection slip” listing reasons for the rejection of the product 

sent by the supplier.

Admittedly, many of the transactions illustrated above will occur in such a late phase of 

the process that agreement in item numbers will already have been established. However, 

the first transaction illustrated above will take place in the supplier discovery phase, 

before such agreement is reached.

3.4 Process information sharing 

A side investigation was carried out to ascertain the degree to which process information 

may be shared between customer and supplier.
One effort, the proposed ASME standard “B5/TC56: Information Technology for 

Machine Tools” for a “virtual machine tool,” intends to develop “a model that predicts an 

output of the machining process by simulating the actions of the machine tool in response 

to the part program and the environment” [12]. The intended setting is that of a 

manufacturer wishing to simulate a particular machine tool before buying it.

The presentation describing the committee’s work states that:

“The critical enabler is efficient access to relevant data:

• The part (geometry, tolerances, material)

• The process plan (part program, set-up and fixturing)

• The machine tool(s)

• The tool(s)

• The machine environment.”

For the current project, only the first class of data is relevant, that is, what is to be 

supplied. The second class, how it is to be made, has traditionally been the province of 

the supplier. In fact, it can be argued that a priori process plan that is not based on a 

particular supplier’s available manufacturing resources is bound to be sub-optimal, as it 

cannot exploit the supplier’s competitive advantages. Furthermore, the description above, 

“part (geometry, tolerances, material),” clearly calls for the fully elaborated engineering 

object. The work on a virtual machine is therefore not relevant to the communication 

issue in the virtual supply chain.

In a similar vein, Mahesh [13] and Serm [14] describe tightly integrated design, 

engineering, manufacturing and logistics systems where process as well as product 

information is shared between participants geographically distributed around the world

interacting via autonomous software agents [13,14]. From the project’s standpoint, both 

systems require more manufacturing and logistics process knowledge on the part of the 

customer than can be assumed to exist in a typical customer-supplier transaction. 

4 Towards a shared terminology

The key concern in effecting the supplier discovery phase of the proposed virtual supply 

chain is an agreement between customer and (potential) supplier on what is to be 

supplied. This concern leads to a search for a computer-processable terminology common 

to the customer and supplier. Possible ways of addressing this concern are described 

below. A literature search for alternative shared terminologies provides examples of three 

approaches to be described below.

4.1 Standard nomenclatures

Standard nomenclatures provide a means for interested parties to communicate through 

terms agreed upon by the parties involved. There are literally hundreds such standard 

nomenclatures. One example is the ANSI/IEEE 505-1977 standard nomenclature for 

generating station electric power systems [15]. An excerpt taken directly from another 

standard nomenclature, ANSI A250.7-1997 Nomenclature for Standard Steel Doors and 

Frames [16] is shown below:
“[ADJUSTABLE BASE ANCHOR]

a device used to anchor frames to a depressed slab or below finished floor line

[ADJUSTABLE FRAME]

frame with profile in two or more pieces that will adjust to accommodate several 

wall thickness—also known as expandable frame

[ANCHOR]

a device for attaching frame to the surrounding structure

[APPLIED STOP]

surface mounted stop attached to a cased opening

[APPLIED TRIM]

decorative piece applied onto the face of a frame”

It can be seen that such standard nomenclatures are designed for human comprehension 

and communication and are not computer-processable. Furthermore, they are linear lists 

with no indications of hierarchical relationships between terms. As such, they are of little 

value to the shared vocabularies that we seek.

4.2 Product codes

Product codes encode product identification into a numeric code. Two examples follow:

HSC (Harmonized System Codes) is a commonly used set of product codes for 

classifying products for trading purposes. This classification is used by customs officials 

around the world to determine the duties, taxes and regulations that apply to the product. 

Under HSC, products are assigned a six-digit identifying number:

• The first two digits of this number identify the chapter into which the product 

falls, as follows:

01-05 Animal & Animal Products

... 

84-85 Machinery / Electrical

...

98-99 Service 

. 

• The second two digits identify the heading within that chapter. As an example, the 

segment of chapter 84 yields:

8459 machine tools for drilling, boring, milling, etc.

8460 machine tools for honing or finishing metal, etc.

8461 machine tools for shaping, slotting, gear cut, etc.

...

8465 machine tools for working wood, cork, bone, etc.

8466 parts, etc for machine tools of head 8459 to 8465.

• The final two digits identify a specific class of products. As an example, heading 

8461 contains:
846110 Planing Machines

846120 Shaping or Slotting Machines

846130 Broaching Machines

846140 Gear Cutting, Gear Grinding or Gear Finishing Machines

846150 Sewing or Cutting-off Machines

846190 Other Machine-tools Working by Removing Metal 

Each country may further expand HSC by adding additional digits. The U. S. version of 

the Harmonized System is maintained by the U.S. Department of Commerce Census 

Bureau Foreign Trade Division [17].

It can be seen that the HSC codes have insufficient precision for identifying products to 

the depth that virtual supply chains would demand. Furthermore, there is no mechanism 

for customization. 

NDC (National Drug Code) [18] is another well-known product code. It is an 11-digit, 3-

segment number assigned to each medication listed under Section 510 of the U.S. Food, 

Drug, and Cosmetic Act. The number identifies the labeler or vendor, product, and trade 

package size, as follows:

• The first segment, the labeler code, is assigned by the Food and Drug 

Administration (FDA). A labeler is any firm that manufactures, repacks or 

distributes a drug product. 

• The second segment, the product code, identifies a specific strength, dosage form, 

and formulation for a particular firm. 

• The third segment, the package code. identifies package sizes. 

Again, as in HSC there are no provisions for customization.

GS1 is a system of standards that governs the bar codes ubiquitous in supply chain 

commerce [19]. The GS1 Identification System provides two types of identifiers. The 

first or primary identifiers are called the Global Trade Item Number (GTIN) or Global 

Location Number (GLN). Other GS1 keys identify trade items (GTIN), locations/trading 

parties i.e., GLN, logistic units i.e., Serial Shipping Container Code (SSCC), individual 

assets i.e., Global Individual Asset Identifier (GIAI), returnable assets i.e., The Global 

Returnable Asset Identifier (GRAI), service relationships (GSRN), and document types

i.e., Global Document Type Identifier (GDTI). The GS1 Identification System also 

provides key "attributes" such as Lot Numbers or Expiration Date. 

Companies joining the system obtain a GS1 Company Prefix from a GS1 Member 

Organization and then assign reference identification numbers to their trade items 

(products or services), themselves (as a legal entity), locations, logistic units, individual 

company assets, returnable assets (returnable pallets, kegs, tubs), and service 

relationships. Finally, they generate numbers for the bar codes using the GS1 Company 

Prefix in combination with the assigned reference numbers.
It appears that all customization takes place only at the company level, so that the GTIN

assigned by the supplier is essentially equivalent to the item number, but it is arrived at 

unilaterally by the supplier without the customer’s input. Furthermore, the GS1 system 

appears to be only a standard for syntax, with no global contents or semantics.

EPC (Electronic Product Code) proposes a new object identification scheme which 

uniquely identifies objects and facilitates tracking throughout the product life cycle [20]. 

The EPC is a short, simple and extensible code designed for efficient referencing to 

networked information. It is intended that a unique EPC be assigned to one and only one 

physical item. For this reason alone, the EPC is not relevant to the subject at hand, the 

discovery of potential suppliers for a product that may not have been designed or 

manufactured yet.

4.3 Taxonomies

Taxonomies are composed of taxonomic units that are typically arranged in a hierarchical 

structure and are related by parent-child relationships. The term taxonomy may also 

apply to relationship schemes other than parent-child hierarchies, such as network 

structures with other types of relationships.

Electromechanical Component Taxonomy is presented in the Appendix of [21]. The 

levels of the taxonomy are:

• Primary component classification (branchers, channelers, etc.)

• Secondary component classification (separators and distributors as subsets of 

branchers)

• Component term (divider, vibrator, material filter, etc. as subsets of separators)

• Component subset (permeable membrane, rake and screen as subsets of material 

filter).

In addition, synonyms and definitions of the leaf nodes are provided. As many of the 

taxonomies surveyed, this one was developed for the support of knowledge- and 

function-based conceptual design. 

Another conceptual design paper refers to catalogs of standard components but does not 

elaborate the catalog’s structure or content [22].

Active Catalog is a third taxonomy developed for the support of conceptual design [23]. 

Quoting: “An Active Catalog, as the name suggests, is a catalog containing active, i.e., 

behavioral and dynamic, information of design components and parts described by a rich 

set of models of different modalities to facilitate information consumption. The 

modalities of models include, for example, a mathematical model, simulation model, 

engineering drawing, 3D geometrical model, electronic model, textural and semantic 

description, a set of information viewers and even simulation code. The major 

components or substrates of an Active Catalog are a semantic model of a domain, a set of 

models in the above mentioned modalities, a set of databases that stores the models, a 

search engine that recognizes users’ queries specified in a vocabulary given by the 
semantic model of the domain, and a set of helper applications for viewing the 

corresponding types of models.”

The application demonstrated deals with pumps. “The pump taxonomy is organized as a 

graph rather than a tree structure by taking advantage of LOOM’s multiple inheritance. 

This provides multiple paths to a specific pump type. At the top levels of the taxonomy 

are a few abstract type-definitions for pumps, such as Kinetic Pumps and Positive 

Displacement Pumps, with Special Pumps, Peripheral Pumps and Centrifugal Pumps 

being subclasses of Kinetic Pumps, and Rotary Pumps, Blow Case Pumps, and 

Reciprocating Pumps being subclasses of Positive Displacement Pumps. In the middle 

levels are a rich set of abstract classes defining varieties of pump classes. At the bottom 

levels a large number of pump classes are defined by combining types from top and 

middle levels. For example, Reciprocating Single Acting Power Multiplex Pumps are 

defined as sub-class of Reciprocating Pumps, Single Acting Power Pumps, and Multiplex 

Pumps.”

4.4 Faceted classification systems

A faceted classification system provides for multiple classifications of an object, enabling 

the classifications to be ordered in multiple ways, rather than in a single, pre-determined, 

taxonomic order. A facet comprises "clearly defined, mutually exclusive, and collectively 

exhaustive aspects, properties or characteristics of a class or specific subject" [24]. 

SNOMED (Systematized Nomenclature of Medicine) is a well-known faceted 

classification system of medical knowledge. SNOMED uses 11 classification axes to 

classify each disease. The axes are:

• T (Topography) -- Anatomic terms

• M (Morphology) -- Changes found in cells, tissues and organs

• L (Living organisms) -- Bacteria and viruses

• C (Chemical) -- Drugs

• F (Function) -- Signs and symptoms

• J (Occupation) -- Terms that describe the occupation

• D (Diagnosis) -- Diagnostic terms

• P (Procedure) -- Administrative, diagnostic and therapeutic procedures

• A (Physical agents, forces, activities) -- Devices and activities associated with the 

disease

• S (Social context) -- Social conditions and important relationships in medicine

• G (General) -- Syntactic linkages and qualifiers

For example, a disease may be located in a body organ which results in a code in a 

topography axis and may lead to morphological alterations represented by a morphology 

code.
4.5 Group Technology

Group Technology (GT) is an approach that seeks to identify attributes of a population 

that permit its members to be collected into groups, also called families. In an industry, 

usually similar parts are identified and grouped together to take advantage of their 

similarities in design and manufacturing. Contemporary GT methods apply coding 

schemes as a popular method for capturing the design and manufacturing information 

pertinent to the parts to be grouped. A GT code is an alphanumeric string, which 

represents critical information about a product in a concise manner. Conventional GT 

coding and classification schemes attempt to capture design and manufacturing attributes 

such as the main shape, size, feature of the product, production quantity and the material 

[26]. Coding schemes for parts classification either fall into a hierarchical structure, 

chain-type structure or a hybrid of the two structures [27]. For example the Opitz coding 

system uses the following digit sequence:

12345 6789 ABCD

The basic code consists of nine digits, which can be extended by adding four more 

characters. The first nine digits are intended to convey both design and manufacturing 

data. 12345, are called the “form code” and describe the primary attributes of the part. 

The next four digits, 6789, constitute the “supplementary code” which indicate attributes 

useful to manufacturing. The extra four characters, ABCD, are referred to as the 

“secondary code” and intended to identify the production operation type and sequence. 

GT codes can be effectively used in database searches to retrieve close matches to a 

given design and generate new process plans automatically using a knowledge-based 

system and to access manufacturability of a product design. But, with a gamut of 

available coding systems for the classification, none has been universally adopted. 

5 Summary of findings

a) There is no comprehensive description of process plans for manufacturing all 

products. However, such a description is not an absolute necessity for an initial 

version of the virtual supply network. The network can come into existence by 

using the traditional division of knowledge where process plan knowledge 

resides exclusively with the supplier. Therefore, the network should rely on 

product description alone, leaving it up to the supplier to devise a manufacturing 

process as part of the supplier’s response to an inquiry, RFP or purchase order.

b) It appears from the literature surveyed that a comprehensive taxonomy of all 

products that may be directly used in supply chain transactions does not exist. In 

fact, it is clear that such an exhaustive list is simply not feasible; among other 

reasons, in today’s rapidly changing technology any static list would quickly 

become outdated. A prototype version of the virtual supply network could be 

launched in a restricted domain where the shared vocabulary could be built up 
interactively by the participants. Initially, the Locator introduced in the 

“strawman” use case could maintain the vocabulary and update it as needed.

c) For a broader domain, a shared nomenclature is still needed. The approaches to 

shared descriptions reviewed here may serve as guidelines.

d) The most promising approach would be the development of a multifaceted 

classification system for manufactured electro-mechanical products that could 

eventually serve as the basis of a standard. The structure of the system could be 

patterned after that of SNOMED, but it will first require a major cooperative 

effort to decide on a comprehensive set of classification axes that “span” the 

domain of discourse. One axis would certainly be “Function” and it could 

initially be based on the taxonomy presented by Porter and Stone [21]. Further 

axes may relate to “Material” and “Manufacturing process,” but it should be 

possible to access product descriptions without classifiers along these axes. Other 

possible axes may refer to the “Environment” or “Context” in which the product 

is used and “Safety” issues associated with the product. 

The implementation of the classification system would have to respond to the rapidly 

changing nature of the global manufacturing enterprise. Modifications, particularly 

additions, would have to be done rapidly, without committee deliberations and multiple 

levels of ballots. Dynamic models, such as open source software, open standards and 

Wikipedia, will have to be investigated. Eventually, an organization would have to be 

formed to manage and maintain the system, similar to what ISDO (International Health 

Terminology Standards Development Organization) does for SNOMED [25].

DISCLAIMER

No approval or endorsement of any commercial product by the National Institute of 

Standards and Technology is intended or implied.

6 References

1. Srinivasan, V., Lammer, L., Vettermann, S., On Architecting and Implementing a 

Product Information Sharing Service, Journal of Computing and Information Science 

in Engineering, Vol. 8, 2008, pp. 6-17.

2. Srinivasan, V., An Integration Framework for Product Lifecycle Management, 

Computer-Aided Design, 2008, doi:10.1016/j.cad.2008.12.001

3. Fenves, S., Subrahmanian, E., Goyal, P., Angbo, J., Daoud, F., Sriram, R.D., The 

Architecture Development Facilitator (ADF) First Year Report, NIST 

Interagency/Internal Report (NISTIR) - 7411, 2007.

4. http://www.x12.org/, Accessed March 31, 2009.

5. http://www.stylusstudio.com/edifact/, Accessed 11 March 31, 2009.
6. http://eidx.comptia.org/, Accessed March 31, 2009.

7. http://www.rosettanet.org/, Accessed March 31, 2009.

8. http://www.openapplications.org/, Accessed 11 March 31, 2009.

9. http://www.supply-chain.org/, Accessed March 31, 2009.

10. http://www.supply-chain.org/cs/root/scor_tools_resources/scor_model/scor_model/, 

Accessed March 31, 2009.

11. http://www.supplychain.org/cs/root/scor_tools_resources/designchain_dcor/dcor_models/, Accessed 

March 31, 2009.

12. ASME B5/TC56 Committee, Information Technology for Machine Tools, ASME 

B5.59-1 (2005), Data specification for machine tool performance tests, ASME, New 

York.

13. Mahesh, M., Ong, S.K., Nee, A.Y.C., Fuh, J.Y.H., Zhang, Y.F., Towards A Generic 

Distributed and Collaborative Digital Manufacturing, Robotics and Computer 

Integrated Manufacturing (RCIM), Vol. 23, No 3, 2007, pp 267-275.

14. Boonserm, K., Ivezic, N., Wysk, R.A., Jones, A., Integrated Product and Process 

Data for Business to Business Collaboration, Artificial Intelligence for Engineering 

Design, Analysis, and Manufacturing (AIEDAM), Vol. 17, No. 3, 2003, pp 253-270.

15. IEEE Standard, Nomenclature for Generating Station Electric Power Systems, 

ANSI/1EEE Std 505-1977, 

http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/2660/850/00021012.pdf?arnumb

er=21012, Accessed March 31, 2009.

16. ANSI A250.7-1997, American National Standard Nomenclature for Standard Steel 

Doors and Steel Frames, 

http://www.deansteelmarine.com/__files/A250_7%20Better%20Nomeclature.pdf, 

Accessed March 31, 2009.

17. http://www.census.gov/foreign-trade/reference/codes/index.html, Accessed 11 March 

31, 2009.

18. http://www.fda.gov/cder/ndc/, Accessed March 31, 2009.

19. http://gpcbrowser.gs1.org/Default.aspx, Accessed March 31, 2009.

20. Brock, D.L., The Electronic Product Code (EPC): A Naming Scheme for Physical 

Objects Biography,

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.6514/, Accessed March 

31, 2009.

21. Kurtoglu, T., A Computational Approach to Innovative Conceptual Design, 

Dissertation, University of Texas, August 2007.

22. Vargas-Hernandez, N., Shah, J.J., Lacroix, Z., Development of a Computer Aided 

Conceptual Design Tool for Complex Electromechanical Systems, 

AAAI Technical Report SS-03-02, 2003, 

http://www.aaai.org/Library/Symposia/Spring/2003/ss03-02-035.php/, Accessed 

March 31, 2009.

23. Coutinho, M., Eleish, R., Kim, J., Kumar, V., Ling, S. R., Active Catalogs: Integrated 

Support for Component Engineering, Proceedings of the American Society of 

Mechanical Engineers, 18th Computers in Engineering Conference, 1998. 

http://www.isi.edu/~jihie/asme-98.ps/, Accessed March 31, 2009.
24. Taylor, A. G., Introduction to Cataloging and Classification, 8th edition, Libraries 

Unlimited, Englewood, CO, 1992.

25. http://www.ihtsdo.org/, Accessed 11 March 31, 2009.

26. Groover, M.P, Automation, production systems, and computer-integrated 

manufacturing, 3rd edition, Prentice Hall, New York NY, 2007.

27. Anupam, G., Expansion of Group Technology Part Coding Based on Functionality, 

MS Thesis, University of Cincinnati, Industrial Engineering Department, 2001.