mlhim-owners team mailing list archive

[Timothy Cook <timothywayne.cook@xxxxxxxxx>]

On Mon, Sep 19, 2011 at 13:53, Luciana Tricai Cavalini
<lutricav@xxxxxxxxx> wrote:
> If Slot is a class and it inherits directly from Locatable,

Well, it doesn't inherit directly from Locatable.  It inherits from
Item. Along with Cluster and Element.  This gives you the ability to
create any "data shape" using those three classes.

> does that
> mean that any MLHIM 2 RM class CCD might be put inside a Slot?

Yes, any CCD can be put into a Slot.  *However* at design time of a
CCD when a Slot is created the allowed_ccds attribute constrains WHICH
CCDs are legal for that Slot.  Then at runtime, one of those can be
selected.  Its name goes into the ccd attribute.

Slots really exist in MLHIM in order to build up larger structures
that may be called operational templates in other environments.  I
envision that in *most* cases this is the only use that Slots will
get.  Say you want to model a specific lab panel.  Then you might add
several Slots to a CCD that only allow a certain CCD in each Slot.
Notice that the cardinality of allowed_ccds is one to many.

>
> If yes, don't you think that that might be dangerous as far as knowledge
> modeling goes, or are we using here the principle of transferring the
> responsability to knowledge modelers (primarily) and app developers
> (secondarily)?

I think I may have explained this above.  But yes, we are imposing;
"don't be stupid" on the modellers.  Otherwise your CCDs won't be used
by anyone else.

The primary place where we are putting a burden is on app developers.
They have to be aware of the selected CCD when the instance data is
created.  But this is already something they are used to doing with
XML.


--Tim