Bert, I think you might be on the right track with your pathed values, it is very similar to an approach that Tom and I discussed as a more efficient XML representation of openEHR data. However, I think you are going to have to keep in mind the complexity of the openEHR Data types, values will not be able to be represented as attributes unless you have pathed items that go down to the datatype attribute level such as .../value/magnitude, or invent a whole new schema representation for each Data Type. You also need to consider RM attributes such as LOCATABLE.uid, not just archetyped data elements.
Again, I think the persistence model article on the WIKI is relevant here. I know you have your own database persistence representation but you could consider this an intermediate persistence representation. You are certainly welcome to represent the data within your application as you wish, but it would be good to work collaboratively to ensure that we don't have a huge number of alternate intermediate formats and that we learn from these experiences. One comment I will make is that when working with application developers unfamiliar with openEHR that the paths are very difficult for them to comprehend and if you are at all expecting third parties to utilise an intermediate format through some API rather than being completely encapsulated within your software that paths will be problematic to the uptake of that API. The comparison of openEHR paths with XPath is often not useful to these kind of developers either. Ocean is also developing the idea of a Template Data Schema, which will be published as a draft on openEHR in the coming months. This does provide a specific XML schema for a template (or combined collect of archetypes) where the XML element names come from the archetype element names, but there is additional meta-data in the schema and the XML document based on that schema which links each XML element back to the archetype element such as the node_ids so that generic transformation logic can be written to generate an openEHR instance for any set of archetypes. These Template Data Schemas can be automatically generated from the archetype/template models based on a set of rules. I can give you a sample of this if you would like but I suspect that you don't need this template specific approach, which is intended more for those that unfamiliar with openEHR or you want a intermediate data representation that is closer to a specific use-case for integration purposes. Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Bert Verhees > Sent: Thursday, 24 April 2008 12:42 AM > To: For openEHR technical discussions > Subject: Re: Data-entry for OpenEhr > > Tim Cook schreef: > > Hi Bert, > > > > Please note that this is MY understanding of the reference model and is > > subject to change by the expert opinion of others. > > > > On Wed, 2008-04-23 at 16:16 +0200, Bert Verhees wrote: > > > >> Archetypes are in fact RM-objects, I have a way to store RM-objects > >> efficiently. > >> > > > > Okay...good. :-) > > > > > > > >> My question: In what form should I shape the data, so that form is > >> usable with every possible valid archetype? > >> > > > > Ahhhh, I think that this is the crux of the issue. > > My answer is that you "do not". > > > > When data is captured (or changed) it is valid for THAT time and place > > in accordance with the constraints of that version of that archetype. > > That data is is not standalone, it is invalid anywhere else. > > > > In order to maintain the semantic context; that data is tied to that > > archetype, in a composition and submitted as part of a contribution. > > > I agree, that is what I do, what I try to find is a form to hand over > the data, with the archetype. So both, at the same time will be eaten > and stored by the kernel. > For example, I have a very simple archetype, only one data entry > > The definition looks like this > > definition > PERSON[at0] matches { > identities cardinality matches {0..*; unordered; unique} matches { > PARTY_IDENTITY[at1] matches { > name matches { > DV_TEXT matches { > value matches {"legal identity"} > } > } > } > > I want to hand this archetype with data, for example from a webform, or > a message interpreter to my kernel which knows what to do with it. > > At this moment, I am thinking about something like this, an XML form > which contains the archetype-ID, and there in, nodes with path and value > Because only leaf-nodes can contain data, there only leafnodes in the > XML-file > > For example for this archetype it would be: > <ArchetypedData > archetype_id="openEHR-EHR-CLUSTER.person_demographics.v1draft" > > <ArchetypedDataset path="/identities[at0]/name[at1]/value" > value="Johnsson"/> > </ArchetypedData> > > But I don't know if this is sufficient. > > Anyway, this XML file will be given to the RM-builder, together with the > ADL-file, and the rm-builder should be able to validate and create good > RM-objects from this. > > That is my idea, but I don't know if it is a good idea > > Bert > > > > > Compositions are versioned in order to maintain temporal context. A > > contribution is a change set of versioned compositions and these are key > > to describing the validity of the data. See the openEHR EHR Information > > Model reference document at > > http://www.openehr.org/svn/specification/TAGS/Release- > 1.0.1/publishing/roadmap.html > > > > > >> I hope I made myself clear, it is difficult to ask the right question > >> and get because of that, the right answer. > >> > >> > > > > I agree. Asking the right question is always the hard part of systems > > analysis. :-) > > > > > > I hope this helps. > > > > > > Cheers, > > Tim > > > > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
