Hi Gerard, > 1- Slots need to 'point at' archetypes by Name of the Archetype and NOT the file name. Plus something else ... > 2- All Nodes in any archetype never derive any meaning from the text of the label attached the Node and thereby can be language independent. Archetypes written in different languages can be used at > will. This is possible only when ... > 3- Node names derive their identity (meaning) from a code from a predefined code set. > 4- In addition we must be able to 'point at' other archetypes using unique identifiers, or a construct using generated Hash-codes for each unique archetype.
Agreed with all of these points and 1-4 are already in use (4 via Hash codes but we would prefer to move to namespaced/ properly versioned/revisioned archetypes) however these are not related to Diego's question. I am not sure that I really understand the issue. I would always expect all of the archetypes in a template to be translated into the 'local language' of the template. Whether en-gb = en is always tricky and you really need to get a clinician to eyeball the eventual dataset in the local language to make sure that there are no inadvertant confusions. Am I missing something? Ian On 2 April 2014 15:13, Gerard Freriks <gfrer at luna.nl> wrote: > imo > > 1- Slots need to 'point at' archetypes by Name of the Archetype and NOT > the file name. Plus something else ... > 2- All Nodes in any archetype never derive any meaning from the text of > the label attached the Node and thereby can be language independent. > Archetypes written in different languages can be used at will. This is > possible only when ... > 3- Node names derive their identity (meaning) from a code from a > predefined code set. > 4- In addition we must be able to 'point at' other archetypes using unique > identifiers, or a construct using generated Hash-codes for each unique > archetype. > > > Gerard Freriks > > +31 620347088 > gfrer at luna.nl > > On 2 apr. 2014, at 13:27, Diego Bosc? <yampeku at gmail.com> wrote: > > I repost this discussion from the java implementation list, I think it > could be interesting to get feedback from the general implementers > community. > > ---------- Forwarded message ---------- > From: Thomas Beale <thomas.beale at oceaninformatics.com> > Date: 2014-04-02 12:51 GMT+02:00 > Subject: Re: Invalid language codes in languages codeset > To: ref_impl_java at lists.openehr.org > > > > I have not been following closely here, but I think the general approach > should be that you perform a *design time *validation pass, that reports > things like language incompatibility, i.e. never let there be ambiguity > close to runtime. > > The question then is: how does the validation of this particular thing > work? The first thing to note is that the possible slot fillers of a given > slot in an archetype are only those that are found in the current *working > set *of archetypes, not some theoretical maximum set (e.g. all of CKM or > all Spanish MOH etc). So, within a chosen working set, validation on > language compatibilty can probably only occur at the point of operational > template (OPT) generation, i.e. where the user specifies which actual > languages and terminologies (for terminology bindings) should be used, then > a tool could run a relatively simple test to see that all archetypes in the > working set do have translations in the chosen language(s). > > One could imagine more complex validations to do with figuring out of all > slot-filling archetypes have any language in common with slot-defining > archetypes, but I don't think this is useful. > > I have no check like this in the ADL Workbench yet, so I am interested to > know what others think it should be. > > We don't really have a proper definition of 'working set' or other > possible 'sets' of archetypes, but we probably need them. Getting a common > definition means everyone agreeing on a standard workflow for archetype > development, and possible ideas like defining a 'deployment set' from a > larger 'working set', or maybe a publisher's 'release set'. > > - thomas > > > On 02/04/2014 11:33, Diego Bosc? wrote: > > Just today we had another interesting discussion on a related topic > about languages, translations, and slot solving. > The problem comes when you have an archetype whose original language > is different from the one that you are solving the slot with. There > are several alternatives, but seems that there is no 'perfect' one. > > There is always the possibility of taking the original language of the > solved slot archetype and just add it to the original archetype as a > translation, marking the strings in the other languages in some way. > > This is related to the languages codes as we could assume that a slot > with an 'en-gb' can be safely placed in a 'en' archetype and reuse all > the texts and descriptions. The problem comes the other way around > (can we assume that a 'en' slot can be safely placed in a 'en-gb' > archetype?). > > Even if you have the same language in both archetypes, we have to > consider if a translation from a slot has the same validity to be > included in the original language descriptions of an given archetype > (In theory, all translations should be made from the original > language, and if the original language was another one, can we assure > that the meaning is the same as the original?) > > Anyone of the list has been dealing with this problem? Which solutions > have you adopted for your tools/systems? > > > > -- > <ocean_full_small.jpg> <http://www.oceaninformatics.com/> > *Thomas Beale Chief Technology Officer* > +44 7792 403 613 Specification Program, *open*EHR<http://www.openehr.org/> > Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> > Health IT blog <http://wolandscat.net/category/health-informatics/> > <btn_liprofile_blue_80x15.png> <http://uk.linkedin.com/in/thomasbeale> > > > _______________________________________________ > 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 > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/8d5cea61/attachment-0001.html>
