Erik, good points; see below
On 28/10/2010 16:00, Erik Sundvall wrote: > 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? not 100% sure what you want to say here: do you mean - will existing data be protected (i.e. will a new RM schema be backwardly compatible with existing data) or are you asking about how this inheritance relation would be represented in the RM XSD? > 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? this is a good question. I have always believed that data based on subsumed archetypes should be the default match for queries, i.e. if you have the path .../items[at0001]/... in your query expression, any data with at0001.1, at0001.0.3 etc should be matched. This is correct provided that the latter specialised codes do indeed correspond to something that is understood as a kind of the parent code (e.g. at0001.4|serum sodium| is a kind of at0001|lab result value|). However, there obviously needs to be a way to avoid this kind of matching. Currenly AQL handles this via wildcards (the wrong way to do it in my view). I think instead some other query switch is needed to turn off matching of data built by subsumed types. > 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? see answer above: as long as semantic subsumption holds, in my view the query should automatically match the data from subsumed archetypes. > 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? currently yes. A dedicated document is needed of course .....;) > Has it > ever been possible to find data from specialisations using calls to > methods of PATHABLE? Should it be? if you mean: could a call to these methods with a path of /x/y[at0001]/z against an information structure whose data actually contained /x/y[at0001.4]/z return the latter node? In my view it should. I don't think this behaviour is specified anywhere properly at all. > > 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). I am sure we have not got it all sorted, but so far I think this concept is also safe and interoperable. It does add a bit of complexity, but as far as I can see, it is unavoidable if we want a) any kind of specialisation / subsumption relationships between data models and b) and the ability to query such data. Q2 and 3 above are important points, and undoubtedly not sufficiently well specified in the specs. Could you record them in the SPEC-PR tracker - http://www.openehr.org/issues/browse/SPECPR - preferably as two separate issues. thanks - thomas * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101030/95d50025/attachment.html>
