RE: hey whilst we are all asking for things

["Schuldt, Ron L" <ron.l.schuldt@lmco.com>]

Title: Re: hey whilst we are all asking for things

Kremena,

 

I truly understand the dilemma that you face - trying to force any government organization (or any large commercial organization) to adopt new data element concept names and then to apply them to their many legacy back-office systems simply because it is a new standard. That fundamental issue is a major reason that the Universal Data Element Framework (UDEF) was developed. The approach of using a computer sensible alias such as "X.2354" that you illustrated in your last message is the foundation "key" that the UDEF uses as well. The primary difference between an EDIFACT randomly assigned "X.2354" and a UDEF derived "d.t.2_8" is that the UDEF structured ID is based on two ontologies (one for basic objects applicable to any enterprise and the other basic properties that are the basic data types applicable to any schema) that conform to both ISO/IEC 11179 and to ISO 15000-5 (Draft). An ebXML Forum article that compares the UDEF to CCTS is available at http://www.ebxmlforum.org/articles/ebFor_20040306.html and illustrates how UDEF IDs are derived.

 

You can find the ISO/IEC 11179 standards at http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm

 

A slightly dated version of the UDEF ontologies (trees) can be seen at http://www.udef.org/specdoc/UDEFv1pt03-July-2003.htm They could provide a good starting point library for the CCTS. Adopters of the UDEF would independently map their data element concept names to the UDEF and then assign the UDEF ID as an optional alias within the back-office system's API.

 

The March 29, 2004 edition of Network World (see page 12 in the paper version) provides a good article highlighting the potential role that the UDEF could play as a B2B integration standard. You can also see the article online at http://www.nwfusion.com/news/2004/0329udef.html

 

Ron Schuldt
Senior Staff Systems Architect
Lockheed Martin Enterprise Information Systems
11757 W. Ken Caryl Ave.
#F521 Mail Point DC5694
Littleton, CO 80127
303-977-1414
ron.l.schuldt@lmco.com

 

 

 

 

-----Original Message-----
From: MCRAWFORD@lmi.org [mailto:MCRAWFORD@lmi.org]
Sent: Tuesday, July 13, 2004 5:20 AM
To: infom@bcci.bg; jdeanh@ihug.co.nz
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: hey whilst we are all asking for things

Kremena,

 

Actually, using 11179 and CCTS will standardize the construct of the data element names as well as the metadata.  The key is using those two ISO standards (yes ccts is ISO 15000-5 (Draft)) in conjunction with a recognized international standards body who maintains the vocabulary.  UN/CEFACT TBG is beginning to build that vocabulary, and many standards bodies - including UBL - have committed to submitting their 11179/CCTS vocabularies to help that effort.  I should also mention that many agencies in the US Government, as well as other governments have already committed to using this new approach.

 

Mark Crawford

Senior Research Fellow

LMI Government Consulting

Vice Chair UBL

Chair CEFACT ATG XML Working Group

 

---

From: Kremena Gotcheva [mailto:infom@bcci.bg]
Sent: Tue 7/13/2004 6:27 AM
To: J. Dean E. P. Hemopo
Cc: ebXML Dev Forum
Subject: Re: hey whilst we are all asking for things

Dean:

I'm not a developer to comment in detail but a general remark on
dictionaries: you will be well advised to stick to standards, even
unpalatable ones. EDIFACT is widely adopted (and because this is my job -
believe me, getting a standard adopted in a national legislation is a hell
of a lot of (paper)work). So even if your "customer. account. number" is
called something unpalatable like data element X.2354 in EDIFACT, you'd
better stick to X.2354, or otherwise take into consideration that the
Government of Tonga wants it to be called "customer's. account. number",
and in Nubia it is "account.number.for.customers", etc. - and code ALL
these ever changing exceptions (which you would have to follow in the
respective languages just to be competitive) in your routines.

Kremena

The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
list archives are at http://lists.ebxml.org/archives/ebxml-dev/
To subscribe or unsubscribe from this list use the subscription manager:
<http://www.oasis-open.org/mlmanage/>

The ebxml-dev list is sponsored by OASIS The list archives are at http://lists.ebxml.org/archives/ebxml-dev/ To subscribe or unsubscribe from this list use the subscription manager: