>> 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 {*}
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
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
> 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.
> 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.
>> 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. 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.
> but there is still the key difference to do with attribute deletions. It
> could
> be faked by including a lot of invariants in an archetype to force all such
> attributes to 0
what's fake about that?
We could talk about whether it is good that HL7 constraint statements implicitly
prohibit anything not mentioned - but this is a policy, it doesn't really
bear relevance on the question of the concepts
> 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. 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.
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.
> 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.
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.
> the problem of overuse of coded attributes in HL7 is what killed this kind of
> effort the last time it was tried - the HL7 people could not produce reliable
> rules as to when some value went into Act.code and when it went into
> Act.code.text, and so on. The combinatorial problem quickly grew out of hand
> due
> to the number of coded attributes on Act and Act_relationship. I an not
> saying
> "don't try", just pointing out the difficulties...
sure. If it was easy, where would the challenge be?
And I agree that the structures is going to be one of the more interesting
challenge.
Grahame
