Re: [ubl-lcsc] Modeling Core Component Types

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

see comments inline...

CRAWFORD, Mark wrote:
> Tim,
>
> Some thoughts for you -
> > 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 bewen synchronized with other deliverables
> > c. the provide a disjointed view of the overall UBL library.
> >   
>
> both the CCT and Unqualified DT schema modules are in fact normative expressions of CCTS to be used by anyone - not just UBL and not just for the UBL library. The recent change to mapping to DTs rather that RTs would seem to eliminate this aspect of the problem.  The focus should be on creating the UBL qualified DT schema module as an expression of the LC content model.  
none of that impacts on the three points made above.  

* when people study the UBL library they find spreadsheets and UMl diagrams
of all the structures except the CCTs.
* we still have to map our BIEs to specific CCTs/DTs (or whatever they are
called today).  Today this means taking a Representation Term and tracking
into into XSD to find the things it contains.
* we do not present a conceptual view of the entire library.

So what we are talking about is at one level documentary support for the
Library.  At another level it will also give us the mechanism to model any
UBL DTs (if we want them).

I personally think that generating XSD schema off these is a pragmatic alternative
to the hand crafting until we get an official ATG2/CEFACT set of schemas
to work from.  But this is debatable.
> > 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 like the idea of the model and it would be a welcome addition to the CCTS, but am not convinced that yours is 100% accurate.  As I look at the CCTs defined in Table 8-1 of CCTS, there appear to be many inconsistencies in terms of both class and subclass as expressed in your model.  I would also like to see a separate UML model of the UBL qualified DTs.
I accept I may not be 100% because I am working like a detective, making
assumptions based on clues in Table 8-1.  That is why i would appreciate
someone telling, but I did base this entirely on table 8-1 and 8-2.  Can
you be more specific as to where it is inaccurate?  (NB I don't know what
a subclass is  :-[ )

My biggest thread of evidence was the Dictionary Entry Names.  These have
Object Classes that imply associations with the 'type'.  

I should emphasise that this model reflects what the CCTS 2.0 tables 8-1 and
8-2 define.  
 
 I have not designed anything, i am just documenting for the benefit of those
trying to make sense of the CCTs - but I had to force myself not to start
refining.  
 
 If the CCTs are going to be maintained then this material should give plenty 
of fodder for some rationalisation and good data modeling.

PS i have a suspicion that someone, somewhere has the original model - in
fact they must have used something similar to build the component library.
 i am happy for you to use my reverse engineered one - but it may pay to
put out a call to the original authors.
 
> > PS this exercise exposed a few typos (i suspect) in the 
> > specification so 
> >  few objects have slightly different names.
> >   
>
> Please identify the typos so I can fix the CCTS.
In Table 8-1
- 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.


> Thanks,
>
> Mark
> > -- 
> > regards
> > tim mcgrath
> > phone: +618 93352228  
> > postal: po box 1289   fremantle    western australia 6160
> >
> >
> >   
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160