Re: [ubl-ndrsc]

[Mike Rawlins <mike@rawlinsecconsulting.com>]

Comments in line

Gregory, Arofan wrote <snipped>:

> 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!
>
True, I may not have been in Barcelona, but the content of your message 
was sufficient to invalidate your example of "location code" as being 
illustrative of the problem.  As I pointed out, location code is 
actually an "identifier" according to Table 6-1 in the CC spec, rather 
than being a "code".

> The original idea was one-to-one, but then you get into situations 
> where the same semantic primitive can be expressed different ways.
>
I challenge this statement.  If a semantic item is assigned the correct 
Representation Term, it should only be expressable one way semantically. 
 If it can't be, then we probably need to throw out the whole notion of 
Representation Terms, since I thought that was one of their main functions.

> 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.)
>
I follow you from a semantic perspective, but don't see this as being 
related to syntax at all.  Your examples are true in semantic terms, 
regardless of implementation syntax.

> 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.
>
Here you have two different things that may perform the same function in 
a business context, but they are not identical semantically.  In an 
airline reservation, either a frequent filer number or a name can 
fulfill the need to uniquely identify a passenger.  However, in absolute 
semantic terms they are not equivalent since they have different 
representation terms.  What you have identified here is not a case of 
two things with the same semantics being expressed differently.  What 
you have instead identified is the need in a business message to specify 
that that both pieces of information may be present, but at least one of 
them must be present.   Perhaps this argues in favor of having an 
abstract "identifier element" thing in a message definition, and the 
BIEs of mumble.FrequentFlier.Identifier and mumble.Passenger.Name could 
be concrete instances of it.  That still does not make them semantically 
equivalent.  They will have different UIDs for both the base CCs and the 
BIEs.  (BTW - This is the type of stuff we've been talking about in 
X12C/TG3 lately.  I hope we have a chance for a joint update on each 
group's work at the Minneapolis meeting).

> In the final analysis, we can't escape the demands of the business 
> data we need to express.
>
Are we talking about anything else ? ;^)

> 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.
>
We can drop CCTs if we fully specify all of the constituent parts of 
basic CCs (or BIEs) for each type of Representation Term.

> 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/
> ===================================================================
>

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