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 <mailto:heath.frankel at oceaninformatics.biz> From: openehr-technical-boun...@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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071022/443ee1a3/attachment.html>
