Hi Bert, 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? Ian On 18 February 2014 15:48, Bert Verhees <bert.verhees at rosa.nl> wrote: > On 02/18/2014 03:52 PM, Sebastian Garde wrote: >> >> >> On 18.02.2014 14:56, Bert Verhees wrote: >>> >>> 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. > > You also participated in this discussion. I started that discussion about > here: > http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html > > 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. > > regards > Bert > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
