Hi Ian, 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 best regards Bert Op dinsdag 18 februari 2014 heeft Ian McNicoll <ian.mcnicoll at gmail.com> het volgende geschreven: > 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<javascript:;>> > 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 <javascript:;> > > > 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 <javascript:;> > ian at mcmi.co.uk <javascript:;> > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org <javascript:;> > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- *This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/0bb9982e/attachment.html>
