CEN CWA 15295

WORKSHOP August 2005

AGREEMENT

ICS 35.240.60

English version

Description of References and Data Models for Classification

This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement.

The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.

This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.

This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: rue de Stassart, 36 B-1050 Brussels

© 2005 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

Ref. No.:CWA 15295:2005 D/E/F CWA 15295:2005 (E)

Contents Contents 2 Foreword 4 Introduction 5 1.1 Trends in doing business 5 1.2 Trends in Product coding 5 1.3 Need for data standards across enterprises 6 1.4 Vision 6 2 Normative references 7 3 Abbreviations, terms and definitions 8 3.1 Abbreviations 8 3.2 Terms and definitions 10 4 Product Classification and Product Description 11 4.1 Product Identification Codes 11 4.2 Product Classification Schema 11 4.3 Lists of characteristics 12 4.4 Product Modeling 12 5 Common Architecture for technical dictionaries 16 5.1 Reference model for implementation 16 5.2 Reference model for maintenance 29 5.3 Requirements to ePDC data model 36 5.4 Conceptual ePDC Model 41 5.5 Standardized Basis for ePDC data model 42 5.6 UML representation of ISO 13584-42 Data model 45 5.7 Methodology to Derive Exchange messages 47 6 Recommendations 53 6.1 ISO 13584 / IEC 61360 53 6.2 Define exchange messages 54 6.3 Define a XML message format 54 7 Rules for the Operation of a Joint Committee 55 8 Requirements on the Toolkit for Maintaining the System 57 8.1 Repository 57 8.2 Data Access and Data Manipulation 59 8.3 Data Import and Data Export 61 8.4 Workflow Management 61

2 CWA 15295:2005 (E)

8.5 User Management 62 9 Requirements on a Website giving Access to the System 63 9.1 Access to Product Classification Schemes 63 9.2 Change Requests 64 10 Conclusion 65 11 Bibliography 70 12 Annex A – Detailed Final ePDC Data model 74 13 Annex B – ePDC Generic Exchange Format Hierarchy 122 14 Annex C – XML Schema Definition of the ePDC Generic Exchange Format 129 15 Annex D - Acknowledgement 130

3 CWA 15295:2005 (E)

Foreword The production of this final draft CWA ‘Description of References and Data Models for Classification’ has been written by the ePDC Project Team. Two versions of the draft CWA were released to the CEN/ISSS Workshop eCAT, the draft CWA was endorsed in September 2004. The comments received were included in this final draft version. ePDC ‘Global Multilingual Product Description and Classification for eCommerce and eBusiness’ is a project within the CEN/ISSS/WS/eCAT ‘Multilingual catalogue strategies for eCommerce and eBusiness’, which started in November 2002 and produced two CWAs. The objective of the project ePDC is to harmonize existing standards for product description and classification into a common horizontal, cross-industry product classification and description schema and how to maintain it, promote it and make it available to the public. Aim of the CWA is to help policy makers, business men, researcher and anybody interested to have an overview of the state of art, activities and possible actions to undertake to promote and facilitate the use of inter-operable product description and classification solutions in the scope of electronic Catalogues, based on recognized standards. The CWA focuses on the following aspects: Requirements on an Information Model supporting Product Classification and Description for electronic Catalogues The following aspects are in particular considered: • Reference Model of Business Processes in Scope • organizational and procedural issues: Workflow for Maintenance • technical issues: Requirements on an Information Model Comparison and Selection of existing standardized Information Models The CWA contains an analysis of existing standards/specifications which are in scope. Moreover the CWA contains recommendations related to further actions to be taken in particular regarding standardization. Requirements on a Toolkit for Maintenance of a Standardized Product Classification and Description Schema The CWA defines a minimum set of requirements on a tool supporting collaborative, multilingual, pan-European maintenance of a Standardized Product Classification and Description Schema. Some suggestions of how this should be done are put forward. The present CWA received the support of various experts representing different organizations, a list of experts who supported the contents of this document may be viewed in the Annex. This CEN Workshop Agreement is publicly available as a reference document from the National Members of CEN: AENOR, AFNOR, BSI, CSNI, CYS, DIN, DS, ELOT, EVS, IBN, IPQ, IST, LVS, LST, MSA, MSZT, NEN, NSAI, ON, PKN, SEE, SIS, SIST, SFS, SN, SNV, SUTN and UNI.

4 CWA 15295:2005 (E)

Introduction This document introduces the background of why Product Classification is important for doing trade in today's eBusiness environment, what are the basic requirements for a classification and shows a vision of how the ideal model should look (principles and methods). In the interconnected world of today there is an increasing emphasis on the efficient flow of products through the supply chain. Information flows are designed to plan and track material within and between enterprises. Often these flows need to encompass a product’s inception in R & D and continue through final disposal at the end of its lifecycle. During its lifetime many units of different companies deal with a product. Many humans and many computer systems need information about the product. Procurement forwards the information to (potential) suppliers and to their order processing systems. Suppliers match the information they receive with the data of their products. The appropriate item is selected. It is delivered and used, for example as a raw material in a production process. The information accompanying the material becomes part of the batch record. Concurrently purchasers perform statistical analyses to determine their market position and performance. Therefore they need information of what has been bought. There is information flow between many people and the computer systems they use. The current situation is that many of these computer systems are not interconnected, and they store the information they have to exchange in different, often proprietary, incompatible formats and data structures. Data is often transcribed, translated and transferred manually between computer systems. Enormous amounts of time and money are wasted. Electronic marketplaces are gaining importance. They are an interface in the supply chain in which this issue is most obvious. Product descriptions, specifications, catalogue data, orders, etc. are exchanged through electronic marketplaces. A more efficient way for exchange of information is critical to achieving their business goals. 1.1 Trends in doing business For many years, enterprises have done business using internal proprietary identification (coding) schemes for their finished products and raw materials catalogs, which usually resided in Manufacturing Resource Planning (MRP) systems. Over the past decade, the nature of doing business in the chemical industry has moved from local, single business models to global, enterprise wide models; at the same time, Information Technology has been instrumental in pushing these models to become reality by e.g. ERP systems and global networks. Globalization of businesses, as well as fast emerging Information Technology is leading to more transparency of business processes and forcing inter-company systems integration. 1.2 Trends in Product coding Coding of Products for internal processes for many years has been locally, as result, businesses and geographic areas had their own Product Identifications. This causes significant duplication and inefficiencies in business processes, not only internally within an enterprise (EH&S, Procurement, Manufacturing, etc.), but also outside the company. Emerging eBusiness technology is pushing the envelope even faster and accelerates the need for transparent business transactions in a B2B, B2C and eMarketplace environment.

5 CWA 15295:2005 (E)

Prerequisite for transparent business transaction processing is consistency in data structures and consistency in coding of Products, Customers, Locations, etc. 1.3 Need for data standards across enterprises As seen, integration across enterprises is driving the need for standardizing data structures. This may not be valid for all types of data; enterprises will always have proprietary data. But it is true for what could be called “structural data”, i.e. data which creates an ordering for the conduct of daily business, such as categories, types, classifications,... Classification systems with sets of properties are quite complex data systems. It takes tens of person-years to create such a system which meets the requirements of a larger enterprise. It is quite obvious that creating and maintaining only one and using it everywhere is much more efficient and economical than using multiple proprietary systems. In addition to their own structure(s), cross-reference tables need to be created and maintained. This is a costly and time consuming effort which, in the absence of a standard, would need to be undertaken within each enterprise. These efforts provide no value to the customer and only add to the difficulty in integrating cross business processes. 1.4 Vision Without a standard for a global Product Description and Classification, accepted by all, business processes and companies will continue to have proprietary hierarchies and codes for Products, continuing to result in huge costs for human intervention and/or translation of product data between steps in the ERP process. Eventually there will be an integrating framework of Product Data Management (PDM) across all industries and all enterprise functions. Product data will be created only once, at the source; others in the supply chain will use the data as provided by the manufacturer (or the necessary part of it). Information, formulated in a common language, will accompany a product during its whole life cycle. This common language will be used in specifications, RFQs, electronic catalogues, data sheets and the like. It will enable highly automated business processes, as all systems can exchange and process specifications and product data without human interpretation. It will make electronic marketplaces work.

6 CWA 15295:2005 (E)

2 Normative references IEC 613601-4:1997-05 IEC Standard. Standard data element types with associated classification scheme for electric components ISO 8879 ISO Standard. ISO 8879:1986(E). Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986-10-15. [Geneva]: International Organization for Standardization, 1986. ISO 10303-1:1994 ISO Standard. ISO 10303-1:1994. Industrial automation systems and integration – Product data representation and exchange – Part 1: Overview and fundamental principles. ISO 11179 Parts 1-6 ISO Standard. Specifications and standardisation of data elements. ISO 13584-1:2001 ISO Standard. ISO 13584-1:2001. Industrial automation systems and integration – Parts library – Part 1: Overview and fundamental principles. Edition of 2001. ISO 13584-20:1998 ISO Standard. ISO 13584-20:1998. Industrial automation systems and integration – Parts library – Part 20: Logical resource: Logical model of expressions. Edition of 1998. ISO 13584-42:1998 / ISO Standard. ISO 13584-42:1998. Industrial automation Technical Corrigendum systems and integration – Parts library – Part 42: Description 1:2003 Methodology: Methodology for structuring part families. Edition of 1998, correction 1 in 2003 ISO-15000-3 ISO Standard. ISO 15000-3. Electronic Business eXtensible Markup Language (ebXML):Registry Information Model Specification (ebRIM) ISO-15000-4 ISO Standard. ISO 15000-4. Electronic Business eXtensible Markup Language (ebXML):Registry Service Specification (ebRS) ISO 17113 ISO Standard. ISO 17113. Method for Development of Messages XML World Wide Web Consortium Recommendations: http://www.w3.org/TR/REC-xml

7 CWA 15295:2005 (E)

3 Abbreviations, terms and definitions 3.1 Abbreviations A A2A – application-to-application EDI – electronic data interchange API – application programming interface EDIFACT – EDI for administration, commerce and transportation B EDP – Electronic Data Processing B2B – business-to-business EPC – electronic product catalogue B2C – business-to-consumer ER – entity relationship BME – Bundesverband Materialwirtschaft, ERD – entity relationship diagram Einkauf und Logistik e.V. BMEcat – Electronic catalogue data E/R Model – Entity-Relationship Model exchange format based on XML ERP – enterprise resource planning [BMEcat] F C FAQ – frequently asked questions CAD – Computer Aided Design FMCG – Fast Moving Consumer Goods CAE – Computer Aided Engineering G CAx – Computer Aided Tools GCI – Global Commerce Initiative CEN – European Committee for Standardization GTIN – Global Trade Item Number CWA – CEN Workshop Agreement GUI – graphical user interface cXML – commerce XML GUID – Global Unique IDentifier D H DTD – document type definition html – hypertext markup language http – hypertext transfer protocol E I EAI – enterprise application integration EAN – European Article Number ICD – International Code Designator ebXML – electronic business XML ID – odentification eCat – electronic product catalogue; in this IEC - International Electrotechnical document eCat will solely be used to Commission refer to the CEN/ISSS workshop and ISO – International Organization for this CWA Standardization ECCMA - Electronic Commerce Code IT – information technology Management Association J eOTD – ECCMA Open Technical Dictionary JIT – just in time ePDC – electronic Product Description L and Classification LoC – Lists of Characteristics

8 CWA 15295:2005 (E)

M UN/CEFACT - United Nations Centre for Trade Facilitation and Electronic MoU – memorandum of understanding Business MRO – maintenance, repair and UNSPSC - United Nations Standard operations Products and Services Code ® MRP – Manufacturing Resource Planning (UNSPSC ® ) N W NWI – new work item W3C – World Wide Consortium O WSDL – web services description language OAG – Open Applications Group X OAGIS – Open Applications Group Integration Specification xCBL – XML Common Business Library OBI – open buying on the Internet XML – extensible markup language OCI – open catalogue interface XSD – XML Schema Definition P pdf – portable document format PCS – Product Classification System PDM – Product Data Management PLIB – Part Library [ISO 13584] PLM – Product Lifecycle Management R RNDT – RosettaNet Technical Dictionary RIM –Reference Information Model [ISO 17113] S SC – supply chain SGML – Standard Generalized Markup Language [ISO 8879] SME – small or medium-sized enterprises smtp – simple mail transfer protocol SOAP – simple object access protocol STEP – Standard for the Exchange of Product data [ISO 10303] SW – software U UDDI – universal description, discovery and integration UML – unified modelling language

9 CWA 15295:2005 (E)

3.2 Terms and definitions For a harmonized ePDC Terminology see CWA 15294:2005.

10 CWA 15295:2005 (E)

4 Product Classification and Product Description The goal of Product Lifecycle Management (PLM) is to handle all information during product lifecycle which is generated in processes in the value chain through the extended enterprise. Information used or served by one process of the value chain must be easily available for other processes. Some pieces of the information are invariant to the processes of the value chain, while for each process some specific information may be added. In contrast, Product Data Management is handled in most enterprises by encoding information about products in numbering systems and describing products in different database tables leading to an overhead in data conversion efforts between systems, processes and enterprises and thus resulting in longer time-to-market. 4.1 Product Identification Codes Identification codes are used to make an unambiguous identification of a thing. Some years ago, products were identified by identification codes which allowed to anticipate the characteristics of a product. Today identification codes have no special semantics; each time a new code for a product is needed, the code is simply incremented. The one-to-one correspondence between the code and the thing is very useful for recording and linking records of items and actions taken on the items (such as point-of-sale transactions, inventory management, record keeping). 4.2 Product Classification Schema The task of product classification is the process to assign each product to a product group comprised by a Product Classification Schema (called “class”) corresponding to attributes or application areas. Mostly each product gets a classification code assigned to group similar things into common categories. The values of the classification codes are arbitrary, i.e. are not deduced from the products properties. With product classification, similar things are members of a class. Similar classes are members of yet a more general class or family, and so on. Product classification is mainly used for identifying where expenditures are being made, and for searching and comparing offered products on electronic markets. Hence, product classification systems are heavily used in procurement. To augment the usability of product classification systems for more general purposes, some product classification systems define sets of attributes [properties in our terminology] associated to classes [Schmitz 2002]. A set of attributes [properties] is assigned to a classification group [class] and contains therefore at least the set of the necessary product properties for this classification group [class]. In e-catalogues that claim to support a specific classification system each product has been augmented by the classification code and the set of group-dependent list of attributes/value pairs.

11 CWA 15295:2005 (E)

Mostly all currently available intra-company wide part management solutions structure their content in respect to similar company or domain specific hierarchical product classification methodologies. Changes in the classification structure, i.e. resulting from a company takeover or project cooperation, needs a complete rework of all products to get the classification keys updated. Due to the huge amount of different products that are used and introduced daily, the goal of product classification can grow immensely complex. A selection of parts on the basis of technical requirements is not possible (for example “bolt with anti-twist device and head without eyebolt-bore). A selection of objects in regards to a specific target is only possible for a limited amount of criteria. Parts can be collected and arranged in a classification system but not fully described. The primary focus of a classification system is to supply an identification and structuring mechanism. Supporting the exchange of data within the product life cycle is not the target of a product classification system. 4.3 Lists of characteristics Another approach is lists of characteristics (LoC). The purpose of lists of characteristics is to bundle an (consensually) agreed collection of properties to an identifier for the concept and relate it to a describing terms and a definition. The number of properties is adjusted for each group of parts. The amount of classification properties needs to be thoroughly investigated in order to have enough detail to distinguish two parts but not too much to complicate the evaluation of a lists of characteristics. The descriptive power of a list of characteristics is much deeper than the previously proposed methods but by no means complete. Not just geometrical characteristics can be defined as properties of a part. Compared to product classifications each lists of characteristics describes one set of similar products. It is not ensured that lists of characteristics do not overlap, i.e. no classification hierarchy tree is created. Since there is no hierarchy in this concept, inheritance of properties to the next lower levels is not possible [Ondracek 1998]. There is no concept of classifying properties which can be used for abstraction or analysis purposes. 4.4 Product Modeling To resolve the above shown problems of product data exchange ISO Technical committee TC184/SC4 developed, together with IEC SC3D and the support of some national standardization bodies, a set of standards targeting these problems. The ISO 13584 PLIB (parts library) is a series of International Standards for the computer sensible representation and exchange of part library data [Pierra 1997]. The objective is to provide a mechanism capable of transferring parts library data, independent of any application that is using a parts library data system. The nature of this description makes it suitable not only for the exchange of files containing parts, but also as a basis for implementing and sharing databases of parts data.

12 CWA 15295:2005 (E)

To underline the multi-discipline acceptance, IEC co-developed the standard and published some parts of ISO 13584 as IEC 61360. The approach of ISO/IEC is somewhat similar to the product classification approach but differs in some essentials. 4.4.1 Models According to Minsky [Minsky 1968] we use the term "model" in the following sense: To an observer B, an object A* is a model of an object A to the extent that B can use A* to answer questions that interest him about A. The model relation is inherently ternary: • real world • model • observer Any attempt to suppress the role of the intentions of the investigator B leads to circular definitions or to ambiguities about "essential features" and the like. The ternary relationship has consequences. A model is only useful if we use it with the same intensions and input/output coding as the observer B had. 4.4.2 Product Models If we look at the product life cycle, we use and change our models frequently when we construct, build, buy or sell products. We build different product models, i.e. when we use documents to describe product requirements, when we model product geometries using CAD systems, when we build mathematical calculation models or when we send emails asking for certain specifications of products, etc. In any case we have to know which questions about real-world products we want to answer with our product models. In fact product models can be used to describe exactly one product or to describe a set of products thus bearing another degree of abstraction. 4.4.2.1 Product Representation Models Product representation models are some kind of product models with the goal to answer precise questions about a specific product. The main purpose of these product representation models is to get exact answers about a product, not to compare products. For each of these models an interpretation tool is necessary. Product representation models are primarily used in product lifecycle phases which have high analytical goals. Examples are product design where the shape (CAD-model) or physical behavior (FE- model) is modeled. The purpose of a CAD model is to describe as completely as possible the geometric properties of a part for manufacturing. But this geometry will never be precisely and accurately modeled. The purpose of a FE-model on the other hand, is to determine strains and expansions of an assembly after applying loads to the construction. Here, the geometry is modeled very strict and accurate. Simple models can be found for instance in a spring-damper-mass system which is used to determine

13 CWA 15295:2005 (E)

oscillations in assemblies. Here, simplifications of the reality are accepted in the model since they do not have an impact. This means that the quality of answers that are retrieved through the model to certain questions is related to the context in which the questions are asked. A standard targeting product representation models is ISO 10303 (STEP). 4.4.2.2 Property based Product Models If we now look at models that also allow the description of a set of products and define equivalence-relations over the investigated products, we can identify another type of product model. This model uses the atomic properties of parts to group these parts into partitions and thus gather some higher degree of abstraction. Consider the following example, let us now isolate the different pieces of information and their relationship as well as the modelled abstraction.

Name: fluorescent lamp

Synonyms: ECO-lamp

Technical Properties: life 60 000 h power 7W, 11W, 21W nominal voltage 110V, 230V lamp bases E14, E27

Description: Fluorescent lamps produce 70% of artificial light throughout the world

Figure 1 - Properties of technical product

Properties value domain In natural language we say each product has certain properties. To be more formal, according to ISO 13584 a property is a piece of information that may be represented by the following set: • Property identification, e.g. for nominal voltage AAE519-005 • Property description1), which is a textual description of the purpose of the property • a set of possible values (value domain), e.g. for lamp basis: E14, E27 Classes Considering our example, we also recognize that specifying the properties of the lamp obtains a certain degree of abstraction. Saying fluorescent lamps are described by the properties • life

1 To avoid ambiguities we have to mention, that all properties are only defined for exactly one class of parts (including subclasses, for details see ISO 13584-42) which is a formal condition for its definition.

14 CWA 15295:2005 (E)

• power • nominal voltage • lamp bases implies that any real world thing, which we treat as being a fluorescent lamp, has to provide for all describing properties exactly one value out of the property’s value domain. In the sense of our abstraction all products which have exactly these properties can be considered as lamps. We now say, a class is a set of • Class identification, • Class description, e.g. “Fluorescent lamps are lamps which produce artificial light throughout fluorescent phenomena” • a set of properties which are describing all products of the class For a given lamp in this product model we now know the exact power, voltage etc. but we do not know anything about its geometric shape: To keep consistent, we need exact rules to relate products to classes and divide classes into subclasses. • Similar objects with the same descriptive features that only distinguish themselves by different property values are bundled into the same class. These classes are described by those properties. • Under certain conditions classes can be structured hierarchically. The parent- child relationship within the hierarchy has the semantic relationship “is_a”. • A class system follows the paradigm of object orientation, meaning that all parameters of a class are inherited in all subclasses. • Every class defines a space wherein the properties for the description of objects are uniquely defined. This means that the semantic meaning of a specific property is the same for all objects within the definition class and all its subclasses.

15 CWA 15295:2005 (E)

5 Common Architecture for technical dictionaries 5.1 Reference model for implementation This section describes elements of a reference model for implementing product classification schemes. The description is structured in two parts: business processes and implementation. First, we discuss the product life-cycle management in general and some use cases in which product classification schemes are used. As a result, we show the need for exchanging product classification schema between standardization organizations, suppliers, intermediaries, and buyers. Second, we present guidelines for the implementation of product classification schemes by classification organizations and companies. These guidelines address the role of standards and the importance of providing semantic-rich data for adopters of product classification schemes. 5.1.1 Product Life-cycle Management Product life-cycle management (PLM) aims at integrating all tasks and information that arise during the life-cycle of a product. Product characteristics, functions and categories belong to this information, thus product classification and description is subject of PLM as well. This concept goes a step beyond traditional product data management (PDM), since it claims to extend its coverage to data relevant to distribution, after-sales, and recycling. PDM is in most cases limited to the early life-cycle phases (product planning, design, construction, process planning, and manufacturing). The differentiation of a number of life-cycle phases leads to different views on products and product data. For instance, selling products requires specific data (marketing texts, price information) whereas concurrent engineering focuses the product characteristics and model information. We can state, that each life-cycle phase makes specific requirements on the product data, meaning classification and description. From this perspective, the class that a product is assigned to and the set of properties (including property values) that describe the product are dependent on the respective life-cycle phase. Therefore, the degree of correspondence between two product classification schemes addressing different phases may be rather small.

16 CWA 15295:2005 (E)

5.1.2 Use case diagram

classify Products

classif ies products

describe Products describes products

Classification Expert Classification Organization

delivers classification schema receiv es Classif ication Schema supply Classif ication Schema receives Classification schema

receives classification schema

recieves catalog supply Catalogue PDC Sender supplies catalog PDC Receiv er

PDC Intermediary

Supplier supplies Inf ormation Puchaser Buy er Seller perf orms Business Transaction

product description purchase deliv ery maintenance order

Figure 2 – Use case diagram

In the use case diagram the following actors are distinguished: Classification expert, Classification organization, PDC sender, PDC receiver, PDC intermediary, supplier and buyer. A classification expert is a person or organization who classifies products according to a specific product classification scheme. Classification organizations develop and publish product classification schemes. They provide formal specifications only. Examples of classification organizations are: standard development organization and industry consortia (eCl@ss, etc). A PDC sender is the role of a person or company that sends product catalogues. A PDC receiver is the role of a person or company that receives product catalogues. A supplier is the role of a person or company that offers products. Sometimes he classifies and describes his products in accordance with one or many product classification schemes. The supplier performs business transactions with buyers.

17 CWA 15295:2005 (E)

A buyer is the role of a person or company that purchases products. Sometimes he uses a Product Classification Scheme to search and find products or services. The buyer performs business transactions with suppliers. Intermediaries fulfil their role by providing intermediation services to suppliers and buyers (e.g., electronic platforms like marketplace, wholesale trade, multi-supplier product databases/dictionaries). 5.1.2.1 Use case: Supply Classification Schema To be able to classify and describe a product correctly, companies need to know the product classification schema. This data includes specifications of product classes, and if available, specifications of product properties (e.g., identifier, name, definition). When applying a schema, these specifications must be imported into an information system, e.g., catalogue management system, ERP system. This role is fulfilled by the formal specification, which is a set of structured data that describes and defines the content of the product classification schema. Importing a formal specification requires that this data can be exchanged between companies/organizations; hence the data is made available by converting it in an exchange format. In a very simple model, some organizations provide a product classification schema, while other organizations use this schema for classifying and describing their products. The importance of exchanging product classification schema is revealed by the results of a detailed analysis of the relationships between the actors. The results are summarized in Figure 3, which especially underlines the high number of relationship types (R1-R9), thus data exchanges.

Classification Organizations

1 2 3

4 5

Suppliers Intermediaries Buyers 6 7

8

9

Figure 3 - Exchange of Product Classification Schema Data

Note: The figure does not imply that there exists a single standardization organization only. In addition, the figure does not visualize cross-references between these standardization organizations. The business meaning of these relationships is as follows:

18 CWA 15295:2005 (E)

• R1: The data provided by the standardization organization is used by a supplier for classifying and describing his products. This relationship is the most common, since it represents the adoption of a standard product classification schema. • R2: The data provided by the standardization organization is used by an intermediary. The intermediary uses this schema for classifying and describing his products or the products listed on the marketplace respectively (in case of a marketplace). • R3: The data provided by the standardization organization is used by a buyer for inclusion in an e-procurement system. For instance, this data is needed for implementing hierarchical and property-based product search. • R4: The intermediary prescribes that his suppliers adhere to a custom product classification schema; hence the intermediary provides the formal specification to the suppliers. • R5: The buyer prescribes that the intermediary adheres to a custom, buyer- specific schema; hence the buyer provides this data to the intermediary. Concerning product classes and product properties, these two components of product classification schemes can be exchanged separately and independently from each other. For instance, a supplier defines a custom class hierarchy built from custom classes (R6, R8), but describes the products by reusing standardized properties. In this case, the exchange of schema data is limited to the classes and the hierarchy, while the property specifications do not need to be exchanged, because the customers already know these specifications (R2, R3). The catalogue will only give references to the properties. This aspect points to the exchange of classified product data. 5.1.2.2 Use case: Classify products Classification experts obtain classification schemes including classes and properties from the classification organizations (note: a supplier, buyer, intermediate or someone else may act as a classification expert). Using this classification scheme, the classification expert will classify the products. To classify means that each product is assigned to a class from the classification scheme. 5.1.2.3 Use case: Describe products Classification experts obtain classification schemes including categories and properties from the classification organizations (note: a supplier, buyer, intermediate or someone else may act as a classification expert). Using this classification scheme, the classification expert will describe the products. To describe means that a set of properties is assigned to the product and optionally for each property a value has been assigned. 5.1.2.4 Use case: Supply catalogue A PDC sender submits his catalogue to a PDC receiver. A PDC intermediary may act as a PDC sender or as a PDC receiver. The PDC sender or PDC intermediary might have classified his products and intends to organize the products in his catalogue according to a specific classification schema. The creation, application and relevance of company-specific product classification schemes (supplier-specific: R6 and R8; buyer-specific: R5 and R9; intermediary-

19 CWA 15295:2005 (E)

specific: R4 and R7) might be incorporated in a product catalogue. Considering the need for standardization, it does not mean that these schemes are completely proprietary, hence built on proprietary classes and properties. Rather the proposed availability of global, standardized and reusable specifications of classes and properties supports the implementation of these schemes without loosing the benefits of standardization. • R6: The supplier classifies and describes his products according to a custom schema; the schema is part of its product data and transferred to all customers, here: intermediary. This relationship is very common, since suppliers structure their products based on company-specific goals and requirements. • R7: The intermediary classifies and describes his products according to a custom schema; the schema is part of its product data and transferred to all customers, here: buyers. This relationship is similar to R6 also very common. • R8: Analogous to R6, the supplier-specific schema is transferred to buyers. • R9: Analogous to R5, the buyer provides his custom schema to suppliers. 5.1.2.5 Use case: Exchange Product Description In the context of product classification and description, the exchange of product data must be separated from exchanging product classification schema data. The reason is that product data relates to actual products that are offered from suppliers or required from buyers. In a word-to-word sense, the product classification schema serves as the template for these products. If two or more companies have agreed on using such a schema, then it is sufficient and meaningful to give references to the schema items only. The reference mechanism is enabled by unique identifiers for all schema items: Classifying a product requires to map the product to a product class by its identifier. The formal specification of the class is part of the schema, not the product data. Describing a product requires to apply or instantiate a product property by pointing to its identifier, and by adding the property value. The formal specification of the property is part of the schema, not the product data. Depending on the business process, the exchange of product data can be structured as shown in Figure 4. It is similar to the exchange of schema data, except that the standardization organizations are not involved. E D

Suppliers Intermediaries Buyers AB

C

F Figure 4 - Exchange of Classified Product Data The business meaning of these relationships is as follows:

20 CWA 15295:2005 (E)

• A: The supplier provides classified product data to his customers, here: intermediaries. • B: The intermediary provides classified product data to his customers, thus buyers. • C: The supplier provides classified product data to his customers, here: buyers. • D: The buyer requests classified product data from an intermediary based on a custom product specification, including requirements for product properties. • E: The intermediary requests classified product data from a supplier based on a custom product specification including requirements for product properties. • F: The buyer requests classified product data from suppliers based on a custom product specification including requirements for product properties. By combining these relationships, complex processes can be described. For instance, a buyer starts a request for proposal and sends it to an intermediary (D). Eventually, the intermediary propagates the request to several of his suppliers (E). Suppliers return their offers and include price and availability information (A). The intermediary evaluates the offers, and selects one or more offers which will be forwarded to the buyer (B). 5.1.3 Implementation This section describes guidelines for the implementation of product classification schemes to meet two goals. First, the fast-and-easy adoption of a given product classification schema should be facilitated and supported by the organizations that provide these schemes. Here, adoption relates not only to suppliers, but to all market players, and focuses the semantic quality and suitability of product classes and product properties as well. Second, companies willing to apply a product classification schema should be provided with data, services and specifications that can be automatically processed and integrated into existing information systems. 5.1.3.1 Adhere to Standard Classes In face of the high number of existing product classification schemes, creating new schemes in order to fulfil custom or largely neglected requirements is a critical, time- consuming and costly effort. While it is questionable, whether the vision of having a single, global and common schema for all or most business purposes could ever be realized, the benefits of standardization in general remain unchanged. This applies to product classes as well. The guideline here is that if an organization aims at building custom product classes and class hierarchies, then the use of already existing standard classes should be considered. Using such standard classes does not only reduce the required effort (by avoiding to reinvent the wheel), but more importantly, enables a common inter-organizational understanding, since these classes are known to other organizations as well. If such classes are already available, and they are appropriate, companies and especially suppliers can integrate them in their product life-cycle management for a standardized view of their products.

21 CWA 15295:2005 (E)

5.1.3.2 Adhere to Standard Properties Adhering to existing standard properties follows the same principles described in the previous section. It prevents the definition of custom properties when standardized ones are already available. It is of even more importance than standardized classes, since the amount of manual work and cost of describing products based on properties is much higher than for finding the right classes to which products belong. For each product of a supplier, to check the given product classes and to select one class as the right one. The product description part requires the assignment of values to all properties that are relevant to the given product class. Looking at existing product classification schemes, the number of properties per class can be very high; often 50, 100 or even more properties are relevant to a class. Today, due to the high number of different product classification schemes, many suppliers face this challenge more than once. Bearing in mind that two competitive schemes addressing the same product domain define their own properties, suppliers are forced to describe their products by the properties of all relevant schemes, even if the meaning of the properties is in many cases similar or even identical. A broader commitment on product properties would prevent a lot of redundant work by suppliers, and indeed all adopters of product classification schemes. 5.1.3.3 Adhere to Standard Data Models While the benefits of standard product classes and properties are caused by defining their semantics, we must consider that these items are processed by data management systems, and that this data is subject to exchange between organizations and their software systems. Therefore, conceptual data models describing the structure and relationships of these items are needed. Even if the items are completely different regarding their semantics, standardization of their structure is beneficial. The main function of a standard data model is to describe the entities in a domain on a conceptual level. In addition, such a model plays an important role in the development of software systems, that is data management systems that handle product classification schemes and classified product data. Finally, a conceptual model can serve as the basis for deriving and specifying data exchange formats. So the guidance here is to base all product classification schemes on a standard data model. The prime candidate for this is ISO 13584. Originally, the ISO 13584 standard aims at serving as a reference model for part libraries. ISO 13584 originated in the product data management area and is therefore focused on engineering, construction and production of technical goods, and related data exchange issues regarding product data, especially libraries describing these products. A common abbreviation for ISO 13584 is PLIB - product libraries. PLIB provides a conceptual data model, specified formally in the EXPRESS language of STEP (the ISO standard for the exchange of product model data). 5.1.3.4 Adhere to Standard Exchange Formats The analysis of the data exchange relationships has shown that product classification schemes (and their formal specifications) are affecting all organizations participating in transactions related to product data, especially e-catalogue data; the schemes may be added to product data and product catalogues (proprietary schemes), or the exchange

22 CWA 15295:2005 (E)

process may be separated from the exchange of classified product data. In the case of standard product classification schemes, it is particularly important that all market partners are able to access and process the formal specifications. From the point of view of organizations that develop and maintain standard product classification schemes, it must be guaranteed that suppliers, intermediaries and buyers are supplied with the specifications in a given, processable, exchange format, thus the data exchange is limited to R1-R3 (see Figure 3). In this regard, one could think that the complexity of data exchange and the number of exchange formats is already reduced by adopting standard product classification schemes. However, business practice does not prove this. As of today, each standard product classification scheme uses a different exchange format. The import of this data calls for flexible tools for mapping data elements of the exchange format to the importing information system. Heterogeneity is not limited to the general format type such as comma separated values (CSV), Microsoft Excel spreadsheets (XLS) and Microsoft Access database files (MDB), but includes the number of data elements, their naming and relationships. Thus the exchange formats and data models as well are different and must be integrated or mapped to a common model. Standardization of exchange is a formats two-fold scenario: On one hand, several XML- based standards for product catalogue data are available, and some of these formats also cover the exchange of product classification schemes. Catalog formats such as BMEcat [Schmitz / Kelkar / Pastoors, 2001], cXML [Ariba, 2004], OAGIS [Open Applications Group, 2002], and xCBL [CommerceOne, 2002] have to be mentioned. However, an analysis [Leukel / Schmitz / Dorloff, 2002] has shown that their capabilities for transferring standard product classification schemes are very limited, because critical information losses occur, especially regarding property definitions. On the other hand, there is to consider the ISO 13584 standard. However, contrary to its above stated aim, the adoption of PLIB is quite low, especially in e-procurement. If we look at current standard product classification schemes, we have to state that no standardization organization currently provides PLIB compliant formal specifications. The reasons are the complexity of the PLIB model and documentation as well as its technological basis. The guidance here is to reduce the number and variety of exchange formats as they are used today by providing a standard format. However, the exchange of classified product data is not subject of the ePDC project, since exchange formats for this transactional data are already available (i.e., message types for e-catalogues, request for proposals, orders etc.) 5.1.3.5 Consider New Requirements of E-Procurement Systems The rise of web-based e-procurement systems has led to some new requirements on product classification schemes for this domain. These can be identified by analysing the respective schemes. Following the role of product class hierarchies in searching for products and segmenting markets, a product class can be identified by its identifier as well by its position in a given hierarchy. The latter information is called coded name. The identifier (e.g.,

23 CWA 15295:2005 (E)

“AAA019”) itself says nothing about the position of the class in the hierarchy, while the coded name (e.g., “03-12-23”) is derived from the hierarchy (here: first level 03, second level 12, and third level 23). The identifier does not change over time, even when the product class is moved in the hierarchy. As a conclusion, the mapping of product to classes (classification) should use the class identifier only, in order to prevent re- classification when the hierarchy changes. In addition, the coded name should be used for presentation purposes only. Another requirement arises from including supplementing multimedia information about classes, properties and other items. For instance, the meaning of a product class can be visualized by showing a picture of characteristic products, or by adding a document of a standard describing these types of products. Hence, multimedia objects can be seen as additional information of product classification schemes. The description of these objects may include the file name and path, URI, object name, object description, file type, file size, and in the case of graphics, the resolution, colour depth, length and width. In order to base this information on a common standard, the MIME [RFC 2046, IANA Media Types] types may be adopted. 5.1.3.6 Provide XML-based Data While XML-based data exchange is very common in business-to-business relationships and its usage is still thriving, this cannot be said for exchanging product classification schemes (see proprietary, non-XML formats). In general, XML-based data exchange offers new possibilities concerning correctness and integrity of the data (due to powerful languages describing the exchange formats, especially XML Schema), importing these data (due to XML import interfaces and graphical tools), and automated data exchange (due to web service technology). Considering the already existing and improving infrastructure for processing XML-based data, for instance, e-catalogues and order transactions, product classification schema data exchange can reuse this infrastructure. The guidance for all organizations that provide specifications of product classification schemes is to provide an XML-based representation of this data. 5.1.3.7 Provide Precise Definitions The basic components of product classification schemes are product classes and product properties assigned to classes. While keeping this in mind, one could assume that such a formal specification would only be complex in terms of its number of classes and properties (several thousand), but that the specification itself could be rather simple. For instance, a product class definition would consist of identification, class name, long description, and a reference to its super class. A property definition would contain identification, property name and description plus data type and domain of values. Relationships between classes and properties would be another component. Yet this simple model does not match the actual complexity that has to be addressed. There are many further concepts that require both additional specification elements and relationships as well. The formal specification thus has to go beyond classes, and provide detailed information about class-specific properties, because sets of properties are a cornerstone of aligned product descriptions and efficient product comparisons. The property specification is not only important for suppliers who have to describe products

24 CWA 15295:2005 (E)

according to these specifications, but it also delivers information for the suitable representation in web-based application systems, e.g., defined sequences of properties instead of alphanumerical listings, semantic grouping of properties (i.e., identification, dimensions, material, shape, business attributes), and mandatory vs. optional properties. The formal specification can also include definitions of synonyms, units and values as additional components. For instance, class synonyms could be defined separately from the classes. Each class synonym is defined by its identifier, name, textual definition, version information etc. Modelling units of measurement is a new concept an addition to giving only references to units already defined in the Système International d'Unités (standardized in ISO 10303-41). The reason is that this information may help to represent the property in application systems (unit name, unit symbol etc., definition of the unit). Modelling of property values is especially useful for customized enumerations. A complex formal specification provides more semantics than a less complex one. These semantics describe product classes and properties in more detail, hence companies that classify and describe products according to a product classification schema can use these semantics in order to classify and describe their products correctly. From this view, a complex specification helps to understand the structure and content of a schema. Contrary to the more detailed class specifications, the relationships between product classes are less specified: all relationships between classes are “is_part_of” relationships. This is sufficient to build a hierarchy of classes, but it does not provide additional semantics, especially no information about the scope of sub and super classes. In addition, there is no formal description of the rational to build a specific hierarchy. For instance, what are the requirements for a product and its properties if it belongs to a given class? This information is expressed by textual definitions only, but not formally. The guidance is to provide precise definitions of classes and properties in order to support the classification process, but also to build consistent and meaningful schemes. In general, an explicit definition of the rationale behind a schema would be beneficial for the creation and maintenance process as well. However, this approach is still demanding. At least, the maintenance model for product classification schemes should aim at guaranteeing to fulfil basic semantic requirements for all specifications of product classes and properties. 5.1.3.8 Provide Meta Information When exchanging product classification schema data, meta information about the schema, its structure and basic concepts can be included. Meta information here relates to data that is added to the actual specifications of product classes, properties and so on. This is very similar to any inter-organizational data exchange, where at the least information about the sender and/or receiver of a message is included in the message header. In this case, full party information including organization, address, contact details etc. is added. Concerning the schema, its official name, a description of its domain, the language (ISO-coded) and version information is part of meta information. Another argument for providing meta information is to enable software systems to build the product class hierarchy correctly and efficiently (Leukel / Schmitz / Dorloff, 2002). This would require that there are data elements that say, for instance, “Number of

25 CWA 15295:2005 (E)

Levels=4”; “Balanced tree=yes” meaning that all sub-trees have the same number of levels, e.g., any product class on the third level has at least one sub-class, fourth level. Additional meta information may be helpful to describe the intended usage of the given product classification schema by suppliers etc., thus it describes requirements on the classification process. For instance, “mapping level=leaf only” would say that if a company adopts this product classification schema, then it has to assign products to classes on the leaf level only; “cardinality=multiple” would allow that a product can be assigned to more than one class (contrary to “single”). 5.1.3.9 Provide Update Information Since product classification schemes evolve and change over time, all adopters are forced to follow these changes in order to keep their classification and description up-to- date. This process of re-classification is time-consuming and costly, since it requires to check what has actually changed, and to alter class relationships and descriptions (adding new properties and values, changing property values, deleting properties etc.). Moreover, this supplier-managed process is necessary for each new version of all product classification schemes. In order to reduce the manual amount of work for re-classification, the organizations that develop product classification schemes should provide meaningful update information. The update information should be transferred with the same standard exchange format. In the best case, this information enables automatic re-classification. The ability to provide this update information is mainly influenced by the maintenance model and its version management concept. 5.1.3.10 Provide Mapping Information Considering the co-existence of, and competition between, a large number of product classification schemes, instruments that aim at integrating different schemes must be taken into account. If possible, similar or equal product classes and properties of two schemes can be mapped. This mapping defines a relationship between two items; based on this relationship, automatic product classification and description is made possible. The mappings may be extended to be very sophisticated, e.g. • at the class level, using operators of description logics • all the property level, using derivation functions.

Very similar to integrating different database schemas, the mapping process defines relationships between schema items (here: product classes, product properties). In this regard a mapping is a semantic relationship between one or more classes of a source classification schema and one or more classes of a target classification schema. The mapping types can be differentiated by looking at the number of classes participating in the source and target schema, thus the cardinality of the mapping. This concept leads to six mapping types: 1:1, 1:N, N:1, 1:0 and 0:1 as described in Table 1. The third column of that table states what effect such mappings have on automating the classification of product data. The N:M mapping reveals that the classification schemes to be integrated are based on two different structuring approaches; thus the classes are

26 CWA 15295:2005 (E)

built on complete different criteria. This mapping occurs when integrating an application- oriented to a characteristic-oriented schema.

Cardinality Definition Re-Classification Process 1:1 One class of the source schema is equivalent Automated to on class of the target schema. 1:N One class of the source schema is equivalent Semi-automated; to two or more classes of the target schema. target class has to be selected manually N:1 Two or more classes of the source schema are Automated equivalent to one class of the target schema. N:M Two or more classes of the source schema are Semi-automated; equivalent to two or more classes of the target target class has to be schema. The mapping is not decomposed into selected manually 1:1, 1:N or N:1 mappings. 1:0 The class of the source schema has no Classification not equivalent in the target schema. possible at all 0:1 The class of the target schema has no (not relevant) equivalent in the source schema.

Table 1: Mapping Types for integrating Product Classification Schemes In most cases, the mapping cardinality, which describes the number of classes participating on the left and right side, allows to draw conclusions concerning the semantic relationships between the classes. However, these relationships are not specified further. By adding relationship types we can support the development of mappings and the re-classification process as well: The relationship Super Class says that the scope of the target class is wider; thus the target class can be seen as a super class of the source classes. The relationship Sub Class says that the scope of the target class is smaller; thus the target class can be seen as a sub class of the source class. The relationship Identical Class means that the source and target class are identical regarding the scope and coverage of products. Finally, the relationship Similar Class describes another kind of relationships that do not belong to the previous types. Either such a relationship is not analyzed in full detail yet, or the decision whether the relationship type is Super, Sub or Identical Class cannot be made. The concept of relationship types allows in combination with the mapping cardinality a detailed description of the relationships between classes as summarized in Table 2 (not shown: relationship type Similar Class). Altogether we get a powerful but also complex instrument for developing mappings.

27 CWA 15295:2005 (E)

Cardinality Super Class Sub Class Identical Class 1:1 The target class is The target class does The coverage of both semantically wider not cover the source classes is identical. than the source class. class completely 1:N The sum of all target The sum of all target The coverage of the classes is classes does not source class and the semantically wider cover the source target classes are than the source class. class completely. identical, but the target schema differentiates the product domain by defining more than one class. N:1 The target class is The target class does The coverage of the semantically wider not cover the sum of sum of all source than the sum of all all source classes, classes and the target source classes. but the source class are identical. classes are not mapped to other target classes. N:M The sum of all target The sum of all target The coverage of the classes is classes does not sum of all source semantically wider cover the sum of all classes and the sum than the sum of all source classes. of all target classes is source classes. identical, but the two (sub-) schemes apply different criteria to define classes.

Table 2: Mapping Cardinality and Relationship Types The mapping as described before can also be applied to product properties. In this case, the mapping has to take the data types, value domains and units of measurement into account. In addition, the re-classification process consists not only of selecting the right property, but includes also the conversion of property values, if necessary. Mapping is also important to enable cross-industry communication by mapping vertical to horizontal product classification schemes and vice-versa. In the context of the long- term goal, the mapping is an instrument to migrate existing product classification schemes to a common structure. The guidance is to provide mapping information, if this is part of the business model behind the product classification scheme. The mapping information should be transferred with the same standard exchange format. In general, the mapping concept helps to integrate different schemes. However, the definition of these mappings is a

28 CWA 15295:2005 (E)

critical effort, and often not possible due to different approaches, or less correctness, dependability, and lifespan of these mappings. 5.2 Reference model for maintenance For the goal to describe the different approaches in this report, we requested the mentioned organizations in this chapter to explain their maintenance procedure of their product classification or description schema. The response was quite poor, the descriptions were structured very differently. 5.2.1 IEC 61360-3 The IEC 61360-3 Maintenance procedure identifies the following actors: • Customer • Validation Agency, • Validation Groups, • Maintenance Agency. The basic goal seems to ensure a fast response to the requests of these actors Maintenance Activity The Maintenance Activity covers mainly the operational aspects of the maintenance of the reference collection. It is making its contents available to registered users, and manages the distribution lists of the assigned experts of the Validation Groups. Validation Activity The validation Activity checks a request if it is compliant with the basic business rules (data format, copyright, …). This activity checks a request on its attributes with respect to completeness and makes a recommendation to the Validation Agency. The Validation Agency validates the request based on the observations / recommendations of the Validation Groups

29 CWA 15295:2005 (E)

Figure 5 - IEC 61360 Maintenance Approach

5.2.2 ISO 13584-501 The ISO 13584-501 Maintenance procedure identifies the following actors: • Technical experts, • Secretary of registration authority (SORA), • National Representatives as member of ISO body

30 CWA 15295:2005 (E)

Exp er t s i n T C SORA Exper t s i n VC ISO Member Body

Not if y Nat ional Assign National Register expert ise Represent atives Represent atives Acknowledge Acknowledge Propose an it em Acknowledge A Formalit y check Rej ect B Formal registration of application Circulat e a Prepare TC submission TC submission wit h in a week for provisional BSU’ s C circulation Study it ems & vot e in 3 weeks Vote & comment Prepare a VC D submission in 2 weeks Not i f y t he r esul t s for approved items with of vot e formal BSU’ s E Circulate VC St udy it ems & submission vot e in 2 weeks Vote & comment F Not i f y t he r esul t s Notify the results May r epor t on of vot e in 2 weeks G of vot e in 2 weeks Vot e & comment

Release int ermediat e Update and maintain dictionary versions of dictionary for review H Cir culat e a dr af t f or Prepare draft formal release, once or twice a year I St udy it ems & Vot e for adopt ion of vot e in 2 a formal release J weeks May negotiate with VC K for comment solution Notify t he formal release of a new dictionary once or twice a year

Figure 6- ISO 13584-501 Registration Timefame

31 CWA 15295:2005 (E)

TC SORA VC ISO member body

Notify Set up RA Assign National Represent at ive

Regist er Notify National Exper t Represent at ive

Rej ec t ed i f i dent i t y Returned if identify check failed check failed Technical Expert Accept if Nat ional Represent at ive Identif y conf irmed Acknowledge & Set up TC Not if y account & Notify account & password password

A Regist er It em Propose item for Dictionary Element Rejected if mandatory pieces of information are not fed B Accepted if formality is ok C St udy t he it em Circulat e It em

D Issue formal Vote & BSU for Comment Appoved it em

E Not ify Result

disapproved Technical Expert Approved if majority F of votes agree

Circulat e It em St udy t he it em

Updat e & Maint ain Vote & Dict ionary Comment

G Not ify Result

disapproved

Approved if 2/ 3 Nat ional Repr esent at ive Technical Expert of votes agree H Not ify Int erim Release Adopt New I Not ify Formal Formal Release Release

Figure 7 - ISO 13584 - 501 - Registration flow

32 CWA 15295:2005 (E)

5.2.3 eCl@ss

questions/discussion proposals to/with proposer (e.g. new commodity class)

eCl@ss eCl@ss revision secretariatsecretariat archive objektive declined archive internal forum objektive eCl@ss decision by proposal internal forum objective verification eCl@ss decision by eCl@ss objective verification adjusted eCl@ss allocation by expert adjusted eCl@sseCl@ss change- change- change commitee allocation by expert proposal change commitee groups proposal commitee groups commitee

assumed proposal

eCl@sseCl@ss - - developer developer edition edition

newnew release release

Figure 8 - eclass Maintenance ApproachUNSPSC Maintained by EAN/UCC Global Standards Management Process for maintenance

Figure 9 - UNSPSC Maintenance Approach

33 CWA 15295:2005 (E)

5.2.5 ECCMA eOTD Code Management Process Manages a process that answers two simple questions: • Does the code fit the design rules? • Is the code duplicative? The ECCMA process is based on the Delphi Method, it uses the Internet to harness global expertise in the development and maintenance of the ECCMA Open Technical Dictionary. Participation from over 1200 members from 47 countries

Members

Internet based request for code addition or re-classification

Secretariat Notify TAG TAGTAGTAG Deletion or edit Design rules com pliance Yes YES Originator of membersmembersmembersmembers of existing code check record vote votevotevote Responses are collated and recorded

NO

Request sent to NO Secretariat Secretariat TAG members by Procedures Review Definition development selected interest category

Approved

Yes Response returned NO to sum bitter New code with recomendation to created correct or use an existing code

To language New code translation added to database

Figure 10 - ECCMA eOTD Code Management Process Flow

5.2.6 Conclusions on Maintenance Procedures In general the maintenance models are highly internally focussed, mainly on adding new properties or class definitions. Sometimes they are defining a process for balloting changes. None of the investigated models are focussed on interoperability. We identified some criteria to mention for each maintenance procedure: • voting process, how to become a nominated expert, ... • how quality insurance of quality is covered in the maintenance model • whether the process is based on commonly agreed (standardized) rules • whether the result, i.e. the content of the dictionary, is a standard • whether the process is capable to reference properties or classes of other dictionaries to avoid duplication • who is holding the copyright of the maintained properties and class definitions.

34 CWA 15295:2005 (E)

The criteria used for the maintenance procedure of ePDC are described as rules for the operation of a joint committee in chapter Rules for the Operation of a Joint Committee. 5.2.7 Proposed ePDC Maintenance Procedure It is suggested to use a procedure which is very similar to ISO directive 1. Therefore it is assumed that each managed item (e.g. class, property, value, etc) will follow a route from “start” to “end” in the state transition diagram below. (Note: The states used for the items are derived from ISO guide 69).

Start Proposal is registered anony mous

00.00

Proposal in discussion

Initiation of discussions

00.20

Decision to proceed to ev aluation

00.99 Proposal ready f or ev aluation

Registration of proposal f or ev aluation Proposal is registered f or ev aluation Decision to abandon 10.00

Drafting by operating organization Proposal is abandoned

Drafting started 20.20

Registration of draft as comitee document 10.98

Is comitee document 30.00

New draf ting Circulation f or enquiry Is circulatied f or enquiry 40.20 Stop

Objection Enquiry is closed Close of enquiry

40.60 Decision to abandon Is abandoned Decision to register for next phase 50.98 50.99

Is registered f or next phase Made av ailable

Stop Is av ailable

60.60

Proposal for withdrawal registered

Proposal f or withdrawal is registered Stop 95.00

Document rev ised or superseded Approv al f or withdrawal

is withdrawn is rev ised or superseded 92.60 99.60

Stop Stop Figure 11 – Suggested ePDC Maintenance Procedure

35 CWA 15295:2005 (E)

5.3 Requirements to ePDC data model 5.3.1 Unique identification of each property / class While creation of an ontology is a very expensive and time consuming process, there is need to reference classes or properties of other ontologies. This implies the need for an associated worldwide uniquely defined source of each property or class. We will reference this relation as identified_by an originator. 5.3.2 Reference to other ontologies / equivalency definitions For example, in creation of product class or description of an industrial measurement instrument, which has electric input/output connectors, it makes sense to reference the appropriate properties or concepts of the IEC electronic components dictionary. There is a need to have a mechanism to reference properties and classes from other dictionaries or ontologies. We will reference this relation either as • is_case_of (which declares two properties/classes equivalent) or • import_in (which imports a property without any modification, not even the originator.). 5.3.3 Distinguish Product Classes and Categories Though many prominent approaches like eCl@ss, UNSPSC are built around a hierarchy of product and service categories, this is not a compulsory feature. The key functionality is the representation of business meanings (e.g. a product or service) in an unambiguous, machine processable manner. This need not reach as far as a true ontology, which usually contains a formal definition of each concept’s properties (including its relationships to other concepts in the ontology). For many business applications, it is sufficient if the concepts behind the entries are defined in a semi-formal way or even in natural language. In other words, the semantic richness of the entries is not as important as the semantic precision. [Hepp 2003]. In contrast this CWA sees the need to define properties including their meaning as formally as possible. A natural language (e.g. English) description of a product requires that someone who understands the natural language utilizes knowledge of the language and some knowledge about the product being described to understand the description. This approach is not computer sensitive, since computers do not understand natural languages and do not have knowledge about products. To make some concepts computer “understandable”, knowledge representation society uses the term “ontology”. Putting properties to Product Classes or List of Characteristics (see 4.3), which is then enriched by a definition is the first step towards an ontology description of the products. All major classification systems are doing this UNSPSC and GPC, eCl@ss, RosettaNet, ….

36 CWA 15295:2005 (E)

Then the List of Characteristics can be categorized either by numerical classification keys and/or put together more formally thus forming a product ontology. In the scope of this document we assume the following items are needed in electronic processing of product classification and description • classes, which are abstractions of a set of products associated with a term and definition forming a concept that represents the set of abstracted products. • class-specific lists of characteristics which contain only references to characteristic properties, to support more precise product descriptions without an inflationary amount of properties. • the classes and properties may be put together to form an ontology of commonly reusable concepts and properties; • optionally one or many hierarchically organised group numbers assigned to each class (or maybe only to some classes), to comply with existing product classification systems. 5.3.4 Separate Property Definition and Application The biggest challenge is to define clear semantics of classes and properties. Especially considering different initiatives nowadays that are already defining sets of properties for classes in conventional product classification for eCommerce (e.g. ecl@ss, proficl@ass, ..) and multiplying these with the number of company-specific product classifications, the problem becomes evident: we are already on the way to different property definitions with the same or, even worse, with only similar meaning. If it is not possible to avoid duplicate property definitions the total number of property values will increase drastically! It is evident that the lack of such semantic distinctiveness will require immense efforts before gaining benefits from usage of properties in product classification. The only solution to solve this discrepancy is separation of property definition scope and property application. 5.3.4.1 Property Definition Scope Property definition scope has the goal of defining a semantically clear meaning of a property. Property definition scope has no interdependency with product classification, but it allows to check, if a property’s application (see below) is done in correct semantics. For example the property “thread diameter” and its definition and value domain will be defined for a class thread without considering its later application for screws, nuts, diodes, … . This allows electronic systems to recognize one property being identical even it gets assigned values in different application. Clean property definitions, including scope have to be based on consensus and need to be standardized following exact rules [DIN 2003, IEC 61360-4 1997]. As a result, well defined standardised properties with formerly agreed meaning will be published and can be referenced by their identifier.

37 CWA 15295:2005 (E)

Example property definitions are IEC 61360-4, or the German online dictionary www.DINsml.net. We will reference this relation as name_scope. 5.3.4.2 Property Application In contrast property application is the process of using well defined properties in the list of characteristics of one or many product classification systems or using them as input/output parameters for other product models. Property application is not only relevant for different product classifications systems. Its scope explicitly includes connecting different applications or processes during the product lifecycle as well. Following the practicable scheme of property based product description leads to interlaced classification systems for different application domains. Different product classification structures are built based on the existing properties of the products. The main application of a property based product description is its usage in processes such as • Requirements specification • Recycling • Digital Catalogues • Engineering Design Classes The concept of property application compiles the class-specific lists of characteristics which contain references to characteristic properties of a concept (class) which is used in any product classification system which distributes also properties. Note: The application of a property requires either that the class where the property shall be applied is either inside the name_scope or imported in the class (see relation: name_scope, import_in). We will reference this relation by the described_by relationship. 5.3.5 Abstraction by use of more generic classes The idea is to use the concept of generalisation / specialisation to express the meaning, that some concept is a specialized meaning of some other concept. We will reference this relation by the described_by relationship. More generic product classes are useful in case of a methodical design approach in which a designer defines the use of a generic part for example “roller bearing” within a bill of material, at an early stage of the design when no concrete part can be specified. A generic “roller bearing” can then be replaced by the designer with a more specific bearing (e.g. “drawn cup needle roller bearing” or “cylindrical roller bearing”) at a later point in time depending on the individual requirements of the current design. This leads to some taxonomy for a specific rule to build the relationship.

38 CWA 15295:2005 (E)

Rolling Bearings

nB: Limiting Speed C: Basic dynamic load

C0: Basic static load

Radial Rolling Bearings

d: Bore diameter D: Outside diameter B: Width

Drawn cup needle Cylindrical roller roller bearings bearings

Fw: Inscribed enveloping circle diameter Fw == d C == B 1 Figure 12- Example of a class structure

This approach leads to a tree, where each node represents abstractions of a set of products, while the child nodes, or “sub-classes” are subsets of the set of products. Hence each product instance classified as a member of a class in a taxonomy is also a member of the parent classes of that taxonomy. Please note, this hierarchy tree may not be mixed with the hierarchical structure of classification systems. In contrast, this class - subclass tree is a relation between classes with a very special semantic meaning. 5.3.6 Domain Restriction for Properties. Properties can be seen as any text. This way to describe properties has a very small element of semantics. Properties could also have a simple data type assigned, for example number, text, date, time, etc. In other words this is a description of the set of allowed values for that property. Modelling a property using this relationship increases the semantics of properties. Additionally the semantics is further enriched if the property has a set of defined allowed values in an enumerated description, or in any other description, like calculation by a formula. We will reference this relation as has_domain relation. 5.3.7 Dependencies of Properties on other Properties Some properties depend on certain other properties or conditions. For example, the property “phase speed of light” depends on the media and the wave- length. The rainbow colours appearing if light passes a prism are a well known representation of that fact. Sometimes these physical phenomena are also used to find out the components of gas. In this case the temperature, pressure and volume of the gas are also impacting the “phase speed of light” in gases.

39 CWA 15295:2005 (E)

To express this dependency of a property as part of the property, it is a requirement to distinguish the property “phase speed of light” which depends on the medium and wavelength and one depending on gas conditions. Adding the relationship between a property and the properties or conditions it depends on, increases the semantics of the property. We will reference this relation as depends_on relation. 5.3.8 Properties expressing abstractions Some classes are built around certain functions, materials, etc. for the items the class is an abstraction of. For example, two instances of products which are classified into a class are distinguished from each other by the material they are made of. So we need a property which encapsulates the abstraction of the material. This can be performed by referencing the class, which abstracts the material by a property of the class. Again this relation increases semantic, in this case of the class. We will reference this relation as abstracted_by relation. 5.3.9 Properties expressing Product Composition / Aggregation For complex products, which are built around product composition, the semantic is increased for a class, if we know where the class is built in. As an example: If one is looking for an engine to drive a conveyor belt, this is a much more specific requirement than simply looking for an arbitrary “engine”. Moreover the complexity of industrial products requires for product description that complex products are composed of the aggregation or the composition relationship. To model the product composition / aggregation allows to build another tree which is based on the consists_of or part_of relationship. 5.3.10 Distinguish General Model from Functional Model throughout the value chain The product class hierarchy serves as a search hierarchy to the technician and as a representation of market structures to the purchaser at the same time. Their requirements are not identical, but they are not in true contradiction either. Therefore, it is needed, if we want to satisfy the procurement as well as the manufacturer or even the designer (CAD-CAM...) to group the standardized set properties into functional representations that are relevant for each phase within the supply chain (from creation to sales to the consumer).

40 CWA 15295:2005 (E)

Common General Model

(List of Characteristics)

View Procurement View Sales

View Inventory View Recycling View manufacturing

Figure 13 – Functional Models and Common General Model

Functional models prevent a long list of properties that are difficult to search and use; it is not impossible, for a product that comprises different parts to finish with hundreds if not thousands of properties. These functional classes are necessary to avoid a too long list of properties, and help each part of the supply chain to find its own properties list. This concept will be refined with time and new classes incorporated whenever the need comes to the surface. 5.3.11 Categorize / Classify Properties To avoid duplication of properties, the guidance is to implement a possibility to add properties to categories, to allow more easy description of properties having similar semantics, e.g. it is possible to add a category about the measurement method or the physical phenomena it depends on. This can be done by means of a specialization mechanism. 5.4 Conceptual ePDC Model On basis of the requirements the following conceptual ePDC data model was created. It expresses all entities and relationships required for Product Description and Classification in the scope of ePDC on a high level of abstraction. No administrative items (especially compared to PLIB: BSU concept) are part of the conceptual ePDC model.

41 CWA 15295:2005 (E)

MESSAGE

SUPPLIER + IDENTIFICATION

1 1 1 PRODUCT CLASS

0..* 1

CLASS VALUE ASSIGNMENT 1 1 0..* 1 PROPERTY DICTIONARY ELEMENT

1 0..* 1 VALUE 1

DOMAIN 0..* 0..* 1 Class instance type TERMINOLOGICAL ENTRY

1 0..*

LANGUAGE SECTION

Figure 14 - Simplified ePDC data model

5.5 Standardized Basis for ePDC data model To fulfil the above requirements investigation of existing standards were made. • ISO 11179 • ISO 13584 • ISO 15926 • IEC 61360 The selection for the most appropriate standard for the ePDC data model should be done on the following criteria • Availability (International Standard; DIS, FDIS) • Semantic richness • Political support • Available processing systems • Available content The goal is to suggest the selected standard to create an ePDC exchange format, while recommending any possible improvements to the relevant standardisation body.

42 CWA 15295:2005 (E)

5.5.1 ISO 11179 ISO/IEC 11179 describes the standardizing and registering of data elements to make data understandable and shareable. Data element standardization and registration as described in ISO/IEC 11179 allow the creation of a shared data environment in much less time and with much less effort than it takes for conventional data management methodologies. The purpose of ISO/IEC 11179 is to give concrete guidance on the formulation and maintenance of discrete data element descriptions and semantic content (metadata) that shall be used to formulate data elements in a consistent, standard manner. It also provides guidance for establishing a data element registry. 5.5.2 ISO 13584 The following sentences are from an ISO TC 184/SC4 WG2 document: ISO 13584 (PLIB) Approach Overview Modeling, exchanging and integrating computerized libraries/catalogues that describes families of reusable parts, together with their behaviour, selection process and application-oriented representations. Reusable part is an abstraction of a number of parts considered as identical. PLIB is not concerned with the life cycle of one individual part once it has been selected and used in some context. PLIB distinguishes between the PLIB dictionary level where the concepts of the reusable parts are defined, and the PLIB library level where sets of reusable parts are described according to the concepts of the dictionary level (PLIB dictionary is also often called an "ontology", PLIB library is the model of a catalogue) [ISO TC 184/SC4 ISO 15926 Task force 2004] For ePDC only the PLIB dictionary is the relevant part. Additionally in the same document, the scope of PLIB is defined: PLIB scope When modelling the domain of parts libraries and catalogues, three levels of objects appear: Class level: objects that describe concepts like classes and properties Part level: objects that describe interchangeable products, materials, etc. Levels of individuals: objects that describe individual items like a specific product which I have bought. Relationship between these levels is a kind of instance_of relationship, i.e. an element of the lower level is an element belonging to the abstract set defined by corresponding element of the next higher level. EXAMPLE - Individual: The office chair on which I am just sitting while I write this sentence Part: The office chair type XYZ of company A which has a maximum height of 70 cm and 5 rolls

43 CWA 15295:2005 (E)

Class: The class of office chairs which are specified among other by properties height and number of rolls

PLIB dictionaries deal only with the class level, PLIB libraries deal with representing the Part level, and PLIB does not represent the individual level. What is in PLIB scope? Building shared and identified conceptualizations of part classes and properties • Exchanging shared conceptualizations of part classes and properties • More broadly, building and exchanging shared and identified conceptualizations of domains where the PLIB dictionary model appears well suited • Modelling and exchanging catalogues of parts (or items) whose conceptualization is defined as a PLIB dictionary • Modelling and exchanging (reusable) parts that consist of a set of other (reusable) parts What is not in PLIB scope • Individual products with their specific life cycle (but life cycle properties might be defined by means of a PLIB dictionary) • Internal parts with their specific life cycle, once they have been selected • Complex part structure with other relationship than whole/part • Definition of technical/conceptual terms that are not classes or classes properties 5.5.3 ISO 15926 ISO 15926 is currently being developed by ISO TC 184/SC4. Today, a process of justification and harmonization with ISO 13584 is ongoing. The following paragraphs are quoted from a task force report for this harmonization process: Information concerning the engineering, construction and operation of oil and gas facilities, process plants and power plants is created, used and modified by many different organizations throughout the life cycle. Economic, safety and environmental considerations demand that this information is available to owners and operators of facilities, contractors, and regulatory bodies in a consistent, integrated form. This requirement can be satisfied by specifications that prescribe the structure and meaning of data that is shared by organizations and disciplines involved in all stages of a plant’s life-cycle. By using a consistent context for data definitions, the information used in the various aspects of the plant’s life-cycle can be brought together. This allows information to be integrated, shared and exchanged in a consistent, computer processable form. Data integration means combining information derived from several independent sources into one coherent set of data that represents what is known. Because the independent sources often have overlapping scopes, combining their data requires the common things to be recognized, duplicate information to be removed, and new information represented. To succeed in the role of integration, the data model must have a context that can include all the possible data that might be wanted or required.

44 CWA 15295:2005 (E)

The purpose of ISO 15926 is to facilitate such integration of data to support the life- cycle activities and processes of oil and gas facilities, process plants and power plants. To do this, ISO 15926 specifies a data model that defines the meaning of the life-cycle information in a single context supporting all the views that process engineers, equipment engineers, operators, maintenance engineers and other specialists may have of the plant. This requires data about components/parts to be available in a computer processable form for incorporation into plant designs and requirements, i.e. such data must be integrated in the same context. This representation is specified by a generic, conceptual data model that is suitable as the basis for implementation in a shared database or data warehouse. The data model is designed to be used in conjunction with reference data, i.e. standard instances that represent information common to a number of users, oil and gas facilities, process plants and power plants, or both. [ISO TC 184/SC4 ISO 15926 Task force 2004] 5.5.4 Comparison and Decision for usage ISO 11179 is a means for self-describing of data-models. For example it is possible to register any entity or attribute or concept of the ePDC data model (model M) according to the ISO 11179 registry, to give a clear formal description of the words of M. ISO 11179 is from that perspective not comparable with the other candidate standards. From point of view of ePDC, ISO 15926 is a model of type M, it uses EXPRESS as language L. Its scope is very broad, which restricts of course semantics. ISO 15926 is commonly used in the oil and gas industries. Some parts are available as an International Standard, other parts are at the state of a Draft International Standard. ISO 13584 is also a model of type M, which uses also EXPRESS as language L. In contrast to ISO 15926, it is designed for exactly the scope ePDC expects of model M. The semantics contained in ISO 13584 to describe an ontology of properties and classes are greater than ISO 15926. Since the data model is identical to IEC 61360-2, this is in effect fairly accepted and therefore available as both ISO and IEC standards. In general it should be possible to model the entities and relation of ISO 13584-42 also by means of ISO 15926. Both standards are developed by ISO TC 184 / SC4, so we expect harmonization to be done by ISO TC 184 / SC4. Hence we start modelling of the ePDC model by ISO 13584 and assume harmonization by TC 184/SC4 will happen in the future. 5.6 UML representation of ISO 13584-42 Data model This chapter presents a manually created UML representation of the ISO 13584-42 data model. It is based on ISO 13584-42 and was completed by texts and explanations. The following rules were applied to convert the ISO 13584-42 model from EXPRESS representation into a UML class diagram. • Leave model structure as it is and do not change the entities, except the following:

45 CWA 15295:2005 (E)

• Names of the entities, were changed to functional names. The original names are placed in comments • Restrict the type system to: named_type, simple_type, placement_type, class_instance_type, level_type, since we recommend to rework the type system in order to comply with ePDC requirements (see section Recommendations) • To keep the model more easy, the following EXPRESS entities are modelled as complex types, which are not shown in the UML model. • Document • Graphics • Mathematical String • … The following steps were performed to convert the ISO 13584-42 model from EXPRESS representation into a UML class diagram. 1. Find all model attributes. 2. Create an UML class diagram. Attributes having the EXPRESS specifier SELF, are inherited attributes and a specialisation of type. This type of specification will be avoided in the UML class diagram. The Type specialisation is added as a rule 3. Attributes in ISO 13584 that express a relationship are modelled as relationships in the UML class diagram 4. DERIVE statement and WHERE rules will be skipped from the model and introduced as Business rule into the UML model. 5. INVERSE Statements are part of the Relationships and not separately added to the model.

46 CWA 15295:2005 (E)

•1 •SUPPLIER BSU

•1 •MATHEMATICAL STRING •CLASS BSU

•VALUE TYPE •1•0..* •PROPERTY BSU

•BUSINESS OBJECT •0..* •DATA TYPE BSU •0..*

•1 •0..* •SUPPLIER RELATED BSU •CLASS VALUE ASSIGNMENT

•1 •1 •0..* •CONTENT ITEM •BASIC SEMANTIC UNIT •CLASS RELATED BSU •0..* •1 •1

•1 •1 •ITEM CLASS •COMPONENT CLASS •CLASS BSU RELATIONSHIP •0..*

•1 •1 •1•0..* •MATERIAL CLASS •SUPPLIER BSU RELATIONSHIP •0..* •CLASS

•1 •SUPPLIER ELEMENT •CONDITION

•1 •CLASS AND PROPERTY ELEMENTS •PROPERTY •DEPENDENT PROPERTY •1

•1 •0..* •NON DEPENDENT PROPERTY •0..* •1 •DATES •DICTIONARY ELEMENT •DATA TYPE ELEMENT

•1 •1

•SYNONYMOUS NAME

•0..* •1 •1 •1 •1 •1

•DATA TYPE •1 •0..* •1 •0..* •ITEM NAMES •TRANSLATION •LANGUAGE

•0..* •1 •0..*

•1 •1 •1

•1 •0..* •SIMPLE TYPE •COMPLEX TYPE •NAMED TYPE •VALUE DOMAIN •VALUE

•NUMBER TYPE •BOOLEAN TYPE Class•STRING instance TYPE •CLASS type INSTANCE TYPE •LEVEL TYPE •ENTITY INSTANCE TYPE •1

•0..* •INTEGER TYPE •REAL TYPE •NON QUANTI TATIVE CODE TYPE •PLACEMENT TYPE •LEVEL

•INTEGER MEASURE TYPE •REAL MEASURE TYPE •AXIS1 •AXIS2 •AXIS3

•INTEGER CURRENCY TYPE •REAL CURRENCY TYPE

•NON QUANTI TATIVE INTEGER TYPE

Figure 15 – UML of ISO 13584-42 data model

Investigation showed, that the ISO 13584-42 data model fulfils nearly all requirements for product description and classification in the scope of ePDC. Therefore we have chosen that the UML representation of PLIB done by ePDC will be the called ePDC data model and serve as a Reference Information Model (RIM) from which exchange formats can be derived. 5.7 Methodology to Derive Exchange messages 5.7.1 Defining message types Before defining the required message types, one should first get a rough idea of the business process. A process model of the interaction and information exchange between internal and external business partners gives a clear perspective of the business process. At this point it can be discussed how the business process can be optimized (Business Process Redesign), by designing and specifying clear procedures (transactions) between the internal and external business partners. Each procedure uses several

47 CWA 15295:2005 (E)

message types. Each message type stands for a specific functionality of information exchange. For each message type a functional and technical message specification needs to be developed. The combination of the functional and technical specifications is called an exchange format. Because we did not analyze all business processes where product classification data has to be exchanged, we developed a generic structure in which product classes, properties and data types can be exchanged all at once or independent of each other. From this structure subsets for specific purposes can be defined easily. 5.7.2 Development of exchange formats The most important step in the development of exchange formats is the development of the functional message specifications. Each message type should have a clear function in the business process and should therefore contain certain data. The functional message specification defines – in a functional manner – the structure and content of a message type. In a functional manner means, that at this stage we don’t care about the technical syntax (e.g. EDIFACT or XML) that will be used to transmit the message. All business partners should agree on the functionality and logical content of the message types. For the development of the exchange formats, we used a methodology that is described in ISO 17113. This standard says that the basis for the specification of a messaging standard is a Reference Information Model (RIM) that completely covers the domain being addressed. All messages and related activities must be derived from the RIM. We used the ePDC model (see Figure 15 – UML of ISO 13584-42 data model) as the RIM to derive our messages. 5.7.3 Develop functional message specifications For each message type the content of the message needs to be specified. To understand the information that will be used in the messages, it helps first to create a relational data model that models all the information in all the messages and then to create a hierarchic model to specify the functional content of the messages. A practical approach is first to create one big hierarchical message (called transaction) that covers all the functionality of all the functional messages used in the transaction and then create a subset for each functional message. After specifying the content of the messages, for each message we can choose which syntax will be used to transmit the messages. The available syntaxes are for example EDIFACT, XML and flat file format. 5.7.3.1 Define relational data models / Repositories The first step is to build the relational reference information data model (RIM). Then the entities, the relations between those entities, attributes, domains and code-lists are defined. It is important that the definitions of all objects in the RIM are specified.

48 CWA 15295:2005 (E)

Figure 16 - Example of a relational reference information model

5.7.3.2 Make a selection The next step is to make a selection of entities and relationships that will form the basis of the transaction (hierarchical) model. The entities and relationships drawn in red are selected to take part in the transaction data model. An additional entity that will act as the root of the hierarchic model is required. In Figure 17 the entity 'TRANSACT' has been added to the entities from the relational data model. This entity can be used to model header data, as in our case, for example, the name and version of the classification system.

Figure 17 - Make a selection from the relational datamodel

5.7.3.3 Add relations to the root entity It is required to be able to connect the root entity to some of the selected entities from the relational data model. In Figure 18 two extra relations have been added from the 'TRANSACT' entity to the entities 'A' and 'G'. Furthermore, existing relations should be selected to connect all the entities that are part of the hierarchic data model.

49 CWA 15295:2005 (E)

Figure 18 - Add relations to the root entity

5.7.3.4 Specify directions, status and repeat of relationships Next, a direction must be specified for each selected relationship in order to specify the hierarchic (transaction) data model. Furthermore, the cardinality and the status (required, optional, dependent, not used) should be defined for all relationships.

Figure 19 - Specify directions of relationships

5.7.3.5 Specify status of attributes Finally, each attribute in each entity in the hierarchic data model is given a status. If an entity from the relational data model occurs twice or more in the hierarchical model, the attributes are given a status for each occurrence separately.

50 CWA 15295:2005 (E)

Figure 20 - Specify status of attributes

5.7.3.6 Specify subsets Part of the data modeling requirements for message development is the specification of a subset of a hierarchical (transaction) data model into different message subsets. This means that the status of entities and attributes can be tightened, which means that objects with an optional or dependent status in the transaction data model can get a required status in the message subset. The cardinality of a hierarchic entity in the message subset will always be less than the cardinality of the same entity in the transaction data model. We used a message development tool that takes care that the message subsets will always be a correct subset from the transaction data model. 5.7.4 Develop technical message specifications Many exchange syntaxes exist that could be used to exchange the product classification data described in the functional message specifications: flat files, EIDFACT and XML. Depending on the syntax chosen, some further activities take place to map the functional message specification onto the technical syntax standard chosen. This results in a technical message specification. 5.7.4.1 Specify flat file For specifying a flat file, one should specify the flat file type: delimited or fixed record. For a delimited flat file, the field and record delimiters should be specified. Each record in the flat file is identified by a unique record tag. A unique record tag for each record will be specified in the technical message specification. Technical rules for the use of the flat file should be specified: the alignment of values in the fields (alphanumeric data left, numeric data right) and how empty values are represented.

51 CWA 15295:2005 (E)

5.7.4.2 Specify EDIFACT mapping When choosing for EDIFACT, a mapping from the hierarchical model to an EDIFACT United Nations Standard Message (UNSM) should be specified, with special attention for qualifier handling and repeating composites. 5.7.4.3 Specify XML tags XML tags can be generated for the hierarchic model that has been defined. Furthermore, also a correctness check of the XML tags can be performed. It is desirable not to define XML tags duplicated. Furthermore, there may be a maximum length defined for the XML tags. The XML schema that represents the technical view of the function message specification can be generated and used as a technical specification of the message.

52 CWA 15295:2005 (E)

6 Recommendations 6.1 ISO 13584 / IEC 61360 6.1.1 Ease structure of ISO 13584 series of standards We recommend to simplify the structure of the ISO 13584 series of standards, to allow comprehension and implementation of a certain set of requirements. As an example the different parts 24/25/42 and different conformance classes within ISO 13584-25 complicate the implementation. Consider unification of the different parts and group it more logically (e.g. make one part for the complete dictionary model). 6.1.2 Make the ISO 13584 data model more comprehensive The complexity of the data model is very high. Although to ease the model can reduce semantics, for the sake of easier understanding it will help if the model was simpler. We recommend to add a conceptual model to ISO 13584 and refine it. As an example the ePDC simplified model could be a starting point. 6.1.3 Consider following changes on the 13584 data model • Enumeration should be possible for all types • We recommend to add a non-abstract Graphics / Document representation to PLIB model. • Change the name of the entity “SUPPLIER” into “OWNER” to prevent misinterpretation of term supplier, which is used as an actor in the ePDC use case diagram [like in natural language]. • Recommend to model the property data-types not as specialization of property, but either derived from usage of a property (part of depends_on relationship) or as an addition attribute to property, to indicate that the property can be / or is a condition, dependent property, or non_dependent_property. • Recommend to model the various subtypes of class (Component class, Material Class) not as specialization. • Recommend to model the various subtypes of property not as specialization. • Move functional model classes from part 13584-24 into the scope of the ePDC model. • Move reference mechanism from part 13584-24 into the scope of the ePDC model. • Add two computer sensitive GUID’s, one to identify an item and one that identifies the combination of item and version. This will increase flexibility and performance when synchronising dictionaries.

53 CWA 15295:2005 (E)

6.1.4 Make ISO 13584 data model fit data exchange If the current ISO 13584 model is used as a RIM for the development of the ePDC exchange format, this leads to a lot of unused entities in the exchange format. The PLIB model has many entities and relationships, but only a few attributes. We advise to simplify the PLIB model, so that it is easier to understand and more suitable as a RIM to derive exchange formats from it: • reduce the number of “is_a” relationships by merging entities • take out the BSU part of the model and replace it with one generic entity that defines how objects are identified (see ISO 11179) • replace entities and relationships with attributes where possible • leave out entities that are not used in part 42 of ISO 13584, and define them in the part where they are used (for example entity CLASS_BSU_RELATIONSHIP). 6.2 Define exchange messages The goal of Data exchange can only be reached if well defined exchange messages with known sets of included entities are defined (see chapter Annex B – ePDC Generic Exchange Format Hierarchy). 6.3 Define a XML message format To allow real world implementations, define at least a XML format for the messages.

54 CWA 15295:2005 (E)

7 Rules for the Operation of a Joint Committee This section describes very briefly rules for the operation of a distributed joint working committee that would be in charge of implementing and maintaining the product classification schema as proposed by the ePDC project. It is intended to further refine the rules and conditions for the work of the joint committee during the ePDC2 project after consideration of gained experiences. Members It is important that the Joint Committee comprises high level responsible persons from the main horizontal Classification schemas, as these will have to take decisions that will impact strongly the Classification schema under their management. We therefore propose that the Managers of GS1, eCl@ss and UNSPSC (or their representatives in case of absence) be part of the joint Committee. As the main rules for designing and implementing a good Classification schema (see chapters 5 and 10) are based on an international standard (ISO 13584/IEC 61360), it is mandatory to also include one of the representatives of ISO TC 184 SC4 WG2 in charge of these standards. Part of the committee may also be national and international standardization bodies if they request membership. As the main rules for designing and implementing a good Classification schema (see chapters 5 and 10) are based on an international standard (ISO 13584/IEC 61360), it is mandatory to also include one of the representatives of ISO TC 184 SC4 WG2 in charge of these standards. We also propose that some active managers of vertical Classifications (Furniture, Shoes, Construction?) be part of this Committee. Finally, the Convenor and the Classification expert chosen during the second phase of the ePDC project (ePDC2) are also mandatory members of the joint Committee. The Convenor of the ePDC project is automatically Chair of the Committee. Voting process It is recommended with respect to the voting process to adhere to already existing channels of the national standardisation bodies. When a voting process is necessary (because e.g. a consensus – the normal way – has not been obtained), it’s the majority of the votes of the present members of the joint Committee that will guide the decisions. Quality insurance Quality insurance is optimised when the proposals are made publicly available for comments to the public and national bodies for a period of at least 60 days. In particular, the national bodies collect the comments from local people and organizations and direct the result from this to the working committee. What is the standard It is recommended that the identification and the description of all managed items are standardized. The reference will be the ISO 13584/IEC 61360 standard, as well as the first CWA that has been publicized with the present CWA with Terminology as main concern.

55 CWA 15295:2005 (E)

Referencing mechanism It is recommended to obtain agreements from other classification organizations in order to be able to reference some interesting items maintained by them, to avoid duplication or to have the best of all. Copyrights Basically, all Classification schemas do retain the copyright of their own terms and data. It is strongly recommended that all Classification schemas be openly available, e.g. by download from a website. This is already the case, since the beginning, of eCl@ss, which provides a free (= at no cost) downloading of the last version of their Classification. Since a few months, GS1 has moved from a paying membership agreement to a freely available Classification, at no charge. To our last knowledge, UNSPSC still requests a membership. The copyright rules should be further refined during the second part of the ePDC project, taking into account the possibility (free of charge or with payment) for a commercial company (e.g. a software vendor or catalogue company) to integrate the Classification schema in its offerings; further, it should be debated if changes can or cannot be brought to the schema, in full or in part. The present tendency, to retain homogeneity of Classification schemas, is not to authorize changes, but preferably to enter some change requests in the Organization for incorporation in a further revision of the schema. When analyzing the situation in International Organizations, the situation is very variable. Examples of standards organizations requesting a fee for standards are ISO and DIN; others do provide their own standards free of charge (e.g. eOTD). This topic of copyright and availability at no cost will also be largely discussed during the sessions of the newly formed Focus Group on Computer-sensitive Dictionaries and Classifications (if this Group is effectively formed – depending on the agreement of the European Commission). It is anticipated that ePDC will follow the rules as discussed in this Focus Group, for the sake of homogeneity. Translations It should be clearly defined who is responsible for translations of the product description and classification system into foreign languages. This is necessary to prevent wrong translations. However, different situations can arise, depending on the Organization that furnishes the translation. Several different experiences are encountered: • within eCl@ss, some translations are furnished by members of the Classification schema, free of charge as they need to have them in different less used languages like Czech. Some translations are being paid by the Organization (Chinese for example). • In GS1, some GS1 (EAN) local offices (France, Germany) are requested to provide free of charge translations • Some catalogue companies request a fee to have the ability to use their home- made translations (Japanese e.g.) It is foreseen that each situation will have to be dealt with individually, depending on the Organization. However, this point will be discussed openly in the Joint Committee in due time.

56 CWA 15295:2005 (E)

8 Requirements on the Toolkit for Maintaining the System

This section describes requirements on a software tool for maintaining product classification schemes that adhere to the principles which were introduced in Chapter 5.1. The tool should cover the maintenance process as described in Chapter 5.2 as well. The following description aims at preparing and structuring the decision process for choosing an actual software tool. The search for and selection of this tool will be part of the proposed ePDC2 project. Here we only describe requirements that are specific for maintaining product classification schemes. Other requirements that apply to software systems are also valid, and should be considered (e.g., scalability, security, backup/recovery). Since we only cover functional requirements, we do not propose software architectures, specific platforms, or respective technologies. Software tools for maintaining product classification schemes show some characteristics that are common for data management systems in which the management process is controlled by a workflow model. Therefore, we structure the requirements in the following five areas: 1. Repository 2. Data Access and Data Manipulation 3. Data Import and Export 4. Workflow Management 5. User Management While this section covers only the back office work that is done by the committee and associated content managers, domain experts and administrative staff (“internal view”), chapter 9. will add requirements for a website giving access to product classification schemes (“external view”). 8.1 Repository A repository is the kernel of every data management system. It defines the structure of the data that is managed, storing the actual data (other terms: items, objects), and guaranteeing to meet the basic goals of every data management system (especially atomicity, consistency, isolation and durability). Next, we describe requirements that arise from characteristics of product classification schemes (e.g., complexity of data structure), their adoption (e.g., multiple schemes, different views) and maintenance (e.g., versions, distributed process). We require that the repository communicates with other similar systems to form a distributed environment.

57 CWA 15295:2005 (E)

8.1.1 Support the ePDC Data Model completely Due to its primary purpose, the software tool must support the ePDC data model completely. First, this includes the coverage of product classes, class hierarchies, product properties and the usage of properties in class-specific sets of properties. Second, all attributes specified in the data model must be part of the data model as well. Since chapter 6 proposes a couple of additions and modifications to the PLIB model, the software tool should support the ePDC model, not only the PLIB model (e.g., mappings). Supporting the ePDC model is also a pre-requirement to be able to import and export product classification schemes that adhere to the ePDC model. However, the repository cannot solely be based on the ePDC model, because additional information (entity types, attributes, relationships) is necessary for the management of this data, for tracking changes and version, monitoring and controlling the maintenance and so on. 8.1.2 Support Different Granularity of Product Classification Schemes Taking the structural complexity of product classification schemes into account, not all schemes necessarily implement all structural concepts. For instance, keywords for class names are beneficial, but not essential, for product classification in general. Hence the software tool should allow selecting the concepts that are supported by an actual schema (e.g. only properties, no classes, no keywords for property names). Based on this initial configuration, the tool should restrict the data management functions to the supported concepts. Unsupported information should not be permitted because it is not part of that specific product classification scheme. 8.1.3 Support Multiple Product Classification Schemes In the face of the high number of product classification schemes, and the need for developing and maintaining different schemes, the software tool should be able to accommodate more than one schema. This requirement is especially motivated by the ePDC2 aim of integrating and migrating existing schemes into the new ePDC model (architecture). The support of multiple schemes calls for separated work spaces for each schema. In addition, this allows working in specific environments for testing and education purposes as well. By importing and exporting these schemes, the separated information can be merged into one schema, if necessary. 8.1.4 Support Multiple Versions The support of multiple versions is based on the principle that two versions of the same product classification schema are not two different schemes, but one. The only difference is that all or some items are part of two or more versions. The reason for storing this information not separately is evident: Version management is crucial for maintaining product classification schemes, especially since each and every item (product class, property etc.) is subject to changes and modifications; hence data

58 CWA 15295:2005 (E)

management stores only the information that has changed, and tracks the changes as well. The implementation of this requirement is partly based on the version model and respective attributes in the ePDC data model. 8.1.5 Support Multiple Languages Similar to the support of multiple versions and in accordance with the ePDC data model, a product classification schema that is available in two or more languages is still one schema. This means, that all language-dependent information is separated from the language-independent structure of the schema (e.g., identifiers of all items, relationships between items). The support for multiple languages addresses the repository, and is also very important for the data management functions, since the user-interface must fulfil this requirement as well. 8.2 Data Access and Data Manipulation The requirements concerning data access and data manipulation result directly from needs and expectations of the users that work with the software tool. 8.2.1 Support Browsing and Searching for Entities Because of the number of product classes and properties, searching for specific entities and browsing the class hierarchy are needed. These functions concern all entity types, hence also units and values. The search functions should be customizable covering class names, class definitions, class synonyms, note and remarks; the same applies to searching for properties. This also helps to simulate the usage of a schema in web- based ordering systems, since browsing and searching for classes is a common way to find products. 8.2.2 Support Life-cycle of Entities The data manipulation includes the creation, modification, and deletion of entities. Thus the complete life-cycle must be supported. Deleting an entity does not imply that this entity is physically deleted from the repository, but means that the entity is withdrawn from the schema. Information about this fact is part of the update information and should be forwarded to adopters. Manipulating the class hierarchy calls for easy modifications of the tree structure; for instance, a common operation is to move a specific sub-tree to another position. Other operations are splitting a class to two or more classes, and merging classes. This should be supported by the software tool. An interactive drag-on-drop procedure is not necessary though. Mappings between different schemas are another requirement (product classes, properties; based on cardinality etc.).

59 CWA 15295:2005 (E)

8.2.3 Support Enforcement of Rules on Data In general, the software tool should prevent the entry of data that does not adhere to the data type of the respective attribute. A more sophisticated concept is the enforcement of rules on data. This means that the tool guarantees a specific data quality that should be achieved. Precise specifications of product classes and properties are crucial. Only if these are available for all entities, precise, and understandable, the adopters use them correctly in their business scenario. The requirements for specifications are similar to important dimensions of data quality. Hence the software tool should check whether each entity is semantically defined by a textual description (attribute definition). For instance, the meaning and intended scope of a product class can hardly be assessed by its class name only (e.g., “Pipe connection for metallic piping”), rather the definition provides more semantics, and helps to demarcate it from a similar, but different class (e.g., “Covers special piping connection like screwed fitting, which are used as complete systems. Flanges and flanged joints are not part of this class.”) In this case, the data quality can be assessed by counting the number of classes that provide a textual description, and relates this number to the total number of classes. A ratio of 1 indicates completeness. By differentiating this metric to all sub-trees we get a measurement for the quality of each sub-tree; therefore we can identify segments of relatively low quality and argue to improve this quality. Another rule that should be enforced is the number of levels, if this is standardized for the whole schema (e.g., 4 levels). In this case, the tool must guarantee that the schema may only be released, until the number of levels is in all sub-trees equal to four. However, during the creation and maintenance phase, the number of levels can be lower or even higher. So we distinguish the release status, which is characterized by a specific data quality, and the development phase. The rules on data emphasize the data quality. Therefore, the software tool should provide a set of basic statistics and reports that describe the data quality. This information is especially helpful for conducting and monitoring distributed, long-term development processes of multi-segment product classification schemes; see [Hepp 2004] for more details on this issue. 8.2.4 Support Maintenance of Multiple Languages and Versions The maintenance of multiple versions and languages of the same product classification schema makes high requirements on the user-interface of the software tool. The goal is to present all language and version information of an entity on a single screen; this allows to access all relevant information and enables to edit the information as well. For instance, localizing a schema requires seeing the initial language version in order to edit the new language version. The language of the user-interface may not be limited to English, since the software tool should be used in different European countries.

60 CWA 15295:2005 (E)

8.3 Data Import and Data Export Requirements on importing and exporting data arise from the need for data exchange. 8.3.1 Support the Import of Product Classification Schemes Requirements on the import of product classification schemes are as follows: The software tool should support the import of both complete product classification schemes and specific parts of it; for instance, the import of a number of properties. The software tool should support the ePDC exchange format completely; this includes the coverage of all message types and mapping information as well. The software tool should also support proprietary exchange formats based on comma- separated values files (CSV) and Microsoft Excel sheets (XLS). The reason is that these two groups of formats are widely used in industry. In addition, the ePDC2 aim of migrating existing product classification schemes calls for being able to import the existing proprietary formats as well. The import of CSV and XLS should be configurable by mapping the data elements of the source format (columns) to the ePDC model. An interactive drag-on-drop procedure is not necessary though. 8.3.2 Support the Export of Product Classification Schemes The requirements on the export of product classification schemes are equal to those on the import. An optional requirement is to export data in XML-based exchanged formats in order to support already existing e-business standards. 8.3.3 Support Update Messages The software tool should be able to import update information and apply these changes to an existing schema. The software tool should be able to export update information for a given schema, or any parts of it. 8.3.4 Support Web Services The software tool should provide a set of web services for accessing product classification schemes. A more detailed description is part of the requirements on the web site. 8.4 Workflow Management Workflow management addresses directly the maintenance model and the distributed process of creating and maintaining a product classification schema. 8.4.1 Support the ePDC Maintenance Model The most important requirement is supporting the different roles and tasks of the ePDC maintenance model including restricted rights depending on the role.

61 CWA 15295:2005 (E)

8.4.2 Support the Customization of Workflow Models In addition to the ePDC maintenance model, a more flexible mechanism should be implemented in the software tool. This should allow modifying the workflow definition. It is part of the customization when introducing the tool, not a specific functionality accessible via the user-interface. The motivation for this flexibility is to prevent hard- coded workflow models. However, the software tool must not provide a comprehensive workflow engine. 8.5 User Management Requirements on user managements results from the fact that different persons with different rights depending on their roles use the software tool. 8.5.1 Support Distributed Work Distributed work as it is characteristic for maintaining a product classification schema should be supported by a model that covers users, roles, and tasks. Hence user management includes functionalities for creating and maintaining user accounts and for assigning users to given roles. 8.5.2 Support Tracking of Changes Similar to a content management system, the software tool should track all changes (Who? When? What?). In addition, based on changes of entities, simple notification processes should facilitated.

62 CWA 15295:2005 (E)

9 Requirements on a Website giving Access to the System This section describes requirements on a website giving access to product classification schemes that are stored in the repository. This functionality is not limited to accessing information, but includes retrieving information for data processing tasks as well initiating change requests. The description of requirements complements the requirements on the software tool that supports the back office processes (internal view). Here we add the external view. 9.1 Access to Product Classification Schemes The major function is to give access to product classification schemes. 9.1.1 Support Browsing and Searching for Entities Accessing a product classification schema via a website should give the users a first impression of the schema and provide the information they are looking for; for instance, browsing for a specific entity in order to retrieve its specification. The browsing and searching functionalities are very similar to those of the maintenance tool. These functions concern all entity types, hence also units and values. The search functions should be customizable covering class names, class definitions, class synonyms, note and remarks; the same applies to searching for properties. This also helps to simulate the usage of a schema in web-based ordering systems, since browsing and searching for classes is a common way to find products. The user interface should be easy to use, provide version information and give access to multiple versions as well. The language of the user interface should be customizable, too. 9.1.2 Support Access Policies Depending on the product classification schema and its access policy, the software tool should grant access to it or not. This means that while some product classification schemes are accessible for the public, others require a formal contract, including the payment of specific fees. Such a policy can only be supported by maintaining user profiles. Which information is made public and which is subject to fees, must be configurable for all schemes separately. For instance, this issue may apply to browsing for data, downloading data files, and registering to web services. In addition, these services can be limited for specific periods of time or to subsets of product classes and properties as well.

63 CWA 15295:2005 (E)

9.1.3 Support Single Sign-On The website should serve as a central access point to a number of different product classification schemes. However, the access is managed by one account for each user only. In this concept, the single sign-on offers access even to physically distributed schemes that are characterized by different access policies. 9.1.4 Support Pull Services Pull services are a method of accessing information. Downloading exchange files (complete schemes, update information only, specific subsets etc.) belongs to this. If the access is executed automatically via a web service, the pull starts with the request transaction, which is answered by the response transaction. Access to web services is also dependent on access policies and user profiles. 9.1.5 Support Push Services Push services are another method of providing information to customers. Automatic notifications (e.g. of updates), newsletters and web services can be part of these services. Especially the notification services possess a high potential for automatic synchronization of schema data between organizations. Subscription services limited to specific subsets of classes and properties respectively should be supported. 9.2 Change Requests User interaction is not limited to accessing information, but includes the initiation of change requests as well. 9.2.1 Support Initiation The website should support the initiation of form-based, pre-structured change requests by users. Which kinds of users are allowed to submit such a request is dependent on the policy and maintenance model behind the respective product classification schema; for instance, this may be restricted to registered users. Once the change request is submitted, it is controlled by the maintenance tool according to the workflow model (each request starts a workflow). 9.2.2 Support Tracking The website should support the tracking of an initiated change request. Following the pull principle, this requires that the initiator can check the status of his requests. Automatic notifications to the submitters adhere to the push principle; for instance, e- mail messages are sent when the status of a request has changed.

64 CWA 15295:2005 (E)

10 Conclusion We have registered now more than 40 classifications schemes: we are sure there are many more we are still not aware of. Some classification schemes are horizontal: they cover many (or all) different branches of industry and sales, including services (UNSPSC, eCl@ss, NATO...). Some classification schemes are vertical, that is, dedicated to one single branch of industry: e.g. the Medical Device industry (GMDN) or the Sanitary and Heating industry (CEN/ISSS CWAs). A product classification schema shall be usable as a structure for the whole manufacturing and retail industries. PRODUCT Classification, Identification & Description LEVEL eCl@ss UNSPSC

(no properties) GPC CLASSIFICATION (EAN/UCC) Most detailed level - Product Group PRODUCT GROUP Product Group - Properties

IDENTIFICATION GTIN

Basic <10 prop. GPC A U T O

Descriptive H A R D L I N E S O I L A G R O A PRODUCT LEVEL E L E C T R O R T C E E L PROPERTIES C H E L MI C A Manufactg I N D IC T S R E DICTIONARY DESCRIPTION DICTIONARY E C V I R E S O D O F Design GENERAL MERCHANDISE FMCG & NON-FOOD FOOD SINGLE DOM APPL DOM Other AFTERM Beispiele: AG+CRISTAL CIDX PIDX RNTD EAN/UCC (OIDDI) Figure 21 - Example structure of properties and classes2

Electronic catalogues to be used by marketplaces or for procurement or sales need to define the products they contain to a very fine level of detail. Therefore, it appeared very quickly that classification to a certain level of detail, from the highest - less detailed level - to the lowest - most detailed level – was insufficient. It was therefore necessary to introduce Properties of the detailed products, to be able to differentiate them properly. Principle 1: A good product classification system consists at least of the following entities and relations

2 *FMCG = Fast Moving Consumer Goods

65 CWA 15295:2005 (E)

• a dictionary or ontology of all available product classes, including for each product class a set of properties (list of characteristics) which reflect the standard product description. These classes may be hierarchically structured • a dictionary or ontology of all available properties • a hierarchical grouping schema (often a numbering schema) to build a product categorization and form an hierarchy of the product classes. The grouping schema is composed of a certain number of levels (most commonly 4 levels)

This section refines some of the concepts developed in this chapter. It applies to electronic catalogues as fit as electronic inventories (warehouse management). The term “catalogue” will be used here as a general term for both types of applications. The fundamental problem in both cases is to find an item with certain characteristics in a large list. A very traditional solution, which does not even require Electronic Data Processing (EDP), is to group the catalogue entries by certain criteria, and then group the groups, and so on. One ends up with a hierarchy that guides the searcher. Such a hierarchy dramatically reduces searching effort if one can be sure to find all candidates for a match in one single group (“class”) – or at least in only a few. Then one only needs to match the entries in that class with the given requirements, instead of all entries in the whole catalogue. The appropriate class is found in a top-down approach: One selects the top level class that appears to contain the match candidates, then looks at the subclasses of the class selected, and repeats this procedure until one arrives at the lowest level. This is just the way old-fashioned “systematic catalogues” in libraries work. It is called “hierarchical search”, and the search procedure is called “navigation”. Principle 2: A good classification system shall propose an efficient, accurate and flexible hierarchy, usable for hierarchical search. The problem with hierarchical search is that the criteria according to which the grouping was done are not always strictly “orthogonal”. This means, it is not always clear whether a selection made at a certain level is the correct one or not. If it turns out to be wrong, one will have to climb up the hierarchy again and make another selection. Example: Adhesive tape could be in “Packaging Material” as well as in “Office Supplies”. Hierarchical search works well if the searcher finds the hierarchy natural and logical. Unfortunately different people will find different hierarchies natural and logical. To help the user find and not only search the correct class, additional support is required, namely a keyword system. The user should be able to enter any reasonable term describing the item required and be returned the appropriate class. If the term is not very specific, such as “screw”, several matching classes may be returned. “Reasonable” terms include dialectal or jargon expressions, familiar expressions (as opposed to technical terms), more specific terms (defining a subset of a class which is not a class of its own). It is understood that the catalogue’s search engine supports exact keyword matching as well as advanced matching functions (truncation, phonetic matching, etc). Principle 3: A good classification scheme shall propose a usable Keyword System

66 CWA 15295:2005 (E)

Even if the number of candidates for a match is dramatically reduced by a flexible classification hierarchy as well as high quality keyword search, it may still be very large. In order to select those products that meet the given requirements, which can be conceptually described by a given product class, we need direct access to the properties of the product to refine the search. As an example, one may want to know whether there are screws in stock that have a diameter of 4mm and a length between 35 mm and 45mm, or whether a supplier sells ethanol with at least 99.7% purity. This kind of request is called “parametric search”. As the examples show, matching functions include inequalities of numerical properties, and physical quantities must be represented properly (most often) as the product of a number and a unit of measure. Obviously the product classes must be defined in such a manner that the same properties are applicable to all members of the same class. In other words, each class corresponds to (is conceptually captured by) a set of properties. This requires of course the products in the catalogue must be described in terms of these sets of properties. Principle 4: A good classification system, which is based on properties, shall have a Standard Set of Properties usable for parametric search, by humans as well as by computer systems. Material Groups are used to make collective statements about goods and services in procurement. This is necessary if the number of items purchased is too large to enumerate the items. In certain cases, however, it can also generate a new quality of information. Typical usage of Material groups are: Statistical Analyses of Procurement Activities Such analyses are performed in order to determine an enterprise’s position in its procurement markets. They are a basis for developing market strategies. This requires that material groups adequately map market structures. As larger enterprises have different reporting levels there are different degrees of abstraction and aggregation in their statistics. A hierarchical structure of material groups is a quite natural consequence. Typical analyses are calculations of purchasing volumes in certain market segments; or in other words: the aggregation of purchasing transactions in certain material groups. In a material group hierarchy the aggregated volume attributed to a parent class is equal to the sum of its child classes’ volumes. Definition of Purchasers’ Responsibilities The materials a purchaser is responsible for are usually expressed in terms of material groups. As the purchasers act in particular market segments this requires that material groups appropriately reflect market structures. The hierarchical organization in larger enterprises again makes hierarchical material groups appear a natural thing. However one cannot expect that a material group standard exactly maps a particular company’s organization, which can be achieved with proprietary material groups.

67 CWA 15295:2005 (E)

Description of Suppliers’ Lines of Products The assortment of products a supplier offers is described in terms of material groups. As procurement markets are defined by the suppliers and their products this requires that material groups reflect procurement market structures. Contract Subjects The subject of a contract can be expressed in terms of material groups. Group Procurement In groups (conglomerates), material groups can be used to identify bundling potentials across group companies and to compare prices and conditions. NOTE: This application can take additional advantage of standard sets of properties.

Principle 5: A good classification system requires that it shall be usable as material groups The use of properties is the key to obtain standardized machine readable conceptual specifications, built by a well defined set of properties associated to the concept, so called List of Characteristics. List of Characteristics are created and used by various enterprise functions, e.g. by an engineer who designs a plant and specifies its parts, or by a purchaser who asks for bids. A classification with standard sets of properties can be viewed as a collection of standard specification forms. Each product class corresponds to a form, with the properties being the empty fields. A standardized specification is created by filling in some or all fields of the corresponding form. In this way one achieves consistent and homogeneous specifications, which can be interpreted and processed by computer systems. Engineers usually work with different computer aided engineering systems (CAE) when they design plants and other industrial facilities. Using a product classification schema which provides a standard sets of properties in this context requires, that the CAE system “knows” the standard sets of properties as well as the corresponding product classes and that the CAE system uses them to specify the requirements which a particular piece of equipment must fulfil. Additionally this principle requires that the CAE system’s parts library3 describes its entries in terms of the standard list of characteristics. This principle also applies to non-industrial processes, like sales of consumer goods in supermarkets or shops. Principle 6: A good classification system must permit the creation and use of computer processable standardized specifications. A good classification system reconciles economy and technology. The product class hierarchy serves as a search hierarchy to the technician and as a representation of

3 The parts library may have additional information which cannot be described in terms of standard sets of properties, e.g. technical drawings.

68 CWA 15295:2005 (E)

market structures to the purchaser at the same time. Their requirements are not identical. Therefore, it is needed, if we want to satisfy the procurement as well as the manufacturer or even the designer (CAD-CAM...) to group the standardized set properties into functional representations that are relevant for each phase within the product lifecycle. Principle 7: A good classification provides a way to build functional groups. Them maintenance process of a product classification system is crucial. Therefore a good product classification system comprises a well defined maintenance process, which is implemented by a software system, which allows concurrent, cooperative access. The maintenance process needs to ensure quality of the definitions within the product classification system, which can be achieved easiest by a cooperative consensual process. Principle 8: A good classification system is based on a well defined, cooperative, consensual maintenance process. The basis for a good product classification system is a highly accepted, world wide standardized information model, to separate the concerns about data modelling and product classification. Any candidate information model shall allow to generate import/export files, which can be formally verified. Exchange messages based on formal creation methods shall apply. Principle 9: A good classification system is based on a standardized, highly accepted information model. The basis for electronic communication between Product Description and Classification Systems are exchange formats derived from the Reference Information Model for ePDC Systems. Principle 10: A good classification system supports standardized exchange messages. One of the important topics which differentiate the European Union from the United States is the language. Europe has several languages which are actively used and therefore the multi-lingual aspect is one of the pan-European requirements in high focus. Large classification systems are usually presented in different languages that allow them to be used not only by large companies, but also by small and medium enterprises, which have very often unilingual staff members. Principle 11: A good classification system will therefore present two parts, one which is language independent, and another which is language dependent.

69 CWA 15295:2005 (E)

11 Bibliography The following material, though not specifically referenced in the body of the present document (or not publicly available), gives supporting information. Agrawal, R. / Srikant, R.: On integrating catalogs, in: Proceedings of the 10th International World Wide Web Conference (WWW10), Hong Kong, China, May 2001, pp. 603-612. http://www10.org/cdrom/papers/076/index.html Ariba: cXML’s User Guide. Version 1.2.011, April 2004. http://www.cxml.org Banerjee, S. / Kumar, R.L.: Managing electronic interchange of business documents, in: Communications of the ACM (CACM), Vol. 45, No. 7, July 2002, pp. 96-102. http://doi.acm.org/10.1145/514236.514241 Baron, J. P. / Shaw, M. J. / Bailey, A. D.: Web-based E-catalog systems in B2B Procurement, in: Communications of the ACM (CACM), Vol. 43, No. 5, 2000, S. 93-100. http://doi.acm.org/10.1145/332833.332845 Bergamaschi, S. / Guerra, F. / Vincini, M.: Product Classification Integration for E- Commerce, in: Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA 2002), September 2002, Aix-en-Provence, France, pp. 861-867. http://csdl.computer.org/comp/proceedings/dexa/2002/1668/00/16680861abs.htm CommerceOne: XML Common Business Library (xCBL), Version 4.0, 2003. http://www.xcbl.org Corcho, O. / Gómez-Pérez, A.: Solving Integration Problems of E-Commerce Standards and Initiatives through Ontological Mappings, in: Proceedings of the Workshop on E-Business and Intelligent Web at IJCAI 2001, August 2001, Seattle, Washington, USA, pp. 131-140. http://www.csd.abdn.ac.uk/~apreece/ebiweb/papers/corcho.pdf Danish, S.: Building database-driven electronic catalogs, in: ACM SIGMOD RecordVol. 27, No. 4, 1998, pp. 15-20. http://doi.acm.org/10.1145/306101.306103 DIN e.V.: DIN 4000-1: Sachmerkmal-Leisten – Teil 1: Begriffe und Grundsätze; Übersicht über genormte Sachmerkmal-Leisten und -Listen, Verlag Beuth, Berlin et al. 1992. http://www.beuth.de/ DIN e.V.: Grundlagen für den Aufbau eines Merkmal-Lexikons. Hilfen zur Umsetzung der Festlegungen in den Normen der Reihen ISO 13584 und IEC 61360 bzw. DIN EN 61360 sowie zum Aufbau und zur Anwendung von Referenzhierarchien und Merkmal-Lexika, DIN-Fachbericht 69, Verlag Beuth, Berlin et al. 1998. http://www.beuth.de/

70 CWA 15295:2005 (E)

DIN e.V.: DIN V 4002: Merkmale und Referenzhierarchie zum Produktdaten- austausch, Verlag Beuth, Berlin et al. 2003. http://www.beuth.de/ Ding, Y. et al.: GoldenBullet: Automated Classification of Product Data in E- commerce, in: Proceedings of the 5th International Conference on Business Information Systems, April 2002, Posen, Poland. http://www.cs.vu.nl/~ying/download/goldenbullet.bis2002.pdf eCl@ss: eCl@ss White Paper 0.6, January 2000. http://www.eClass-online.com/informationen/download/eClassWhitePaper06.doc Fairchild, A. M. / Vuyst, B.: Coding Standards benefiting Product and Service Information in E-Commerce, in: Proceedings of the 35th Hawaii International Conference on System Sciences (HICSS-35), January 2002, Big Island, Hawaii, USA. http://csdl.computer.org/comp/proceedings/hicss/2002/1435/08/14350258b.pdf Fensel, D. et al.: Product Data Integration in B2B E-commerce, in: IEEE Intelligent Systems, Vol. 16, No. 4, 2001, pp. 54-59. http://homepage.uibk.ac.at/~c703205/download/x4fensel.lo.pdf Hepp, M.: Güterklassifikation als semantisches Standardisierungsproblem, Deutscher Universitäts-Verlag, Wiesbaden 2003. Hepp, M.: Measuring the Quality of Descriptive Languages for Products and Services, in: Proceedings of Multi-Conference Business Informatics 2004 (MKWI04), Vol. E-Business – Standardization and Integration, Essen, Germany, pp. 157-168. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=503602 Minsky, M. M.: Matter, Mind and Models. Published in Semantic Information Processing, MIT Press, 1968. http://medg.lcs.mit.edu/people/doyle/gallery/minsky/mmm.html Hümpel, C. / Schmitz, V.: BMEcat - Produktkataloge austauschen per XML, in: Turowski, K.; Fellner, K. (Eds.): XML in der betrieblichen Praxis: Standards, Möglichkeiten, Praxisbeispiele, dpunkt-Verlag, Heidelberg 2001, pp. 205-217. http://www.bli.uni-essen.de/publications/2001_XML_HuempelSchmitz.pdf Kelkar, O. / Leukel, J. / Schmitz, V.: Price modeling in standards for electronic product catalogs based on XML, in: Proceedings of the 11th International World Wide Web Conference (WWW2002), May 2002, Honolulu, Hawaii, USA, pp. 366- 375. http://doi.acm.org/10.1145/511446.511494 Kim, D. et al.: Catalog Integration for Electronic Commerce through Category- Hierarchy Merging Technique, in: Proceedings of the 12th International Workshop on Research Issues in Data Engineering: Engineering E-Commerce/EBbusiness Systems (RIDE'02), February 2002, San Jose, California, USA, pp. 28-33. http://csdl.computer.org/comp/proceedings/ride/2002/1480/00/14800028abs.htm

71 CWA 15295:2005 (E)

Kim, D. et al.: A Semantic Classification Model for e-Catalogs, in: Proceedings of the IEEE International Conference on E-Commerce Technology (CEC’04), July 2004, San Diego, California, USA, pp. 85-92. http://csdl.computer.org/comp/proceedings/cec/2004/2098/00/20980085abs.htm Leukel, J. / Schmitz, V. / Dorloff, F.-D.: A Modeling Approach for Product Classification Systems, in: Proceedings of the 13th International Workshop on Database and Expert Systems Applications (DEXA 2002), September 2002, Aix- en-Provence, France, pp. 868-874. http://www.bli.uni-essen.de/publications/2002_WEBH_LeukelSchmitzDorloff.pdf Leukel, J. / Schmitz, V. / Dorloff, F.-D.: Coordination and Exchange of XML Catalog Data in B2B, in: Proceedings of the 5th International Conference on Electronic Commerce Research (ICECR-5), October 2002, Montreal, Canada. http://www.bli.uni-essen.de/publications/2002_ICECR5_LeukelSchmitzDorloff.pdf Leukel, J. / Schmitz, V. / Dorloff, F.-D.: B2B E-Procurement Beyond MRO?, in: Proceedings of the 6th International Conference on Electronic Commerce Research (ICECR-6), October 2003, Dallas, Texas, USA, pp. 493-500. http://www.bli.uni-essen.de/publications/2003_ICECR6_LeukelSchmitzDorloff- d.pdf IANA: MIME Media Types, January 2002. http://www.iana.org/assignments/media-types/ NATO Group of National Directors on Codification (AC/135): Guide to the NATO Codification System, September 2002. http://www.nato.int/structur/AC/135/ncs_guide/e_guide.htm Ng, W. / Yan, G. / Lim, E.-P.: Heterogeneous Product Description in Electronic Commerce, in: ACM SIGeCom Exchanges, Vol. 1, No. 1, 2000, pp. 7-13. http://portal.acm.org/citation.cfm?id=844305 OMG: Unified Modeling Language Specification, 2003. http://www.omg.org Ondracek, N.: Electronic Catalogues Management and Usage, in: Proceedings. of the International Symposium on Global Engineering Networking GEN ’97, April 1997, Antwerp, Belgium. http://www.lisi.ensma.fr/ftp/pub/PLUS/Documents/PLib_Usage.doc Ondracek, N.: Überführung bestehender Sachmerkmale in ein Merkmal-Lexikon, Referatensammlung der DIN Tagung Merkmallexikon in der Anwendung, Beuth Verlag 1998. http://www.beuth.de/ Ondracek, N. / Sander, S.: Concepts and Benefits of the German ISO 13584 compliant online dictionary www.DINsml.net, in: Proceedings of the 10th ISPE International Conference on Concurrent Engineering (CE 2003), Vol. Enhanced Interoperable Systems, July 2003, Madeira, Portugal, pp. 255-262. http://www.oiddi.org/plib/upload/Ondracek_sander.pdf

72 CWA 15295:2005 (E)

Open Applications Group: Open Applications Group Integration Specification, Release 8.0, 2002. http://www.openapplications.org Quantz, J. / Wichmann, T.: E-Business-Standards in Deutschland. Bestands- aufnahme, Probleme, Perspektiven. Ein Forschungsauftrag des Bundes- ministeriums für Wirtschaft und Arbeit, Endbericht, Berlecon Research GmbH, Berlin 2003. http://www.berlecon.de/studien/downloads/200304eStandards.pdf Pierra, G.: Context-explication in conceptual ontologies: the PLIB approach, in: Proceedings of the 10th ISPE International Conference on Concurrent Engineering (CE 2003), Vol. Enhanced Interoperable Systems, July 2003, Madeira, Portugal, pp. 243-253. http://www.lisi.ensma.fr/ftp/pub/documents/papers/2003/2003-CE2003-Pierra.pdf Pierra, G. / Potier, J.-C. / Sardet, E.: From digital libraries to electronic catalogues for engineering and manufacturing, in International Journal of Computer Applications in Technology (IJCAT), Special Issue on Applications in Industry of Product and Process Modelling Using Standards, Vo. 18, No. 1, 2000, pp. 27-42. http://www.oiddi.org/plib/upload/IJCAT2000.pdf Pierra, G.: The PLIB Ontology-based approach to data integration, in: Processind of the 18th IFIP World Computer Congress (WCC’2004), August 2004, Toulouse, France. http://www.lisi.ensma.fr/ftp/pub/documents/papers/2004/2004-IFIP-Pierra.pdf Schmitz, V. / Kelkar, O. / Pastoors, T.: Specification BMEcat, Version 1.2. http://www.bmecat.org Schulten, E.: The e-commerce product classification challenge, in: IEEE Intelligent Systems, Vol. 16, No. 4, 2001, pp. 86-89. http://csdl.computer.org/comp/mags/ex/2001/04/x4086abs.htm Stonebraker, M. / Hellerstein, J. M.: Content Integration for E-Business, in: Proceedings of ACM SIGMOD/PODS 2001, Santa Barbara, California, USA, May 2001, pp. 552-560. http://doi.acm.org/10.1145/375663.375739

73 CWA 15295:2005 (E)

12 Annex A – Detailed Final ePDC Data model This chapter presents a printout representation of the ePDC datamodel. This model was created using an integrated tool for developing datamodels and exchange messages. The electronic representation of the model, the HTML representation of this chapter and the message specifications as well as XML Schema specifications of the messages can be obtained from the CEN website.

DATAMODEL Name Part Library Datamodel Code PLIB Version 1.0 Footer (c) ePDC project

Contents

Entities

Relations

Domains

ENTITIES Entity Name Code in Tag Description Comment Diagram AXIS1 XS1 XS1The axis1_placement_type ENTITY entity provides for values of axis1_placement_type DETs that are instances of axis1_placement. entity data type. (See ISO 10303-42 for details). AXIS2 XS2 XS2 The ENTITY axis2_placement_2d_type axis2_placement_2d_type entity provides for values of DETs that are instances of axis2_placement_2d entity data type (See ISO 10303-42

74 CWA 15295:2005 (E)

for details). AXIS3 XS3 XS3 The ENTITY axis2_placement_3d_type axis2_placement_3d_type entity provides for values of DETs that are instances of axis2_placement_3d entity data type. (See ISO 10303-42 for details). BASIC BSU BSU A basic_semantic_unit is an ENTITY basic_semantic_unit SEMANTIC UNIT unique identification of a dictionary_element. BSU is the abbreviation of Basic Semantic Unit. BOOLEAN TYPE BLT BLT The boolean_type entity ENTITY boolean_type provides for values of DETs that are of type BOOLEAN. BUSINESS BOB BOB OBJECT CLASS CLA CLA The class entity is an abstract ENTITY class resource for all kinds of classes. identified_by: the class_BSU identifying this class. CLASS AND CPE CPE The ENTITY PROPERTY class_and_property_elements class_and_property_elements ELEMENTS entity captures the attributes that are common to both classes and property_DETs. CLASS BSU CLB CLB The class_BSU entity ENTITY class_BSU provides for the identification of classes. code: the code assigned to this class by its supplier. CLASS BSU CBR CBR The class_BSU_relationship ENTITY RELATIONSHIP entity is a provision for class_BSU_relationship association of BSUs with classes. CLASS CIT CIT The class_instance_type ENTITY class_instance_type INSTANCE entity provides for values of TYPE DETs that are represented as

75 CWA 15295:2005 (E)

instances of a class. It is used, in particular, for the description of assemblies or to describe the material a (part of a) component consists of. domain: the class_BSU referring to the class representing the described type. CLASS CRB CRB The class_related_BSU ENTITY class_related_BSU RELATED BSU provides for the dictionary elements to be associated with classes, e.g. for ISO 13584 tables, documents, etc ... CLASS VALUE CVA CVA Class-valued properties are ENTITY ASSIGNMENT those properties to which in class_value_assignment each subclass one single value, valid for the whole subclass, is assigned, not for every instance within the class individually. By being included in the list sub_class_properties in entity item_class a property is distinguished as being of that type. In subclasses that inherit this property, values may be assigned using the attribute class_constant_values that contains a set of class_value_assignments. COMPLEX TYPE CPT CPT The complex_type entity ENTITY complex_type provides for the definition of types of which the values are represented as EXPRESS instances. COMPONENT CCL CCL The entity component_class ENTITY component_class CLASS captures the dictionary description of a class of items that represent, at some level of abstraction, parts or components. A property of

76 CWA 15295:2005 (E)

which the data type is defined by a component_class stands for the aggregation relationship. CONDITION CON CON A condition_DET is a property ENTITY condition_DET on which other properties may depend upon. CONTENT ITEM COI COI A content_item is a piece of ENTITY content_item data referring to its description in the dictionary. It shall be subtyped. DATA TYPE DTT DTT The data_type entity serves ENTITY data_type as a common supertype for the entities used to indicate the type of the associated DET. DATA TYPE DAB DAB The data_type_BSU entity ENTITY data_type_BSU BSU provides for identification of data_type_elements. code: to allow for unique identification within the scope indicated by the name_scope attribute. DATA TYPE DTE DTE The data_type_element entity ENTITY data_type_element ELEMENT describes the dictionary element for types. Note that it is not necessary in every case to have BSU and dictionary_element for a certain data_type, because a property_DET can refer to the data_type directly. Usage of the BSU relation is only necessary when a supplier wants to refer to the same type in a different Physical File. identified_by: the BSU that identifies the described data_type_element. NOTE The redeclared attribute identified_by is used to encode the reference to the BSU, this data_type_element is related to. This itself,

77 CWA 15295:2005 (E)

beside the data_type_BSU entity (see above) is used to encode the class attribute "Visible Types" (see 7.2). DATES DAT DAT The dates entity describes the three dates associated respectively to the first version, the current version and the current revision for a given description. DEPENDENT DEP DEP A dependent_P_DET is a ENTITY dependent_P_DET PROPERTY property whose value depends explicitly on the value(s) of some condition(s), like e.g. ambient temperature. DICTIONARY DEL DEL A dictionary_element is a full ENTITY dictionary_element ELEMENT definition of the data required to be captured in the semantic dictionary for some concept. For every concept a separate subtype is to be used. The dictionary_element is associated with a basic_semantic_unit (BSU), that serves to uniquely identify this definition in the dictionary. By including the version attribute in the basic_semantic_unit entity, it forms part of the identification of a dictionary element (in contrast to the revision and time_stamps attributes). ENTITY EIT EIT The entity_instance_type ENTITY entity_instance_type INSTANCE entity provides for values of TYPE DETs that are represented as instances of some EXPRESS entity data types. A type_name attribute enables the specification what are the allowed data types. This attribute, together with the EXPRESS TYPEOF function applied to the value, permits

78 CWA 15295:2005 (E)

strong type checking and polymorphism. This entity will be subtyped below for some data types that are allowed for use in the dictionary schema. INTEGER ICT ICT The int_currency_type entity ENTITY int_currency_type CURRENCY provides for values of DETs TYPE that are integer currencies. INTEGER IMT IMT The int_measure_type entity ENTITY int_measure_type MEASURE TYPE provides for values of DETs that are measures of type INTEGER. INTEGER TYPE ITT ITT The int_type entity provides ENTITY int_type for values of DETs that are of type INTEGER. ITEM CLASS ICL ICL The entity item_class enables ENTITY item_class the modelling of any type of entity of the application domain that corresponds to an autonomous and stand- alone abstraction as a class. It is a supertype intended to be sub-typed to define the nature of the objects. Nevertheless, it is not defined as ABSTRACT to enable its instanciation to model the classes that are super- classes of two classes corresponding to two different kinds of objects (e. g., components and materials). EXAMPLE 1 A material is an autonomous and stand-alone abstraction of an object of the parts library application domain. It is represented as a specific sub-class of item_class. EXAMPLE 2 A feature is an autonomous and stand-alone abstraction of an object of the parts library application domain. It might

79 CWA 15295:2005 (E)

be represented as a specific sub-class of item_class. EXAMPLE 3 A product representation is not an autonomous and stand-alone abstraction of an object of the parts library application domain: it may only exist with a relation to a product. In ISO 13584-24, part representations are represented as specific sub- class of class. ITEM NAMES ITN ITN The item_names entity ENTITY item_names identifies the names that can be associated to a given description. It states the preferred name, the set of synonymous names, the short name and the languages in which the different names are provided. It may be associated with an icon. LANGUAGE LNG LNG The language_code type TYPE language_code = enables to identify a language identifier according to ISO 639. Values are e.g. "EN" for English in general, "FR" for French, "RU" for Russian, "DE" for German, "en GB" for UK English, "en US" for US English etc... LEVEL LVL LVL The level type provides an TYPE level = abbreviated name of the ENUMERATION OF ( min, different qualified values that (*corresponds to the minimal may be associated with a value of the physical physical quantity, quantity*) nom, (*corresponds distinguishing it from other to the nominal value of the possible or allowed values of physical quantity*) typ, the same quantity. (*corresponds to the typical value of the physical quantity*) max, (*corresponds to the maximal value of the physical quantity*) )

80 CWA 15295:2005 (E)

LEVEL TYPE LVT LVT The level_type entity provides ENTITY level_type an indicator to qualify the values of a quantitative data element type. MATERIAL MCL MCL The entity material_class ENTITY material_class CLASS captures the dictionary description of a class of materials. Materials are used to define properties of parts or components. Materials are associated with an idea of amount, they may not be counted. A property of which the data type is defined by a material_class captures that some (part of a) product is made of, or contains, some material. MATHEMATICAL MST MST The mathematical_string STRING entity provides resources defining a representation for mathematical strings. It also allows a representation in the SGML format. NAMED TYPE NMT NMT The named_type entity ENTITY named_type provides for referring to other types via the BSU mechanism. referred_type: the BSU identifying the data_type the present entity refers to. NON NDP NDP A non_dependent_P_DET is ENTITY DEPENDENT a property that does not non_dependent_P_DET PROPERTY depend explicitly on certain conditions. NON NCT NCT The ENTITY QUANTITATIVE non_quantitative_code_type non_quantitative_code_type CODE TYPE entity is an enumeration type where elements of the enumeration are represented with a STRING value (see also ENTITY non_quantitative_int_type

81 CWA 15295:2005 (E)

and figure D.11). NON NQT NQT The ENTITY QUANTITATIVE non_quantitative_int_type non_quantitative_int_type INTEGER TYPE entity is an enumeration type where elements of the enumeration are represented with an INTEGER value (see also ENTITY non_quantitative_code_type and figure D.11.). NUMBER TYPE NBT NBT The number_type entity ENTITY number_type provides for values of DETs that are of type NUMBER. PLACEMENT PLT PLT The placement_type entity ENTITY placement_type TYPE provides for values of DETs that are instances of placement entity data type. (See ISO 10303-42 for details). PROPERTY PRO PROThe property_DET entity ENTITY property_DET captures the dictionary description of properties. identified_by: the property_BSU identifying this property. NOTE 1 The three subtypes condition_DET, dependent_P_DET and non_dependent_P_DET of the entity property_DET are used to encode the "Category" attribute for properties (see 6.2). condition_DET is used for context parameters, dependent_P_DET is used for context dependent characteristics and the non_dependent_P_DET entity is used for part characteristics. NOTE 2 The depends_on attribute of the dependent_P_DET entity is used to encode the "Condition" attribute for

82 CWA 15295:2005 (E)

properties (see 6.2). PROPERTY BSU PRB PRB The entity property_BSU ENTITY property_BSU provides for identification of a property. code: to allow for unique identification within the scope indicated by the name_scope attribute. REAL RCP RCP The real_currency_type entity ENTITY real_currency_type CURRENCY defines real currencies. TYPE REAL MEASURE RMT RMT The real_measure_type entity ENTITY real_measure_type TYPE provides for values of DETs that are measures of type REAL. REAL TYPE RLT RLT The real_type entity provides ENTITY real_type for values of DETs that are of type REAL. SIMPLE TYPE SPT SPT The simple_type entity serves ENTITY simple_type as a common supertype for the entities used to indicate a simple type of the associated DET. STRING TYPE STT STT The string_type provides for ENTITY string_type values of DETs that are of type STRING. SUPPLIER BSU SUB SUB The supplier_BSU entity ENTITY supplier_BSU provides for unique identification of suppliers of dictionary data. code: the supplier's code assigned according to ISO 13584-26. version: the version number of a supplier code shall be equal to 001. SUPPLIER BSU SBR SBR The ENTITY RELATIONSHIP supplier_BSU_relationship is supplier_BSU_relationship a provision for association of BSUs with suppliers. SUPPLIER SUE SUE The supplier_element entity ENTITY supplier_element ELEMENT gives the dictionary

83 CWA 15295:2005 (E)

description of suppliers. identified_by: the supplier_BSU used to identify this supplier_element. SUPPLIER SRB SRB The supplier_related_BSU ENTITY RELATED BSU provides for the dictionary supplier_related_BSU elements to be associated with suppliers, e.g. for ISO 13584: program libraries. SYNONYMOUS SYN SYN The syn_name_type identifies TYPE syn_name_type = NAME the values allowed for a SELECT synonymous name. (label_with_language, label) TRANSLATION TRL TRL The present_translations ENTITY present_translations entity serves to indicate the languages used for translated_label and translated_text. VALUE VAL VAL The dic_value entity is one of ENTITY dic_value the values of a value_domain entity. VALUE DOMAIN VAD VAD The value_domain entity ENTITY value_domain describes the set of allowed values for a non-quantitative data element type. VALUE TYPE VLT VLT Each value of a non- TYPE integer_type = quantitative data element is INTEGER TYPE value_type = associated with a code, that SELECT (value_code_type, characterizes the value. A integer_type) value_type may be either an INTEGER or a value_code_type.

Attributes of Entity AXIS1 Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity AXIS2 Attribute Tag Key Domain Format Data Description Comment

84 CWA 15295:2005 (E)

Name Name Type

Attributes of Entity AXIS3 Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity BASIC SEMANTIC UNIT Attribute Tag Key Domain Format Data Description Comment Name Name Type Code CDE CODE TYPE an..5 Alnum code: the code code: code_type; assigned to identify a certain dictionary element. Version VRS VERSION an..5 Alnum version: the version: TYPE version number version_type; of a certain dictionary element.

Attributes of Entity BOOLEAN TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity BUSINESS OBJECT Attribute Name Tag Key Domain Format Data Description Comment Name Type Classification CNM Name Type an..70 Alnum name Version VRS VERSION an..5 Alnum TYPE Revision RVS Revision an..20 Alnum Number Type

85 CWA 15295:2005 (E)

Attributes of Entity CLASS Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CLASS AND PROPERTY ELEMENTS Attribute Tag Key Domain Format Data Description Comment Name Name Type Definition DEF DEFINITION an..70 Alnum definition: the text definition: definition_type; TYPE describing this dictionary element. NOTE 2 The definition attribute will be used to encode the property attribute "Definition" (see 6.2) and the class attribute "Definition," (see 7.2). Source SDD Document an..70 Alnum source_doc_of_defin source_doc_of_definition: document Type ition: the source OPTIONAL document; of document of this definition textual description. NOTE 3 The source_of_doc_defin ition attribute will be used to encode the property attribute "Source Document of Definition" (see 6.2) and the class attribute "Source Document of Definition," (see 7.2). Note NTE Note Type an..70 Alnum note: further note: OPTIONAL information on any note_type; part of the dictionary element, which is essential to the understanding. NOTE 4 The note attribute will be used

86 CWA 15295:2005 (E)

to encode the property and class attribute "Note" (see 6.2 and 7.2). Remark REM Remark an..70 Alnum remark: explanatory remark: OPTIONAL Type text further clarifying remark_type; the meaning of this dictionary element. NOTE 5 The remark attribute will be used to encode the property and class attribute "Remark" (see 6.2 and 7.2).

Attributes of Entity CLASS BSU Attribute Tag Key Domain Format Data Description Comment Name Name Type Absolute AID Identifier an..10 Alnum absolute_id: the absolute_id: identifier := identifier Type unique defined_by.absolute_id identification of + sep_id + this class. UR1: dic_identifier; UR1: the absolute_id; concatenation of supplier code and class code is unique.

Attributes of Entity CLASS BSU RELATIONSHIP Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CLASS INSTANCE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CLASS RELATED BSU

87 CWA 15295:2005 (E)

Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CLASS VALUE ASSIGNMENT Attribute Tag Key Domain Format Data Description Comment Name Name Type Assigned AVL VALUE an..70 Alnum assigned_value: the assigned_value: value CODE value assigned to the value_code_type; TYPE property, valid for the whole class referring this class_value_assignment instance in the class_constant_values list.

Attributes of Entity COMPLEX TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity COMPONENT CLASS Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CONDITION Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity CONTENT ITEM Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity DATA TYPE Attribute Tag Key Domain Format Data Description Comment

88 CWA 15295:2005 (E)

Name Name Type

Attributes of Entity DATA TYPE BSU Attribute Tag Key Domain Format Data Description Comment Name Name Type Absolute AID Identifier an..10 Alnum absolute_id: absolute_id: identifier := identifier Type the unique name_scope.defined_by.absolute_id identification (* Supplier*) + sep_id + of this name_scope.dic_identifier (* Class*) property. + sep_id + dic_identifier; (* Data_type *) UNIQUE absolute_id;

Attributes of Entity DATA TYPE ELEMENT Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity DATES Attribute Tag Key Domain Format Data Description Comment Name Name Type Date of DOD DATE TYPE an10 Alnum The date original associated to definition version 001. Date of DCV DATE TYPE an10 Alnum The date current associated to the version present version. Date of DCR DATE TYPE an10 Alnum The date current associated to the revision last revision.

Attributes of Entity DEPENDENT PROPERTY Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity DICTIONARY ELEMENT

89 CWA 15295:2005 (E)

Attribute Tag Key Domain Format Data Description Comment Name Name Type Revision RNB Revision an..20 Alnum revision: the revision: Number revision number revision_type; Type of this dictionary element. NOTE 3 The revision attribute will be used to encode the property and class attribute "Revision Number" (see 6.2 and 7.2).

Attributes of Entity ENTITY INSTANCE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Type name TNM STRING an..70 Alnum type_name: the type_name: SET set of strings that OF STRING; describe, in the format of the EXPRESS TYPEOF function, the EXPRESS entity data type names that shall belong to the result of the EXPRESS TYPEOF function when it is applied to a value that references the present entity as its data type.

Attributes of Entity INTEGER CURRENCY TYPE Attribute Tag Key Domain Name Format Data Description Comment Name Type

90 CWA 15295:2005 (E)

Currency CUR CURRENCY an3 Alnum currency: the currency: CODE associated OPTIONAL code of the currency_code; described currency according to ISO 4217. If not present, the currency code has to be exchanged together with the data (values).

Attributes of Entity INTEGER MEASURE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Unit UNT UNIT an..70 Alnum unit: the unit unit: dic_unit; associated to the described measure. NOTE The attribute unit is used to encode the "Unit" attribute for properties (see 6.2).

Attributes of Entity INTEGER TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity ITEM CLASS Attribute Tag Key Domain Format Data Description Comment Name Name Type Simplified SDR GRAPHICS an..70 Alnum simplified_drawing: simplified_drawing: drawing optional drawings OPTIONAL (graphics) that can graphics;

91 CWA 15295:2005 (E)

be associated to the described class. Coded CNM VALUE an..70 Alnum coded_name: to coded_name: name CODE be used in the OPTIONAL TYPE value domain of value_code_type; the Classifying DET of the superclass.

Attributes of Entity ITEM NAMES Attribute Tag Key Domain Format Data Description Comment Name Name Type Preferred PNM Name Type an..70 Alnum preferred_name: the preferred_name: name name that is pref_name_type; preferred for use. NOTE 1 The attributes preferred_name, synonymous_names and short_name are used to encode the "Preferred Name", "Synonymous Name" and "Short Name" attributes respectively for properties and classes (see 6.2 and 7.2). Short SNM Short an..35 Alnum short_name: the short_name: name Name Type abbreviation of the short_name_type; preferred name. NOTE 1 The attributes preferred_name, synonymous_names and short_name are used to encode the "Preferred Name", "Synonymous Name" and "Short Name" attributes

92 CWA 15295:2005 (E)

respectively for properties and classes (see 6.2 and 7.2). Icon ICN GRAPHICS an..70 Alnum icon : an optional icon : OPTIONAL icon which graphics; graphically represents the description associated with the item_names.

Attributes of Entity LANGUAGE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity LEVEL Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity LEVEL TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Value type VLT SIMPLE an..70 Alnum value_type: the value_type: TYPE type of value of simple_type; the different qualified values.

Attributes of Entity MATERIAL CLASS Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity MATHEMATICAL STRING Attribute Tag Key Domain Name Format Data Description Comment Name Type

93 CWA 15295:2005 (E)

Text TRP Representation an..70 Alnum text_representation: representation Type "linear" form of a mathematical string, using ISO 843-2: "Transliteration of Greek characters into Latin characters", if necessary. SGML SRP Representation an..70 Alnum SGML_representation: representation Type SGML-Text (ISO 8879), marked up according to the Math DTD (document Type Definition) in ISO 12083: "Electronic Manuscript Preparation and Markup". The SGML text must be processed so that it will be treated as one single string during the exchange (see ISO 10303-21).

Attributes of Entity NAMED TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity NON DEPENDENT PROPERTY Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity NON QUANTITATIVE CODE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Domain DOM VALUE an..70 Alnum domain: the set domain: DOMAIN of enumerated value_domain; values described

94 CWA 15295:2005 (E)

in the value_domain entity.

Attributes of Entity NON QUANTITATIVE INTEGER TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Domain DOM VALUE an..70 Alnum domain: the set domain: DOMAIN of enumerated value_domain; values described in the value_domain entity.

Attributes of Entity NUMBER TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity PLACEMENT TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity PROPERTY Attribute Tag Key Domain Name Format Data Description Comment Name Type Preferred PSB MATHEMATICAL an..70 Alnum preferred_symbol: a symbol STRING shorter description of this property. NOTE 1 The preferred_symbol attribute is used to encode the "Preferred Letter Symbol" attribute for properties (see 6.2). Synonymous SS1 MATHEMATICAL an..70 Alnum synonymous_symbol synonymous_ s: synonymous for symbols: SET

95 CWA 15295:2005 (E)

symbol 1 STRING the shorter [ 0 : 2 ] OF description of the mathematical property. NOTE 2 _string; The synonymous_symbol s attribute is used to encode the "Synonymous Letter Symbol" attribute for properties (see 6.2). Synonymous SS2 MATHEMATICAL an..70 Alnum synonymous_symbol synonymous_ symbol 2 STRING s: synonymous for symbols: SET the shorter [ 0 : 2 ] OF description of the mathematical property. NOTE 2 _string; The synonymous_symbol s attribute is used to encode the "Synonymous Letter Symbol" attribute for properties (see 6.2). Figure FIG GRAPHICS an..70 Alnum figure: an optional figure: graphics that OPTIONAL describes the graphics; property. Classification CLS CLASSIFICATION an..70 Alnum det_classification: the det_classificat TYPE ISO 31 class for this ion: property. NOTE 3 OPTIONAL The det_classification DET_classific attribute is used to ation_type; encode the "Property Type Classification" attribute of a property (see 6.2). Formula FRM MATHEMATICAL an..70 Alnum formula: a formula: STRING mathematical OPTIONAL expression for mathematical explaining the _string; property. NOTE 5 The formula attribute is used to encode the "Formula" attribute for properties (see

96 CWA 15295:2005 (E)

6.2).

Attributes of Entity PROPERTY BSU Attribute Tag Key Domain Format Data Description Comment Name Name Type Absolute AID Identifier an..10 Alnum absolute_id: absolute_id: identifier := identifier Type the unique name_scope.defined_by.absolute_id identification (* Supplier *) + sep_id + of this name_scope.dic_identifier (* Class property. *) + sep_id + dic_identifier; (* UR1: the Property*) UR1: absolute_id; property identifier absolute_id is unique.

Attributes of Entity REAL CURRENCY TYPE Attribute Tag Key Domain Name Format Data Description Comment Name Type Currency CUR CURRENCY an3 Alnum currency: the currency: CODE associated OPTIONAL code of the currency_code; described currency according to ISO 4217. If not present, the currency code has to be exchanged together with the data (values).

Attributes of Entity REAL MEASURE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Unit UNT UNIT an..70 Alnum unit: the unit unit: dic_unit; associated to the

97 CWA 15295:2005 (E)

described measure. NOTE The attribute unit is used to encode the "Unit" attribute for properties (see 6.2).

Attributes of Entity REAL TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity SIMPLE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type Value VFM VALUE an..70 Alnum value_format: value_format: format FORMAT the encoding of value_format_type; TYPE the format of values for properties. NOTE - The value_format attribute of the simple_type entity is used to encode the "Value Format" attribute for properties (see 6.2).

Attributes of Entity STRING TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity SUPPLIER BSU Attribute Tag Key Domain Format Data Description Comment

98 CWA 15295:2005 (E)

Name Name Type Absolute AID Identifier an..10 Alnum absolute_id: absolute_id: identifier := identifier Type the absolute SELF\basic_semantic_unit.code identification ; UR1: absolute_id; of the supplier. UR1: the supplier identifier defined by the absolute_id attribute is unique.

Attributes of Entity SUPPLIER BSU RELATIONSHIP Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity SUPPLIER ELEMENT Attribute Tag Key Domain Format Data Description Comment Name Name Type Organisation ORG Organisation an..70 Alnum org: the org: Type organizational organization; data of this supplier. Address ADR Address Type an..70 Alnum addr: the addr: address; address of this supplier.

Attributes of Entity SUPPLIER RELATED BSU Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity SYNONYMOUS NAME Attribute Tag Key Domain Format Data Description Comment

99 CWA 15295:2005 (E)

Name Name Type Label LBL LABEL an..70 Alnum l: the label l: label; associated to a language. Language LCD LANGUAGE an..3 Alnum language: the language: code CODE code of the language_code; labelled language.

Attributes of Entity TRANSLATION Attribute Tag Key Domain Format Data Description Comment Name Name Type

Attributes of Entity VALUE Attribute Tag Key Domain Format Data Description Comment Name Name Type Value VAL VALUE an..70 Alnum value_code: the code value_code: code TYPE associated to the value_type; described value. It can be either a value_code_type or an INTEGER. Source SDC DOCUMENT an..70 Alnum source_doc_of_value: source_doc_of_value: document the optional source OPTIONAL document in which document; the value is defined.

Attributes of Entity VALUE DOMAIN Attribute Tag KDomain Format Data Description C Name eName Type o y m m e n t Source SDC DOCUMENT an..70 Alnum source_doc_of_value source_doc_of_valu document _domain: the e_domain:

100 CWA 15295:2005 (E)

document describing OPTIONAL the domain document; associated to the described value_domain entity.

Attributes of Entity VALUE TYPE Attribute Tag Key Domain Format Data Description Comment Name Name Type

RELATIONS

Entity Name Entity Type Description Comment

BASIC Definition DICTIONARY 1:1 definition : a definition: SET [ SEMANTIC ------ELEMENT reference to 0 : 1 ] OF UNIT the dictionary_elem dictionary ent FOR element identified_by; identified by identified_by: this BSU. If basic_semantic not present _unit; in some exchange context, it is assumed to be present in the dictionary of the target system already. identified_by : the BSU identifying this dictionary element. NOTE 1 The type of the identified_by attribute will be

101 CWA 15295:2005 (E)

redeclared later to property_BS U and class_BSU and will then be used to encode together with the code attribute of the BSUs the "Code" attribute for properties (see 6.2) and classes (see 7.2) respectively. It will also be used to encode the "Version Number" attribute for properties and classes respectively.

BASIC Referenced by CONTENT 1:1 referenced_ referenced_by: SEMANTIC ------ITEM by: items SET[ 0 : 1 ] OF UNIT making use content_item of the FOR dictionary dictionary_defini element tion; associated dictionary_defini with this tion: BSU. basic_semantic dictionary_d _unit; efinition: the Basic Semantic Unit to be used for referring to the definition

102 CWA 15295:2005 (E)

in the dictionary.

SUPPLIER BSU BASIC isa ---isa--- SEMANTIC UNIT

CLASS BSU BASIC isa ---isa--- SEMANTIC UNIT

PROPERTY BASIC isa BSU ---isa--- SEMANTIC UNIT

DATA TYPE BASIC isa BSU ---isa--- SEMANTIC UNIT

SUPPLIER BASIC isa RELATED BSU ---isa--- SEMANTIC UNIT

CLASS BASIC isa RELATED BSU ---isa--- SEMANTIC UNIT

SUPPLIER DICTIONARY isa ELEMENT ---isa--- ELEMENT

CLASS AND DICTIONARY isa PROPERTY ---isa--- ELEMENT ELEMENTS

DATA TYPE DICTIONARY isa ELEMENT ---isa--- ELEMENT

CLASS CLASS AND isa ---isa--- PROPERTY ELEMENTS

ITEM CLASS CLASS isa ---isa---

103 CWA 15295:2005 (E)

COMPONENT ITEM CLASS isa CLASS ---isa---

MATERIAL ITEM CLASS isa CLASS ---isa---

PROPERTY CLASS AND isa ---isa--- PROPERTY ELEMENTS

CONDITION PROPERTY isa ---isa---

DEPENDENT PROPERTY isa PROPERTY ---isa---

NON PROPERTY isa DEPENDENT ---isa--- PROPERTY

DATA TYPE DATA TYPE 1:1 type_definiti type_definition: ------ELEMENT on: the data_type; description of the type carried by the data_type_el ement.

SIMPLE TYPE DATA TYPE isa ---isa---

COMPLEX DATA TYPE isa TYPE ---isa---

CLASS COMPLEX isa INSTANCE ---isa--- TYPE TYPE

VALUE Values VALUE 1:n its_values: its_values: LIST DOMAIN ------< the [ 2 : ? ] OF enumeration dic_value; list of values contained in the

104 CWA 15295:2005 (E)

described domain.

ITEM NAMES Synonymous SYNONYMOUS 1:n synonymous synonymous_na names NAME _names: the mes: SET OF ------< set of syn_name_type; synonymous names. NOTE 1 The attributes preferred_na me, synonymous _names and short_name are used to encode the "Preferred Name", "Synonymou s Name" and "Short Name" attributes respectively for properties and classes (see 6.2 and 7.2).

CLASS AND Names ITEM NAMES 1:1 names: the names: PROPERTY ------names item_names; ELEMENTS describing this dictionary element. NOTE 1 The names attribute will be used as a starting point to encode in the item_names entity the

105 CWA 15295:2005 (E)

property and class attributes "Preferred Name", "Short Name" and "Synonymou s Name" (see 6.2, 7.2 and D.3.8.2).

DATA TYPE Names ITEM NAMES 1:1 names: the names: ELEMENT ------names that item_names; allow the description of the defined data_type_el ement.

VALUE Terms ITEM NAMES 1:n terms: the terms: LIST [ 0 : DOMAIN ------< list of ? ] OF item_names item_names; to allow for IEC 61360 the link to the terms dictionary.

DICTIONARY Time stamps DATES 1:n time_stamps time_stamps: ELEMENT ------< : the optional OPTIONAL dates of dates; creation and update of this dictionary element. NOTE 2 The time_stamps attribute will be used as a starting point to encode in the dates entity the

106 CWA 15295:2005 (E)

property and class attributes "Date of Original Definition", "Date of Current Version" and "Date of Current Revision" (see 6.2, 7.2 and D.3.8.2).

CLASS Described by PROPERTY n:m described_b described_by: >------< BSU y: the list of LIST [ 0 : ? ] OF references UNIQUE to the property_BSU; additional describes_class properties es: SET OF available for class FOR use in the described_by; description of the parts within the class, and any of its subclasses NOTE In ISO 13584- 24, a property may also be applicable to a class when this property is imported from another class through the is-case-of or is-view-of semantics relationships . Therefore

107 CWA 15295:2005 (E)

the properties referenced by the described_b y attribute do not define all the applicable properties for an ISO 13584- defined class describes_cl asses: the classes declaring this property as available for use in the description of a part.

CLASS Defined types DATA TYPE 1:n defined_type defined_types: ------< BSU s: the set of SET [ 0 : ? ] OF references data_type_BSU; to the types defining_class: that can be SET [ 0 : 1 ] OF used for class FOR various defined_types; property_DE Ts throughout the inheritance tree descending from this class. NOTE In ISO 13584-24, a data_type may also be applicable to a class when

108 CWA 15295:2005 (E)

this data_type is imported from another class through the is-case-of or is-view-of semantics relationships . Therefore the properties referenced by the defined_type s attribute do not define all the applicable data types for an ISO 13584- defined class defining_cla ss: the classes declaring this data_type as available for use in the description of a part.

ITEM CLASS Class CLASS VALUE 1:n class_consta class_constant_ constantvalues ASSIGNMENT nt_values: values: SET [ 0 : ------< assignments ? ] OF in the class_value_ass current class ignment; for class- valued properties declared in superclasse

109 CWA 15295:2005 (E)

s. See D.3.6.4 "Class- Valued Properties".

SUPPLIER SUPPLIER BSU n:1 related_toke related_tokens: RELATED BSU >------RELATIONSHIP ns: the set of SET [ 1 : ? ] OF dictionary supplier_related elements _BSU; associated to the supplier identified by the relating_sup plier attribute.

CLASS CLASS BSU n:1 related_toke related_tokens: RELATED BSU >------RELATIONSHIP ns: the set of SET [ 1 : ? ] OF dictionary class_related_B elements SU; associated to the class identified by the relating_clas s attribute.

SUPPLIER BSU Relating SUPPLIER n:1 relating_sup relating_supplier RELATIONSHIP supplier ELEMENT plier: the : >------supplier_ele supplier_elemen ment that t; identifies the associated_item data s: SET [ 0 : ? ] supplier. OF associated_i supplier_BSU_r tems: allows elationship FOR access to relating_supplier other kinds ; of data via the BSU mechanism (e.g. program

110 CWA 15295:2005 (E)

library in ISO 13584).

CLASS BSU Relating class CLASS n:1 relating_clas relating_class: RELATIONSHIP >------s: the class class; that associated_item identifies the s: SET [ 0 : ? ] dictionary of element. class_BSU_relat associated_i ionship FOR tems: allows relating_class; to access other kinds of data using the BSU mechanism.

CLASS BSU Added visible PROPERTY 1:n added_visibl added_visible_p proper BSU e_properties roperties:SET [0 ------< : the set of : ?] OF property_BS property_BSU Us that refer FOR to the class name_scope; as their name_scope: name_scope class_BSU; and that are therefore visible for the class (and any of its sub- class). NOTE 1 Only the property_BS Us that belongs to the same exchange context are referenced by this inverse attribute. On the receiving system they

111 CWA 15295:2005 (E)

may already exit other property_BS Us that refer to this class (a PLib exchange context is never assumed to be complete). NOTE 2 The added_visibl e_properties attribute will be used to encode the class attribute "Visible Properties" (see 7.2). name_scope : is the reference to the class at which or below which the property element is available for reference by the described_b y attribute. NOTE The name_scope attribute of the property_BS U entity will be used to encode the "Definition Class"

112 CWA 15295:2005 (E)

attribute for properties (see 6.2).

CLASS BSU Added visible DATA TYPE 1:n added_visibl added_visible_d datatp BSU e_data_type ata_types:SET ------< s: the set of [0 : ?] OF data_type_B data_type_BSU SUs that FOR refer to the name_scope; class as name_scope: their class_BSU; name_scope and that are therefore visible for the class (and any of its sub- class). NOTE 1 Only the data_type_B SUs that belongs to the same exchange context are referenced by this inverse attribute. On the receiving system they may already exit other data_type_B SUs that refer to this class (a PLib exchange context is never assumed to be complete).

113 CWA 15295:2005 (E)

NOTE 2 The added_visibl e_data_type s attribute will be used to encode the class attribute "Visible Types" (see 7.2). name_scope : the reference to the class at which or below which the data type element is available for reference by the defined_type s attribute. NOTE The name_scope attribute is used to encode the reference to a class the related data type belongs to. This itself, beside the data_type_el ement entity (see below) , is part of the encoding of the class attribute "Visible Types" (see 7.2).

114 CWA 15295:2005 (E)

CLASS Superclass CLASS BSU n:1 its_supercla its_superclass: >------ss: reference OPTIONAL to the class class_BSU; the current subclasses: one is a SET [0 : ?] OF subclass of. class FOR subclasses: its_superclass; the set of classes specifying this class as their superclass.

DEPENDENT Depends on PROPERTY 1:n depends_on: depends_on: PROPERTY ------< BSU the set of SET [ 1 : ? ] OF basic property_BSU; semantic units identifying the properties on which this property depends on.

PROPERTY Domain DATA TYPE n:1 domain: the domain: >------reference to data_type; the data_type associated to the property. NOTE 4 The domain attribute is used as a starting point for the encoding of the property attribute "Data Type" (see 6.2). The entity data_type

115 CWA 15295:2005 (E)

will be subtyped for various possible data types.

CLASS BSU Defined by SUPPLIER BSU 1:1 defined_by: defined_by: ------the supplier supplier_BSU; defining this class and its dictionary element

ITEM CLASS Sub class PROPERTY 1:n sub_class_p sub_class_prop properties BSU roperties: erties: SET [ 0 : ------< declares ? ] OF properties as property_BSU; class- valued, i.e. in subclasses one single value will be assigned per class. See D.3.6.4 "Class- Valued Properties".

CLASS VALUE Super class PROPERTY 1:1 super_class super_class_def ASSIGNMENT def prop BSU _defined_pr ined_property: ------operty: the property_BSU; reference to the property (defined in a superclass as being a class_valued _property) to which a certain value is assigned.

NAMED TYPE DATA TYPE isa

116 CWA 15295:2005 (E)

---isa---

STRING TYPE SIMPLE TYPE isa ---isa---

BOOLEAN SIMPLE TYPE isa TYPE ---isa---

NUMBER TYPE SIMPLE TYPE isa ---isa---

REAL TYPE NUMBER TYPE isa ---isa---

INTEGER TYPE NUMBER TYPE isa ---isa---

INTEGER INTEGER TYPE isa MEASURE ---isa--- TYPE

INTEGER INTEGER TYPE isa CURRENCY ---isa--- TYPE

NON INTEGER TYPE isa QUANTITATIVE ---isa--- INTEGER TYPE

REAL REAL TYPE isa MEASURE ---isa--- TYPE

REAL REAL TYPE isa CURRENCY ---isa--- TYPE

NON STRING TYPE isa QUANTITATIVE ---isa--- CODE TYPE

LEVEL TYPE Levels LEVEL 1:n levels: the levels: LIST [ 1 : ------< list of unique 4 ] OF UNIQUE elements level; that

117 CWA 15295:2005 (E)

specifies which qualified values shall be associated with the property.

LEVEL TYPE COMPLEX isa ---isa--- TYPE

ENTITY COMPLEX isa INSTANCE ---isa--- TYPE TYPE

PLACEMENT ENTITY isa TYPE ---isa--- INSTANCE TYPE

AXIS1 PLACEMENT isa ---isa--- TYPE

AXIS2 PLACEMENT isa ---isa--- TYPE

AXIS3 PLACEMENT isa ---isa--- TYPE

ITEM NAMES Languages TRANSLATION 1:n languages: languages: ------< the optional OPTIONAL list of present_translati languages in ons; which the different names are provided. NOTE 2 The attribute languages is used to define the sequence of translations (if requested

118 CWA 15295:2005 (E)

for attributes).

TRANSLATION Language LANGUAGE 1:n language_co language_codes codes des: the list : LIST [ 1 : ? ] ------< of unique OF UNIQUE language language_code; codes UR1: correspondin language_codes g to the ; language in which a translation is made. UR1: for each list of language_co de there shall be a unique instance of present_tran slations

VALUE Languages TRANSLATION 1:n languages: languages: DOMAIN ------< the optional OPTIONAL languages in present_translati which the ons; translations are provided.

VALUE Meaning ITEM NAMES 1:1 meaning: the meaning: ------meaning item_names; associated to this value. It is provided by names.

DOMAINS Domain Name Type Sign Data Format Codelists Description Type Address Type Normal Unsigned Alnum an..70

119 CWA 15295:2005 (E)

CLASSIFICATION Normal Unsigned Alnum an..70 TYPE CODE TYPE Normal Unsigned Alnum an..5

CURRENCY Normal Unsigned Alnum an3 CODE DATE TYPE Normal Unsigned Alnum an10

DEFINITION TYPE Normal Unsigned Alnum an..70

DOCUMENT Normal Unsigned Alnum an..70

Document Type Normal Unsigned Alnum an..70

Dummy

GRAPHICS Normal Unsigned Alnum an..70

Identifier Type Normal Unsigned Alnum an..10

LABEL Normal Unsigned Alnum an..70

LANGUAGE Normal Unsigned Alnum an..3 CODE MATHEMATICAL Normal Unsigned Alnum an..70 STRING Name Type Normal Unsigned Alnum an..70

Note Type Normal Unsigned Alnum an..70

Organisation Type Normal Unsigned Alnum an..70

Remark Type Normal Unsigned Alnum an..70

Representation Normal Unsigned Alnum an..70 Type Revision Number Normal Unsigned Alnum an..20 Type SIMPLE TYPE Normal Unsigned Alnum an..70

STRING Normal Unsigned Alnum an..70

Short Name Type Normal Unsigned Alnum an..35

UNIT Normal Unsigned Alnum an..70

120 CWA 15295:2005 (E)

Undefined ?

VALUE CODE Normal Unsigned Alnum an..70 TYPE VALUE DOMAIN Normal Unsigned Alnum an..70

VALUE FORMAT Normal Unsigned Alnum an..70 TYPE VALUE TYPE Normal Unsigned Alnum an..70

VERSION TYPE Normal Unsigned Alnum an..5

121 CWA 15295:2005 (E)

13 Annex B – ePDC Generic Exchange Format Hierarchy BUSINESS OBJECT 1..1, R MATERIAL CLASS 0..*, O ITEM NAMES 0..1, O SYNONYMOUS NAME 0..*, O CLASS BSU (Identified by) 0..1, O SUPPLIER BSU 0..1, O CLASS BSU (Superclass) 0..1, O SUPPLIER BSU 0..1, O PROPERTY BSU 0..*, O PROPERTY BSU 0..*, O CLASS VALUE ASSIGNMENT 0..*, O PROPERTY BSU 0..1, O COMPONENT CLASS 0..*, O ITEM NAMES 0..1, O SYNONYMOUS NAME 0..*, O CLASS BSU (Identified by) 0..1, O SUPPLIER BSU 0..1, O CLASS BSU (Superclass) 0..1, O SUPPLIER BSU 0..1, O PROPERTY BSU 0..*, O PROPERTY BSU 0..*, O CLASS VALUE ASSIGNMENT 0..*, O PROPERTY BSU 0..1, O PROPERTY 0..*, O ITEM NAMES 0..1, O SYNONYMOUS NAME 0..*, O DEPENDENT PROPERTY 0..1, O PROPERTY BSU 0..*, O DATA TYPE 0..1, O DATA TYPE ELEMENT 0..1, O DATA TYPE BSU 0..1, O SIMPLE TYPE 0..1, O DATA TYPE 0..*, O DATA TYPE ELEMENT 0..1, O DATA TYPE BSU 0..1, O COMPLEX TYPE 0..1, O

122 CWA 15295:2005 (E)

ENTITY INSTANCE TYPE 0..1, O LEVEL TYPE 0..1, O SIMPLE TYPE 0..1, O NUMBER TYPE 0..1, O INTEGER TYPE 0..1, O NON QUANTITATIVE INTEGER TYPE 0..1, O INTEGER CURRENCY TYPE 0..1, O INTEGER MEASURE TYPE 0..1, O REAL TYPE 0..1, O REAL CURRENCY TYPE 0..1, O REAL MEASURE TYPE 0..1, O STRING TYPE 0..1, O NON QUANTITATIVE CODE TYPE 0..1, O

BUSINESS OBJECT 1..1, R BUSINESS OBJECT Classification name O an..70 Version O an..5 Revision O an..20

MATERIAL CLASS 0..*, O MATERIAL CLASS - ITEM CLASS - CLASS - CLASS AND PROPERTY ELEMENTS - DICTIONARY ELEMENT Revision O an..20 Definition O an..70 Source document of definition O an..70 Note O an..70 Remark O an..70 Simplified drawing O an..70 Coded name O an..70

ITEM NAMES 0..1, O material class - item class - class - class and property elements - dictionary element - ITEM NAMES Preferred name O an..70 Short name O an..35 Icon O an..70

SYNONYMOUS NAME 0..*, O material class - item class - class - class and property elements - dictionary element - item names - SYNONYMOUS NAME Label O an..70 Language code O an..3

CLASS BSU (IDENTIFIED BY) 0..1, O material class - item class - class - class and property elements - dictionary element - CLASS BSU - BASIC SEMANTIC UNIT (IDENTIFIED BY) Code O an..5

123 CWA 15295:2005 (E)

Version O an..5

SUPPLIER BSU 0..1, O material class - item class - class - class and property elements - dictionary element - class bsu - basic semantic unit (identified by) - SUPPLIER BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

CLASS BSU (SUPERCLASS) 0..1, O material class - item class - class - class and property elements - dictionary element - CLASS BSU - BASIC SEMANTIC UNIT (SUPERCLASS) Code O an..5 Version O an..5

SUPPLIER BSU 0..1, O material class - item class - class - class and property elements - dictionary element - class bsu - basic semantic unit (superclass) - SUPPLIER BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

PROPERTY BSU 0..*, O material class - item class - class - class and property elements - dictionary element - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

PROPERTY BSU 0..*, O material class - item class - class - class and property elements - dictionary element - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

CLASS VALUE ASSIGNMENT 0..*, O material class - item class - class - class and property elements - dictionary element - CLASS VALUE ASSIGNMENT Assigned value O an..70

PROPERTY BSU 0..1, O material class - item class - class - class and property elements - dictionary element - class value assignment - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

COMPONENT CLASS 0..*, O COMPONENT CLASS - ITEM CLASS - CLASS - CLASS AND PROPERTY ELEMENTS - DICTIONARY ELEMENT Revision O an..20 Definition O an..70 Source document of definition O an..70 Note O an..70 Remark O an..70 Simplified drawing O an..70 Coded name O an..70

124 CWA 15295:2005 (E)

ITEM NAMES 0..1, O component class - item class - class - class and property elements - dictionary element - ITEM NAMES Preferred name O an..70 Short name O an..35 Icon O an..70

SYNONYMOUS NAME 0..*, O component class - item class - class - class and property elements - dictionary element - item names - SYNONYMOUS NAME Label O an..70 Language code O an..3

CLASS BSU (IDENTIFIED BY) 0..1, O component class - item class - class - class and property elements - dictionary element - CLASS BSU - BASIC SEMANTIC UNIT (IDENTIFIED BY) Code O an..5 Version O an..5

SUPPLIER BSU 0..1, O component class - item class - class - class and property elements - dictionary element - class bsu - basic semantic unit (identified by) - SUPPLIER BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

CLASS BSU (SUPERCLASS) 0..1, O component class - item class - class - class and property elements - dictionary element - CLASS BSU - BASIC SEMANTIC UNIT (SUPERCLASS) Code O an..5 Version O an..5

SUPPLIER BSU 0..1, O component class - item class - class - class and property elements - dictionary element - class bsu - basic semantic unit (superclass) - SUPPLIER BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

PROPERTY BSU 0..*, O component class - item class - class - class and property elements - dictionary element - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

PROPERTY BSU 0..*, O component class - item class - class - class and property elements - dictionary element - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

CLASS VALUE ASSIGNMENT 0..*, O component class - item class - class - class and property elements - dictionary element - CLASS VALUE ASSIGNMENT Assigned value O an..70

125 CWA 15295:2005 (E)

PROPERTY BSU 0..1, O component class - item class - class - class and property elements - dictionary element - class value assignment - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

PROPERTY 0..*, O PROPERTY - CLASS AND PROPERTY ELEMENTS - DICTIONARY ELEMENT Revision O an..20 Definition O an..70 Source document of definition O an..70 Note O an..70 Remark O an..70 Preferred symbol O an..70 Synonymous symbol 1 O an..70 Synonymous symbol 2 O an..70 Figure O an..70 Classification O an..70 Formula O an..70

ITEM NAMES 0..1, O property - class and property elements - dictionary element - ITEM NAMES Preferred name O an..70 Short name O an..35 Icon O an..70

SYNONYMOUS NAME 0..*, O property - class and property elements - dictionary element - item names - SYNONYMOUS NAME Label O an..70 Language code O an..3

DEPENDENT PROPERTY 0..1, O property - class and property elements - dictionary element - DEPENDENT PROPERTY

PROPERTY BSU 0..*, O property - class and property elements - dictionary element - dependent property - PROPERTY BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

DATA TYPE 0..1, O property - class and property elements - dictionary element - DATA TYPE

DATA TYPE ELEMENT 0..1, O property - class and property elements - dictionary element - data type - DATA TYPE ELEMENT - DICTIONARY ELEMENT Revision O an..20

126 CWA 15295:2005 (E)

DATA TYPE BSU 0..1, O property - class and property elements - dictionary element - data type - data type element - dictionary element - DATA TYPE BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

SIMPLE TYPE 0..1, O property - class and property elements - dictionary element - data type - SIMPLE TYPE Value format O an..70

DATA TYPE 0..*, O DATA TYPE

DATA TYPE ELEMENT 0..1, O data type - DATA TYPE ELEMENT - DICTIONARY ELEMENT Revision O an..20

DATA TYPE BSU 0..1, O data type - data type element - dictionary element - DATA TYPE BSU - BASIC SEMANTIC UNIT Code O an..5 Version O an..5

COMPLEX TYPE 0..1, O data type - COMPLEX TYPE

ENTITY INSTANCE TYPE 0..1, O data type - complex type - ENTITY INSTANCE TYPE Type name O an..70

LEVEL TYPE 0..1, O data type - complex type - LEVEL TYPE Value type O an..70

SIMPLE TYPE 0..1, O data type - SIMPLE TYPE Value format O an..70

NUMBER TYPE 0..1, O data type - simple type - NUMBER TYPE

INTEGER TYPE 0..1, O data type - simple type - number type - INTEGER TYPE

NON QUANTITATIVE INTEGER TYPE 0..1, O data type - simple type - number type - integer type - NON QUANTITATIVE INTEGER TYPE Domain O an..70

127 CWA 15295:2005 (E)

INTEGER CURRENCY TYPE 0..1, O data type - simple type - number type - integer type - INTEGER CURRENCY TYPE Currency O an3

INTEGER MEASURE TYPE 0..1, O data type - simple type - number type - integer type - INTEGER MEASURE TYPE Unit O an..70

REAL TYPE 0..1, O data type - simple type - number type - REAL TYPE

REAL CURRENCY TYPE 0..1, O data type - simple type - number type - real type - REAL CURRENCY TYPE Currency O an3

REAL MEASURE TYPE 0..1, O data type - simple type - number type - real type - REAL MEASURE TYPE Unit O an..70

STRING TYPE 0..1, O data type - simple type - STRING TYPE

NON QUANTITATIVE CODE TYPE 0..1, O data type - simple type - string type - NON QUANTITATIVE CODE TYPE Domain O an..70

128 CWA 15295:2005 (E)

14 Annex C – XML Schema Definition of the ePDC Generic Exchange Format Due to the nature of the XSD we do not include the XML Schema here, but refer to the CEN website where it can be found. The electronic representation of the model, the HTML representation of this chapter and the message specifications as well as XML Schema specifications of the messages can be obtained from the CEN website.

129

15 Annex D - Acknowledgement

Acknowledgement to the ePDC project team:

Jörg LEUKEL, Universität Duisburg-Essen (Campus Essen), [email protected] Nikolaus ONDRACEK, Paradine, [email protected] Frans VAN BASTEN, Digitect B.V., [email protected]

The following experts have in particular contributed to the work with this report:

Paul VRIEND, Digitect B.V., [email protected] Christian GALINSKI, Termnet, [email protected] Raymond BETZ, [email protected] Reinhard POHN, Paradine, [email protected] Guy PIERRA, LISI ENSMA / University of Poitiers, [email protected]

130