While reviewing CKM archetypes we found that slots are usually
pointing to other v1 archetypes.
Shouldn't archetype slots point to any version of the included
archetypes and not a single archetype? Shouldn't be Templates the ones
pointing to an specific archetype?
This is also true even for "archetype and all its children" slots
(e.g. openEHR-EHR-OBSERVATION\.respiration(-[a-zA-Z0-9_]+)*\.v1) in
which the v1 seems to be even more misplaced as it points to a set of
archetype v1 by default.
Probably v1 should be changed to v[0-9]+ (or even v[0-9\.]+)
your general argument is potentially right, at least in some circumstances. But don't forget, a v2 archetype is a breaking change with respect to v1. With full versioning, it's like with software - v2.0.4 compared to say v1.1.0. Where there is a breaking change, it's a new archetype. For that reason, the first digit of the version is part of the identifier of the archetype.
Under the more advanced ADL 1.5 rules, this is still the case, but has been described more accurately in these two documents (in particular, the old archetype id the ends in '.v1' etc is now called an 'interface id'):
In the second one you will see a section called 'artefact referencing' which is exactly on the topic you mention here. So when you see 'xxxx\.v1' in a slot regex, it's probably correct; the author might want to do this: 'xxxx\.v[12]' if they know that v1 and v2 will actually work in that slot, but in general that won't be the case.
I can agree you with the 'absolute' references, but I still think that
slots to specialized archetypes are not well defined as they are
currently defined:
If you want to say that all children from a .v3 archetype are allowed
you cannot say openEHR-EHR-OBSERVATION\.respiration(-[a-zA-Z0-9_]+)*\.v3
because specialized archetypes start with v1 even if the father was a
v3 or v20.
and if you say openEHR-EHR-OBSERVATION\.respiration(-[a-zA-Z0-9_]+)*\.v1
to somehow be correct with all the specialized children then you can't
assure who is the parent archetype.
I think in this case the version shouldn't be fixed as you are no
longer pointing to a single archetype ('absolute' reference) but to a
set of archetypes (that can be potentially infinite).
You are right that it's not easy to do with regex lexical referencing. That's why there is a proposal to use semantic referencing <http://www.openehr.org/wiki/display/ADL/Semantic+slot+proposal>, which would define slot fillers of an archetype in the following way:
<< openEHR-EHR-OBSERVATION.respiration.v1
which would mean 'any child of openEHR-EHR-OBSERVATION.respiration.v1, or any minor version of openEHR-EHR-OBSERVATION.respiration.v1, or openEHR-EHR-OBSERVATION.respiration.v1 itself'. So then it doesn't matter what versions the child archetypes are - if they refer to openEHR-EHR-OBSERVATION.respiration.v1 or any variant minor version as their specialisation parent, they are included.
In this approach, the string 'openEHR-EHR-OBSERVATION.respiration.v1' is understood as a 'reference' not an 'identifier', where a reference may evaluate to more than one target. So if you write:
<< openEHR-EHR-OBSERVATION.respiration.v1.4.0
then it would mean: just children of v1.4.0, and not children whose parent could be a different minor version.
We would also have operators:
= openEHR-EHR-OBSERVATION.respiration.v1
meaning: just the archetypes that openEHR-EHR-OBSERVATION.respiration.v1 refers to, and
< openEHR-EHR-OBSERVATION.respiration.v1
meaning only the children, but not the direct referents of 'openEHR-EHR-OBSERVATION.respiration.v1'.
I thought we would convert to this system some years ago, but people seem to be happy with the current system for now. It won't work forever though....
I thought we would convert to this system some years ago, but people seem to
be happy with the current system for now. It won't work forever though....
We agree on this. We just must be aware of the potential problems of
using current archetypes.
I understand your point but I am not sure that slot naming is really working out as any of us envisaged. In the vast majority of cases where we specify an archetype pattern in the slot description we also leave the constraint open-ended because experience has shown us that too tightly coupling the parent and child leads to over-complication of dependencies and insufficient flexibility to cope with new use cases. In this respect the slot filling constraint acts as useful ‘design guidance’ i.e this is the sort of archetype we expect to be slotted in here but others (including V2 versions are allowed).
I agree with you in those instances where we do tightly constrain a slot to be filled with only a certain pattern but in those cases we would also probably want to make a judgement about the fitness of subsequent versions on a case-by-case basis i.e I would probably not want the version allowed to be open-ended since I need to make sure that the breaking change introduced in V1-V2 does not also mess up whatever imposed the need for a tight constraint in the first place.
So, in theory, you are correct but in practice, I suspect the current approach is working quite well, though I am sure there will be examples of errors and inconsistencies.
The semantic referencing will work quite well for slot filling and was part of the reason for adhering closely to semver.org numbering but I am not so sure it works at individual archetype level for slot constraint definitions.
it might be worth noting that slots and external references (i.e. direct references to archetypes, without the slot) have identifiers, like all nodes, in ADL/AOM 1.5, and also that external references are used ubiquitously in CIMI, which are all named (if you mean that they have ‘meanings’, i.e. id-code references). We also have to remember that 13606 and other archetype formalism users might have quite different styles of use, as CIMI does. - thomas