Hi! Thanks again for quick and informative replies.
Obviously was not paying enough attention when the discussion of the identifier change was taking place some time ago. I had started composing a long reply of how query implementation would get more complex unless the RM was changed at the same time. Then I saw Ian's reply regarding suggested RM changes, and trashed my reply. Nice :-) Three perhaps stupid followup questions: 1. Will the XML schema get updated to make sure patient data instances carry along the archetype/template inheritance in a good way? 2. Should AQL be modified to include a convenient way of specifying if we are asking for data only entered using a specific archetype or if we are looking for data entered using that archetype any of its specialisations? (Previously wildcards might have worked depending on interpretation/implementation of AQL documentation, now with the 1.5 change they definitely won't.) What should be the default behaviour if just writing an archetype name in part of the query? Quoting from the 01 Feb 2010 version of "Knowledge Artefact Identification" Section 5.3.3: ..."given an archetype X used to create data, the following archetypes could be used for querying: ? X, i.e. exact same version, revision & commit; ? any previous revision of X; ? any of the specialisation parents of X; ? any previous revision of any of the specialisation parents of X." Does the "could be used" wording here mean that the default behaviour of an AQL response should be to retrieve data matching all these cases? 3. Will the semantics and syntax of the path strings used in PATHABLE objects be affected? Where is that path syntax actually defined, is chapter 11 of the Archetype Overview the authoritative source? Has it ever been possible to find data from specialisations using calls to methods of PATHABLE? Should it be? Carrying specialisation lineage (including version numbers) in the RM/data itself sounds like a safe and good idea. That would be useful for simplifying e.g. distributed query implementation and for when you, in multi-purpose GUIs, want to climb up the generalisation ladder (e.g. when creating archetype based overviews/summaries). Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Thu, Oct 28, 2010 at 11:29, Ian McNicoll <Ian.McNicoll at oceaninformatics.com> wrote: > The draft spec for 1.5 knowledge identifiers can be accessed via > http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts ... > To get around the querying problem that Erik describes, it is proposed > to carry the specialisation inheritance list in the data. ... > >From Idenitifer document 5.3.3 > > The other possibility is to include archetype lineage information in > the data itself. This could be a > modified form of the identifier reference in the case of specialised > archetypes to allow lineage information > to be stored. > > TBD_14: proposed RM change: ARCHETYPED.archteype_id -> List[ARCHETYPE_ID]; in > LOCATABLE, just continue to use the direct archetype id as currently done. > > The simplest form of this would be as a list of operational identifiers, e.g. > > se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, > org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, > org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4
