For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM.
Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed.
Hi Bert,
I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes.
We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible.
Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do.
Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year.
That a stronger/better/different archetype-id system is needed is true in my opinion - but a different story: for starters the archetype-id system predates CKM (or even any vision of it) by many years as far as I am aware.
It is true that the CKM archetypes are of high quality (as far as I can judge), and that their existence is a good thing.
But, archetypes can be much more then only having a specific high quality contents.
They can, for example be structured, as I am thinking of, for example in a framework which causes some leaf-nodes to have predictable paths. This can have good effects on system-performance, data-mining, easy development, and other aspects.
It is only a thought, not everyone will agree this is necessary, but that does not mean that it is useless to think in such a way.
I think it is time to make that step forwards in two level modeling thinking.
Hi Bert, I am not arguing with that, I am just pointing out that you are relating two things (CKM and the archetype ids) that are not related in the way you said. If anything, the existence of several CKMs around the world now - which can all talk to each other to get each other’s archetypes - the need for a different archetype id system. As for the one-archetype-per-concept-principle in that discussion you link to: It is what I said in other words above, the lofty aim to agree where possible. It is not one step, but rather a very long process with potentially many archetypes about the same concept in e.g. different regions/countries in the meantime (and likely more than one forever). Sebastian
I don't think you need to convince anyone that the archetype_id
mechanism 'would do'. The question of namespacing/ oids etc started
to be discussed long before 2012, although it is blindingly easy to
get around most namespace collisions with some 'pseudo-namespace'
suffixes e.g. EVALUATION.adverse_reaction_uk.v1. From memory the
discussion was about the best solution, not about the need to make
some sort of change.
If there ever was a vision that a single set of archetypes might rule
the world, that has long since disappeared. I think there will be
gradual convergence as the economics increasingly dictate that
interoperating is better than local but it will take time and a fair
bit of confusion/ competition of ideas and frameworks. I think you and
i have a similar vision of progress through an open source-like market
of ideas.
However, you cannot easily square that with your desire for leaf nodes
to have predictable paths. The only way for that to be absolutely
achieved is to describe those leaf-nodes on the RM e.g ACTION.time or
OBSERVATION.origin. The second-best alternative is to construct a
hierarchy of top-level 'reference archetypes' (the approach taken by
CIMI) but if these are to work consistently, everyone has to use them
and their paths have to be fixed and consistent, just as if they had
been defined in the reference model. There may be other advantages to
using reference archetypes in this way but I can't see that you gain
anything over an RM expression of predictable paths.
I think there are many aspects of the openEHR class structure that can
be simplified and improved but I can't see how you can provide the mix
of flexibility and 'fixed leaf node paths' other than declaring them
in the RM or in 'reference archetypes' which have to be managed just
as strictly as an RM. Either you have a commitment to a framework
(however expressed) or you do not.
Perhaps I am not understanding .. Can you give a specific example of
how you might model differently?
I think the original 'one-archetype-per-concept' statement was really
applicable within a single repository or 'framework'. Much as we might
want there only ever to be one for the world, this was clearly only
ever going to be possible in the very long term, and quite impossible
for some concepts.
Maybe this discussion has been on this list before December 2012, I must have missed it. I was concluding from the opposition I got, that many disagreed with me that the archetypeId specs were not good enough. It is true that I needed to defend this idea for over ten messages, during a full week. Check the discussion. The link is below.
But it is not very important who brought it up, I thought it was me, but maybe I was wrong.
It is the results that count.
My point is that other ways of modeling then the way fixed in the RM are possible. The predictable leafnode path is something which comes to my mind. That is even possible inside the constrained RM we have today.
As I said before, two level modeling means that the RM should not enforce too much structure.
It is also not necessary to do so, because it can all be done in archetypes. The structure enforced from the RM is a way of constraining liberty, constraining innovation. If the RM structure is good, people will choose for it in liberty.
There is nothing to gain in this higher authority constraints.
But since the OpenEhr community already arranged the generic concrete ENTRY class, there is no need to find examples. We can see and wait what people will think of it and do with it. And maybe over a year from introduction, we can evaluate it
I must have missed the discussion before, and I checked a bit the discussion of December 2012. It was not like I had it in my mind, it was more about the way to avoid archetypeId-clashes then about the archetypeId-clashes itself, as I yesterday suggested.
However, in the wiki you link to is first time a ID-system described after the discussion in 2012, but the messages from 2011 and 2009 indicate that the problem was identified before the discussion in 2012, and I was wrong in thinking that I brought the problem under attention.
I just brought a possible solution under attention.
It is fore most a matter of principle.
The question to answer is where are the boundary lines between the different layers of the Semantic Stack.
Feel free to blur this anyway you like.
I’m a firm believer that we must prevent problems in the future.
The RM must be stable and must NOT contain any semantic notions.
It must deal with lego-ethical things of storing, retrieving, exchange, etc.
All the health specific semantics have to be dealt with in the archetype layer.
And the set of standardised super-archetypes we use to specialise all other from.
The whole business of taking care of the full semantics is to fluid at this point in time to be frozen in the RM.
I had fun reviewing the 2012 conversation. My take on it is is that
there was complete agreement from all contributors that many different
flavours of archetype will with us for a long time, and as such the
current archetypeId mechanism is inadequate. The only
disagreement/debate was about how best to rectify that problem. The
preferred solution was namespacing use reverse-urls but you and others
argued for more definitive unique identification via OID/UIDs.
For now we have decided to go with the reverse-url namespace as the
primary approach but allowing other identifiers such as UID/OIDs to
co-exist if that is preferred by specific regions or developers.
We have started work on adding namespacing (and actually more
critically full version/revision numbers) to CKM and the other openEHR
tools, so we can start to get some real experience with this before
too long.
I am not anymore so sure if it need to be UIDs. I think now, one year later, that organisations need to keep their namespaces tidy, if they do not, chaos is likely to happen on their data.
