-----Original Message----- From: Thomas Beale [mailto:[email protected]] Sent: Thursday, July 08, 2004 21:16 To: Liberman Dar?o Subject: Re: proposed ADL and archetype modification
Liberman Dar?o wrote: >Hello Thomas, > >I believe you are in the right way. I like the Xpath like expression, >it is powerful. However, it seems to me that the biding should be held >between concepts, not terms. The term can just been added "inline" or >just a default term can be chosen, etc. The synonyms can differ between >communities in the same language for people living in the same city. > >Best regards, >Dario. > > Hi Dario, maybe you could send this reply to the list as well? - thomas > >-----Original Message----- >From: Thomas Beale [mailto:thomas at deepthought.com.au] >Sent: Thursday, July 08, 2004 18:20 >To: Openehr-Technical >Subject: proposed ADL and archetype modification > > > >Dear all, > >after quite a few months of experimentation and reflection, Sam Heard >and I have come to the conclusion that a modification is needed in the >semantics of the ontology section of ADL archetypes, to do with term >bindings. > >The current situation is shown in the example archetype: >--------------------------------------------------------------- >archetype > adl-test-OBSERVATION.apgar.draft >concept > [at0000] -- apgar observation > >definition > OBSERVATION[at0000] matches { > -- apgar observation > data matches { > HISTORY[at0001] occurrences matches {1} matches { > -- history > events cardinality matches {1..*} matches { > EVENT[at0002] occurrences matches {0..1} matches { > -- 1 min event > data matches { > LIST[at0003] matches { > -- list > items cardinality matches {1..*; >unordered} matches { > ELEMENT[at0004] occurrences matches >{0..1} matches { -- cardiac score ************** > ... > } > } > } > } > } > } > } > } > } > } > } > >ontology > primary_language = <"en"> > languages_available = <"en", ...> > terminologies_available = <"openehr", ...> > > term_definitions("en") = < > items("at0004") = <text = <"cardiac score">; >description = <"cardiac score in Apgar observation of neonate">> > > >------------------------------------------------------- > >Now the question here is what does the 'term_binding' section of the >archetype look like? Currently, we simply list bindings from internal >"at" codes to external terms, such as snomed terms, as follows: > > term_binding("snomed") = < > items("at0004") = <[snomed::123456789]> -- snomed term >for Apgar cardiac score > > > >But what we should in fact be doing is binding external terms to >_paths_, e.g. the path: >[at0000]/data[at0001]/events[at0002]/data[at0003]/items[at0004], which >refers to 'cardiac score' in the context of an Apgar observation, and >not something else. There are undoubtedly other 'cardiac scores' >elsewhere in cardiology, and we don't want to mix them up. So the new >proposal would allow us to bind to paths, not just to terms regardless >of where they appear in an archetype. However, the latter _is_ something >we still want to do quite often - e.g. bind a snomed term to the "at" >code for "systolic blood pressure" regardless of where it appears in the >archetype. We can represent this as a path expression using the Xpath >approach, e..g "//[@meaning=at0004]" matches any node with the "meaning" >attribute set to "at0004". (We have not yet determined a complete >proposal for improving archetype paths to be completely Xpath - >compatible, but this work is also underway) > >The result would be something like the following term_binding section >in >an archetype: > > term_binding("snomed") = < > >items("[at0000]/data[at0001]/events[at0002]/data[at0003]/items[at0004]") >= <[snomed::123456789]> -- snomed term for Apgar cardiac score > items("//[xxxx]") = <[snomed::12313412414]> -- a context >- independent mapping > > > >Where each string in the items() expression is an Xpath compatible >expression, rather than just a single internal "at" code. > >Making this change will make the binding capabilities of archetypes >more >general, while retaining the current capabilities, but does require >changes to a number of things, including the ADL specification, the path >syntax, the existing software, and all the existing ADL examples. > > >reactions? > >- thomas beale > > > -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Hon. Research Fellow, University College London openEHR (http://www.openEHR.org) Archetypes (http://www.oceaninformatics.biz/adl.html) Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
