[ontolog-forum] Formal Invitation and Explanation of Universal Data Ele

["John Hardin" <john.hardin@xxxxxxxxxxxx>]

 

Hello to all -

 

I promised an explanation of the Universal Data Element Framework to Adam a few weeks ago, please excuse the length of time that it has taken to respond. This is intended for general distribution to the Ontolog group, and colleagues that you believe may be interested:

 

The committee representing the Universal Data Element Framework would like to invite you to attend the first ever UDEF conference, titled INDUSTRY TRENDS TOWARD AUTOMATED DATA INTEGRATION, held in St. Louis, Missouri August 19, 2003. It will be held as a one day conference with leaders from the IT and Business domains addressing the audience regarding convergence, globally distributed multi-enterprise information systems, interoperability, and the need for semantic linking between the disparate groups, standards and formats. The online conference information and registration can be found at: http://www.envision.com/feature/ or from the home page of the UDEF.

 

Thank you for your time, and look for the invitation email shortly after this.

 

Please feel free to contact Ron Schuldt ron.l.schuldt@xxxxxxxx, or myself john.hardin@xxxxxxxxxxxx with comments, questions, etc.

Best regards to all -
John

~~~~~~~~~~~~~~~~~~~~
John Hardin
Practice Director, Enterprise Integrations
http://www.envision.com 
mailto:john.hardin@xxxxxxxxxxxx
800-438-7721
314-878-4777 

 

****************************************************************************************

 

 

To more fully explain the UDEF:

 

The UDEF is a rules based process, designed to allow standards bodies, software development organizations and API developers to independently arrive at the same UDEF ID's for identifying semantically equal data element concepts.

 

The Universal Data Element Framework is targeted specifically at the Semantic Equivalency of a data element, ie: there are many different formats of purchase orders, for example, from OAGIS, RosettaNet, UBL, CIDX, PIDX, etc etc the list goes on ad nauseum. Each of these formats or messages has the "data element concept" of Purchase Order Number. In some, the field is named <PONumber> in others it might be called <BuyerOrderNumber> in still others it may be <POID>.  Incidentally the UDEF ID for Purchase.Order.Document_Identifier is d.t.2_8, as built using the existing UDEF trees found in the power point entitled "UDEF Master Trees" on the UDEF home page http://www.udef.org under the Specs and Docs section. The UDEF is currently moving from this format to XML Schema, using a variety of support technologies, including XSLT, XPath, RDF and others to support a global registry and repositories.

 

By assigning a semantic link, or Global Universal ID (to use the term that ebXML had used at one time), and keeping a registry of the UDEF trees that make up the ID's, the semantic equivalency can be determined at design time or run time. The trees are built according to the Object and Property words found in ISO 11179 ( http://metadata-stds.org/ Drill down in the Documents section for a WordPerfect doc on 11179 part 5), and support the ebXML Naming Convention for Core Components ( http://www.ebxml.org/specs/ebCCNAM.doc ). But I'm preaching to the choir on the ISO and ebXML support of the object / property words, since I have seen many of your names on the posting in discussion groups related to these topics.

 

We believe that the UDEF effort is complementary to the UBL effort in that the CCTS is specifying the "Reusable pieces of contents that can be atomic or aggregate" and "Are using common semantic units at any level consistent across context"  ( page 21 of Latest UBL Presentation by Mark Crawford, found at

http://www.oasis-open.org/committees/documents.php?wg_abbrev=ubl ). In my understanding, this approach will require, short, mid and long term, a link to the other XML standards that are currently becoming very entrenched, and will most likely continue to be used for quite some time while UBL establishes it's dominance. This link will provide semantic equivalency with the differently named data elements in the other standards.

 

The best analogy we have been able to come up with thus far is that of the Dewey Decimal System, which uses the same intelligent numbering scheme in every library in the US to identify a class, subject or other attributes of library materials. The UDEF would serve as the Dewey Decimal numbering scheme for data elements in any (and hopefully all) ebusiness document formats.

 

At the Envision standards portal, http://stds.portal.envision.com (user/pass = envision) you may view two purchase order documents (xCBL and OAG 7.1) that contain the UDEF ID, labeled as "GUID=d.t.2_8" for example. These are found under the menu item entitled "EIDX UDEF Web Services".

 

On this site, you may also view the web service or the simple web page that produces a compare report between these two differently formatted documents. The objective of the report is to provide an analyst or mapper with the equivalent fields in two different documents. Use the xCBL and OAG Purchase Orders on the site for these services, as they have been "UDEFized", meaning UDEF tags have been added to the data elements.

 

Also at this site are a number of documents on the UDEF, on OAGIS and links to UBL and other standards.

 

We believe that there will continue to be a plethora of competing standards, disparately named and managed documents, and other formats (read: SAP iDocs for example) that need to communicate with one another across the aether of the internet. We also believe that to eliminate the lengthy process of analyzing each document format before communication takes place is a worthwhile goal. In addition, to provide an open, standard based way to do this (as opposed to a proprietary format or software vendor way to do this) has great merit for the future of ebusiness and web services.

 

Web services and the Semantic Web, as currently envisioned, cannot deliver on it's promised vision without some very stable, global and deeply built out set of semantic definitions which all services can refer to. The alternative is before-hand agreement by both or all parties participating in a web service regarding what the exact meaning of a data element is, which seems unrealistic given the automated promise of web services. 

 

Our current effort for the UDEF is to build out the trees in a way that subject matter experts can contribute to the depth and breadth of the data element concepts that currently exist. There is quite a bit of work to do, but we believe that a well architected registry/repository that hosts the base UDEF ID trees and matrixes of data models/message formats with UDEF IDs built in can provide a namespace-based design time resource and run time validation service. We are requesting domain experts to participate in the effort, please email me or Ron Schuldt if you are interested.

 

The group that is working on UDEF includes members of Aerospace, Electronics, Product Data Management, Standards, and other groups/industries.

 

Thanks again for your time.

John