mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

Hi All,

I have now created a blueprint at:
https://blueprints.launchpad.net/mlhim-specs/+spec/rm-simplify-2011

as well as creating bug reports:
https://bugs.launchpad.net/mlhim-specs

for the items discussed so far in this email.   BUT!!! this doesn't
mean the discussion part is over.  I am just hoping that it will make
it easier for everyone to make comments directly on the bug reports
themselves instead of replying to this huge email.  The Blueprint
references this thread in the archives.

Cheers,
Tim



On Mon, Sep 19, 2011 at 15:04, Luciana Tricai Cavalini
<lutricav@xxxxxxxxx> wrote:
> Hi Tim and mlhim-owners,
>
> I decided to rebuild the entire thread from the beginning for us not to
> loose important part of the discussion that is still pending, but I
> don't have anything else to add or suggest. Thank you Tim for your
> dedication to this project and you kind attention to our questions.
>
> ======================================================================
>
> Em 18/09/2011 21:21, Luciana Tricai Cavalini escreveu:
>> Hello Tim and mlhim-owners,
>>
>> Thank you Tim for sharing your considerations about the MLHIM 2 model.
>>
>> After working a little bit with real examples of knowledge modeling,
>> it was clear to me that some classes bring confusion among knowledge
>> modelers. The most prevalent confusion, amazingly IMO, was the fact
>> that apparently there is too much semantics into the RM classes, what
>> might not be a good idea.
>>
>> I'll make more comments and ask some questions along Tim's original
>> text:
>> Em 18/09/2011 10:21, Timothy Cook escreveu:
>>> Hi All,
>>>
>>> >From the beginning MLHIM design has been focused on the good things
>>> about the more popular models as well as the Albert Einstein quote;
>>> "Make everything as simple as possible; but no simpler."
>>>
>>> It has certainly been my experience based on talking to many people
>>> and reading many blog posts.  That the reason for lack of wide spread
>>> implementations of any of these models has been complexity that did
>>> not readily show a reason for being so complex.
>>>
>>> MLHIM shows a marked reduction in complexity as well as use of main
>>> stream technologies.
>>>
>>> The original MLHIM 1.x model, as a proof of concept, is largely
>>> openEHR converted to using XML as the constraint and implementation
>>> technology.
>>>
>>> MLHIM 2.x already has a number of changes in order to reduce
>>> complexity and to bring it further in alignment with XML.  I think
>>> the benefits of using XML is obviously and need to be discussed here.
>>>
>>> But in consultation with Luciana and her experiences with teaching
>>> modelling and analyzing the model.  Especially the quantitative
>>> datatypes section.
>> I would suggest that we discuss the quantitative datatypes here in
>> this thread as well. IMO, at this point in MLHIM 2, there are overlaps
>> between the Data Types inherited from openEHR and the XML datatypes.
>> The main example is DvCount and DvInteger. The only difference
>> between them is that DvInteger doesn't have an element to constraint
>> the unit(s) of measurement of what's being counted. Still IMO, this
>> is not enough to keep both classes; maybe we should consider
>> including an element "units" in DvInteger. Same thing for DvQuantity
>> and DvDecimal.
>
>>   We have come up with a few more points to remove
>>> some classes that carry semantics and do not necessarily benefit the
>>> art of modelling.  In fact in many cases students find them
>>>  confusing. In addition to classes like Observation and Instruction
>>> carrying semantics.  There are also a number of classes that carry
>>> the semantics of an EMR/EHR.
>> The CareEntry child classes are the most classical cases of "excessive
>> semantics" inside RM classes that only bring confusion to knowledge
>> modellers. Twice this year I gave KM courses and there were many
>> moments in which the students wouldn't agree about which class to
>> choose and the ambivalence of the classes was genuine. The main
>> example is modeling psychometric diagnostic instruments. There is
>> ambivalence between Observation and Evaluation classes in many
>> Elements of this kind of concept.
>> Furthermore, some students have trouble understanding why do we need
>> an Instruction class archetype and an Action class archetype in order
>> to model something that has the same structure (e.g., medication). My
>> orthodox answer: "oh, because one is for drug prescription and the
>> other is for drug administration" didn't convince even myself. IMO,
>> we are leaving semantics inside the RM that is perfectly solved at
>> the CCD or implementation level.
>>
>>> It is my opinion that these do not benefit the idea of creating
>>> Concept Constraint Definitions (CCDs).  Specifically classes like
>>> Composition do not make sense in making a CCD (and possible sub-CCDs
>>> in Slots) as a unit of committal and transfer.
>> Here I would like to hear you more. Why do you think that the
>> Composition class carries semantics into it?
>>
>>> All of these ideas below will need to be put into blueprints and bug
>>> reports to make them formal to the project.  However, I wanted to
>>> pass these along as a simple email first to get general feedback.
>>> At this point some of these are just ideas and do not contain all of
>>> the detail required for actual model implementation.  Sometimes
>>> things like additional attributes, removing or renaming attributes
>>> may also be needed.
>>>
>>> 1.  Make CareEntry a concrete classes and remove its subclasses.
>> Agree (see above)
>>
>>> 2.  Remove the Section class.
>> Definitively Section and Folder are confusing. But could you please
>> explain to us what you have in mind if those classes are removed from
>> the MLHIM 2 RM?
>>
>>> 3.  Remove the Composition class.
>> Please ellaborate (see above).
>>
>>> 4.  Remove or modify EventContext
>
> This is a typical class completely full of context and EHR-oriented (EHR
> somewhere, what's more problematic). You can probably model all that
> knowledge on an AdminEntry class CCD and/or as any Entity class CCD.
>
> Exactly.
>
>>> 5.  Remove or modify Activity.
>
> I knew I remembered that; I just wasn't sure. This is the class you use
> under the CareEntry child class Action. It is like History under
> Observation, sort of. Agree to eliminate if Action is being eliminated.
>
> Similar to.  But it was put into openEHR for the ability to model a
> State Machine.  Since that functionality is actually part of an
> implementation it doesn't need to be here.
>
>>> 6.  Remove Folder.
>> Same as Section (see above).
>>
>>> 7.  Remove the Link class as it is superceded by Relationship.
>
> OK, Relationship replaces Link and it keeps the same attributes? Is it
> just a renaming decision? But we already renamed so many classes, why
> not this one?
>
> I don't have the original openEHR definition at hand and Link has
> already been changed in MLHIM.  However, Relationship was designed to
> allow for the semantics of the relationship to be entered from a
> standard ontology.  <red_faced>I see now that the relationship_type
> attribute is missing.  </red faced> In this way you could use 'is-a',
> 'contains', 'part-of', etc.  Link did not have that ability and I
> personally think Relationship is a better word for the function.
>
>>> 8.  Examine further the PartyProxy class and subclasses.  These are
>>> very important but are they the best implementation?
>
> I can't see any problems with the way they are implemented now.
>
> The remaining message is similar to the last one, OK?
>
>>> 9.  Remove the word Feeder from FeederAudit and FeederAuditDetails.
>>> Again, very important but need cleaning up and clarifying.
>> Why do you think it is important to remove "Feeder" from those
>> classes?
>
> I just think they are unneeded and can be confusing to developers.
>
>> 10.  Remove DataStructure and its subclasses.  The conventional wisdom
>> is that any "shape" data structure can be built using Clusters,
>> Elements and Slots.
>>
>> Agree. When you start teaching people and giving them "hints" such as
>> "if you are confused, choose ItemTree" or axioms such as "everything
>> might be ItemTree except ItemTable", it is because something is not
>> working well.
>>
>>> AFAIK there is no implementation work going on with MLHIM2.  It is
>>> all still MLHIM 1.x  So the impact is minimal if at all.
>> Yes. We need to do something. There is a reason why such a good idea
>> is not widely implemented and everything that comes to my head is: (1)
>> opposite academic and economic interests, (2) excessive complexity
>> that makes people give up and go do something else and (3) sustained
>> adoption of old-fashioned technologies for knowledge modeling when
>> there are updated industry standards for that (e.g. XSDs).
>>
>>
>>   I would really
>>> appreciate your replies with questions, comments or criticisms.  One
>>> thing that may need to be explained further is how CCD Slots work and
>>> what the instance data looks like.  I know that this was a concern
>>> Luciana had concerning interoperability.   If anyone needs a more
>>> formal explaination please let me know.
>> I do! Slot as a class is still an enigma to me.
>>
>>> Kind Regards,
>> Likewise and thank you Tim!
>>
>>> Tim
>>>
>>>
>>> PS.  Just as an FYI for those that may not be following the other
>>> mailing lists.  HL7v3, openEHR and 13606 are all currently pursuing
>>> various types of simplifications.  Many of which we have already done
>>> in MLHIM.
>> I wonder if at least a tiny proportion of that is not due to the
>> existence of MLHIM itself. Well, about the discrete release of the
>> Template Designer as a freeware software I am almost convinced it was.
>
> Well, even in my most arrogant hour (and they can be big and often)  I
> wouldn't suggest that to be the case.  I doubt they even know we are
> here.
>
> If we were that significant in their eyes then there would be people
> from those groups on the mailing lists.
>
> Cheers,
> Tim
>
>>
>> Sincerely,
>>
>> Luciana.
>>
>>
>>>
>>>
>>>
>>>
>>>
>
>
> --
> Esta mensagem foi verificada pelo sistema de antivírus e
>  acredita-se estar livre de perigo.
>
>



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