For Tim --
I found the UML and XLS that you provided very helpful in understanding
the core components. There are still ambiguities, but there is enough
information that I am working on formalizing them into an ontology
consistent with SUMO/MILO -- though it requires a number of additions
to the SUMO beyond the bare core component types themselves. (01)
One thing that appears missing from the UML (and the xls) is
any notion of subclasses or subtypes. There are a few core
components that appear to me to be subtypes of others --
a CodeList Scheme, for example, would seem to be a subtype of
Identifier Scheme, and Code is a subclass of Identifier. (02)
Would you be able and willing to create a modified UML that
included the subclass dependencies? If so, I will suggest
some links. (03)
Pat (04)
================ (05)
Peter Yim wrote: (06)
> fyi ...
>
> -------- Original Message --------
> Subject: [ubl-lcsc] Models for generating CCT and Data Type schemas
> Date: Fri, 27 Feb 2004 01:46:09 +0800
> From: Tim McGrath <tmcgrath@xxxxxxxxxxxxxxx>
> To: dill2@xxxxxxxxx
> CC: ubl-lcsc@xxxxxxxxxxxxxxxxxxxx
>
> From what i could gather at today's meeting, it was decided not to use
> the current CCT.xsd and other Rep. Term and Data Type schemas.
>
> Instead we would create new schemas based on your understanding of the
> CCTS.
>
> A few weeks ago i sent this out for comment. I think it follows your
> earlier idea of a spreadsheet/model for data types. However, i have
> crafted these so using existing naming rules we get the correct CCTS
> Dictionary Entry Names (as near as our spreadsheet formulas allow anyway).
>
> I wonder how we would go if we took these CCT models and loaded them
> into EDIFIX with the assumption that they were treated as ABIEs, BBIEs
> and ASBIEs (as in the spreadsheet) instead of types and supplementary
> components? In other words, treat this spreadsheet model just like any
> other UBL document model. The schemas we could generate would follow
> the NDRs for ABIEs, BBIEs and ASBIEs - but that is a good thing. After
> all these things are really aggregates, components and assocations. As
> was discused we will end up with more elements and no attributes! But i
> suspect that is not a bad thing either.
>
> The more i think about this there seems no reasons to have different XSD
> representations for CCT, DTS and their supplementary components than for
> BIEs. What is more we then have a consistency between the models and
> the schemas - which i know you have argued for.
>
> I think if we can work this out over the next weeks or so it will be
> acceptable in the 1.0 release. But we will need to commit to a plan
> tomorrow to get NDRs approval for this. Let me know if this seems
> practical and achievable or if you need more information.
>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________
> 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
> (07)
--
=============================================
Patrick Cassidy (08)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (09)
internet: cassidy@xxxxxxxxx
============================================= (010)
_________________________________________________________________
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 (011)
|