Full text of "Data model development and validation for product data exchange"

See other formats

NISTIR 90-4241

NEW NIST PUBLICATION
December 1989

DATA MODEL
DEVELOPMENT AND
VALIDATION FOR
PRODUCT DATA
EXCHANGE

Mary Mitchell

U.8. DEPARTMENT OF COMMERCE
National Inatituta of Standards
and TochnoloSy

Cantor for Manufacturing Engineering
Factory Automation Systems Division
Gaithersburg, MD 20899

Yuhwei Yang

D. Appleton Co.

Steve Ryan

QE Aircraft Engines

Bryan Martin

Lockheed

U.S. DEPARTMENT OF COMMERCE
Robert A. Mosbacher, Secretary

Lee Meroer, D eputy Under Secretary
for Technology

NATIONAL INSTITUTE OF STANDARDS
AND TECHNOLOGY

Raymond Q. Kammer, Acting Director

NIST

NISTIR 90-4241

DATA MODEL
DEVELOPMENT AND
VALIDATION FOR
PRODUCT DATA
EXCHANGE

Mary Mitchell

U.8. DEPARTMENT OF COMMERCE
National Inatituta of Standards
and Tachnolo^

Center for Manufacturing Engineering
Factory Automation Systems Division
Gaithersburg, MD 20899

Yuhwei Yang

X Appleton Co.

Steve Ryan

GE Aircraft Engines

Bryan Martin

Lockheed

January 1990

U.S. DEPARTMENT OF COMMERCE
Robert A. Mosbacher, Secretary

Lee Mereer, Dep u ty Under S ecr e tary
for Technology

NATIONAL INSTITUTE OF STANDARDS
AND TECHNOLOGY

Raymond Q. Kammer, Acting Director

V...

DATA MODEL DEVELOPMENT AND VALIDATION FOR
PRODUCT DATA EXCHANGE

Mary J. Mitchell, NIST
Yuhwei Yang, D. Appleton Co.

Steve Ryan, GE Aircraft Engines
Bryan Martin, Lockheed

ABSTRACT

Data modeling techniques have been used extensively in the
development of an emerging standard for the exchange of product
design and manufacturing information. PDES, Inc., an industry
cooperative, is applying resources to accelerate the development
and implementation of this emerging standard, the Product Data
Exchange Specification (PDES). An objective of PDES, Inc. is to
validate the completeness and usability of the specification.

This paper describes some strategic and technical issues which
directly impact this effort. Experience with actual validation
activities identified the need to develop additional requirements
documentation. This paper serves as the background for a series
of papers which will describe the actual methods and processes
used in the requirements specification activity. Three types of
results came out of this requirements activity. The form of the
project deliverables changed considerably. Insights on
conducting requirements activities were identified. New issues
on the relationship of this work to portions of the specification
were identified.

Introduction

The Product Data Exchange Specification (PDES) is an emerging
standard for the exchange and integrated use of product
information over the life-cycle of a product (fig. 1). This
specification will play a key role in improving competitiveness
and the ability to manufacture products in a world market
[C0088].

The need for standardization has been nationally [HEN88] and
internationally recognized. Subcommittee 4 of the International
Standards Organization (ISO) , Technical Committee 184 (TC184) ,
passed a resolution describing the need for such a standard
(Resolution 1, ISO TC184/SC4, July 1984) ; this need has been
reaffirmed on a number of occasions. The development has
required enormous amount of technical effort. There have been
hundreds of contributors from a wide spectrum of industry. The
national effort has been coordinated by the IGES/PDES

Organization [SMI89] and the international effort has occurred
within Working Group 1 of ISO TC184/SC4. Both of these standards
organizations have the common goal of having a single standard.
The first working draft of the specification has been submitted
to ISO TC184/SC4 [SMI88]. It has been registered with ISO as
Draft Proposal 10303.

PDES differs from many existing standards in that it is not based
upon any proven implementation. The scope, complexity,
divergence of approaches, divergence of disciplines, and
immediacy of need demand coordinated action. Achieving a quality
standard which is useful across industry boundaries is of the
utmost concern.

The ISO ballot on the draft proposal and the United States ballot
response made two facts evident. First, an enormous amount of
technical effort has been accomplished. Second, the effort is
not complete and the content is untested. The ballot has
identified what areas need the most effort as well as many
specific deficiencies with some proposed solutions. In this
respect, the ballot was positive. The ballot was the first
comprehensive evaluation of the technical content, and it is
helping to set the priorities of the committees involved in the
development .

Another organization is also working towards the common goal of a
quality standard. PDES, Inc. is a cooperative of more than
twenty companies from the aerospace, automotive, computer, ship
building, and other manufacturing sectors. PDES, Inc. was formed
to accelerate the development, validation, standardization, and
implementation of PDES. This organization has advantages over a
standards organization of full-time resources, a restricted
scope, and a more controllable organization. PDES, Inc. has
government associates as well. The National Institute of
Standards and Technology (NIST) is one; NIST's National PDES
Testbed has participated by providing testing facilities, by
contributing to test development, and through configuration
control of the standards documents [FUR89]. The requirements
effort described is being conducted by PDES, Inc. with NIST
participation. All authors were part of this requirements
activity.

The focus of this paper is on providing a framework for PDES,

Inc. validation efforts and identify how this affects the PDES
specification. Data modeling has been and continues to be a
fundamental technology used in developing the specification.

This report is designed to provide the foundation for a series of
papers which will follow the process of using the formal
description techniques for describing information requirements
and for ensuring that a model which embodies these requirements
is useful for the purpose intended. The series will describe;

1) the methodologies used for documenting requirements and
developing information models;

2) the process of developing information models;

3) a methodology for model validation and a description of
testing techniques; and

4) the development of test criteria, testing suites, test
procedures and such.

The series will makes some important distinctions between
appropriate validation techniques for models containing
information requirements.

The rest of the discussion in this paper provides additional
background material that will be needed to understand the series
of papers. Certain barriers to providing effective feedback and
acceptable technical solutions to the standards organizations
have impacted the critical success factors for this project.
Identifying criteria to judge the success of a project or
requirements activity is very important.

After some experience was gained by PDES, Inc. project members, a
review occurred in the form of a requirements activity. A brief
introduction to this requirements activity is provided, and the
results are described along with their effect on the PDES, Inc.
project as a whole. The findings changed the form of the project
deliverables considerably. Insights on conducting a requirements
activities are identified. New issues on the relationship of
this work to portions of the specification were identified.
Finally, the current direction of the project is provided.

The Initial State

The PDES, Inc. project began its efforts with a collection of
conceptual information models and the formal descriptive language
models which were developed by the standards organization. The
project was divided into three teams. One team focused on
improvements to these baseline models such as completing the
documentation. One team concentrated on testing and validating
the models. The third team was responsible for the software
environment and prototype implementations.

The decision was made in the first phase of the project to limit
the scope to mechanical piece parts and rigid body assemblies.

In addition, this initial phase was only concerned with PDES used
for exchange purposes and not for the integrated sharing of
product data between processes. The modeling team identified the
subset of models needed for this purpose. This team studied,
evaluated the quality of the modeling, and corrected
deficiencies. The validation team developed a model validation
methodology which was adapted from accepted software testing
methodologies [HET88]. The implementation team concentrated on

putting together a prototyping environment. Some months of work
took place, and reworked models were released as feedback to the
standards organization. There were difficulties associated with
completing the models and testing them. A limited number of
these problems have more general relevance to data modeling
projects, and these deserve discussion.

Barriers to Making it Work

The barriers to providing effective feedback and technical
solutions that are accepted by the standards organization really
fall into two categories: those which are related to PDES
strategic issues and those which are technical issues. The
strategic category includes scoping issues and the standard-
making process. The technical concerns involve the use of
multiple data modeling methodologies, the lack of proven
techniques for validating conceptual models, and the lack of
software tools that work together to aid in the development and
testing.

The scope of PDES is enormous. PDES is envisioned to support all
aspects of product description from initial conception through
product design, manufacture, support and disposal. In addition
to this, PDES is intended to support a broad industrial base.
There is an analogy between this effort and any enterprise which
attempts to get its information requirements under control. Any
project which is accountable must restrict the scope of its
efforts to something which is both useful and realistically
accomplishable within the allowed schedule and resources. The
challenge to the PDES, Inc. project has been to carve out a
useful subset of the entire PDES effort, and at the same time to
ensure that the piece will fit into the larger scheme. The
challenge to the first data modeling project for an enterprise is
to build a framework for information requirements and then to
scope follow-on efforts into useful and manageable pieces.

The standards-making bodies must achieve a consensus on technical
content before a standard can be achieved. Alternative technical
solutions must be weighed, and one solution must be agreed upon.
This consensus-building process can be difficult and lengthy. It
is appropriate for each member of such an activity to have their
own company's best interests in mind. A standards organization
has no control over the available manpower or the skills that
these resources have. Neither contract nor employment bind
members to work commitments. The standards organization
management must always rely upon the good will of corporate
management to support their member contributions. A shortage of
team skills, data modeling skills and technical publications
skills have had a negative impact on the PDES development effort
[DAY88] .

The need to recognize that multiple agendas will exist, the need
to obtain committed resources, and the need to have the correct
balance of skills available are all project-planning issues.

These issues were addressed by the PDES, Inc. requirements
project, and they are relevant to other requirements projects and
data modeling activities.

The technical issues are not any easier to solve. One technical
issue has been the data modeling techniques. In developing PDES,
a number of data modeling approaches have been used. EXPRESS is
formal descriptive language for data definition. EXPRESS was
chosen for writing the normative specification forwarded to ISO
TC184 SC4 . IDEFIX is a graphical semantic data modeling
technique. An informational annex to the specification used
IDEFIX. IDEFIX and other data modeling techniques were used to
develop the information content embodied in the specification.
Each committee within the IGES/PDES Organization chose the
technique or techniques they found most appropriate [BUR89]
although there were attempts to restrict their work to either
IDEFIX, EXPRESS or both. Only IDEF and EXPRESS are being used in
the PDES, Inc. efforts.

No proven translation utilities exist between IDEFIX and EXPRESS.
There is no direct correspondence between all concepts, although
a correspondence can be derived for a majority of concepts.

While EXPRESS definitions can convey more concrete implementation
decisions and more formalized constraints, the semantics of
information should be compatible between the IDEFIX and the
EXPRESS forms. The compatibility of semantic content is one key
issue in validating the specification.

Another technical issue is related to the best approaches for
testing conceptual information models. The initial months of
experience with the software testing-based techniques led some
project members to question whether there were better methods for
verifying the quality and usefulness of these resources. The
criteria found in the specification was either extremely high-
level, such as design goals, or explicitly stated within the
model to be tested. Many criteria that the testing team could
derive readily were subjective, and there were questions of
whether the criteria could address usefulness and usability
issues. One sample question relates to the Geometry Model [sub-
clause 4.3], is it meaningful to test the model's elements when
they are only used when collected together with elements from
other models? A test criteria task group was formed to analyze

the techniques in use and to refine these techniques to make them

more appropriate for testing information models.

The desired environment for developing complex formal
specifications would include software tools that would both aid
in the development and participate in the validation of the

specification. Fragments exist which should be part of this

environment, but there is nothing which comes close to a
comprehensive toolset for PDES. Such tools could play an
important role in the fitness testing of information models. The
testing tool set should include modules to check the syntax, to
check the semantic consistency, to provide for constraint
checking libraries, to support the convenient capture of test
results, and to support a simulation environment. Many questions
related to semantics, usefulness, and compatibility between
IDEFIX models and EXPRESS specifications can only be answered by
either simulation or actual implementation. Simulation
techniques have promise and other standards efforts using formal
descriptive techniques have found building a simulation
environment to be essential [SIJ89].

Where the Effort Is

Management of the PDES, Inc. project chose to study the concerns
raised during the initial months of experience by bringing
together a small task-group. The most pressing concerns rested
within the domain of testing and validation. The testing tasks
were openly accepted as the most difficult to accomplish. The
top priorities were to:

Develop a testing approach that could evaluate "usefulness"
by defining an applications framework for PDES.

Develop criteria for the selection of targeted applications.
Develop plans and justifications for follow-on activities.

The findings of this effort set the direction for the current
efforts of the entire project.

Impact on the PDES» Inc. Project

The recommendations identified by the PDES, Inc. testing criteria
task group have resulted in key refinements to the interactions
between the teams. Modeling efforts are now focused on building
context-driven integrated models (CDIMs) which focus on the
information requirements of specific applications and identify
how to apply the more general resources found in the topical
models. Testing efforts are now focused on deriving acceptance
criteria based upon what is useful to specific applications and
are restricted to the use of PDES for exchange purposes. The
implementation team now has much more specific requirements and
priorities for the tools needed for model development and model
testing.

Lessons for Recruirements Activities

The task team developed a set of lessons learned from their
experience for the follow-on activities. We believe that some of
them have a more general application to activities beyond what we
are currently tasked to accomplish. These are:

Any project needs to gain peer and management support.
Activities which will accomplish this need to be planned and
scheduled periodically during the activity.

A team will naturally have diverse skills, personalities,
and agendas. The diversity is beneficial if individual
skills are identified at the beginning and continuing team
duties are assigned based on these skills soon after the
activity begins. Everyone on the team needs to be
responsible for tasks that they can successfully perform.

The structured methodology provided us with an operational
framework that was valuable in keeping us focused and making
efficient use of time. The specifics of this will be
discussed in a paper that follows.

The team effort really did produce better results. We had
good expertise and experience on the team. Still, even the
best individual contribution was weak when compared to a
team collaborative effort.

Having a support team was CRITICAL to the success. The
greatest impact came from those who participated in a review
capacity. Even the most brilliant idea needs a sanity
check. These reviews kept us on track, added value, and
accelerated our progress.

Other support team members allowed us to keep focused on our
work by making sure the facilities and supplies we needed
were available.

Additional Issues Identified

The testing requirements task group was able to identify
additional issues relating to the validation of CDIMs and the
specification. These issues could not be resolved within the
scope of the activity. They remain as issues which must be
resolved within the follow-on PDES, Inc. activities and through
PDES, Inc. coordination with the standards organization.

The first issue which needs resolution is the effect of CDIM
validation on the topical models and other work from the
standards organization. Validating a CDIM only validates the
portions of models that were needed by the application. A CDIM

is validated only for the specific usages within the application
context. The implication is that validation needs to occur for a
variety of usages before there is a degree of confidence that the
topical models in the specification are suitable for the variety
of disciplines the specification is targeted to support.

The next issue relates to what information should be in the
general requirements found currently in topical models. It is
likely that additional information requirements will be
identified for the application usages. The unanswered question
is by what criteria should these requirements be evaluated to
determine if any should be added to the resource pools of topical
models .

The last issue is that the review of CDIM development and testing
approach identified a relationship to work going on in the
Application Validation Methodology Committee of the IGES/PDES
Organization. Their application protocol (AP) work has similar
concepts [HAR89]. The AP methodology has only recently been
adopted for PDES, although the AP methodology is being tested in
the IGES environment. This methodology requires further
refinement in order to ensure its utility for PDES. We feel that
the CDIM development and testing should precede the development
of standardized application protocols.

Current Direction

There are four follow-on activities taking place. Two are
developing CDIMs and two are developing testing criteria for
CDIMs. This work will take three months to complete.

Terminology Defined

The following terms can be expected to be used throughout the
series of papers:

Application Protocol (AP) - A method to achieve
consistent and reliable exchange of product definition
data within a specified application area. The key
components of an application protocol are a conceptual
information model for the application area with
supporting documentation, an application protocol
format specification, and a set of application protocol
test cases. [HAR89]

Assertions - A logical expression specifying a state
that must exist and/or a set of conditions that a
process interface must satisfy at a particular point
during process execution. [IS089-1]

Conceptual Information Model - A description of the
information requirements, relationships between
informational objects, information structure, and
constraints for a subject area.

Conformance Testing - The testing of a candidate
product for the existence of specific characteristics
required by a standard. Testing the extent to which an
implementation under test is a conforming
implementation. [OSI88]

Context Driven Integrated Model (CDIM) - A conceptual
information model which represents the information
requirements of a discipline or application usage. The
model is integrated because it draws upon the resources
of other models to specify shared information
requirements and is not specific to an application.

Expected Result - A foreseen test outcome converted to
the required form for analysis. [IS089-1]

Fitness Test - The review and walk-through of an
application reference model which demonstrates that the
model is useful in a particular application area.
[IS089-1]

Integrated Model - A conceptual information model
which represents the assemblage of multiple information
models into a coherent, non-redundant , and internally
consistent model. An integrated model is characterized
by an even degree of detail and elements which are at
the same level of abstraction.

Integrity Testing - Those tests applied which
demonstrate that an application reference model is
syntactically correct and self-consistent. [IS089-1]

Semantics - (1) The meaning that is assigned to an item
of information. [HAR89] (2) The discipline of
expressing the meanings of computer language constructs
in metalanguages. [ANS83]

Topical Model - A conceptual information model which
represents the set of information requirements needed
to represent a subject matter. A topical model is
intended to be a shared resource and therefore is not
expected to contain concepts specific to any particular
application or industry.

Verification - The process of determining whether or
not the products of a given phase of the development

cycle fulfill the requirements established during the
previous phase. [IEEE84]

VizUsility Testing - The process of fitness testing and
integrity testing. [IS089-1]

BIBLIOGRAPHY

ANS8 3

"Software Engineering Standards: ANSI/IEEE Standard 729-
1983, Glossary of Software Engineering Terminology," The
Institute of Electrical and Electronics Engineers, Inc.,
1984 .

BURS 9

Burkett, W. , "What is PDES and Why is Everyone Saying
These Things about It," California State University -
Northridge, Industrial Engineering Department, Masters
project, 1989.

C0088

Cooke, P. , "Summary of the New European Community
Approach to Standards Development," National Institute
of Standards and Technology, NISTIR 88-3793-1, August
1988 .

DAYS 8

Day, T. and Lopatka, R. , "Barriers to PDES Approval,"
Conference Proceedings, Society Mechanical Engineers,
March, 1988.

FIPS88

"Conformance Testing Policy and Procedures." Draft
Federal Information Processing Standard. National
Institute of Standards and Technology, 1988.

FURS 9

Furlani, C. , "The National PDES Testbed - An Overview,"
Proceedings of UPCAEDM'89, Laramie, Wyoming, 1989.

HAR89

Harrison, R. and Palmer, M. , "Guidlines for the
Specification and Validation of IGES Aplication
Protocols," National Institute of Standards and
Technology, NISTIR 88-3846, 1989.

HEN89

Henghold, W. , Schumaker, J., and Baker, L. ,
"Considerations for the Development and Implementation
of PDES within a Government Environment," Manufacturing
Technology Directorate, Wright Aeronautical Laboratory,
Air Force Systems Command, Wright-Patterson AFB, OH,
AFWAL-TR-89-8009, 1989.

IS089

Owen, J. , Kemmerer, S., and Woodall, A., "Conformance
Testing Methodology and Framework; General Concepts," ISO
TC184/SC4/WG1 Document Number N355, April 1989.

OSI88

"OSI Conformance Testing Methodology and Framework; Part
1: General Concepts," ISO Draft International Standard
9646-1, 1988.

SIJ89

Sijelmassi, R. , "An Object-oriented Model for Estelle and
its Smalltalk Implementation," National Institute of
Standards and Technology, Technical Report NCSL/SNA-89/7 ,
1989.

SMI88

Smith, B. and Rinadot, G . , "Product Data Exchange
Specification: First Working Draft," NISTIR 88-4004,
National Technical Information Service (NTIS) , Order PB
89-144794, 1988.

PDES EXCHANGE ENVIRONMENT

Ilf

.V •”

A •

V •».

.;.;k

’I

\*'\ *\

■ •y

; T*

' ’w.,»

^.: -W'v;.

f '

01 vi

.uA'- '

' '• •*■■ '■^'- '}} ‘s'

t. ->.“'

•.

:ijf ^ ‘vtu,.-

tr'-'

' '*' jili i (.•

.•»1. *•»•' ,

' V''?'

.S-

4 ■''’

4 ^/

NBS«1 14A REV. 2-80

U.S. DEPT. OF COMM.

U.S. DEPT. OP COMM.

BIBLIOGRAPHIC DATA

1. PUBLICATION OR
RE^PmXtJo.

2. Performing Organ. Report No.

3. Publication Date

SHEET (See instructions)

NISTIR Qn-L241

FEBRUARY 1990

4. TITLE AND SUBTITLE

Data Model Development and Validation for Product Data Exchange

5. AUTHOR(S)

Mitchell, Mary J., Yang, Yuhwei, Ryan, Steve, Martin, Bryan

6. PERFORMING ORGANIZATION (If joint or other than NBS, see in struction s)

NATIONAL BUREAU OF STANDARDS

U.S. DEPARTMENT OF COMMERCE

GAITHERSBURG, MD 20899

7. Contract/Grant No.

8. Type of Report & Period Covered

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State. ZIP)

10. SUPPLEMENTARY NOTES

I ‘ Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. abstract (A 200-word or less factual summary of most significant in formation . If document includes a significant
bi bl lography or literature survey, mention it here)

Data modeling techniques have been used extensively in the
development of an emerging standard for the exchange of product
design and manufacturing information. PDES, Inc., an industry
cooperative, is applying resources to accelerate the development
and implementation of this emerging standard, the Product Data
Exchange Specification (PDES) . An objective of PDES, Inc. is to
validate the completeness and usability of the specification.

12. <EY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semi colon sj

Data lysodel Validation, Data Modeling Methodology, Data Modeling Projects, Product Data,
Testing Methodology

13. availability

, X; Unlimited

j For Official Distribution. Do Not Release to NTIS

1 1 Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

15. Price

AO 2

USCOMM-OC 8043-P80

. * »»■

*=,"- 4^'^':''t .1

iiivi.- ■• .‘iiTc-rt'j

ki>r<MOO ■«i0 ^*;,w

V!!fio^jjv!W«*!‘'#*2) T33{f|

' ■3 jr'ltl3U« 0fi^'-3 JT(t

^/.'■'' :...' r • ‘■'■v • -■'■•?jr....'f:.f3.U*5V oiif- ‘ ■^i£?vs9Q laiX^S'

w ■&£' n- MB wiiiialili;;

r .»\ 'i

;u , . r'

f '%i1

■x ■• • .,v : >..v. tv j ^ X Ts^ aAviorr ah': ’#i

X' ^ ■’ V ^ 'vi:i i }^‘3x^a.^Awr.?^.u %

.V««— - , »-•••»•• .• -w • . -.nwv ti — 1«» ‘ —

1^:11, M '

, ' ?"!

rc-wi

■4',.ff>i

'■ ";■ V

,.^ »e«- .It -u.ii*., «■ • JM .<aww», ■■Pi>»^ "'*’^*’^***** ^^! i ; * ?| *" * ' ?* '^!y*^^**™*"

• -.1, r’.i ■ . ' ■ . .*1^ '^*'' ..v.:' . I ' W:*' ■<.! ^»fiti«»/!i(^S AV'T.^AflT-2

'f..'.." $. (I , ■ .,Ti II. .■ '«\<’ini'cii.-'a\9JH no

r'^"

"■ !'?:-^V.:. ..lI.rir.'SlJ' VniXfikbOat

IvVj •'■■' - - - -- -I-

.r: - . ■ ,. r-. , ri,?.,-i'._ -pi'f, n$- SO _

-.1 ., r... ..‘S', r'v’f ■'’!;!'* ■ i'i :.''-:Jf''>iarjf,i'n'S,sa ba.®'

‘ -.t^, ■■:;■■ i% nrt.;V- v<^3 vjvi.l

.- J ■ ■ .. K,,-..: ^5-..

. .1^ ,. \r^ 7 - ■ cu i" 3-'ia

■ , ^ , ; 'ft.*, ,im£* . •'^ 5. Crf.ttO-- Siii^

• ' f .'r'. I'-'U'' 't r:?>d

. . . r ^ ^

., ^itrxX '

\ : X jr -i

•; '. fet'- • .lO f. ? fii.J

t., '’;‘«.ir ; ! >.M ri;DHlw

I I

ns(5;.rX., ■ s.n:s

-■ T:

^ '4

t<. ■ ^ j,' »-

:.. :•,-/' J

rfii-

■i.J

f ./f •«' — — n -Ml--' vw<vmM'

A i-' r ' .sr

. ).>DXQbcdi^^^

'<t'

S.Ty, ct nwH jjO .f*«Mn.itf'i|«lOvj«»»J^

J. '.»(, - j W:rtl<«) li'i.^i.KinrsivOD u U ..Krt.sttuOljC] ' ■• 1«Mfi>*W'>rU'»Cl>S,^

■

•-'nY;-*

"♦‘k, * • ,<>('•>•- ••,*t|,l ,, .[^TM) iH. iJBW'Hi'knl i«jinrb«T

Internet Archive Audio

Featured

Top

Images

Featured

Top

Software

Featured

Top

Books

Featured

Top

Video

Featured

Top

Mobile Apps

Browser Extensions

Archive-It Subscription

Save Page Now

Full text of "Data model development and validation for product data exchange"

See other formats