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> Thomas Beale > Chief Technology Officer > +44 7792 403 613 Specification Program, openEHR > Honorary Research Fellow, UCL > Chartered IT Professional Fellow, BCS > Health IT blog <btn_liprofile_blue_80x15.png> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/cffa0c59/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140402/cffa0c59/attachment-0001.asc>
