mlhim-owners team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

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

I am not going to give my opinion because of my ignorance about this
specific class.

> 5.  Remove or modify Activity.

Ignorance (see above)

> 6.  Remove Folder.

Same as Section (see above).

> 7.  Remove the Link class as it is superceded by Relationship.

Ignorance (see above)

> 8.  Examine further the PartyProxy class and subclasses.  These are
> very important but are they the best implementation?

Ignorance (see above). I promise I'll study them tomorrow and them I'll
come up with my opinions.

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

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.

Sincerely,

Luciana.


> 
> 
> 
> 
> 
> 

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