Hi Gerard, see below...
On Fri, 2013-06-14 at 11:54 +0200, Gerard Freriks wrote: > > See below > Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 14 jun. 2013, at 11:09, Daniel Karlsson <daniel.karlsson at liu.se> > wrote: > > > On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote: > > > Hi, > > > > > > > > > While we are at it. > > > > > > > > > -1- > > > Why do we need a TDD? > > > Isn't a Template just a Composition archetype with Sections > > > archetypes > > > and ENTRY archetypes and Cluster archetypes and Element archetypes > > > plus data types. > > With ADL 1.5, yes I believe. > > > We, EN13606 Association, use the ADL1.4 spec in our tool: LinkEHR. > This is sufficient for our and CIMI purposes, we believe. Ok > > > > > > > > In addition as many possible degrees of freedom need to be > > > constrained > > > so as to reflect the agreement between the two exchanging actors. > > > In all aspects they rare nothing but an archetype in my part of > > > the > > > world. > > Ok > > > > > The peculiar thing about templates is that they are for prime time > > > actual use/deployment. > > What's peculiar about that? > > > 'Normal' archetypes can be produced just to produce other archetypes > at design time. > > > Templates are for specific use in a specific context and moment in > time when actors define a screen or the content of an exchange. > Of course Templates can be designed as templates to be used in local > contexts. > > > Archetypes can not be used without the Composition because a lot of > the audit info and other info needed for versioning is defined at the > Composition level. > The meta-data about the pay load is defined in the EHR-Extract. > Templates are mostly EHR-EXtracts with Compositions inside. > > > > > > > > > -2- > > > Transformations: > > > The Template (archetype) has node names changed in places (and > > > therefor their meaning). > > No, these are (should be) just two alternative serializations of the > > same meaning. However, what constitutes the meaning of an archetype > > is > > not a trivial question. > > > When specializing an archetype the name (and meaning) changes. > When originally the Name node is ENTRY it can be changed in > specialization to ENTRY:Observation > Or into ENTRY:Observation:ClinicalFinding > Or into ENTRY:Observation:ClinicalFinding:BodyTemperature That's fine, but serializing is not specializing. Templates also allow specializing (that is in a way what templates do) as does archetypes so there's an overlap. But that's a separate (and important) issue. I was asking about the possibility of having more compact serialization formats. > > The names are different and therefore their meanings. > Although all names are related to each other. > > > > > > > > They are more complex in places (because new branches) have been > > > added, less complex in places (because branches are not used), > > > more > > > constrained in places than the pure parent archetype. > > Here I must confess I don't understand your use of the word > > "complex". > > E.g. if there in an openEHR model is two specific named events in an > > observation which are expanded in the TDD (isn't it??) does this > > increase or decrease complexity? > > > > > In a parent one node can allow zero to many siblings > In a specialisation we can constrain it to any within the limits as > specified by the parent. > When allowed we can remove branches with zero-to-zero constraints and > not use them at all. > We can insert (when allowed) in places additional nodes (new banches) > that were not in the parent. Can you provide an example because I thought the latter was not allowed (depending on what a branch is). > > > > > > > > > > > > To write generic transformations is not trivial, I expect. > > > If possible at all. > > I do not agree. I believe this is what every implementer necessarily > > has > > to do, to provide a two-way transformation between a canonical form > > and > > any serialization and/or persistence form with a different set of > > requirements (query performance, OLTP vs. OLAP, space requirements, > > legacy systems integration, etc. etc. etc.). Not trivial but done on > > a > > regular basis. > > > > > Using the 13606 AOM based tools it must be possible to track the whole > provenance of any archetype/template. > (There is a problem known for Archetype Slots and keeping track of the > original choices that were expressed.) > Although the template might be a sub-set in places and a super set in > other places, as I said I don't think this is the case, but if there are issues these should be discussed and straightened out. Do you have specific examples or template functions where templates loosen constraints? > all must conform to the Reference Model and all parent archetypes > that were used in the chain of specializations. > > > Without the complete set of artifacts the transformation will be NOT > possible, that's fair, but trivially true. Templates (or any compositional-framework models) cannot be interpreted without having access all it's constituent sub-models. > Tracking all these changes that were made to the parent archetype > > > > > > > Cheers, > > Daniel > > > > > Gerard Freriks > > > +31 620347088 > > > gfrer at luna.nl > > > > > > On 14 jun. 2013, at 09:41, Daniel Karlsson > > > <Daniel.Karlsson at liu.se> > > > wrote: > > > > > > > Hi Ian, > > > > > > > > On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote: > > > > > Hi Erik, > > > > > > > > > > > > > > > The Ocean TDD->canonical transform is available at > > > > > > > > > > > > > > > http://openehr.codeplex.com/SourceControl/latest#176376 > > > > > > > > > > > > > > > > > > > > look for TDD_to_openEHR.xsl > > > > > > > > > > > > > > > As far as I know a generic reverse transform is not possible. > > > > > > > > How could that be? Is there something in the TDD format that is > > > > not > > > > in > > > > the RM format? The intuition tells me that it should be easier > > > > going > > > > from the rich RM format to the TDD format than in the opposite > > > > direction. What are the specific issues that make a reverse > > > > transformation problematic? Could anything be changed to make > > > > the > > > > transformation possible? > > > > > > > > > _______________________________________________ > > > openEHR-technical mailing list > > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
