Thanks all for the excellent explanations on the differences between archetypes and templates both from functional and technical point of view. I agree with Sebastian, these rather educational comments should be included in our FAQ page.
On the technical side, I will be glad to review the early draft of TEMPLATE_SPEC specification. It can even be implemented by the Java community to provide feedbacks for further refinement. Cheers, Rong On 10/22/07, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > > I haven't followed this whole thread, in particular I haven't seen Rong's > emails about templates and aggregation archetypes but I thought I would > provide a little input about the future of the template specifications. > > > > If you have a look at the Template Object Model as published as a draft in > R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC > package. This provides a mechanism to specify a template using references > to archetypes and aggregating them together. In addition it provides a > series of constraint rules of various kinds to do things like constrain > cardinalities or specify default values. We have been recently comparing > this with the current proprietary template definition used within the Ocean > Template Designer and have found that there are very few required template > semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft. > > > > The second model is the operational template model. We have actually > implemented this and have needed to augment and change this model slightly, > but the principles expressed in the R1.0.1 draft (a Template object with > definition specified by a C_COMPLEX_OBJECT and list of path and default > value pairs) has work fine. This implementation experience will be feed > back into the openEHR community for the next release. > > > > So in summary, Rong's premise that we can express templates using the AOM > is true, but what he calls an "aggregation archetype" is an operational > template. The TEMPLATE_SPEC is just another representation of the same > template where it references the existing archetype artefacts and constrains > them using rules. The TEMPLATE_SPEC is used to store and maintain the > template definition within an authoring environment while the operational > template is derived from the TEMPLATE_SPEC and is used within software at > run-time. > > > > We are just completing the testing of a new export function in the Ocean > Template Designer that generates an operational template from its > proprietary template definition. This operational template will be used for > all sort of purposes including the generation and validation of RM objects > that conform to the template. > > > > Hope this helps keep you up to date with progress in this area. If you > have interest in this area from the technical perspective I suggest that we > progress this further in a collaborative manner. > > > > > > Regards > > > > Heath > > > > Heath Frankel > Product Development Manager > > Ocean Informatics > > Ground Floor, 64 Hindmarsh Square > > Adelaide, SA, 5000 > > Australia > > > > ph: +61 (0)8 8223 3075 > > mb: +61 (0)412 030 741 > email: heath.frankel at oceaninformatics.com<heath.frankel at > oceaninformatics.biz> > > > > *From:* openehr-technical-bounces at openehr.org [mailto: > openehr-technical-bounces at openehr.org] *On Behalf Of *Lisa Thurston > *Sent:* Monday, 22 October 2007 1:32 PM > *To:* For openEHR technical discussions > *Subject:* Re: Multiple parents and max number of nested specialized > archetypes? > > > > Hi all > > I think that in the absence of a template specification it is indeed > difficult to see, from a technical viewpoint, the difference between > templates and "aggregation archetypes" (which is what I think Rong means by > "all the constraints done in templates can be done with archetypes"). > Heather and Hugh point out that such archetypes would not be universal in > their applicability and therefore less shareable. This still leaves a blurry > line between where the archetype ends and the template begins. There are > some features of templates that do make this line clear, however. > > The best example I can think of is default values (not to be confused with > assumed values). At some point you'll want to be able to say things like > "the default temperature scale is Centigrade" or "the default number of > foeti is 1". If the default value is free text or even a coded term, this > implies that the template is targeted to a specific language/culture, thus > NOT universal. Therefore the template specification, when it arrives, is > likely to include ways to define default values and the target > language/culture of the template. A template is language/culture-specific. > There is provision made for default values in the AOM's archetype constraint > model but the TYPE of a default is left open. Since the TYPE of these values > cannot be constrained by the AOM, default values can never be meaningfully > applied in ADL. Rather they can only be applied in the template (which knows > about the reference model and target language/culture of the data). This > connects to Rong's point about expressing template constraints in AOM > semantics. I fully agree the template specification should make use all > useful parts of the archetype constraint model or "build on top of" the AOM. > > If a template was ever suddenly considered to encapsulate a structure > which was universally (or near-universally) applicable, as Hugh suggests, > the default values would have to be discarded (as well as other > culture-specific structures or assumptions). And for the archetype to be > practical in a more universal sense, any items added to the ontology in the > template (in the template's target language) would probably need to be > translated into the other languages. Therein lies the distinction. > > Regards > Lisa > > -- > > Lisa Thurston > > Phone +61.8.8223.3075 > > Skype lisathurston > > > > Ocean Informatics Pty Ltd > > Ground floor, 64 Hindmarsh Square > > Adelaide SA 5000 > > > > http://www.oceaninformatics.com > > > Hugh Leslie wrote: > > Hi All > > I think that there is a clear need for a distinction between archetypes > (specialized or not) and templates and this relates mainly as Rong has said > as to their intended use. Archetypes are for interoperability and so they > need to be designed to be able to handle any usage of the particular concept > that they are modelling. This means that valid ranges in archetypes should > be set so that valid values will never fall outside the range. ie the bp > archetype sets the max systolic value to 1000. Archetypes should be kept as > generic as possible for the particular concept and are maximal data sets and > so should contain every concept that is required for any use of that > concept. > > Templates are specific use cases of a particular archetype or groups of > archetypes and can be constrained down for a particular usage ie for the bp > archetype, you may constrain it to just contain the systolic and diastolic > in an 'any event' and remove any other non mandatory elements. Templates > are useful for turning a generic archetype into something more specific > i.e. the laboratory archetype can be constrained in a template (or at > runtime) to be a specific type of laboratory result. This means that > instead of 5000 specific laboratory archetypes, we only need one generic and > probably 20 or 30 agreed specializations. Templates can also be used for > creating very complex documents such as an antenatal visit which is made up > of many different archetypes. Templates can be made up of nested archetypes > as well as nested templates all of which can be further constrained within > the limits of the archetypes used - this allows for the development of > concepts and documents with any arbitrary level of complexity that still > conform to archetypes. > > The question has been raised as to the difference between a specialization > of an archetype and a template and when to use each. There is no absolute > answer to this, but there is a need to examine the need for specializations > of archetypes to see whether the archetype is general enough to be used * > everywhere*. If it meets this test, then it is reasonable to create it > and submit it as an archetype, otherwise a template should be used > constraining some more general archetype. I think that over time it will > become clear that there are some templates that should become archetypes. > > regards Hugh > > > > Rong Chen wrote: > > > > On 10/19/07, *Andrew Patterson* <andrewpatto at gmail.com> wrote: > > > Templates are the main means of constraint on archetypes - > Specialisations are mainly > > about adding attributes. > > Sam, surely those attributes are available by virtue of the fact that the > parent > archetype says nothing about them. Something in an archetype can never > 'add' > an attribute. All archetypes can do is constrain. And the specialised > archetype > can never remove a constraint of the parent surely? > > For example, an observation archetype that says nothing about the > 'State' attribute > imposes no constraints on that attribute. A specialisation of the > archetype could > impose extra constraints on 'State', but can't add the attribute in. I > mean, there is > either a 'state' attribute there in the RM or not - the archetype > can't add attributes. > > Of course this all leads to a much more interesting theoretical question - > aside > from the immediate syntactic differences, what exactly is the difference > between > a template and a specialisation? > > > Andrew, this is indeed a very interesting question. It seems to me that > all the constraints done in templates can be done with archetypes. The > 'artificial' divide between templates and archetypes are probably to do with > their different intended uses. Archetypes are semantically coherent and are > supposed to be shared between systems. Templates are, on the other hand, > created to meet local specific requirements, therefore not supposed to be > shared across sites. But the line of distinct seems to be blurred. How local > is a local requirement and thus justify the use of a template? Can one start > with a template for local use, and later convert the template into an > archetype for shared use? > > Also if all constraints can be expressed using the AOM semantics (which is > already very generic and powerful), we perhaps could re-use the same object > model to represent template constraints, which would facilitate the > conversion between archetypes and templates. > > Cheers, > Rong > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071022/25829cad/attachment.html>
