Guideline for Implementing the Universal Data Element Framework (UDEF)

Guideline for Implementing the Universal Data Element Framework (UDEF) Version 1.0 November 14, 2007 Developed By: Electronic Enterprise Integration Committee Aerospace Industries Association, Inc. Important Disclaimer: The Aerospace Industries Association of America, Inc. ( AIA ) has no intellectual property or other interest in this Guideline for Implementing the Universal Data Element Framework (UDEF). By developing this Guideline for Implementing the Universal Data Element Framework (UDEF) and making it freely available to anyone, AIA assumes no responsibility for this Guideline s content or use, and disclaims any potential liability associated therewith.

History Page Date Version Change Reason 1-11-2008 1.0 Original Release ii

1 Executive Overview...1 1.1 The Challenge:...1 1.2 Solution:...2 1.3 Purpose for this Guideline:...3 1.4 Target Audience:...3 1.5 When Used:...3 1.6 Benefits:...4 2 Guiding Principles for Use:...6 2.1 Characteristics of Organizations Implementing UDEF...6 2.1.1 Intra-Organization Application Integration:...6 2.1.2 Inter-Organization Application Integration:...6 2.2 Skills necessary for UDEF based application integration....6 3 UDEF Basics...7 3.1 Background...7 3.2 What is the UDEF...7 3.3 The UDEF is Enterprise Centric...9 3.4 Key Terminology...9 3.4.1 Data Element Concept...9 3.4.2 Object Class...10 3.4.3 Property...10 3.4.4 Qualifier Term...10 3.5 Mapping Enterprise Application Data to UDEF...10 3.6 UDEF Extension Process...11 4 High Level Metadata Management Architecture...13 4.1 Global UDEF registry hosted by The Open Group http://www.opengroup.org/udefinfo/defs.htm 13 4.2 Enterprise metadata registry/repository hosted within the enterprise...13 4.3 Application semantic alignment tool used within the enterprise...14 4.4 Industry registry/repository for subsets of UDEF optional component...14 5 Concept of Operation...15 5.1 Map Application Data Element Concepts to The Open Group UDEF Registry...15 5.2 Maintain a cross reference matrix for mappings across disparate standards and applications...16 5.3 A Sample Of How It Works...19 A. Appendix Use Cases...22 A.1 Example Use Case - Details Intra-Enterprise Application Integration...22 A.2 Example Use Case - Details Inter-Enterprise Application Integration...22 B. Glossary...23 C. External References:...23 iii

Table of Figures Figure 1 Complexity of Inter-Enterprise Integration...2 Figure 2 - Highlights the Cost Avoidance Opportunity...4 Figure 3 - The UDEF is Based on International Standards...8 Figure 4 An Example UDEF ID Derived from the UDEF Trees...9 Figure 5 Data Element Concept Diagram from ISO/IEC 11179...10 Figure 6 The Six Basic Steps for Mapping Data Element Concepts to the UDEF...11 Figure 7 The UDEF Extension Submittal Process...12 Figure 8 A UDEF-Based Metadata Management Architecture...13 Figure 9 The UDEF ID Provides the Global Indexing Key...15 Figure 10 An Example Cross Reference Matrix Highlighting the UDEF Indexing ID...16 Figure 11 Data Element Concepts from an Invoice Mapped to UDEF...17 Figure 12 Two Different Purchase Order Standards Mapped to UDEF...18 Figure 13 Two Example Export Files from Two Different Applications...19 Figure 14 UDEF with Two Example Export Files from Two Different Applications..20 Figure 15 Example Gap Analysis Results Using UDEF to Automate the Comparison 21 iv

1 Executive Overview This Guideline for Implementing the Universal Data Element Framework (UDEF) can assist organizations in reducing the costs of building and extending application-to-application interfaces that extend beyond the scope of existing standards whether within the enterprise or between enterprises or between industries. For this document, the terms organization and enterprise are interchangeable. Please keep in mind that this document is provided as a GUIDELINE and not a mandatory standard. Neutral data standards are a strategic enabler for reducing costs in application integration, avoiding the expensive and common tactical execution of point-to-point interfaces. Information standards such as STEP and ebxml have been adopted to solve the semantic integration challenge in specific domains, and are being progressively integrated at the international level. The UDEF global indexing standard has been designed to offer unlimited extensibility across all information domains to facilitate any semantic integration. At this time, UDEF is the only standard that is robust enough to enable integration across domain limited data standards. Like all neutral standards, the UDEF enables capture and reuse of knowledge of application subject matter experts and reduces the risk of losing it as resources change. Once the use of UDEF expands beyond the current pilot and proof of concept implementations to gain acceptance and adoption on a global scale, the use of UDEF will accordingly reduce costs in the supply chain whenever a single standard is not sufficient. 1.1 The Challenge: Enterprises must exchange data electronically within their industry and with enterprises in adjacent industries where there are many overlapping and conflicting data standards and lack of common vocabulary (semantics) across applications and their associated data stores. This challenge applies to any organization/enterprise that has the requirement to exchange data between applications, whether internal or external to the organization, and that cannot be adequately satisfied by an existing data standard. All organizations face the challenge of sharing data with organizations that they do not control. No single current data standard is sufficient to address all data integration requirements for all enterprises. 1

Figure 1 Complexity of Inter-Enterprise Integration Today, the alignment of semantics is a time consuming manual process. There is a need to automate the alignment of the semantics of different data sources. Thus mapping the semantics to an open standard alleviates the task and reduces cost. No single current data standard is sufficient to address all data integration requirements for all enterprises. Data standards are typically based on data models and are constrained to specific domains such as product definition, manufacturing, logistics, human resources, finance, health care, procurement, etc. Since there are numerous points of intersection between domains, a need exists to reduce this semantic integration effort. Also, organizations that intend to implement a Service Oriented Architecture (SOA) will likely need to address the same semantic integration challenges where the service extends beyond the scope of a single data standard. 1.2 Solution: The Universal Data Element Framework (UDEF) http://www.opengroup.org/udefinfo/defs.htm is a proposed global implementation of the naming convention and unique identification requirements specified within the international standard for naming and identification of data elements (ISO/IEC 11179-5). The UDEF naming convention includes seventeen object class terms that are intrinsically intuitive and eighteen property terms that are the same as the allowable core components representation types specified in Tables 8-1 and 8-3 of ISO 15000-5. The UDEF is not another data standard. The UDEF provides a semantic bridge between data standards or between applications that need to share data but cannot use an existing data standard. The goal of the UDEF Project http://www.opengroup.org/udef/ within The Open Group is to establish a global standard for categorizing data element concepts (see ISO/IEC 11179 for definition) that exist across multiple applications. The latest version of the UDEF is hosted on a Web server and is globally available to anyone with a Web browser. Extending the UDEF to address terminology not currently available within the UDEF is necessary for global adoption. This is facilitated through a manual extension process that is managed by The Open Group. When The Open Group completes the automated extension process, this guide will be updated to reflect the enhanced process. The UDEF global indexing standard enables the assignment of a unique language independent alphanumeric tag that computers can understand to a meaningful (semantically rich) name for each data 2

element concept that anyone on the globe can understand. For example, Purchase Order Number found in an invoice is a commonly encountered data element concept. This concept has a UDEF tag d.t.2_8 and associated UDEF name Purchase.Order.DOCUMENT_IDENTIFIER. Unique alphanumeric tags such as the UDEF ID enhance any automated mechanism for semantic alignment for inter-enterprise and intra-enterprise transactional processing and as applicable to support Service Oriented Architecture (SOA) requirements for integration across applications. For further explanation of this semantic alignment approach see Section 5.3. The UDEF name and associated ID pair is similar in several ways to the Domain Name System (DNS) used to manage computer-sensible IP addresses in a numerical string ( i.e. 123.456.789.12) format and to associate them to user-friendly formats such as www.yourcompanyname.com. If adopted on a global scale, the UDEF would become a Semantic DNS. Another example of an associated indexing identifier is the Dewey Decimal System used to categorize all books within a library, which allows a user to efficiently determine the location of a particular book Note that the specific use of the term index throughout this guide is key to understanding the UDEF. In this document, as in other documents about UDEF, what are being indexed are the data identifiers, not the instances of the data itself. This is not an index in the sense of a database index where access to data is being optimized. The UDEF provides hierarchical categorizations of object classes and properties. Some examples of object classes within UDEF are: product, enterprise, and person. Examples of properties within UDEF include, name, identifier, and date. The UDEF tag for an item of data is obtained by putting together the tags for the object class and the property of which it is an instance. An example UDEF object class combined with a UDEF property is Enterprise Name. Note that the classification depends on the context in which the data is used. For example, information about a person in a corporate directory might have object class "Employee Person", but when that information is used in a purchase order it might have the object class: "Approver Person". It is not possible to categorize all data in the abstract; however, each item of data is categorized by a unique and determinable UDEF in the context of a particular organization s process. Based on this principle, the UDEF is enterprise-centric and the intended use of the data within the organization/enterprise establishes the context a critical element for establishing meaning. 1.3 Purpose for this Guideline: This document provides guidance to assist organizations that decide to implement the UDEF. For how application-to-application cost can be reduced, see the UDEF Basics section. This is a guideline and not a standard. Use of this guideline is expected to simplify the data integration process and help enterprises reduce costs in the supply chain once the UDEF http://www.opengroup.org/udefinfo/defs.htm has gained broad acceptance and adoption. 1.4 Target Audience: The target audience of this guideline is any organization that has the requirement to exchange data between applications, whether internal or external to the organization, and that cannot be adequately satisfied by an existing data standard. 1.5 When Used: The primary use case is to align the data semantics between two or more applications that use dissimilar data standards. The integrating applications could be cross-domain or cross-industry, or cross application within the same company. Therefore, as an indexing standard the use of UDEF is always to simplify the alignment of data semantics between dissimilar data standards as referenced in Figure 2 below. 3

1.6 Benefits: Once it is widely adopted, UDEF and its method for indexing names across applications will enable savings where the scope of information extends beyond individual standards. Potential time and cost savings increase in accordance with the number of data stores that require integration, provided that companies invest in UDEF. UDEF definitions, a gap analysis tool, and other reference material are freely available at the Open Group website for enterprises and vendors to begin developing solutions based on UDEF. The Open Group is actively promoting vendor adoption through strategies such as vendor challenges. Smaller enterprises without an information technology (IT) staff will be able to leverage the UDEF through solutions and services resulting from these vendor challenges. The following figure highlights the potential cost reduction opportunities in a scenario where multiple applications from one organization use disparate and possibly overlapping data standards to exchange data with applications from other organizations (within or across industries). The traditional point-to-point approach becomes cost prohibitive for the multiple interfaces compared to the global semantic standard approach available via UDEF where the standards and applications are all indexed with UDEF IDs. Figure 2 - Highlights the Cost Avoidance Opportunity Today, enterprises need to access huge amounts of data of many different kinds both internally and globally. Within a typical supply chain many different standards are imposed on any given company, which causes significant cost impact converting data from one standard to another. Also, as this data volume increases it becomes harder to locate a particular piece of data. Thus, the organization operating costs increase, as users spend time searching for the right sources for that data. The latest trends in information technology architecture, particularly SOA, are reducing other cost factors but not this one. Data integration is a critical cost element of information technology development. 4

Similar to the Dewey Decimal System used in libraries the UDEF enables enterprises to assign a standardized index identifier to each data name used within their enterprise applications. This enables developers to identify the content of data sources more efficiently, reducing data integration costs. With a small amount of training the UDEF global indexing standard can be used effectively. The UDEF currently encompasses the data commonly used by most enterprises. There is a simple process for extending the UDEF to include more specialized data used by specific enterprises or within vertical market groups. Since UDEF is the only global indexing standard at this time that provides a scheme that transcends any domain and extends beyond the scope of any individual standard, an organization/enterprise can index its data names across disparate applications with a relatively low one-time investment and cut its data integration costs using tools built to leverage the UDEF ID. Examples: A large enterprise typically has many different information stores and applications, which organize and categorize data in different ways. Information flow between data stores and applications, either within an enterprise or between different enterprises, must be identified, analyzed for meaning, mapped, and potentially transformed into the needed data formats. The UDEF ID provides a global indexing alias that assists in data discovery and semantics alignment; but does not aid in the data format transformation process. Data analysis is an expensive task, carried out by teams of programmers, who may have documented descriptions of existing data to help them. Generally, the documentation available to programmers to accomplish the data analysis task is poor. The UDEF global indexing standard enables enterprises to categorize their data in a standard and consistent way. Providing globally recognized data element names and associated indexing aliases for the data, will reduce the time and cost of the effort by automating much of the data semantic alignment task. Small and medium enterprises will likely be expected to exchange data electronically with multiple partners using differing data standards. In those situations where the data to be exchanged is already available in a back-office application, the small or medium enterprise can realize cost savings if the applications have standardized interfaces. If the applications and data standards have been UDEF enabled, additional savings may result when the partners use differing standards. 5

2 Guiding Principles for Use: 2.1 Characteristics of Organizations Implementing UDEF 2.1.1 Intra-Organization Application Integration: Any organization that has multiple back-office applications with the requirement for application-toapplication data exchange, which cannot be adequately satisfied by an existing data standard. The organization may have its own IT staff or it may outsource the IT function; but in either case a significant portion of the IT function is to build and/or maintain application interfaces. 2.1.2 Inter-Organization Application Integration: Regardless of the size of the organization, the inter-organization application requirements are dependent on the number of trading partner interfaces. A large organization very likely has a large IT support budget, a high volume of data transactions, and will strive to use electronic data interfaces with all trading partners to minimize costs. A medium organization will likely have a small IT support staff that can build and maintain electronic data interfaces with their larger trading partners. However, they will likely use less complex interfaces with their smaller trading partners requiring more human intervention. A small organization will likely not have an IT staff and will either buy software, pay a third party service provider, or add labor to perform manual interaction with trading partner systems. 2.2 Skills necessary for UDEF based application integration. Subject matter experts in the applications to be integrated. Application interface developer with understanding of metadata concepts. This can be outsourced if no internal available resource exists. Knowledge of the UDEF and its key mapping principles. Strong linguistic skills in any of the languages in which a UDEF version exists. The UDEF is not dependent on any one language. 6

3 UDEF Basics 3.1 Background The Universal Data Element Framework (UDEF), which was developed by the U.S. Computer Aided Logistics Support (CALS) Industry Steering Group (ISG) in the late 1980s and early 1990s, represents a small but potentially crucial aspect of information management: specifically, simplification of information management through consistent classification and assignment of a structured indexing identifier to the names (metadata) of data. The UDEF provides a framework for naming and identifying data element concepts. It provides a means to associate different data element names (i.e. vocabulary terms) that semantically refer to the same concept, to a standard data element concept name provided by the framework that conforms to the relevant international standard on naming conventions, ISO/IEC 11179-5. This allows interpreting the meaning of data element concepts, which is the essential first step of enabling semantic interoperability between disparate applications. The Open Group is promoting the UDEF global indexing standard as the universally used classification system for data elements, and provides a web server that hosts the UDEF descriptions and identifiers to ease the process of translating between different data description standards. AIA is among several industries involved in developing and evolving the UDEF concept. The complete guideline package is available on the AIA Public Web Site (www.aia-aerospace.org/library/library.cfm). 3.2 What is the UDEF The UDEF is a proposed global instantiation of the naming convention and unique identification requirements specified by ISO/IEC 11179-5. The UDEF controlled vocabulary includes seventeen object class terms that are intrinsically intuitive and eighteen property terms that are the same as the allowable representation types specified in Tables 8-1 and 8-3 by ISO 15000-5 (formerly ebxml Core Components). 7

Figure 3 - The UDEF is Based on International Standards The UDEF trees (one for each UDEF Object Class and one for each Property) provide taxonomies of sub-types and roles. A UDEF Object Class and a Property are top-level components of a data element s pedigree. The words selected in each tree are abstract terms frequently used within domains that are commonly used by organizations and are based on existing standards or normalized data models from existing applications. By design, the UDEF trees have unlimited extensibility and can theoretically accommodate any data element concept within any domain relevant to any organization. 8

Figure 4 An Example UDEF ID Derived from the UDEF Trees 3.3 The UDEF is Enterprise Centric The UDEF is enterprise-centric, since the seventeen top-level object classes are all defined in the context of an enterprise. The UDEF is built around the basic premise that the enterprise establishes the critical cornerstone context for the semantic meaning of concepts that need to be exchanged between applications or systems either within the enterprise or between enterprises. The underlying assumption is that the enterprise manages data that is relevant to that enterprise. When a particular enterprise needs to share data with another enterprise, each needs to interpret meaning of the data in the context of the other enterprise. Once an organization establishes the type of enterprise it is and the role it plays, the meaning (interpretation) of all of the other UDEF objects will fall into place in the context of that enterprise. 3.4 Key Terminology 3.4.1 Data Element Concept A Data Element Concept as defined by ISO/IEC 11179 is a concept that can be represented as a data element, described independently of any particular representation. An example data element concept used by many enterprises is product scheduled delivery date. There are many possible representation forms for date such as July 5, 2006 or 20060705 or 07/05/2006, etc. The semantic meaning of the data element concept remains the same regardless of the representation form. ISO/IEC 11179 uses a diagram (see below) to further describe a data element concept and to compare it to a data element. The diagram highlights the fact that a data element concept includes one or more object classes and only one property. For each data element concept there are one or more possible data elements since there are potentially multiple ways of representing a given data element concept. 9

Figure 5 Data Element Concept Diagram from ISO/IEC 11179 3.4.2 Object Class An Object Class as defined by ISO/IEC 11179 is a set of ideas, abstractions, or things in the real world that are identified with explicit boundaries and meaning and whose properties and behavior follow the same rules. Within the context of any enterprise and the data that the enterprise needs to manage, a universal set of object classes include the seventeen identified in the UDEF Object Class List http://www.opengroup.org/udefinfo/defs.htm. If the list of seventeen is inadequate to accommodate all domains of all enterprises, then it is possible to extend the UDEF with one or more additional object classes. 3.4.3 Property A Property as defined by ISO/IEC 11179 is a characteristic common to all members of an object class. Within the context of the data that the enterprise needs to manage, a universal set of properties includes the eighteen identified in the UDEF Property List http://www.opengroup.org/udefinfo/defs.htm. The list and their definitions are derived from Tables 8-1 and 8-3 in ISO 15000-5 (same as ebxml Core Components Technical Specification). 3.4.4 Qualifier Term A Qualifier Term as defined by ISO/IEC 11179 is a word or words that differentiate a concept. Within the context of the data that the enterprise needs to manage, qualifier terms enable sub-type and role specialization of the universal set of UDEF object classes and properties. The primary approach for extending the UDEF is by identifying suitable qualifier terms for the UDEF object class and/or the UDEF property for a given data element concept assuming that the data element concept does not already exist within the UDEF. 3.5 Mapping Enterprise Application Data to UDEF When interfacing disparate applications, one of the initial design-time steps is to determine if the semantics are the same prior to determining a suitable transformation for those data element concepts that have different representation forms. There are six basic steps that one should follow when semantically aligning data element concepts used within enterprise applications to the UDEF. The six steps are described in the following figure, assuming that an appropriate UDEF name can be identified. When additional qualifiers to either a UDEF Object Class and/or Property are required, see section 3.6 UDEF Extension Process. Then repeat steps 1 through 6 to finalize the UDEF pedigree. 10

Figure 6 The Six Basic Steps for Mapping Data Element Concepts to the UDEF To leverage the advantages that the UDEF can provide, the UDEF ID should as a minimum be recorded as an optional alias for the data element concept within the API of each application or within a mapping matrix. If the enterprise has multiple applications, then a metadata registry should capture the UDEF name and ID for each data element concept that is shared between applications. The UDEF name and ID pair provides a simple but effective indexing mechanism for discovering reusable data element concepts across the enterprise. 3.6 UDEF Extension Process To extend the UDEF, one needs to develop a data element concept with proposed UDEF extensions that adhere to the requirements specified in The Open Group Guide for Extending the UDEF http://www.opengroup.org/bookstore/catalog/g064.htm. The following diagram highlights the process for extending the UDEF. See the Guide for Extending the UDEF for detailed instructions. 11

Figure 7 The UDEF Extension Submittal Process 12

4 High Level Metadata Management Architecture The following diagram highlights the basic elements of a metadata managed architecture and associated high-level concept of operations that the UDEF is intended to support. Section 5 of this guideline provides the concept of operation for implementing the UDEF. Each numbered component in the diagram corresponds to its associated paragraph in this section. For example, item number one in the diagram corresponds to paragraph 4.1.1 and item number two corresponds to paragraph 4.1.2. The concept is applicable to any organization interested in implementing the UDEF. This implementation guide is written to address the current web-based server that hosts the UDEF global indexing standard. Subsequent versions of this guide will address future Open Group UDEF Registry enhancements such as those that support the UDEF extension process Figure 8 A UDEF-Based Metadata Management Architecture 4.1 Global UDEF registry hosted by The Open Group http://www.opengroup.org/udefinfo/defs.htm Provides global central registry of existing UDEF names and IDs A planned enhancement will provide a capability (service) for extending the UDEF trees o Submitting the proposed extensions o Observe proposed extensions o Facilitate review and approval of proposed extensions to the UDEF Provide Web browser based access to all UDEF trees Provide various format (e.g., XML, RDF, Excel, etc.) access to UDEF trees 4.2 Enterprise metadata registry/repository hosted within the enterprise Should remain synchronized with the global UDEF registry and/or industry registry Provide registry for enterprise-adopted UDEF based data element concepts 13

Provide repository for mapping matrices (showing UDEF semantic alignment across the applications within the enterprise) Provide access to the content for enterprise users such as application interface developers Provides capability (service) for extending the UDEF trees enterprise unique o Submitting the proposed extensions o Observe proposed extensions o Facilitate review and approval of proposed extensions to the UDEF Provide Web browser based access to all UDEF trees 4.3 Application semantic alignment tool used within the enterprise Interfaces with enterprise metadata registry/repository Provides user-friendly interface to associate UDEF name and ID to enterprise application data architecture (such as enterprise data dictionaries). 4.4 Industry registry/repository for subsets of UDEF optional component Synchronizes with global UDEF registry Contains data element concepts applicable to the industry Provide access to the content for industry users 14

5 Concept of Operation This is the concept of operation for exchanging data between applications, whether internal or external to the organization, and that cannot be adequately satisfied by an existing data standard. 5.1 Map Application Data Element Concepts to The Open Group UDEF Registry Follow the six basic steps described in Mapping UDEF to Enterprise Application Data within section 3.5 above. If applicable, submit proposed extensions to the UDEF global indexing standard as described in section 3.6. The following diagram highlights the key role that the Global UDEF Registry plays in aligning data element concepts across different applications. Once the application data element concepts have been assigned a UDEF ID, it is a relatively simple process to use the UDEF ID to map data element concepts with different names that have the same meaning. As illustrated in the diagram, both the System A data element concept named Emp-Sal and the System B data element concept named Pay were independently mapped to the same UDEF name and ID pair; therefore, they have the same meaning. The UDEF ID should be assigned as an optional alias for each application and recorded in a mapping matrix. Figure 9 The UDEF ID Provides the Global Indexing Key 15

5.2 Maintain a cross reference matrix for mappings across disparate standards and applications The following example mapping matrix shows how the same data element concept, though named differently in each column, share the same UDEF ID. If all the data elements in all data standards and application interfaces were associated to a UDEF ID, mapping one data standard or application programming interface (API) to another would be greatly simplified and could be automated. Figure 10 An Example Cross Reference Matrix Highlighting the UDEF Indexing ID An example cross-reference matrix for a typical purchase order was developed by the Electronics Industry Data Exchange (EIDX) organization and is freely available for download at http://www.eidx.comptia.org/guidelines/xref_download.aspx. This cross reference matrix maps data element concepts that are common for a typical purchase order across widely adopted standards such as X12, EDIFACT, OAGIS, RosettaNet, and xcbl to the UDEF. The following sample spreadsheet extract shows example mappings where UDEF IDs are mapped to data element concepts in a government invoice transaction. When the data element concepts associated with the application that generates the invoice are also assigned a UDEF ID, mapping the data elements in a financial application to create the government invoice transaction, would be greatly simplified. Once the data elements in a financial application have a UDEF ID, cost savings can be realized in creating other transactions using the same data elements for the same or different trading partners, regardless of the variations in data element names and structures that different trading partners may use. 16

Figure 11 Data Element Concepts from an Invoice Mapped to UDEF To leverage the UDEF IDs as a common indexing mechanism, the use of an online gap analysis service enables an organization to substantially reduce the effort to align the semantics across disparate systems. In May 2003, a prototype online gap analysis service was demonstrated live at an EIDX Conference in Orlando, Florida. The following is an example mapping of a portion of a purchase order using two different file layouts for two different applications used to either generate or process a purchase order. The OAGIS file layout represents the purchase order from a customer s procurement application and the xcbl file represents an example target application layout used by a typical supplier s order management system. Note that for the purposes of this example, UDEF IDs have been embedded within each file. These UDEF IDs would provide the independently mapped basis for semantic alignment across disparate applications or standards. 17

UDEF Tagged Source & Target OAGIS Standard xcbl Standard Figure 12 Two Different Purchase Order Standards Mapped to UDEF 18

5.3 A Sample Of How It Works The following example shows how it works. Company A needs to send an XML file to Company B. Company B needs to process the data into their application using a flat file. COMPANY A XML File COMPANY B Flat File Layout Figure 13 Two Example Export Files from Two Different Applications For COMPANY B to use COMPANY A s data file to feed their application they will first need to map COMPANY A s XML Child Node names to their Flat File Data Element names. This can be difficult to do without a good understanding what exactly is provided in the XML Child Node names and the Flat File Data Element names. 19

This would have been a much simpler mapping process if UDEF IDs were associated to both applications and/or data standards. See the same XML file from COMPANY A below with UDEF IDs and look at COMPANY B Flat File Layout with UDEF IDs included below. Even though existing standards can provide this capability within their individual scopes, the UDEF global indexing standard can simplify integration across multiple scopes resulting in cost and time savings. COMPANY A XML File with UDEF COMPANY B Flat File Layout with UDEF Figure 14 UDEF with Two Example Export Files from Two Different Applications Having the UDEF IDs in both shows us which XML Child Notes and Flat File Data Element have the same meaning. We still may have differences in field size and type, and missing or extra data items; but the semantic alignment has been simplified. COMPANY B only has to do assign UDEF IDs to it s flat file layout once. Once this is done COMPANY B can use that information to do their semantic data element alignment with any other entity that needs to provide them data. So the more entities that use UDEF the more cost savings we can expect throughout the industry. The next section describes an Online Gap Analysis Service that can make this data element alignment even faster on the assumption that UDEF IDs are provided. 20

The following is a portion of an example gap analysis report generated by the Online Gap Analysis Service for the source and target files shown above. Within the report a null indicates that the data element from one application does not have a corresponding data element in the other application. The free online gap analysis service is available at: https://jserver.opengroup.org/udef/udefreport1 Sample source and target files are available at http://www.opengroup.org/udefinfo/ Gap Analysis Report < 1 Second OAGIS Standard xcbl Standard Figure 15 Example Gap Analysis Results Using UDEF to Automate the Comparison 21

A. Appendix Use Cases A.1 Example Use Case - Details Intra-Enterprise Application Integration Use Case Topic Use Case Title: Use Case Details Intra-Enterprise Application Integration Use Case User/Actor: Multiple applications within the same organization and application subject matter experts Use Case Fit Criterion: The need to share information between two or more applications within the same organization. Use Case Scenario: Application subject matter experts map the data from their respective application to the UDEF and assign each data element concept with its UDEF ID. Use Case Notes: Send source and target files to the Online Gap Analysis Service. Gap analysis report is then reviewed for non-matched items to determine which items are critical and need to be addressed. Perform analysis of all items to determine if and where transformations are required. With support of a transformation tool, build your map between source and target. This use case assumes that the subject matter experts are trained in the use of the UDEF. A.2 Example Use Case - Details Inter-Enterprise Application Integration Use Case Topic Use Case Title: Use Case Details Inter-Enterprise Application Integration Use Case User/Actor: Two or more applications between two or more organizations and associated application subject matter experts. Use Case Fit Criterion: The need to share information between two or more applications across two or more organizations. Use Case Scenario: Application subject matter experts map the data from their respective application to the UDEF and assign each data element concept with its UDEF ID. Use Case Notes: Send source and target files to the Online Gap Analysis Service. Gap analysis report is then reviewed for non-matched items to determine which items are critical and need to be addressed. Perform analysis of all items to determine if and where transformations are required. With support of a transformation tool, build your map between source and target. This use case assumes that the subject matter experts are trained in the use of the UDEF. 22

B. Glossary Unless indicated otherwise, the Glossary term definitions below are taken from the ISO/IEC 11179 http://metadata-standards.org/11179/. Characteristic Concept Data Data Element Data Element Concept Metadata Metadata Registry Object Class Property Qualifier Term Semantics abstraction of a property of an object or of a set of objects unit of knowledge created by a unique combination of characteristics re-interpretable representation of information in a formalized manner suitable for communication, interpretation, or processing. NOTE: Data can be processed by humans or by automatic means. unit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes concept that can be represented in the form of a data element, described independently of any particular representation data that defines and describes other data information system for registering metadata a set of ideas, abstractions, or things in the real world that are identified with explicit boundaries and meaning and whose properties and behavior follow the same rules. An example UDEF object class is Person which has widely accepted and well understood properties and behavior. characteristic common to all members of an object class word or words that differentiate a concept Example: Delivery Date vs. Shipment Date; the words Delivery and Shipment are qualifiers of date. branch of linguistic science that deals with the meanings of words C. External References: Aerospace Industry Association www.aia-aerospace.org The Open Group www.opengroup.org The Open Group UDEF Project www.opengroup.org/udef The Open Group Guide for extending the UDEF www.opengroup.org/bookstore/catalog/g064.htm ISO 11179 www.metadata-standards.org/11179 Electronics Industry Data Exchange (EIDX) www.eidx.comptia.org/guidelines/xref_download.aspx. 23