IEC TR 61908:2004

TECHNICAL IEC
REPORT TR 61908
First edition
2004-11
The technology roadmap for industry
data dictionary structure,
utilization and implementation

Reference number
IEC/TR 61908:2004(E)
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
TECHNICAL IEC
REPORT TR 61908
First edition
2004-11
The technology roadmap for industry
data dictionary structure,
utilization and implementation

 IEC 2004  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale X

International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – TR 61908 © IEC:2004(E)
CONTENTS
FOREWORD.4
1 Scope.7
2 Normative references .7
3 Overview .7
3.1 Dictionaries and Libraries.7
3.2 The IEC Dictionary .8
3.3 The ECALS Dictionary.9
3.4 The RosettaNet Dictionary.9
3.5 The Global Dictionary situation analysis .9
3.6 The interoperability experiment .11
3.7 Phase I mapping results .12
3.8 Phase II Dictionary Interchange results .12
3.9 Phase III Formal harmonization results.13
4 Background .13
4.1 Evaluation techniques .13
4.2 Proposed participation.14
4.3 Proposed process flow .14
4.4 Reports .14
4.5 Timing .15
5 Introduction of the actual programme experiment .15
6 Procedure used for Section A experiment (RosettaNet to ECALS and MERCI) .15
6.1 Queries (Use case queries) both MERCI and ECALS .17
6.2 Queries (3-level queries) .18
6.3 Output files (created by ECALS).19
6.4 RosettaNet to MERCI (IEC) queries .20
6.4.1 Specific mappings .21
6.4.2 Identification of missing values .22
6.4.3 Qualification properties without mapping .22
6.4.4 Result presentation .22
6.4.5 Mapping problems .24
6.5 Evaluation of RosettaNet to ECALS exchange.24
6.5.1 TRP (transport, routing, packaging) issues .25
6.5.2 Mapping issues (RN->ECALS).25
6.5.3 Query-Response rule differences.25
6.5.4 Mapping issues (RN->ECALS).25
6.5.5 Mapping issues (ECALS – >RN) Preliminary.26
6.5.6 Mapping issues (ECALS – >RN) Preliminary.26
7 Procedure used for Section B experiment (ECALS to RosettaNet and MERCI) .27
7.1 Queries (Use case queries, both RosettaNet and MERCI) .28
7.2 Queries (3-level queries) .28
7.3 Output files (created by RosettaNet).28
7.4 ECALS to MERCI (IEC Queries) .29
7.4.1 Procedure used for Section B experiment (ECALS to MERCI) .29
7.5 Output files (created by MERCI) .30

TR 61908 © IEC:2004(E) – 3 –
7.6 Evaluation techniques (ECALS to RosettaNet) .32
7.6.1 Mapping issues (ECALS to RosettaNet).32
7.6.2 Message translation issues (ECALS to RosettaNet).32
7.6.3 Maintenance of mapping tables (ECALS to RosettaNet) .32
7.6.4 Contents are not provided enough (ECALS to RosettaNet) .33
7.6.5 Additional comments (ECALS to RosettaNet) .33
7.7 Evaluation technique (ECALS to MERCI).33
8 Procedure used for Section C experiment.33
9 Phase III evaluations .35
10 Conclusions.35
10.1 Cooperative spirit statement.35
10.2 Lessons learned.35
10.2.1 Dictionaries vs. Libraries .35
10.2.2 Discontinuity in class structures.36
10.2.3 Product complexity (viewpoints ) .36
10.2.4 Transportation mechanisms (software tools).36
10.2.5 Search engine capabilities.37
10.3 Importance of interoperability .38
11 Recommendations.38
12 Epilogue .39
Annex A (informative) Open and interoperable domain dictionaries initiative.40

Figure 1 – Data element pyramid .11
Figure 2 – Process flow for Phase II, Section A RosettaNet and ECALS .16
Figure 3 – Process flow for Phase II, Section A RosettaNet and MERCI .16
Figure 4 – ECALS response process.19
Figure 5 – MERCI response process.21
Figure 6 – Process flow for Phase II Section B ECALS to RosettaNet .27
Figure 7 – Process flow for Phase II Section B ECALS to MERCI .28
Figure 8 – RosettaNet response process .28
Figure 9 – Process flow for Phase II Section B ECALS to MERCI .30
Figure 10 – Example of a Google search engine finding a microprocessor supplier.37

Table 1 – Dictionary hierarchy and status (January 2003) .10
Table 2 – Selection of classes .15
Table 3 – Example of 3 level query .19
Table 4 – Example of detailed results of ECALS response .20
Table 5 – Selected classes populated in the MERCI database .21
Table 6 – Example of MERCI mapping table for .22
Table 8 – Mapping of properties completed by ECALS.29
Table 9 – Mapping of properties completed by MERCI (Class XJA644, Dynamic RAMs) .31
Table 10 – Section C mapping between RosettaNet and MERCI (IEC).34

– 4 – TR 61908 © IEC:2004(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
THE TECHNOLOGY ROADMAP FOR INDUSTRY DATA DICTIONARY
STRUCTURE, UTILIZATION AND IMPLEMENTATION

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC 61908, which is a technical report, has been prepared by IEC technical committee 93:
Design Automation.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
93/195+195A/DTR 93/205/RVC
Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

TR 61908 © IEC:2004(E) – 5 –
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 6 – TR 61908 © IEC:2004(E)
INTRODUCTION
In order for a standard to be effective, there need to be utilization and implementation. In
today’s global economy the leading edge companies forge ahead with their agenda and many
times produce what are known as pseudo-standards. Whether driven by an individual
company (i.e. Microsoft) or a consortia group, the ability to satisfy a customer need is their
main focus and goal. This, in many instances, puts the groups developing standards in a
“catch-up” mode while they make sure that industry has accepted the new concept, domain or
technology. Unfortunately, although there may be better ideas developed during the
standardization process or the playing field be levelled by the standard requirement, there is a
“reluctance to change” by those organizations or individuals that have invested a good
number of resources in developing or implementing the new concept.
If the standard defines physical performance requirements or conformance details, the
contractual agreements between members of the supply chain handle these according to an
implemented revision level. Many engineering hours are spent in determining the variation
between an existing version and a new change proposal, to ascertain whether the change is
compatible with the implemented processes, or whether the change would require a major
process overhaul. The effort to change, many times, impacts business relationships and thus
support of the next revision of the standard.
When it comes to software these issues become more complex, and take on market share,
technical competence, business process, and competitive rhetoric significance. Instead of
working together to help the industry, many times the players work to enhance their own
position. This is counter productive to helping the electronic industry make sound decisions
and continue to follow along the path of outsourcing much of the supply chain transactions,
whether purchasing, fabrication, assembly or testing of electronic hardware.
In order to clearly define the difference between a dictionary and a library; a dictionary
contains only meta data (data about data supported by an Information model of such entries).
So the definition according to a certain methodology is given of a specific characteristic, for
instance “terminal diameter” For such a characteristic, the identification, description and value
representation shall be defined. What is not given in the dictionary is the actual value(s) of
diameters of something.
A library is like a catalogue. It uses dictionary entries to be built into the database. In a library
you find the characteristics with their values, so you can compare components of different
manufacturers on their characteristics.

TR 61908 © IEC:2004(E) – 7 –
THE TECHNOLOGY ROADMAP FOR INDUSTRY DATA DICTIONARY
STRUCTURE, UTILIZATION AND IMPLEMENTATION

1 Scope
This Technical Report is applicable to the technology roadmap for industry data dictionary
structure, utilization and implementation.
This report covers one aspect of industry relationships; that of data dictionaries. A data
dictionary is made up of information about products. The products can be electronic
components, base material, clothing, chemicals or any product that can be described in terms
of an industry understood descriptive name (element) and the characteristics that make up
that part (attributes). Another item that helps data dictionaries become very efficient is to
reuse the characteristics (attributes) in more than one element. Reuse of information is
desirable in any implementation strategy in order to reduce search time for the
implementation software. The topic of discussion, therefore, in this report is the status,
completeness, implementer goals, and standardization efforts related to electric components.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 61360-1, Standard data element types with associated classification scheme for electric
components – Part 1: Definitions – Principles and methods
IEC 61360-2, Standard data element types with associated classification scheme for electric
components – Part 2: EXPRESS dictionary schema
IEC 61360-4, Standard data element types with associated classification scheme for electric
components – Part 4: IEC reference collection of standard data element types, component
classes and terms
ISO 13584-26, Industrial automation systems and integration – Parts library – Part 26: Logical
resource: Information supplier identification
ISO 13584-42, Industrial automation systems and integration – Parts library – Part 42:
Description methodology: Methodology for structuring part families
3 Overview
3.1 Dictionaries and Libraries
The ultimate goal is the transfer of product data in a library which can be interpreted by
computer systems. For this reason, the structure and meaning of elements in the libraries
have to be defined. In addition to a basic information model, which defines, for instance, that
each product has to have a unique attribute Product ID, and that it contains a list of
properties, the structure and meaning is defined by dictionary.

– 8 – TR 61908 © IEC:2004(E)
A dictionary contains the definitions of the properties which are used in libraries to describe
products. As such, a dictionary may define a property "supply current", specify its type and
potential value restrictions, define its meaning, its unique identifier, who has specified it, etc.
Normally, the properties are organised in classes which themselves are often organised in an
inheritance hierarchy.
A Dictionary Information Model describes the way in which a Dictionary is built. Thus, this
model specifies how classes are described (e.g. that they have a unique identifier, a preferred
name, a code, a set of synonyms, a textual definition, etc.), how properties are described
(e.g. that they have a unique identifier, a preferred name, a code, a set of synonyms, a textual
definition, a type definition, etc.), which data types are allowed for properties, how classes
can be related to each other, how properties can be related to classes, etc.
Examples of Dictionary Information Models are IEC 61360-1, IEC 61360-2 and ISO13584-
42, the DTD (plus verbal specifications) of the RNTD, and the table structure of the ECALS
dictionary (plus some verbal specifications). If a Dictionary Model is populated by classes and
property definitions, then a dictionary is produced (e.g. the RNTD or the IEC61360-4 or the
ECALS dictionary, i.e. the content of the tables). Of course, different dictionaries can be built
with the same Dictionary Information Model. For instance, besides the IEC61360-4 quite a few
other dictionaries have been defined and are under development on the basis of the model of
IEC61360-2 and ISO13584-42. A dictionary contains meta data in the sense that this data
describes other data, namely the meaning of product data in a library (or in an exchange file
which can be regarded as a library). For this purpose, in a library all elements are related to a
dictionary, i.e. all products belong to a product class and all values are defined in a
corresponding property of that class.
Electric component dictionaries are the most essential architecture in forming the basis for
shared understanding that makes product information exchanges possible. At the time of this
report there are three major Dictionaries that describe electric components being used
through out the global electronics industry. These dictionaries are supported by either IEC
standard bodies or Groups of consortia formed to address the global needs of their supply
chain members. It should be understood that there are several conditions for the data
dictionary to be useful to a trading partner transaction. These are:
• the dictionary descriptions must be clear and unambiguous;
• the dictionary shall have the possibility to be linked to a transport mechanism that must be
available to create, send and match responses to queries to libraries and/or dictionaries;
• the dictionary development must be flexible for quick update and approval of new
characteristics of products. The dictionary itself does normally not contain products
information;
• the implementation of the library/catalogue must have been populated by industry supply
chain members or the dictionary may also be populated by other organisations/persons;
• a group must be responsible for the development, maintenance and update;
• mapping software between different descriptions must be available;
• data dictionaries must be available on-line in an electronic format;
• there must be a depth of coverage that is aimed at completeness of the user needs.
3.2 The IEC Dictionary
The IEC Reference collection (dictionary) is published in IEC 61360-4. It has software support
through EXPRESS information modelling and other STEP tooling. MERCI an IST project
Number 12238 technically managed by the University of Hagen, Germany is based on that
IEC dictionary. Since approval for new entries in the dictionary would require consensus by
the countries that participate in the IEC, and the associated development and approval
process would take too much time special delegation has been made to a maintenance
agency and a validation agency to overcome this problem. By doing so, the IEC, being
sensitive to industry needs, is able to meet these requirements using the expertise available
in the many Technical Committees.

TR 61908 © IEC:2004(E) – 9 –
Sector Boards review project relevance to industry needs. The Presidents Advisory
Committee on Future Technology (PACT) evaluates visions for the future. Due to the late IEC
implementation of an on-line database of the dictionary, the number of implementations using
the IEC dictionary is only now starting. The initial population of the dictionary was created in
1997 and has been under constant development ever since.
3.3 The ECALS Dictionary
The Second dictionary is an expansion of the IEC effort. The dictionary is managed by JEITA
(Japan Electronic and Information Technology Association) under the consortia membership
known as ECALS. The ECALS format was built on the IEC standard and the members have
developed several search engines to help identify component availability. JEITA has a
Memorandum of Understanding (MOU) with the IEC in order to use the standard in order to
build the enhancements into the ECALS dictionary descriptions. Several of the ECALS
consortia users are also impatient to have new products defined in the Data Dictionary used
by ECALS. Delegates from Japan participate in the IEC Technical committee responsible for
the IEC data dictionary TC3/SC3D. Implementation is minimal and is used mostly by
Japanese OEMs who also produce electronic parts. The descriptions in the ECALS dictionary
provide different characteristics (attributes) from those that are available in the IEC. This is
part of the agreement reached in the MOU.
3.4 The RosettaNet Dictionary
The third dictionary is that of RosettaNet and its partners. RosettaNet has a dictionary that
complements that of the IEC and ECALS also by adding other features. The attitude of
RosettaNet members is that they must have a concept that is flexible, and has a fast approval
cycle amongst the trading partners. Their goal is responsive turn-around time for new product
descriptions or changes. Thus implementation and approval is measured in weeks as
apposed to months or years, and implementations grow at a phenomenal rate. New parts,
new members, new partners populating dictionaries have caused the need for high levels of
implementation software, search engines, transport mechanisms and other tools to smooth
the highway for B2B transactions. The energy level put into the RosettaNet consortia efforts
has not gone unnoticed, thus other industries want to take advantage of the same strategies
and goals. The RosettaNet dictionary has expanded outside electronic components
descriptions, to IT, SM and soon TC. RosettaNet has no desire to become the standard
developer; they do want to be the most robust implementation. To that end they have
achieved their goal, however with that comes the problem of a different structure or
description of the Data elements.
3.5 The Global Dictionary situation analysis
All three dictionaries use a number/naming scheme in order to keep track of their products,
elements and attributes. As can be imagined, the alphanumeric descriptions are relatively
different, although both ECALS and RosettaNet, at times, reuse each others main
alphanumeric description. However, the attribute lists of an individual alphanumeric may be
very different based on enhancements needed by ECALS or RosettaNet users. The IEC has a
standard scheme for the IEC descriptions and will not adopt other schemes lest it upsets the
significant organization of the information.
All three dictionary representatives, through their members, are active in the promotion of
their approach. Most new features originate from the IEC SC3D working group 2, the EEC
CIREP and MERCI projects and the close harmonisation work with ISO/TC184/SC4 PLIB. At
that point the new information is part of the maintenance programme of the IEC and follows
the natural process to update the standard on those items that are agreed to by the National
Committees of participating countries following the relevant procedures as described in
IEC 61360-3. The status of the three approaches is shown in Table 1.

– 10 – TR 61908 © IEC:2004(E)
Table 1 – Dictionary hierarchy and status (January 2003)
Dictionary Characteristic description
IEC status IEC has 483 class definitions
IEC has 1354 property definitions  (other IEC figures)
IEC has 113 condition definitions
ECALS status ECALS has 728 class definitions
ECALS has 2688 EC characteristic instances (1316 unique characteristics)
ECALS has 724 EC classes
RosettaNet status RNTD has 915 EC classes
RNTD has 44,279 characteristic instances (2774 unique characteristics)
– 2708 instances for automotive (417 unique characteristics
– 25121 instances for IT (907 unique characteristics)
– 16450 instances for EC (1450 unique characteristics)

The IEC dictionary is published as IEC 61360-4: 1997. An amendment is in circulation that
contains many additions to the IEC reference collection, mainly originating from IEC TC47
(geometries of electric components 50 %), the EEC ‘Good-Die’ project and TC47/PT62258
(DIE data 25 %) and JEITA/ECALS (connectors among others 25 %). The amendment has
been accepted as a CDV and a consolidated version of Part 4 containing the new material is
about to be circulated as an FDIS.
The IEC on-line database became operational in May 2003. It permits at present searching
and browsing with simple download of class and property definitions. Besides this database, a
CDROM database version has been produced by Dr. Radley; this contains, in addition to the
IEC on-line database, a whole set of input tools, output generators and format converters for
various data formats (tagged file, STEP physical file, XML and CSV formats) www.iec.ch.
The ECALS dictionary, ECDIC1.2J, dated January 2001, is available as Excel tables. It is
implemented in several Japanese supplier and customers, however search engines and
content are just evolving. http://www.e-parts.org
JEITA formed the ECALS steering committee in May 2000. In order to continue the efforts
toward commercial application of the achievements of ECALS, the national project aimed at
standardization and digitalization of catalogue data for semiconductor and electronic
components. The committee commenced action in August 2000, and disclosed to the public
version 1 of the ECALS dictionary developed in compliance with IEC standards. The
dictionary concepts are used by e-Pianet /EIAK in Korea and some RosettaNet members.
As a result of establishing guidelines for data distribution, improving software for such
services, recruiting companies for business start-up, and other commercialization activities,
the dictionary is spreading widely with disclosed data exceeding 310,000 as of July 2002.
Dictionary standards and member data is managed centrally at JEITA and distributed to the
members of the consortia. Parts data are kept in distributed storage by information suppliers
and joint servers.
The RosettaNet dictionary RNTD1_3, dated August 2001, is available as an Excel table and
an XML file. All versions of the dictionary include the same package of XML files and
spreadsheet documents, and can be viewed with the RosettaNet viewer. The official release
is the parsable XML file.
It is still a huge problem for non-XML users to read/study the RosettaNet results. The Excel
files are almost unreadable for a human, while forcing companies to use an XML environment
is in the author’s view still a bad proposition

TR 61908 © IEC:2004(E) – 11 –
Version RNTD1_4 is now also available as an XML file. It is clear that the RN dictionary was
based on ECALS and many of the identifiers are the same in the two dictionaries. There are a
number of cases where the two dictionaries use different identifiers for the same property
probably due to RosettaNet modifying the entity at some level. There is some overlap
between both classes and properties in the three dictionaries. However, the classification
philosophy and the end user goals vary dramatically. The philosophy used in the IEC is to
develop a standard that is bound by rigid rules; the philosophy of RosettaNet is to serve the
industry in the quickest manner possible and that the transport and search engines are
efficient in what they are supposed to do. Thus software implementation philosophy varies
and each software expert has his preference for the code and practice used in the queries
and response mechanisms. There are quite a few implementations and a good amount of
content in the data dictionary supply chain hierarchy.
Each dictionary and each organization has a focus and a goal. The purpose of the IEC
harmonization experiment was to explore the differences and the similarities between their
respective approaches to data element dictionaries. The world is changing, as are the needs
of the supply chain and the companies involved. In an ideal world everyone would use the
same procedures. If the world can manage to work around different power and voltage
extremes and different wall sockets, by exploring the conditions of interoperability and
granularity of the data elements, software can accomplish some of the needed bridging of the
gaps. The rule should be that all must work together. All must make a commitment that no
one gets left behind. Figure 1 shows the data element pyramid where each domain in their
specific focus needs to continue to serve the industry in their own way. RosettaNet has the
broader view and in many instances represents the leading edge. They have a responsibility
to work with ECALS enhancement. ECALS works to help populate RosettaNet dictionary
descriptions, and then influences the IEC standardization process catch-up.
IEC  1398/04
Figure 1 – Data element pyramid
3.6 The interoperability experiment
The intent of the "Electronic Component Description Interoperability Experiment" was to verify
the ability of one system’s query about electronic component information to be handled
correctly by another. As long as the software search engines are able to understand the
communiqué and manage the information without ambiguity, certification tools can be
developed that ensure that new techniques deal with the back and forward transfers are
compatible without data loss.
– 12 – TR 61908 © IEC:2004(E)
There were several phases to the Electronic Component Data Interoperability Experiment
programme. Each phase was intended to accomplish a particular function of the experiment.
TC93/WG6 was assigned the responsibility to monitor the results of each phase and make
any necessary adjustments in the subsequent phases. A preliminary report was to be issued
at the end of each phase highlighting the results and making recommendations to either the
participants or the concept developers. The three phases were:
• Phase I – Mapping and Database Structure;
• Phase II – Dictionary Interchanges (comprised of sub sections A, B, and C);
• Phase III – Formal Harmonization and Final Report.
3.7 Phase I mapping results
Mapping was intended to establish the relationship between the three formats and the
database structure. All three dictionaries were included in a one-to-one mapping that
contained as many classes as possible. The classes were selected from the most popular
group of classes that had information content.
A purely random sample would not provide the best results of the experiment. It was
determined that selection of classes with information content was essential. A list of
populated classes was created and the random sample taken from that list.
3.8 Phase II Dictionary Interchange results
The test plan called for the following data transfer concepts of queries and responses being
exchanged between the test plan participants in pair sets including:
Phase A:
RosettaNet Query> ECALS RosettaNet Query> MERCI (IEC) Phase B:
ECALS Query> RosettaNet ECALS Query> MERCI (IEC) Phase C:
MERCI (IEC)> RosettaNet MERCI (IEC)> ECALS For every possible partner query and response the following guideline was used to determine
the queries to be used in the experiment:
• 32 classes chosen from ECALS, RosettaNet, MERCI containing product information;
• 32 classes for the experiment were selected randomly from most populated group of
classes;
• 16 classes to be used by 3 fixed queries;
• 16 classes to be used by 5 queries based on business use cases;
• query results to be limited to 3 product listings per query response;
• RosettaNet Member Company to act as the single source for queries;
• class section was the same for sections A, B, and C.

TR 61908 © IEC:2004(E) – 13 –
Originally, all classes were to be selected randomly from all classes in the dictionary, but an
investigation revealed that such a pure random sample would only have 20 % of the classes
populated in real databases.
The ECALS and RN members suggested that classes with part information contents were
essential for this experiment. A list of populated classes was created and a random sample
taken from that list. The result of that sample is shown below.
3 classes Populated in all three organizations
9 classes Populated in two organizations
18 classes Populated in one organization
2 classes Not populated in any organization
(they were selected intentionally)

The details of the experiment are provided in Clauses 4 and 5.
3.9 Phase III Formal harmonization results
The final phase of the experiment will involve doing a data analysis of the three phases of
query response pairs (Phase A, Phase B, and Phase C). The results of the experiment will
then be circulated to the test plan participants in order to produce a series of conclusions and
recommendations. The goals of the conclusions and recommendations are to provide a
roadmap or a practical guide on how to move forward in modifying existing and producing new
dictionaries in order to achieve a greater level of interoperability.
4 Background
The need to determine interoperability between and among data element users was first
discussed during the TC93 meeting held in Florence Italy, 2001. Proposed to the TC93
plenary session, the project was approved with the idea that a test plan should be developed
and a group of individuals identified who could participate in the experiment. The project
goals were identified during a meeting held in Arizona USA in February 2002. the project was
discussed during the ACET and ACET Area 4 meetings held in Geneva in April 2003. Those
discussions led to completion of the preliminary test plan that explained the goals and steps
to completion. TC93 issued a new work item proposal based on those discussions and
reports. It was circulated and approved by national committees in January 2003. It was
93/164/NP. This clause of the report details the original dictionary mapping proposal.
4.1 Evaluation techniques
Several phases were defined for the TC93/WG6 interoperability experiment. The goal of the
activity was to determine harmonization complexity and what accomplishments can be shared
with a global industry concerning evaluations of Phases I, II, and III evaluations. Some of the
evaluations were performed by an independent group of participants who already were
involved in the candidate's procedures, i.e. ECALS, RosettaNet, and MERCI. Other
evaluations were to be performed by WG6 personnel. Evaluations involved in the programme
included:
• comparison of class structure and variation;
• response from industry and exchange partners regarding class harmonization proposal;
• display of class and query information at http://www.rntd.info/harmony/query.asp;
• use of the NIST reflector tc93-wg6@nist.gov;
• store query results and analysis at an open IEC TC93 WG6 ftp site ftp://ftp.iec.ch;
• conference call strategy;
– 14 – TR 61908 © IEC:2004(E)
• issue tracking system and procedure;
• email notification when necessary on topics for review or input.
4.2 Proposed participation
All IEC member countries were invited to participate in the programme. Participants should
have experience in Web-based data transfer and have the credentials from their National
Committees. Participation in Phase I and Phase III would be as a part of the TC93
membership. These phases were coordinated through the central office as a part of the
normal information distribution system.
Phase II was coordinated by the officers of TC93WG6. Individuals, with their National
Committee approval, could make request directly to the officers of WG6 or through the IEC
Central Office. As a part of Phase II all participants received their time frame and schedule for
sending, receiving or returning query information. A master schedule was maintained by WG6
officers and was available for review on the programme’s IEC Web site.
4.3 Proposed process flow
In order to understand the working of the programme, a process flow was developed for the
proposed experiment. Coordination of this flow was delegated to WG6 officers who became
the interface between the participants. The process flow also shows how the database on the
Web site was managed.
During the programme, the process flow was used to identify various milestones. The status
of each participant in any of
...