>> 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
of course
>> 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.
ok, I'll rephrase:
This is a statement that attributeName cannot be valued in an instance
that conforms to this constraint. 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
This is a statement that attributeName cannot be valued in an instance
that conforms to this model. But attributeName must exist in the
reference model, and it is superfluous to say this if some other *IM
on which you are based has already said this. And you cannot add or define
attributeName in an *IM
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
so, you say:
> 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.
And I say that this is equally true about archetypes and *IMs, and you can
choose, if you want, to create schemas or class models from either. HL7
chooses to. OpenEHR doesn't.
> 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, an archetype is not a definition of semantics for how to use a
model in a particular context?
> 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
you do. tell me that this isn't how openEHR works? You define everything
you will need in the reference model and strip it out from the instances
using archetypes
>> 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....
So, I can see that I'm not getting anywhere. I am claiming that this
difference is a feature of how these things are used, and hoe they are
presented, not what they are. And that you can use either in either way.
Am I wrong to claim that you *can* use either in either way? (I am not
claiming that anything is useful, only possible)
You told me that you could a schema from an archetype....
And, if you remember, we spoke about why this would be useful and
how it would be limited - they are exactly the same issues that HL7 V3
implementers face today
Grahame
