Well, in ADL specialization allows extension >From here >(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL&AOM1.5-SpecialisationSemantics) "extensions, i.e. object constraints added to a container attribute with respect to the corresponding attribute in the parent archetype, but only as allowed by the underlying reference model."
So new nodes that change completely the meaning can be added. 2013/6/14 Daniel Karlsson <daniel.karlsson at liu.se>: > 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 > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
