RE: [ubl-ndrsc]

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Title: RE: [ubl-ndrsc]

Mike:

Much of what is  behind this suggestion comes from discussions in Barcelona, so you may not have all the background, but the same basic problem has been creeping up everywhere: CC does not give you enough ability to describe the things you need to describe!

These problems have been solved in the past, and I think everybody finds them confusing.

The problem about one-to-one is perhaps the most confusing part, and we spent a long time talking about this one in the NDR group in Spain.

The original idea was one-to-one, but then you get into situations where the same semantic primitive can be expressed different ways. In part, this situation arises because almost any syntax demands that the "primitives" from a semantic viewpoint be expressed as not single bits of data, but as clusters of related data - typically, the "primary" bit of data, a code, or a bit of text, or a number, PLUS the supporting metadata (which code list, what language, what currency, etc.)

Problem is, if I have two "clusters' of data that perform the same semntic function, but are expressed differently - a coded identifier as opposed to a spelled-out name, for example - then I run into trouble. In the final analysis, we can't escape the demands of the business data we need to express.

I am almost with you on the idea of getting rid of CCTs, and leaving that up to the syntax binding, except that I'm afraid that (1) there are some things that are absolute requirements of the data itself, and not the syntax (like numeric precision); and (2) if we don't specify what the clusters consist of, we will end up with non-interoperable chaos.

Tough problem, though, and one we have to get right.

Cheers,

Arofan

-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Friday, April 05, 2002 3:28 PM
To: Gregory, Arofan
Cc: ubl-ndrsc@lists.oasis-open.org
Subject: Re: [ubl-ndrsc]

Dropping back in again to comment on this, since I plan to be submitting
comments individually on the CC spec. I've a few comments in-line.

Mike

At Friday, 05 April 2002, "Gregory, Arofan" <arofan.gregory@commerceone.
com> wrote <snipped>:

>Originally, there were *NO* CCTs. All we had in the CC work was
a set of
>semantic "primitives" that were called RTs. The list in the spec
has not
>changed much since then. At one of the ebXML meetings it was realized
that
>although some of the RTs were single bits of data, others were actually
data
>composites. For each RT, one (and exactly one, in theory) CCT was
indicated,
>to suggest the semantics of the properties needed to fully express
the use
>of the RT.

I find a one to one relationship to be the most intuitive.

>
>As we start trying to use the spec set up in this way (UBL and others),
we
>have been realizing that there are some significant failings in
this system.
>One great example of this is a Location Code, a common bit of data that
>cannot be described as a set of enumerated values - what we traditionally
>and typically think of as a 'code list' - even though it's business
function
>is that of a code. 

This is actually a very poor example.  Location "code", strictly
speaking,
falls into the CC definition of an identifier and not a code.  It is
not an enumerated list in any practical sense.  Calling it a "code"
would
be like calling the U.S. Social Security number a "code".

>This is true not only of codes, but also of other kinds of data.
We need to
>specify *both* the semantic primitive of the model (the Representation
Term,
>traditionally) *and* the set of properties by which it is made manifest
(the
>CCT), and there is neither a one-to-one relationship between RTs
and CCTs,
>nor a many-to-one relationship between RTs and CCTs. It is, by the
practical
>dictates of business information, a many-to-many, unless we substantially
>increase the range of our RTs and CCTs.

I find this extremely confusing.  I don't see how there can be more
than a
many RT to one CCT relationship under the current definitions, or one
to one relationship under my preferred alternative, if the piece of
information in question is classified with the correct representation
term.  In fact, if we find a case where the CCT can't handle the
semantics, that may be a strong indication that the wrong RT has
been assigned (as in your example of Location "code").

>This is the absolute need for a solid description of the physical
>representation of data, at a finer level of detail than is currently
>possible.

I agree with that idea.

>
>Take, for example, the degree of precision of a price. This is a
fundamental
>kind of data-type issue, since the degree of precision in prices
defines the
>tolerances used in the calculations for essential business processes
such as
>Order/ASN/Invoice reconciliation (aka "book-keeping").
>
>If we are to describe a "price" using the current system, here is
what we
>would know about it:
>
>RT = "Amount" (which is always a monetary amount according to the CC
>definitions)
>CCT = "AmountType" (which gives us a number and a currency code)
>
>The degree of precision of the price cannot be specified in the
semantic
>model, given these capabilities. All monetary amounts are the same.
But in
>reality, prices have a very different specificity than some other
monetary
>amounts. This means we cannot simply assume a single precision for all
>monetary amounts, and make that part of our syntax-binding.

All this argues is that to be fully described semantically, a monetary
amount must have the value of the amount, the currency, and precision.

>
>In other words, there is a need to capture in the model some distinction
>between a price and another kind of monetary amount, since they have
>different requirements in terms of how they are represented.

How is a "price" different from any other monetary amount?  I find this
distinction a bit arbitrary and confusing.

>Please note
>that, in this example, precision is *not* syntax-specific. It is
a critical
>property of the business data itself, and can be described equally
well in
>many different syntaxes.

Agreed.

Without commenting on your proposal in any further detail, the failing
that I found in  a recent CC spec (not the most recent) was that
RTs were used to specify semantics but they themselves were not fully
specified.  I think the simplest and most straight forward solution
is to insure that the CC spec fully describes the (compound) semantics
of each Representation Term.  That is what I will suggest in my comments.
If that is done, it should be very straight-forward to develop
a set of CCTs that reflects a one-to-one relationship between RTs
and CCTs.  (Or, even better, do away with CCTs entirely!  However,
I don't expect that anyone is going to go for that radical a suggestion
;^) )

Cheers,

Mike

---------------------------
Michael C. Rawlins
Rawlins EC Consulting
www.rawlinsecconsulting.com

===================================================================
EASY and FREE access to your email anywhere: http://Mailreader.com/
===================================================================