Grahame Grieve wrote:
>>> The "subtractive logic" as you call it, is exactly what cADL is.
>>>
>>>
>> No, it's not - this is a fundamental misunderstanding. The subtractive logic
>> of
>> the HL7v3 methodology is the ability of one model in the chain (say an RMIM)
>> to
>> remove attributes in class A that were defined in the same class A in the
>> predecessor model (say a DIM).
>>
>
> In cADL, I can say something like this:
>
> attributeName cardinality matches {0} matches {*}
>
Grahame,
you can only do this if the reference model already says that the
cardinality (which is only for container types by the way) is
0..something. You can't say and attribute value is absent unless the
reference model already allows that.
> this is a statement that attributeName cannot be valued in this model.
> But attributeName must exist in the reference model, and it is superfluous
> to say this if some other archetype on which you are based has already said
> this. And you cannot add or define attributeName in cADL
>
no, that's not right - the attributeName of course exists in the RM, but
if its cardinality is 0..1 or 0..*, clearly it is allowable for there to
be no value in the data. cADL statements are statements about objects,
i.e. instances, not models.
> In an RMIM, you make a statement that attributeName cannot be valued
> in this model. AttributeName must exist in the reference model, and it
> is superfluous to say this if some other RMIM or DMIM on which you are
> based has already said this. And you cannot add or define attributeName in
> DMIMs or R-MIMS
>
> If you want, you can interpret the statement, either in an archetype or
> an RMIM, as a definition of a new class which has had that value
> "subtracted", as HL7 does with RMIM's. This may or may not be a good
> idea, but doesn't change the fact that what is going on in concept is
> no different
>
see above. There are no new classes of any kind in ADL archetypes, nor
any subtractions, additions or any other modifications to the reference
model, because archetypes are not saying anything about models, or
classes, they only make statements about instances.
> > The models are defined, starting with the RIM,
>
>> loaded with attributes that can be deleted (projected out) in this way.
>>
>
> you've been listening to someone who's trying too hard to pretend these
> things are not the same too much; ignore him. In spite of the fact that
> I will use "projection" below, I think it's an extremely unhelpful term.
>
well, he's the most vocal advocate/defender/architect of the RIM, and
seems to represent HL7 on the matter...and that's how he describes the
theory behind the RIM.
>
>> This isn't a deficiency in object modelling, because it is not part of the
>> object model
>>
>
> I believe that it should be; it's certainly part of Bertrand Meyer's scope
> for an object model: design by contract.
>
that is something else entirely - DbC statements like in Eiffel and OCL
are statements attached to models, defining or modifying their
semantics. Archetypes don't add anything to the model, they say how its
instances should be used.
>
>>> So you invent cADL and
>>> Hl7 invents Static Model Diagrams, but they both do the same thing,
>>> and in this regard OpenEHR and HL7 do not follow normal object
>>> modelling.
>>>
>
> You objected to this. And yes, The reference models for both are normal
> object models.
well, I don't think many people would agree,with respect to HL7 - I have
numerous reports and references to that effect over the years. And they
are right: no-one builds object models by including all possible
attributes in the most abstract classes so that they can be stripped out
in "derived" models - there is not one paper, textbook or other
published source that says to do this, and there are many that show why
it should not be done. I will write a cheque for ?100 to anyone who can
find one that anyone has heard of (not published by HL7 obviously),
describing why an object model should be built this way.
> But the idea that the value of the construct is found in
> constraint definitions on the construct is not normal practice. I believe
> it's the only game in our town, but it is not normal practice. I think
> it should be.
>
>
well constraints on models have been normal since Djikstra and others
invented the concepts; it's a pity that only languages like Z, Eiffel
and a few others have incorporated them. In fact, I think we should
consider it an aberration that the other programming languages have
failed to do something so basic so far.... But now Java has the JML
effort, and C# will finally get design by contract. But we need to be
careful in our understanding - these contracts are constraints on the
reference model; there is no point trying to express domain specific
constraints (i.e. business rules) on instances as contracts, because a)
we don't want that stuff built into the software and b) there are
different sets of constraints depending on the particularities; they
have to be separated from the object model and encapsulated each on
their own.
I made some points about this difference some years ago....see
http://www.deepthought.com.au/it/ocl_review.html
>> And the other problem with this is that two
>> distinct RMIMs each containing (say) a clone of the Observation class from
>> the
>> RIM could delete different combinations of attributes (i.e. create 2 new
>> projections on the RIM Observation class); multiply this up to N RMIMs doing
>> the
>> same thing, and M classes. None of this can happen in openEHR.
>>
>
> really? So I cannot make cADL statements that make different constraints on
> a reference model class in different archetypes (or even the same one)? Of
> course
> this is how things work.
yes you can, naturally...but since cADL is not defining any classes, or
saying anything about the reference model, it's not the same thing - 2
archetype models are just like 2 LEGO instruction sheets - they give 2
different ways to put the LEGO pieces together; they don't invent or
modify the LEGO pieces.
> If I chose to treat an archetype as a "projection" - which
> I could - then this might be a problem. If I chose not to treat an RMIM is a
> "projection", then it's not a problem.
>
but - an archetype isn't, and an RMIM is....these are both facts - they
are in the formal expressions....
> I'm going to keep saying this until everyone listens: the difference is not
> in what is being done, it's in how the outcome is treated.
>
>
And I am going to keep repeating: two different things are being done
here: a) constraining instances (archetypes) and b) creating new schemas
in terms of projections of existing classes (xIMs). There may well be
practical solutions to connecting them, but establishing such a solution
doesn't change the underlying theory of the two approaches; and neither
should we - the theories are clear.
>
>
>> Believe me, if interconversion was easy, we would have done it years ago
>> (when
>> we did in fact try, in concert with senior HL7 people). What you are now
>> able to
>> do is a conversion between formalisms (or parts thereof; RMIMs etc don't
>> have a
>> place to put the meta-data, archetype terminology or code-bindings), which
>> is
>> not the same as a conversion between artifacts. It will be great if the ADL
>> formalism can be used more widely, but please don't imply that a) archetypes
>> and
>> RMIMs now seamlessly interconvert or b) that the methods are really the same
>> in
>> HL7 and openEHR. This will just confuse people.
>>
>
> the methods are the same, the perception is different. Agree that RMIM's
> are missing some things. They can - and will - be changed.
>
see above ....
> But yes, I don't (yet) convert between reference models. I don't want to
> imply something different, but the language you have chosen to use is
> confusing. what's an "archetype"? Is it an ADL statement against any
> reference model, or an ADL statement against the openEHR reference model?
> Please advise me how to describe things so they aren't confusing.
>
I accept any criticism of the above sort - I know we have to find better
ways of explaining things. To answer your question:
* an archetype is a set of statements constraining the instances of a
reference (object) model to a particular configuration or set of
configurations
* an openEHR archetype is the above, where the reference model is the
openEHR reference model
hope this helps,
- thomas
