mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

Hi Luciana,

THANK YOU!!!!!!!

This is such an awesome piece of documentation.  I hope that you are
going to include this in the CDD manual (with a few changes).


I have several comments but wanted to acknowledge the work you have
done here.  I'll post more comments tomorrow.

The one key thing I think is the misunderstanding of inheritance in
the CDD.  The XMind hyperlinks are kind of overloaded to serve two
purposes.  When they appear on a class name bubble, they represent OO
inheritance (data and behaviour).  When they hyperlink is on a 'type'
node it indicates the type constraint for the 'value' or 'dv' node on
the same level.  This latter instance is not inheritance.  It is
constraint.

After going over your models, I will offer more concrete replies.

Thank you again for such a wonderful explanation of the modelling
process in MLHIM.

Cheers,
Tim

PS: Please do not apologize for the work you are doing.  You are
without a doubt one of the best multi-level modelling experts in the
world.




On Wed, May 18, 2011 at 8:34 PM, Luciana Tricai Cavalini
<lutricav@xxxxxxxxx> wrote:
> 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írus e
>  acredita-se estar livre de perigo.
>
>



-- 
================
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

You may get my Public GPG key from  popular keyservers or
from this link http://timothywayne.cook.googlepages.com/home