UDEF, a Dewey Decimal System for business XML

When XML first appeared seemingly everyone who was anyone was prognosticating that finally we would have completely effective, painless data exchange. Alas, this turned out to be simply feverish dreams possibly brought on by the irrational exuberance of the Internet bubble.

Reality proved to be somewhat different: XML became balkanized into dialects, one for each purpose and each assigned different names with often different meanings to each entity they were describing. This was a big problem.

Thus, in purchase orders – something that one would think unlikely to have very many ways of saying the same things – the names of fields are disjointed. For example, under the XML Common Business Library (xCBL) the price of an item is quite understandably called “UnitPriceValue” while under the schema from the Open Applications Group the same thing is called “OPERAMT.”

So if you and I are using different schemas and we want to intercommunicate we are reduced to hiring a data architect and a programmer to create some kind of translation mechanism.

But there is a better way: The Universal Data Element Framework (UDEF) is a cross-industry metadata identification strategy. The intention is to provide a means of real-time identification for semantic equivalency, as an attribute to data elements within e-business document and integration formats.

To put that another way, UDEF aims to be the Dewey Decimal system for structured business-to-business messaging. You can think of UDEF as replacing the many-to-many links between businesses exchanging data with conceptually a single semantic hub that provides common ground.

A note on OASIS Cover Pages (an online resource for markup language technologies) outlines UDEF as addressing a “problem [that] has been labeled ‘semantic dispersion,’ the dilution of shared meaning due to [the] proliferation of synonyms and homonyms.”

The note goes on to say: “What is needed is a direction toward ‘semantic convergence,’ clarity of shared meaning with a minimum number (approaching zero) of synonyms and homonyms.”

The same article continues: “Ron Schuldt, the originator of [UDEF], calls it the ‘standard’ to harmonize other ‘standards.'”

Schuldt describes the relationship between UDEF and XML in these terms: “The fundamental thing that XML lacks is what UDEF has to offer. Specifically, XML lacks a rigorous rules-based approach for standardizing tag names across multiple domains of discourse. UDEF applies a rigorous rules-based approach for naming data elements (tags) from which one is able to derive a taxonomy-based intelligent ID to the name. The ID is the key that allows an unlimited number of aliases.”

The ID referred to is created from objects and their qualifiers along with a hierarchy of properties. The objects are assigned values so: Entity=0, Asset=1, Document=2; Enterprise=3; Environment=4; Person=5; and so on (there are 15 objects in all) and there are 18 top-level properties including Amount=1; Graphic=2; Picture=3; Code=4; Date Time=5; Date=6; Name=10; Quantity=11; Rate=12; and so on.

The values of these objects and properties are combined to create Data Element Names as follows starting from the left:

1. Optional qualifiers for the object class.

2. A period if item 1 exists.

3. Mandatory object classes separated by periods.

4. An underscore.

5. Optional qualifiers.

6. A period. 

7. Mandatory properties separated by periods.

So a UDEF mapping would, for example, assign document-publication-date to 2_5.6; software-product-version-identifier to p.9_8.8; and product-part-identifier to 9_5.8. See the UDEF presentation from July 25,

2003, for diagrams of the object classes, properties, and qualifiers (a revision of the UDEF objects and properties specification is due for release in the next few weeks).

So now that we have UDEF IDs (UID), we can use them in XML documents as attributes of tags to ensure that objects have unequivocal meanings. For example:

This example is taken from an OAG document describing a purchase order. The UIDs provide the invariant framework for establishing cross standards interpretation. See the UDEF Compare report example which features two UDEF tagged Purchase Orders and a servlet that creates a comparison of matching data elements and the NIST/OAGi UDEF Proof of Concept meeting notes.

So what will this mean in practice? The reality will be that no semantic framework, UDEF included, can do everything when it comes to translation between standards – there will always be some entity in some standard that simply won’t fit the model.

But the power of UDEF is that it will probably take care of the translation of the majority of entities leaving just a handful that will require more sophisticated translation to be carried out by custom code. And for run-of-the-mill business purposes, UDEF will most likely do it all.

UDEF is a powerful idea and one that could have a major impact on your Web applications in the near future. Join the udef.builders mail list to track what is developing and watch for a major announcement in the next 30 days or so.

[Special thanks to John Hardin of Sangha Interactive for his help with this article.]