The UDEF is being superseded by the Open Data Element Framework (O-DEF). This standard will better suit the needs of business-to-business communication, but will not be backwards-compatible with UDEF. These pages are maintained to provide access to legacy UDEF.
UDEF Concept of Operation
This concept of operation for the Universal Data Element Framework (UDEF) applies to 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.
- Identify the applicable UDEF property word that characterizes the dominant attribute (property) of the data element concept. For example: Name, Identifier, Date, etc.
- Identify the dominant UDEF object word that the dominant property (selected in step 1) is describing. For example, Person_Name, Product_Identifier, Document_Date, etc.
- By reviewing the UDEF tree for the selected property identified in step 1, identify applicable qualifiers that are necessary to describe the property word term unambiguously. For example, Family Name.
- By reviewing the UDEF tree for the selected object identified in step 2, identify applicable qualifiers that are necessary to describe the object word term unambiguously. For example, Customer Person.
- Concatenate the object term and the property term to create a UDEF naming convention compliant name where it is recognized that the name may seem artificially long. For example, Customer Person_Family Name.
- Derive a structured ID based on the UDEF taxonomy that carries the UDEF inherited indexing scheme. For example <CustomerPersonFamilyName UDEFID=”as.5_11.10”>.
As an example, Figure 1 shows each UDEF ID that was mapped to every data element concept 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.
You should 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, has 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. See the row highlighted in blue, below, as UDEF ID = e.2_8 corresponding to Standard A name “Contract Document Identifier”.
Example Mapping Matrix
The following example shows how the UDEF helps a company to interpret information from external sources so that it can be processed by their applications.
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.
Input File and Application Data Format
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.
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, the UDEF simplifies the integration resulting in cost and time savings.
Input File and Application Data Format – UDEF Tagged
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 UDEF enables rapid comparison of appropriately tagged XML files to determine how their semantics correspond. This simplifies and speeds up development of interface software. You can use the gap analysis utility to do this. Submit two XML files, each containing UDEF IDs as illustrated by the input sample and the target sample. One should be from a source system and the other from a target system that need to exchange data. A gap-analysis report is generated.
The example illustrated below shows the use of this tool. Figure 5 shows 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. UDEF IDs have been embedded within each file. Figure 6shows a portion of an example gap analysis report generated by the Online Gap Analysis Service in less than 1 second 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.
UDEF-Tagged Source and Target Files
Gap Analysis Report
Downloading the UDEF
You can download the UDEF definitions, in XML or in RDF format, for use in your enterprise. To do this, you must join the UDEF Interested Parties Group.
Downloading Files for the Current Version
Retrieving Files from Previous Versions
Files for versions 1.12 and later can be retrieved from directories http://www.opengroup.org/udefinfo/dl/Vx/ where x is the version id. For example, the files for version 1.2 are at http://www.opengroup.org/udefinfo/dl/V1.2/.
The Versions of the UDEF
A history file describing the versions of the UDEF to date, and showing which files have changed for each version, is at http://www.opengroup.org/udefinfo/dl/UDEFHistory.xml.