mlhim-owners team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

Hi MLHIM owners,

OK, let me try to get my point across the best I can. I feel a little
bit concerned about posting my questions, because I don't want the MLHIM
community to get frustrated or to feel that it is a waste of time to
discuss my questions if they are not phrased in a technically correct
way. But I'll do my best.

Em 18/05/2011 14:37, Timothy Cook escreveu:
> Hi,
> 
> On Wed, May 18, 2011 at 8:55 AM, Luciana Tricai Cavalini <lutricav@xxxxxxxxx
>> wrote:
> 
>> Hi Tim and the mlhim-owners community,
>>
>> At this point, I think it is possible to model some CDDs, as long as
>> they are under the CARE_ENTRY class and they don't have Slots.
>>
> 
> 
> In MLHIM that would be the CareEntry class.
> 
> 
> 
>> IMO, The Entity Package needs further discussion,
> 
> 
> 
> Of course I welcome this discussion.  We certainly have people in the MLHIM
> community with experience and knowledge in this area.  I hope that they will
> choose to contribute.

I can't speak on the behalf of anybody else than me. But I will be
giving the MLHIM Winter Course on July and I know that the students will
ask for us to model "demographic" CCDs, something that is done by the
use of the Entity classes in MLHIM.

Of course I could tell the students that the Entity package is still
under development, but I'd rather feel more secure about this part of
the knowledge modelling instead.

So, I have studied demographic models a little bit, and I have been
discussing it with experts, but that's *my* understanding of all that
study and interaction. So, I am the only responsible for what I am
discussing here.

I understood that, in most of the demographic models that are used
nowadays, the classes we are calling Person, Non Human, Group,
Organization and Device inherit from a class called something like
"Actor". That's done because Actors are Parties, but Parties have Roles.
So, usually, in the demographic models, you have Actor and Role
inheriting from Party, and Person, Group, Organization etc inherit from
Actor.

At this point, in the MLHIM Entity package, Person, Non Human, Group,
Organization and Device inherit directly from Party and Role is shown as
a floating topic on the CDD 2.2.0. That doesn't make clear to me if that
means that Role inherits from Party or not. If it does, why not showing
it graphically as it is being done with the Person, Non Human, Group,
Organization and Device; and in this case, the "Actor" class might be a
good idea, because it organizes the model: Actors are one thing and Role
is another thing, but they would be in the same hierarchy of the model.

I built a XMind file (that is not a CCD, please!) in order to try to
explain what I meant above.

That is the most important question about the Entity package so far,
IMO; the others can wait until we discuss this one, I guess.

> 
> 
> 
>> and I need to
>> understand better how to model CCDs starting with COMPOSITION, for
>> instance, and how Slots operate.
>>
> 
> I hope this will get the discussion of Slots started.  I am not sure what
> your concerns are but this is the general application to date.
> 
> A Slot is simply a place to include another fully developed concept.
> [caution, I am not a pathologist so this may be missing some details]
> 
> Let us say that we have a CCD for a CBC (complete blood count).  In that
> concept there would be a white blood count (WBC) among many other tests.
> Now WBC is obviously a concept onto itself.  Therefore the may well be a WBC
> CCD.  In the structure of the CBC, you would not want to model the WBC all
> over again.  Reuse is a desired approach.  So where can we put the WBC in
> the CBC structure?
> 
> That is actually up to the person doing the modelling.  Notice that Slot
> inherits from Item.  So that means that it can be anywhere there is an Item
> class defined.  The expanded part of this is that Item inherits from
> Locatable, therefore a Slot can be inserted anywhere the is a locatable
> entry.

OK. So let me try to explain what I am having trouble understanding.

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
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.
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.
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.
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.
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.
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.

This is my heart_rate CCD, without the metadata.

I attached it on this message as well to show the results of this
34-step process.

Now, I want to build a CCD called bp_and_bt. This CCD will be my
complete application: a combination of two other CCDs: blood pressure
and body temperature. I know that this CCD needs to have a structure of
a COMPOSITION, because Composition is the minimal unit of data extract
that I can send from my application to another application.

Let's forget about the MetaData again and let's try to do the same step
by step:

1) Go to the Content sheet and copy the Composition purple rectangle
2) Go back to the CCD sheet and paste the Composition 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
Composition purple rectangle
4) Click on the "+" sign on the right side of the "content" element of
the Composition purple rectangle
*************Now I reached to my question**************************
5) Following the same strategy that worked well for building the
heart_reate CCD starting with an Observation, I should proceeed like (5)
for the heart_rate CCD. So, I sould Click on the "F" inside the yellow
square on the right side of the "type" element of the "content" element
of the Composition purple rectangle. That should tell me which class
inherits from Composition.
6) But the hyperlink sends me to Locatable on the Common sheet. If I
follow the same logic I used to build the heart_rate CCD starting with
Observation, that hyperlink is telling me that Locatable inherits from
Composition. Because for the Observation class, the hyperlink sent me to
History, and I understood that History inherits from Observation.
7) But by reading the MLHIM RM I understood it was the other way around;
I understood that Composition inherits from Locatable; but the hyperlink
on the "type" element of the "content" element of the Composition purple
rectangle is telling me that Locatable inherits from Composition, if it
has the same meaning of the hyperlink of the "type" element of the
"data" element of the Observation purple rectangle.
8) I read the documentation and I think I understood that, for the
"content" element, the class that inherits from Composition is ContentItem.

So, that's my question: let's say that the way I proceeded to build my
heart_rate CDD with the Observation class is right. Following the same
logic, why is CDD 2.2.0 telling me that, for the "content" element,
Locatable inherits from Composition? What's correct about the MLHIM RM
for the "content" element of the Composition class:

1) Locatable inherits from Composition?
2) ContentItem inherits from Composition?

I need to solve this problem before I start discussing anything about Slots.

I attached my incomplete bp_and_bt CCD in order to show what's my doubt.

I am sincerely sorry if this e-mail is somehow frustrating or a waste of
time for the MLHIM community. My only intent was to contribute the best
I can with the only thing I can do: knowledge modelling.

Thank you very much,

Luciana.




> 
> 
> 
>>
>> I will be working on phrasing my questions in an understandable way over
>> the next weeks. But it is not easy for me, since I don't have the
>> required IT background, and I don't understand the Reference Model well
>> enough to guarantee I will get my point across. That's why it will take
>> time.
>>
> 
> 
> I am sure you will do fine.
> 
> 
> 
>>
>> If my constraints were understood; then I can ask Tim: what is the
>> software you suggest for us to perform the videotaping?
>>
>>
> On Linux and certainly on Ubuntu.  RecordMyDesktop is easy to use.  I think
> it is installed by default.  Other OSs, I am not certain but there are a
> number of alternatives.
> 
> Regards,
> Tim
> 

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

Attachment: Party.xmind
Description: application/vnd.xmind.workbook

Attachment: bp_and_bt.xmind
Description: application/vnd.xmind.workbook

Attachment: heart_rate.xmind
Description: application/vnd.xmind.workbook