mlhim-owners team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

Hi Tim and the MLHIM community,

Just for the MLHIM community to see that I am not even close one of the
best knowledge modellers of the world:

There is a severe mistake on my heart rate CCD. I'll give a free trip to
Rio for the first person who figures it out. :-)

And no, different from what's written after (12), I didn't understand
the difference between class heritance and attribute values. I can take
care of my own ignorance in the long run, but if the MLHIM community
wants to use my example as a documentation in a short term, it is needed:

1) To fix the severe mistake I made (I can handle that, but it is
funnier to offer this trip to Rio and wait for a couple of days);

2) To complete the correction across all places where I wrote that
"class A inherits from class B" and it is wrong, because I can't handle
that for myself.

Sincerely,

Luciana.


Em 19/05/2011 00:55, Timothy Cook escreveu:
> On Wed, May 18, 2011 at 8:34 PM, Luciana Tricai Cavalini
> <lutricav@xxxxxxxxx> wrote:
> 
>> If I am starting my CCD from OBSERVATION, it makes sense to me. Let's
>> make the simplest example, by modelling "heart rate" as an Observation,
>> and let's skip the MetaData sheet, in order to go straight to the point:
>>
>> 1) Go to the Content sheet and copy the Observation purple rectangle
>> 2) Go back to the CCD sheet and paste the Observation purple rectangle
>> in the "value" element of the Definition green reactangle
>> 3) Click on the "+" sign inside the blue circle on the right side of the
>> Observation purple rectangle
>> 4) Click on the "+" sign on the right side of the "data" element of the
>> Observation purple rectangle
> 
> At this point we might want to add that Observation has several
> attributes.  Most of which were inherited.  The inherited attributes
> names are in green text. This is hopefully consistent thought out the
> CCD template.  But whether inherited or not.  The attributes with
> minOccurs = 1 are required.
> 
>> 5) Click on the "F" inside the yellow square on the right side of the
>> "type" element of the "data" element of the Observation purple
>> rectangle. That tells me which class inherits from Observation.
> 
> No.  It tells you what type / class instance must be here.
> 
>> 6) When I click on the "F" mentioned on (5), the hyperlink sends me to
>> the History class on the Structures sheet. So, I understand that History
>> inherits from Observation.
> 
> It tells you that the value of the data attribute must be History.
> 
>> 7) Copy the History orange rectangle from the Structures sheet.
>> 8) Go back to the CCD sheet and paste the History orange rectangle in
>> the "value" element of the "data" element of the Observation purple
>> rectangle
>> 9) Click on the "+" sign inside the blue circle on the right side of the
>> History orange rectangle
>> 10) Click on the "+" sign on the right side of the "events" element of
>> the History orange rectangle
>> 11) Click on the "F" inside the yellow square on the right side of the
>> "type" element of the "events" element of the History orange rectangle.
>> That tells me which class inherits from History.
> 
> It tells you that the instance of the events attribute must be  an
> Event (or one of its children).
> 
>> 12) When I click on the "F" mentioned on (11), the hyperlink sends me to
>> the Event class on the Structures sheet. So, I understand that Event
>> inherits from History.
> 
> I think by now we have cleared up the inheritance vs. type of confusion?
> Therefore I won't mention it thought the rest of this example.
> 
>> 13) The Event class has a red "A" on it, saying that it is an abstract
>> class and it can't be chosen to be pasted. Then I need to choose between
>> the classes that inherit from Event: PointEvent or IntervalEvent. That's
>> something that the modeller needs to know: whether the concept under
>> modelling is an event that is measured cross-sectionally (PointEvent) or
>> longitudinally (IntervalEvent).
>> 14) The vast majority of events are measured cross-sectionally, so let's
>> choose PointEvent, because it is more common and simpler as an example.
>> 15) Copy the PointEvent orange rectangle from the Structures sheet.
>> 16) Go back to the CCD sheet and paste the PointEvent orange rectangle
>> in the "value" element of the "events" element of the History orange
>> rectangle
>> 17) Click on the "+" sign inside the blue circle on the right side of
>> the PointEvent orange rectangle
>> 18) Click on the "+" sign on the right side of the "data" element of the
>> PointEvent orange rectangle
>> 19) Click on the "F" inside the yellow square on the right side of the
>> "type" element of the "data" element of the PointEvent orange rectangle.
>> That tells me which class inherits from Point Event.
>> 20) When I click on the "F" mentioned on (19), the hyperlink sends me to
>> the DvAny class on the Non-Quantitative DT sheet.
>> 21) I know that the division of Non-Quantitative and Quantitative DT is
>> just for visualization purposes; actually, all Non-Quantitative and
>> Quantitative data types are part of the DataTypes package.
>> 22) I want heart rate registered as a Quantitative data type, because
>> the instance of data will be something like 80bpm, 97bpm, 72bpm, etc;
>> so, in order to go to the Quantitative DT sheet, I click on the "F"
>> inside the yellow square on the right side of the Quantitative Datatypes
>> white rectangle.
>> 23) The hyperlink sent me to DvOrdered, an abstract class; I need to
>> choose on of the concrete classes on that sheet; I chose DvQuantity,
>> because I want something that allows a number with any decimal places
>> AND an unit of measurement (bpm - beats per minute - is the unit of
>> measurement of heart rate).
>> 24) Copy the DvQuantity blue rectangle from the Quantitatite DT sheet.
>> 25) Go back to the CCD sheet and paste the DvQuantity blue rectangle in
>> the "value" element of the "data" element of the PointEvent orange rectangle
>> 26) Click on the "+" sign inside the blue circle on the right side of
>> the DvQuantity blue rectangle
>> 27) Click on the "+" sign on the right side of the "magnitude" element
>> of the DvQuantity blue rectangle
>> 28) Then you can constraint a lot of things. To make it as simple as
>> possible, let's just constraint the minimum value allowed and the
>> maximum value allowed.
>> 29) The minimum value of heart rate a person can have is 0, when the
>> heart is not beating; it is not possible to have negative values for
>> heart rate. That sounds absurd, but the fact is that some systems we
>> have nowadays allow the registration of -44bpm. Trust me, I'm not kidding.
>> 30) And "0" is a possible value, so the value = 0 is the minimum and it
>> should be included; so, I will click on the "minInclusive" element and
>> press the TAB key; "Subtopic 1" is created as a child topic of the
>> "minInclusive" element; I double click on "Subtopic 1", type "0" and
>> press the ENTER key.
>> 31) The maximum value is a matter of conjecture, but it is a good
>> practice to define a maximum when huge numbers are absurd and should not
>> be allowed; for instance, if somebody sleeps on the key number 2 of the
>> keyboard, a value such as "222222222222222" should be registered, and
>> that is not a good idea; you are laughing, but I've seen this happening
>> before, trust me. Let's choose the number 1000 as the maximum value of
>> heart rate allowed. But then you can say: oh, but someone can sleep on
>> the key number 8 and "888" can be registered; well, OK, then you can
>> choose 500; oh, but someone can sleep on the key number 4... that's an
>> endless discussion. That's what's good about MLHIM: you are not
>> satisfied with a maximum of 1000, fine, build your CCD and define a
>> maximum of 500. You will still exchange data with the "Maximum 1000
>> Application" and both extracts of data will still be valid on both
>> systems. So, I defined 1000 as the maximum value of heart rate for my
>> CCD, and I defined that the maximum value includes the number 1000.
>> 32) So, "1000" is a possible value, so the value = 1000 is the maximum
>> and it should be included; so, I will click on the "maxInclusive"
>> element and press the TAB key; "Subtopic 1" is created as a child topic
>> of the "maxInclusive" element; I double click on "Subtopic 1", type
>> "1000" and press the ENTER key.
> 
> An excellent discussion of these issues and one that experts must
> determine in the modelling.
> 
> 
>> 32) Now, it is time to define that "bpm" is the unit of measurement.
>> Just to simplify the process, let's say that "bpm" is an universal unit
>> of measurement and that it doesn't need to be translated.
>> 33) Click on the "+" sign on the right side of the "units" element of
>> the DvQuantity blue rectangle
>> 34) Click on the "value" element of the "units" element and press the
>> TAB key; "Subtopic 1" is created as a child topic of the "value" element
>> of the "units" element; I double click on "Subtopic 1", type "bpm" and
>> press the ENTER key.
> 
> Actually, this is something that is available as a defined concept in
> a controlled vocabulary so it should be linked to one of the common
> vocabularies such as UUCM, SNOMED, etc.
> 
> 
> --Tim
> 

-- 
Esta mensagem foi verificada pelo sistema de antiv�s e
 acredita-se estar livre de perigo.