OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ubl-ndrsc] Tag structure discussion kick-off


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





-----Original Message-----
From: John C Dumay [mailto:jcd@progressivemanagement.com.au]
Sent: Sunday, December 16, 2001 12:12 AM
To: Eve L. Maler; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Tag structure discussion kick-off


Hello Folks,

After listening in on my first teleconference I would like to add my opinion
to the discussion on UIDs and highly structured names. I have listed UIDs as
my first priority as I feel that this is more important than having highly
structured names (which I feel are necessary as well). 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. 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. Secondly giving the UIDs a semantic meaning would not
be compliant with ebXML.

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.

Regards,

John C Dumay

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Thursday, 13 December 2001 8:06 AM
To: ubl-ndrsc@lists.oasis-open.org
Subject: [ubl-ndrsc] Tag structure discussion kickoff


 From the latest minutes:

			*		*		*
    Outstanding issues:

    - Do we use highly structured names (option 1) or slightly structured
      names (option 2)?

    - Do we use fully qualified structured names (option 1a) or abbreviated
      structured names (option 1b)?  How much abbreviation do we want
      to allow?

    - Do we use ebXML/11179-style names (option 1E) or UDEF-style names
      (option 1U)?

    - Do we add attributes to UBL elements that link them to the UDEF
      structured UIDs?

    ACTION: Everybody to discuss this on the list!
			*		*		*

Okay folks, have at it!  I will be on vacation from tomorrow through next
Tuesday, so won't be able to participate during that time.  Here are my
thoughts on the matter, as unformed as they may be:

- I think regularity is important, and can't see much "intuition-affecting"
difference between Mark's xCBL example and his modified option #1 version
(which uses 1b, by the way).  So I'm in favor of option 1.

- I prefer option 1b, so that we give reusability some amount of
importance.  I think we should try to come up with an algorithm (not a
heuristic), if we can, to ensure that our regularity stays regular.

- I prefer option 1E, so that we can more easily align with semantics that
we know are important to us and so that the Library Content SC can continue
to work in the effective way that they've been using so far (working off of
CC semantics).  I see nothing inherently wrong in the UDEF semantic trees
(though I don't know them very well yet), but do have some questions about
the object words that are aligned with context drivers -- how would that
work against the context methodology that needs to be developed?  It sounds
a bit weird to be baking context into base UBL.

- I don't, in principle, have a problem with adding UDEF UIDs to our leaf
elements.  I see this as very much an adjunct, however, and it could
possibly be done at a later stage.  Perhaps because I'm not entirely
familiar with the usage/processing situations envisaged for these "hub"
semantic sets, I have some doubts about how helpful it really is to link up
to a standard semantic when the internal structure of the so-marked element
can possibly be arbitrarily different from any other such element on the
planet.  (Or maybe this is solved only by linking from leaf nodes?)

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC