Re: Methodology for describing Core Components(Rev.04)

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Hisanao 

Following pilot work undertaken prior to, and at, last week's UK Data Harmonization Group meeting I have been asked to extend the data capture forms to provide more functionality. In the course of doing this I have noted some problems with the basic data model, as follows:

Whilst I have added an Industry field that matches the Industry entry in the EntityApplication box of the latest revision of the model, I note that the revised model does not currently record the fact that both Industry and Business Process are properties that have been addeed to the models for EntityPattern and BusinessEntity. I have also been asked to add Industry to the CodeValue entity as certain code values are only applicable in certain industry segments.

The forms still contain no Unit of Measure entry. The new Basic Data Type field is the nearest, but it is based on the basic data types of XML Schemas, so I am not completely sure that this is what is meant by this field (which has always confused me). See if you think this is a good match for what you intended, or if this property is no longer relevant to the model.

Users have complained about the lack of matching of form names with names used in the model. I have tried to use easily understandable names in the forms, so you have  Pattern instead of EntityPattern (or as it is described in section 3, an Analysis Pattern) and Permitted Value instead of CodeValue. Is it really important that we align terminology? Should we maintain a listing of the equivalences? Pattern seems particularly confusing to people: would we be better to use Analysis Pattern in all instances of referring to this object?

The model for ValueDomain seems to be wrong. At the moment the forms only show Type and Identification (this being a pointer to the identifier of the associated code set or data format). I really feel we need to try to realign the model with the forms better from Representation Class downwards.

My mappings of your Representation Classes to XML Schema built-in datatypes is as follows:

Amount -> Decimal
Code -> String
Description -> String
Identifier -> String
Name -> String
Number -> Integer, Decimal and Float (I have not provided support for fload as I do not believe it is relevant for most e-business applications)
Percent -> Decimal
Quantiy -> Integer (or, maybe, Decimal)
Rate -> Not supported directly in XML Schema - its simply a pair of quantities
Date -> timeInstance, date or time.
Age -> timePeriod or duration
Indicator -> Boolean
Measure -> Decimal (or more complex type consisting of Decimal + enumeration list of measurement units.

The question arises as whether Representation Classes are just instances of a Data Format or whether they are more fundamental than this. Please try out the new Data Format form and see if they are missing something that relates t o the ISO 11179 concept of Representation Classes.

In reviewing the latest draft of the Methodology document I get the feeling that the meat of the material, which is really Section 3, is being swamped by the justification material and examples that precede and follow it. Would you object if I created a separate document that just tried to explain the model and those things that are also covered in Section 3?

Martin Bryan

CoreComponents.zip