In response to John's comments, I offer the following: John wrote - I have had a number of years experience in inventory management at the retail level and we have found that a Universal Identifier such as a barcode to be invaluable reference. One only worries about the bar code when beginning to construct a stock management system. If one is not present a number is invented for the product so that it can conform with the system. UIDs are a way of life in the business world and we would be remiss in not including them, especially if one of our aims is to be ebXML compliant. I concur that a universal identifier is an invaluable reference. It is my understanding that bar codes are assigned by a widely recognized non-profit standards organization and the bar codes have structure based on an adopted standard taxonomy. I believe that UCC is an example of an organization that assigns bar codes - see
http://www.uc-council.org/ . John wrote -- As with ebXML, these numbers should not have any semantic meaning what so ever. It is a similar practice that I have used in the construction of stock management systems in the retail and hospitality sectors. When I find that this methodology has not been used, the item numbers are confusing and often the system designers run out of numbers, thus breaking their methodology and thus meaning. While UDEF UIDs seem to be logical and are designed to be unique to someone familiar with UDEF, they would appear to a lay person as confusing and present a new language to learn. This may present a barrier to a person or entity taking up UBL. Since the UDEF is built to be continuously (indefinitely) extensible, it should never run out of numbers to uniquely identify a new data element concept. The portions of the UDEF that demand the greatest potential extensibility is on the object side and the UDEF uses alpha characters for all layers below the top object numeric (e.g., Product = 9, Document = 2, Person = 5, etc.). At layers below the top object a-z is followed by aa, ab, ac-zz followed by aaa, aba, aca-zzz, etc. and there is no limit to its extensibility as new types of objects are identified (e.g., NewProduct = h.9, ContractDocument = e.2, CustomerPerson = as.5). Based on my experience teaching others to use the UDEF, it requires 2-3 hours of hands on practice using actual data elements from existing systems. Typically, the difficulty is not in understanding the UDEF but in analyzing the data elements (particularly the complex ones) that need to be mapped. The UDEF Property Terms are built using all of the ebXML Representation Terms and use numerics for the IDs below the top Representation Words (e.g., Date = 6, Text = 14, Name = 10 etc.) Property Term examples showing one layer below the top representation term are DeliveryDate = 29.6, TitleText = 6.14, LastName = 5.10. If combined into an ISO 11179 compliant name (both Object and Property required), the above object and property examples would become <NewProductDeliveryDate UID= h.9_29.6 > <ContractDocumentTitleText UID= e.2_6.14 > <CustomerPersonLastName UID= as.5_5.10 > I find it hard to believe that the UDEF would be any more difficult than learning any other naming convention. In terms of potential benefits, the UDEF structured UID offers an imbedded indexing scheme. Once a list of unstructured UIDs exceeds 150-200 at some ebXML registry, a person who is tasked with mapping legacy systems to ebXML will find it nearly impossible to cross reference to the new ebXML names. The task of cross referencing becomes much simpler if the names have structured IDs associated with them. The proposed indexing scheme with the UDEF would be to list all mapped names that contain both product and date and then all mapped names that contain both product and identifier etc. John wrote -- This then leads us to the issue of structured names. I feel the most important issue is to present UBL names, which are the most visible part of UBL, in a highly structured manner in order to have as much semantic clarity as possible. This makes the semantic meaning of the names very precise and understandable to the users of UBL. This also has a parallel to my experience in naming stock items. In practice we follow the ObjectClassPropertyTermRepresentationTerm methodology as ISO 11179-5 and ebXML uses. So we are presented with the option of using a naming convention and methodology that is clear and represented by an international standard for UBL. The only draw back, as presented by others, is the possible length of the names and the computer memory space the names may use. As we are in an era that no longer concerns itself with every bit and byte and knowing the future will be less concerned, I feel we should err on the side of semantic clarity and adopt the ISO 11179-5 methodology. I agree completely - structured names are very important and the UDEF naming convention is very structured. The UDEF approach uses the ObjectClassPropertyTermRepresentationTerm plus it uses qualifier terms. I quote from ISO 11179-5 paragraphs 6.1 and 6.1.1 6.1 Principles governing semantic content of names Semantics concerns the meanings of name components and possibly separators which delimit them. 6.1.1 Semantics of name components Components consist of discrete terms. The components described in ISO/IEC 11179 are: object class terms, property terms, representation terms, and qualifier terms. The UDEF conforms to ISO 11179-5. Ronald L. Schuldt Senior Staff Systems Architect Lockheed Martin Enterprise Information Systems 11757 W. Ken Caryl Ave. #F521 MP DC5694 Littleton, CO 80127 303-977-1414
ron.l.schuldt@lmco.com