[ubl] Re: [ubl-ndrsc] Proposal 3 in our CCTS feedback

[Tim McGrath <tmcgrath@portcomm.com.au>]

Title: RE: [ubl-ndrsc] Proposal 3 in our CCTS feedback

Before we get too confrontational and Arofan starts opening the armoury,
let us take stock of what ISO 11179 says and how it has been interpreted
for CCTS.

ISO11179-5 (many thanks to Mark who posted this.. http://lists.oasis-open.org/archives/ubl-lcsc/200201/msg00020.html)
makes three key points about representation terms:
1. A representation term is a component of a data element name which describes
the form of representation of the data element.  
2. Each term is developed from a controlled word list or a taxonomy.  
3. This term describes the form of the set of valid values of a data element. 

The CCTS states:
"A representation term defines the type of valid values for an information
entity. " (CCTS lines 1116 and 1239) and "The type of valid values for a
Basic Core Component." (CCTS Definition of Terms line 2167)
This changes "the form of the set of"(point 3.) to "the type of".  It is
actually quite a significant difference that dilutes the meaning of ISO11179
and hence leads into the need for CC Types to be defined as well.

So i am not convinced that CCTS is "using RT as defined in ISO11179" as sacredly
as Mike suggested - they have interpreted the definition to suit their application.
 What we are proposing is a change in this interpretation.  I think they
were nearer to the definition we mean with ...
 "The Representation Term is the part of a Core Component name that describes 
the form of valid values in which the business information is expressed in 
a data item" (CCTS line 1313)

In fact, looking at this again, I wonder if  just asking them to adopt the
original ISO 11179 definition is what we really mean!??





Gregory, Arofan wrote:

Bill:

I will play devil's advocate here for a moment.

ISO 11179 is a sacred cow, and "Representation Term" is the thing that connects the CC work to 11179.

CCT was invented by the CC group as a convenience, to describe the supporting properties of an RT.

If you apear to be messing with RTs (say, by relegating them to an aspect of the naming conventions while replacing their technical function) then you will be violating the sacred donkey (ooops - sacred cow!)

It's a damned-if-you-do & damned-if-you-don't situation. I recommend that we stick to our guns, and point out that CCTs are unneeded, and that RTs are both needed and need to be specifically extended and clarified for their application here.

We do, after all, have some smart people in positions of power on the CC editing team, and they are ultimately the ones who will have to make it all fit together. I think we should submit what Eve has proposed.

Cheers,

Arofan

-----Original Message-----
From: Burcham, Bill [ mailto:Bill_Burcham@stercomm.com ]
Sent: Thursday, April 25, 2002 9:54 AM
To: ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Proposal 3 in our CCTS feedback

I agree with Mike (that the UN folks might have strong reactions to
redefining "RepresentationTerm") and I've got an alternative that fits with
ISO 11179 and gives us a single set of semantic primitives at the expense of
possibly running afoul of the "original intent of Representation Terms" from
the old days of ebXML.

Why don't we keep Core Component Type in the model and make it stand for the
"semantic primitives" (rather than throwing out CCT and keeping RT).  Let's
keep Representation Term as part of the dictionary entry name. 

ISO 11179 is a standard for naming "data elements".  Think: ** global
variables in a big ole FORTRAN program **  That standard gives no clear
guidance on naming types (which is what CC's, BCC's, ACC's, BIE's, ABIE's,
BBIE's are), nor does it give clear guidance on the relationship between
types and data elements.  (it does mention that it is applicable to naming
"data concepts" but on the mapping of those to classes in OO languages,
structures in languages like Pascal or C, and types in XSD, the
specification is completely mute.)  The ebXML folks extended/interpreted
that model to naming "types" as well.  That was a stretch, and it just so
happens they got it wrong when they made Representation _Term_ part of their
model.

So... since RepresentationTerm is... a "term"... and it is defined by ISO
11179 as part of the dictionary entry _name_ -- I don't see any
justification for making it stand for "the set of semantic primitives".

The argument gets stronger when we consider the practice right now in LCSC.
They are using the RepresentationTerm only as a part of the dictionary entry
name -- not really as a "type".  In their current usage, that part of the
dictionary entry name, names a _property_ whose type is either a CCT or an
ABIE or a BBIE depending on which kind of property is being described.

In current _practice_ there are three kinds of types in UBL: Aggregate Core
Components (ACC's), Basic Core Components (BCC's) and Core Component Types
(CCT's).  Each of these needs a dictionary entry name.  Also each of the
properties of each instance of each of these needs a dictionary entry name.
Each of those dictionary entry names will need a "Representation Term" if we
are to apply ISO 11179.

Please have a look at the attached diagram.  In it I show the mapping of ISO
11179 naming to the proposed CC model.  Notice that an ISO 11179 dictionary
entry name always has ObjectClassTerm, PropertyTerm, and RepresentationTerm.
A DataElementName (using ISO terminology here!) names a DataElement.  From
the standpoint of ISO 11179 there are two kinds of DataElement in Core
Components:

1. a property of an Aggregate Core Component
2. a property of a Core Component Type (i.e. its Content Component or one of
its Supplementary Components).

These are the "data elements" that ISO 11179 allows us to name (with the
tripartite naming scheme).
   
My proposal provides a clean separation betwen the concepts that comprise
the dictionary entry name from the concepts that comprise the CC model.
This is appropriate since dictionary entry names must be applied to many
different parts of the model.  The names are separate from the things named.

So an ACC, Contact can have a property called homeAddress of (ACC) type
Address.  We'd need three dictionary entry names to describe this situation:

ObjectClassTerm PropertyTerm RepresentationTerm
--------------- ------------ ------------------
Contact                                   * this dictionary entry is for the
Contact ACC
Contact         homeAddress  Address      * this dictionary entry is for the
homeAddress property of Contact
Address                                   * this dictionary entry is for the
Address ACC

Now let's say Address has a property called street which is of (BCC) type
Street which in turn is of (CCT) type StreetType (I hate the fact that we
have both BCC's and CCT's but one battle at a time!!).  We'd have something
like:

ObjectClassTerm PropertyTerm RepresentationTerm
--------------- ------------ ------------------
Address         street       Street       * this dictionary entry is for the
street property of Address
Street          *content*    Text         * content
Street          *supp:x*     ...          * supplimentary goop...

And we'd _infer_ the CCT type (StreetType) from the BCC type Street (that's
unambiguous since a BCC has exactly one CCT -- that much is undisputed).

The point of this exercise was to show that we've got two kinds of data
element (per the ISO defintion), both of which will need dictionary entry
names, and both of which will need an attribute describing their "kind".
Applying ISO 11179, that attribute is called "RepresentationTerm".  However,
the thing named is not the term.  In the first case, the thing named by
RepresentationTerm is the Address (ACC) type.  In the second case, the thing
named by the RepresentationTerm is the Street (BCC) type.

Regards,
Bill

-----Original Message-----
From: Michael C. Rawlins [ mailto:mike@rawlinsecconsulting.com ]
Sent: Thursday, April 25, 2002 10:20 AM
To: Eve L. Maler
Cc: ubl-ndrsc@lists.oasis-open.org
Subject: Re: [ubl-ndrsc] Proposal 3 in our CCTS feedback

This is an interesting proposition, and I agree with most of it except
for the bit that says that "the definition of Representation Term be
modified".  My guess is that the ebTWG CC team would flatly reject this
as worded on the basis that they are using RT as defined in ISO 11179.
 I don't have a better wording right off, but I think you want to convey
the idea that there must be a fully specifed set of supplementary
components that is associated with each type of RT.

Mike

Eve L. Maler wrote:

> I took an action to suggest revised wording for Proposal 3 in our CTTS
> feedback.  How's this?
>
> "We suggest that the definition of Representation Term be modified to
> encompass the function of both Representation Terms and Core Component
> Types, and that the notion of Core Component Types be removed, e.g. ..."
>
> I think we will also need to come up with an actual list of what the
> RTs would be (though perhaps this belongs in a separate Proposal 3a,
> or perhaps it should be associated with Proposal 4).  Please see my
> recent message for my proposed list.  We don't have to tackle the
> "inheritance" aspect at this time -- we can avoid it just by providing
> a flat list -- but if people familiar with the CCTS process think it
> will be well received, we can try it.
>
> Thanks,
>
>     Eve

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

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

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142