Peter,
Thanks for clarifying. One comment we could make for them right away
would be that amounts and units should be in a hierarchy and be used with a
single relation instead of having various dedicated and unrelated relations
like Amount and AmountCurrency, as in the current components. SUMO already
has an extensive hierarchy of unit types, with full semantic definitions
for each. (01)
Adam (02)
At 11:20 AM 2/25/2004 -0800, Peter Yim wrote:
> > Did you have another post you'd like [to] highlight?
>
>I was referring more to building a case for expressing the Core Component
>Types (and eventually all core components, and then UBL, ... and so on) in
>an ontology, or more specifically, in a KIF-SUMO-based ontology. Some of
>that discussion may be helpful.
>
>Pertinent questions may include:
>
>* how would that improve upon whatever is being done now?
>
>* what more would that add to (or what's wrong with) modeling the CCT's in
>UMM (in this case, or UML in general)?
>
>We could discuss this more, in real time on Thu 2004.03.04 (hopefully with
>TimMcGrath's presence) when we will try to specifically tackle this matter
>during our regular phone conference (ref:
>http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2004_02_19#nid041).
>
>Regards. -ppy
>--
>
>Adam Pease wrote Tue, 24 Feb 2004 18:28:10 -0800:
>>Peter,
>> The only post that seemed to address the actual content of the model
>> appeared to be
>
>>>- 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.
> >> (ref. TimMcGrath / Fri, 13 Feb 2004 08:56:39 +0800
><http://ps1.cim3.net/ps.php?theurl=http://lists.oasis-open.org/archives/ubl-lcsc/200402/msg00063.html#purp147>)
>
>>...and for me, I'm afraid that didn't shed much light. Did you have
>>another post you'd like the highlight?
>>Adam
>
>
>>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 (03)
_________________________________________________________________
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 (04)
|