Peter,
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.
>similarly
>- 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)
Adam (04)
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:
>http://ps1.cim3.net/ps.php?theurl=http://lists.oasis-open.org/archives/ubl-lcsc/200402/threads.html#purp431
>
>Regards. -ppy
>--
>
>Adam Pease wrote Thu, 12 Feb 2004 10:01:29 -0800:
>
>>Peter,
>> 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.
>>Adam
>---
>
>>At 06:34 AM 2/12/2004 -0800, Peter Yim wrote:
>>
>>>Hi Everyone,
>>>
>>>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:
>>>http://ontolog.cim3.net/cgi-bin/wiki.pl?UblRelease1_0
>>>
>>>Regards,
>>>PPY
>>>--
>
>
>>>-------- Original Message --------
>>>Subject: [ubl-lcsc] Modeling Core Component Types
>>>Date: Thu, 12 Feb 2004 15:01:40 +0800
>>>From: Tim McGrath <tmcgrath@xxxxxxxxxxxxxxx>
>>>To: ubl-lcsc@xxxxxxxxxxxxxxxxxxxx
>>>
>>>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
>>>models.
>>>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
>>>specification.
>>>
>>>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.
>>>
>>>--
>>>regards
>>>tim mcgrath
>>>phone: +618 93352228
>>>postal: po box 1289 fremantle western australia 6160
>
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Subscribe/Unsubscribe/Config:
>http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
>mailto:ontolog-forum@xxxxxxxxxxxxxxxx (05)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (06)
|