The only post that seemed to address the actual content of the model
appeared to be (01)
>- the CCT Component Quantity. Unit. Code - i suspect was supposed to be
>Quantity Unit. Code (ie the object class is Quantity Unit not Quantity) -
>this keeps it consistent with the remaining components and with the way it
>was modeled for Measure Type. This carries into table 8-2 as well.
>- the CCT Component Identification Scheme Agency. Identifier was possibly
>meant to be Identification Scheme. Agency. Identifier (the object class
>is Identification Scheme). this is not only consistent with other
>components in Identifier Type but also parallels the way agency details
>were defined for Code Types (cf. Code List). However, in table 8-2, we
>seem to have the alternative. Here we find Identification Scheme Agency.
>Identifier and Identification Scheme Agency. Name .Text. These imply
>that the object class should be Identification Scheme Agency. This
>disagrees with table 8-1 and more significantly does not follow the
>pattern for the Code Type and Code List. I made the assumption that the
>way Code Type and Code List were constructed was the intended approach for
>Identifier and Identification Scheme as well. (02)
...and for me, I'm afraid that didn't shed much light. Did you have
another post you'd like the highlight? (03)
At 06:16 PM 2/24/2004 -0800, Peter Yim wrote:
>For those who are working on this, I would like to draw your attention to
>the discussion thread on the UBL-LCSC list that has developed since Tim's
>initial post on the subject. Some of the issues discussed would make the
>case for pursuing the matter with ontological engineering rigor.
>Please take a look at the ten or so responses to Tim's post at:
>Adam Pease wrote Thu, 12 Feb 2004 10:01:29 -0800:
>> This sounds like a good opportunity. I would suggest that we offer
>> SUMO + MILO + Invoice as core components. I also agree that after
>> people start trying to formalize terms (my message of 1/16/04 suggests
>> who might try which terms) and come up to speed, that Tim's list would
>> be a good next step.
>> I've left off the UBL mailing list from the cc list until the group
>> reaches consensus on this.
>>At 06:34 AM 2/12/2004 -0800, Peter Yim wrote:
>>>Given our charter, I would invite the [ontolog] community to:
>>>1. review Tim's input (message below and the two attachments).
>>>2. seek clarification (where appropriate), discuss & comment. Note that
>>>Tim McGrath (UBL-LCSC), Sue Probert (UN/CEFACT-TBG17), and a good number
>>>of pertinent players (like Monica Martin, Bill McCarthy, John Yunker,
>>>Farruhk Najmi, Marion Royal, Eduardo Gutentag, ... etc.) are actually
>>>either active or observing on this [ontolog-forum] list.
>>>3. consider how "you" would (or "we" should) have tackled it, with an
>>>ontological engineering approach, giving the methodologies the ontolog
>>>community has been deliberating and working on.
>>>4. consider tackling this as our first real formalization requirement in
>>>the UBL-Ontology project, once we, as a team, get past learning the
>>>ropes in SUO-KIF formalization. (ok with you, Adam?)
>>>5. would be wonderful if we can reach some concrete and actionable
>>>conclusions (in relatively short order) and provide that as feedback and
>>>recommendations to Tim/UBL.
>>>6. for other pertinent references, see:
>>>-------- Original Message --------
>>>Subject: [ubl-lcsc] Modeling Core Component Types
>>>Date: Thu, 12 Feb 2004 15:01:40 +0800
>>>From: Tim McGrath <tmcgrath@xxxxxxxxxxxxxxx>
>>>The UBL Library has been built upon a set of data types/core component
>>>types defined by the CEFACT CCTS v2.0 specification.
>>>To date, we have relied upon hand crafted schemas to define these. This
>>>has resulted in a few problems...
>>>a. the schemas have to be mapped to the representation terms in the UBL
>>>b. they have not always been synchronized with other deliverables
>>>c. the provide a disjointed view of the overall UBL library.
>>>Over the past few weeks we had had various discussions about how to deal
>>>with this in a more controlled manner.
>>>One of the options is to go back to our basic design approach and create
>>>models of these from which XSD code can be generated. I know the
>>>Michael Dill has been keen to see this.
>>>To this end I have dug into the CCTS specification and created a model
>>>of the Core Component Types - both as a UML Class Diagram and a UBL
>>>format spreadsheet model. These are attached. My objective was to
>>>create structures that modelled the Dictionary Entry Names in the
>>>I would be interested in other opinions on this strategy - particularly
>>>Michael and the TBG17 group.
>>>PS this exercise exposed a few typos (i suspect) in the specification so
>>>few objects have slightly different names.
>>>phone: +618 93352228
>>>postal: po box 1289 fremantle western australia 6160
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (06)