Universal Data Element Framework

The Universal Data Element Framework (UDEF) provides the foundation for building an enterprise-wide controlled vocabulary. It is a standard way of indexing enterprise information that can produce big cost savings. UDEF simplifies information management through consistent classification and assignment of a global standard identifier to the data names and then relating them to similar data element concepts defined by other organizations. Though this approach is a small part of the overall picture, it is potentially a crucial enabler of semantic interoperability.

How UDEF works

UDEF provides semantic links, through assigning an intelligent, derived ID as an attribute of the data element, essentially labeling the element as a specific data element concept. When this UDEF ID exists in both source and target formats, it can then be used as an easy analysis point via a match report, and then as the primary pivot point for transformations between source and target.

UDEF takes a list of high-level root object classes and assigns an integer to each class plus alpha characters to each specialization modifier. It then also assigns integers to property word plus integers to each specialization modifier. These object class alpha-integers are concatenated together with the property integers to form a dewey-decimal like code for each data element concept.

Examples

For the following examples, go to http://www.opengroup.org/udefinfo/htm/en_defs.htm and expand the applicable UDEF object and property trees

Assuming an application used by a hospital needs to map the data element concepts to the UDEF, the last name and first name (within UDEF you will find Family Name and Given Name under the UDEF property Name) of several people that are likely to appear on a medical record that could include the following example data element concepts –

Patient Person Family Name – find the word “Patient” under the UDEF object “Person” and find the word “Family” under the UDEF property “Name”

Patient Person Given Name – find the word “Patient” under the UDEF object “Person” and find the word “Given” under the UDEF property “Name”

Doctor Person Family Name – find the word “Doctor” under the UDEF object “Person” and find the word “Family” under the UDEF property “Name”

Doctor Person Given Name – find the word “Doctor” under the UDEF object “Person” and find the word “Given” under the UDEF property “Name”

The associated UDEF IDs for the above are derived by walking up each tree respectively and using an underscore to separate the object from the property. For the examples above, the following data element concepts are available within the current UDEF – see http://www.opengroup.org/udefinfo/htm/en_ob5.htm and http://www.opengroup.org/udefinfo/htm/en_pr10.htm

“Patient Person Family Name” the UDEF ID is “au.5_11.10”

“Patient Person Given Name” the UDEF ID is “au.5_12.10”

“Doctor Person Family Name” the UDEF ID is “aq.5_11.10”

“Doctor Person Given Name” the UDEF ID is “aq.5_12.10”

Six basic steps to map enterprise data to the UDEF

There are six basic steps to follow when mapping data element concepts to the UDEF.

1. Identify the applicable UDEF property word that characterizes the dominant attribute (property) of the data element concept. For example: Name, Identifier, Date, etc.

2. 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.

3. 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.

4. 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.

5. 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.

6. Derive a structured ID based on the UDEF taxonomy that carries the UDEF inherited indexing scheme. For example <CustomerPersonFamilyName UDEFID=”as.5_11.10”>.

The Open Group UDEF Project objectives

The UDEF Project aims to establish the Universal Data Element Framework (UDEF) as the universally-used classification system for data element concepts. It focuses on developing and maintaining the UDEF as an open standard, advocating and promoting it, putting in place a technical infrastructure to support it, implementing a Registry for it, and setting up education programs to train information professionals in its use.

Organizations that implement UDEF will likely realize the greatest benefit by defining their controlled vocabulary based on the UDEF. To help an organization manage its UDEF based controlled vocabulary, it should seriously consider a metadata registry that is based on ISO/IEC 11179-5.

History of UDEF

Ron Schuldt, Sr. Enterprise Data Architect, Lockheed Martin, originated the UDEF concept based on ISO/IEC 11179 Metadata standards in the early 1990s. Currently, he is a Senior Partner with UDEF-IT, LLC.

Ownership of UDEF intellectual property

The Open Group assumed from the Association for Enterprise Information (AFEI) the right to grant public use licensing of the UDEF.

The Supplier Management Council Electronic Enterprise Working Group of the Aerospace Industry Association (AIA) supports the UDEF as the naming convention solution to XML interoperability between standards that include all functions throughout a product's life-cycle and is working through a well defined process to obtain approval of this position from AIA and its member companies.

Criticism

Classification in UDEF is sometimes hampered by ad hoc decisions that might produce problems. Example:

b.be.5 is "United-Kingdom Citizen Person" and
c.be.5 is "European Union Citizen Person"

As the United Kingdom is part of the European Union, the classification is not unique. Response: The UDEF is flexible and is designed to match the semantics and behaviour of existing systems. Therefore, if one system has a table for United Kingdom Citizens and a different system has a table for European Union Citizens, the UDEF can handle both situations.

Some of the concepts in UDEF are not as universal as it is claimed. They show a lot of bias to Anglo-American tradition and way of thinking and are not easily transferable to other languages. Example: The following part of the hierarchy shows the concept of an officer.

j.5 Officer.Person
a.j.5 Contracting.Officer.Person
a.a.j.5 Procuring.Contracting.Officer.Person
a.a.a.j.5 Government.Procuring.Contracting.Officer.Person
b.a.j.5 Administrative.Contracting.Officer.Person
b.j.5 Police.Officer.Person
c.j.5 Military.Officer.Person

In many cultures, the part of the tree below "a.j.5 Contracting Officer Person" would not be placed under j.5 (see officer) as b.j.5 (see Law enforcement officer) or c.j.5 (see Officer (armed forces)).