Multiple translators
Anyone have further thoughts on this - if changes are to go into ADL2 for this, we need them sooner rather than later. thanks - thomas On 17/03/2015 20:33, Thomas Beale wrote: this is doable as well, except not quite like that - multiples of the same thing have to have unique keys, so it would be more like the following. I also added in the 'version_last_translated' which was agreed in principle recently. translations = [fr] = language = [ISO_639-1::fr] authors = [frederiktyler] = [name] = Frederik Tyler [email] = freddy at medicaltranslation.co.uk mailto:freddy at medicaltranslation.co.uk [] = y *[accreditation] = British Medical Translator id 00400595 * [bonnietyler] = [name] = Bonnie Tyler [email] = *_bonnie at medicaltranslation.co.uk_* mailto:freddy at medicaltranslation.co.uk [] = *[accreditation] = Whatevs* [yannickguillou] = [name] = *Yannick Guillou* [email] = *_yg at francaistrad.fr_* mailto:freddy at medicaltranslation.co.uk [] = aabb *other_contributors = ?Jules Verne jules at nautilus.fr mailto:jules at nautilus.fr?, ?Victor Hugo vic at hunchback.net mailto:vic at hunchback.net?* version_last_translated = 2.0.1 However.. it's not clear who did the most recently translation, and who only did some old translation. How do we deal with representing what's a current picture of affairs? It might not matter - it's ok if we assume that the translation work is recorded in some registry for example. Finding the balance is the challenge. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150320/10c86510/attachment.html
Multiple translators
Hi Thomas, Yes I have some thoughts and concerns on this (but I am not too clear on the conclusions yet). I think we have to be careful not going over the top here as far as metadata in the archetype is concerned: Yes, we could have multiple primary translators (maybe with a modifier so that one is the original author?). We could then also specify a person or an organisation currently responsible for maintaining this translation. Also while we can have a version_last_translated, it may not be enough, we may need at least to specify the last full translation and the last update to this translation, which may be incomplete. To be useful, we may then need to introduce states for the translation and put this in the archetype as well - has this translation been published or at least reviewed in some way? Maybe a translation_last_published revision number that indicates the latest publication of the translation would be more helpful here? But, personally, I would stay away from most of this for the following reasons: * It will never be quite enough to satisfy all requirements or be sufficiently precise in its meaning * It is hard to keep it up to date * It increases the 'clutter' in the archetype * It needs to be dealt with by all kind of tools, incl. CKM and editors, and especially these other_details lists with unknown keys, or multiple elements with unknown occurrence simply make it yet another bit harder/time-consuming/error-prone to deal with. * On the other hand, some of the information could be derived more precisely by a tool like ckm on demand. For example, some advanced functionality could list items that have changed since the translation was last touched and allow easy updating of the changed elements. * These are yet more changes from 1.4 that requires dealing with when upgrading * If we have multiple translation authors, we then need support for multiple original authors as well? In the end, as you say, it is all about the balance, and I am not sure what the best balance is either, but I would suggest the following: * Remove the explicit accreditation field and move it in the author field as one of the key/value pairs as in your suggestion. * Add the other_contributors as a key/value set, by all means * Leave the author (translator) as is (non-repeating) (Or if it really needs to be repeating, make the same change for the original author of the archetype as well.) * Consider having translation_last_published instead of version_last_translated (or revision_last_translated) or none of it. * Consider removing the TRANSLATION_DETAILS/other_details (is this really needed: I haven't seen much use for it so far, and besides we have the translation author that can have any key/value pairs AND the RESOURCE_DESCRIPTION_ITEM other_details). For ADL 1.4 the main problem I then see is that we need to deal with 0..* other_contributors: Not sure there is an ideal solution, but we could e.g. simulate this with a string in the TRANSLATION_DETAILS/other_details with key other_contributors where the value would contain all contributors, separated by linebreaks. Alternatively it could be part of the translation author directly. Cheers Sebastian On 20.03.2015 12:25, Thomas Beale wrote: Anyone have further thoughts on this - if changes are to go into ADL2 for this, we need them sooner rather than later. thanks - thomas On 17/03/2015 20:33, Thomas Beale wrote: this is doable as well, except not quite like that - multiples of the same thing have to have unique keys, so it would be more like the following. I also added in the 'version_last_translated' which was agreed in principle recently. translations = [fr] = language = [ISO_639-1::fr] authors = [frederiktyler] = [name] = Frederik Tyler [email] = freddy at medicaltranslation.co.uk mailto:freddy at medicaltranslation.co.uk [] = y *[accreditation] = British Medical Translator id 00400595 * [bonnietyler] = [name] = Bonnie Tyler [email] = *_bonnie at medicaltranslation.co.uk_* mailto:freddy at medicaltranslation.co.uk [] = *[accreditation] = Whatevs* [yannickguillou] = [name] = *Yannick Guillou* [email] = *_yg at francaistrad.fr_* mailto:freddy at medicaltranslation.co.uk [] = aabb *other_contributors = ?Jules Verne jules at nautilus.fr mailto:jules at nautilus.fr?, ?Victor Hugo vic at hunchback.net mailto:vic at hunchback.net?* version_last_translated = 2.0.1 However.. it's not clear who
Multiple translators
Hi, I'm going to do a provocative proposal, that just came to my mind. Why being a translator is different from being archetype author? When somebody does a translation he/she is in fact authoring the textual part of the archetype. Thus, why do we have to manage it separately from the authors section? Moreover, how do we deal with other types of contributions that could be of interest? For example the reviewers of the archetype, not just listing them as Other contributors. Could we simplify all this stuff and just support a participation kind of approach for archetypes metadata? The idea would be to have one single section called Participants, with with the name, organisation, mail, etc., and a coded field Type of participation using a controlled vocabulary including for example Main author, Contributor author, Main translator, Contributor translator, Reviewer, Consulted domain expert, etc. In fact, this should be a multi valued field, since nothing avoids that the same person is the main author and a translator to a different language. In case that new participation roles appear in the future, we only have to complete the controlled vocabulary, without changing other things. Probably we would still need to support some specific details depending on the type of participation (for example the accreditation info), but this approach could simplify part of the metadata management. I know that are some details to be fixed, but what do you think about the general idea? David 2015-03-20 13:22 GMT+01:00 Sebastian Garde sebastian.garde at oceaninformatics.com: Hi Thomas, Yes I have some thoughts and concerns on this (but I am not too clear on the conclusions yet). I think we have to be careful not going over the top here as far as metadata in the archetype is concerned: Yes, we could have multiple primary translators (maybe with a modifier so that one is the original author?). We could then also specify a person or an organisation currently responsible for maintaining this translation. Also while we can have a version_last_translated, it may not be enough, we may need at least to specify the last full translation and the last update to this translation, which may be incomplete. To be useful, we may then need to introduce states for the translation and put this in the archetype as well - has this translation been published or at least reviewed in some way? Maybe a translation_last_published revision number that indicates the latest publication of the translation would be more helpful here? But, personally, I would stay away from most of this for the following reasons: - It will never be quite enough to satisfy all requirements or be sufficiently precise in its meaning - It is hard to keep it up to date - It increases the 'clutter' in the archetype - It needs to be dealt with by all kind of tools, incl. CKM and editors, and especially these other_details lists with unknown keys, or multiple elements with unknown occurrence simply make it yet another bit harder/time-consuming/error-prone to deal with. - On the other hand, some of the information could be derived more precisely by a tool like ckm on demand. For example, some advanced functionality could list items that have changed since the translation was last touched and allow easy updating of the changed elements. - These are yet more changes from 1.4 that requires dealing with when upgrading - If we have multiple translation authors, we then need support for multiple original authors as well? In the end, as you say, it is all about the balance, and I am not sure what the best balance is either, but I would suggest the following: - Remove the explicit accreditation field and move it in the author field as one of the key/value pairs as in your suggestion. - Add the other_contributors as a key/value set, by all means - Leave the author (translator) as is (non-repeating) (Or if it really needs to be repeating, make the same change for the original author of the archetype as well.) - Consider having translation_last_published instead of version_last_translated (or revision_last_translated) or none of it. - Consider removing the TRANSLATION_DETAILS/other_details (is this really needed: I haven't seen much use for it so far, and besides we have the translation author that can have any key/value pairs AND the RESOURCE_DESCRIPTION_ITEM other_details). For ADL 1.4 the main problem I then see is that we need to deal with 0..* other_contributors: Not sure there is an ideal solution, but we could e.g. simulate this with a string in the TRANSLATION_DETAILS/other_details with key other_contributors where the value would contain all contributors, separated by linebreaks. Alternatively it could be part of the translation author directly. Cheers Sebastian On 20.03.2015 12:25, Thomas Beale wrote: Anyone have
Multiple translators
that actually sounds like the basis of the model of what a proper registry might record - thomas On 20/03/2015 13:46, David Moner wrote: Hi, I'm going to do a provocative proposal, that just came to my mind. Why being a translator is different from being archetype author? When somebody does a translation he/she is in fact authoring the textual part of the archetype. Thus, why do we have to manage it separately from the authors section? Moreover, how do we deal with other types of contributions that could be of interest? For example the reviewers of the archetype, not just listing them as Other contributors. Could we simplify all this stuff and just support a participation kind of approach for archetypes metadata? The idea would be to have one single section called Participants, with with the name, organisation, mail, etc., and a coded field Type of participation using a controlled vocabulary including for example Main author, Contributor author, Main translator, Contributor translator, Reviewer, Consulted domain expert, etc. In fact, this should be a multi valued field, since nothing avoids that the same person is the main author and a translator to a different language. In case that new participation roles appear in the future, we only have to complete the controlled vocabulary, without changing other things. Probably we would still need to support some specific details depending on the type of participation (for example the accreditation info), but this approach could simplify part of the metadata management. I know that are some details to be fixed, but what do you think about the general idea? David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150320/e9b20ccb/attachment.html
Multiple translators
For now, the other_details attribute within TRANSLATION_DETAILS should do the trick. The main issue is to keep the different translators separated, which this seems to do: other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE The main issue is probably getting support for this in the tooling (ie Archetype Editor and the CKM)? Mvh. Silje From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Saturday, March 14, 2015 5:15 PM To: For openEHR clinical discussions Subject: Re: Multiple translators Sure - happy to wait until Silje and other clarify the level of detail needed. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.commailto:ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 14 March 2015 at 14:14, Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote: er hang on - can we see a clear proposal first for: * the ideal solution - what we would do in ADL/AOM 2 - preferably somewhere under this wiki pagehttps://openehr.atlassian.net/wiki/display/ADL/ADL+2+Specifications * possible approaches to ADL 1.4 (preferably on this pagehttps://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Change+Requests) * short term - e.g. 'other_translators' inside 'other_details' * does this include deeper structure or not * medium term - any kind of ADL 1.5/1.6 change that actually could be implemented in current tools like AE, with on-the-fly conversion of existing archetypes * CKM changes We don't want to create too much rework for later. - thomas On 13/03/2015 17:09, Ian McNicoll wrote: Hi Sebastian, I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc. I will have a crack at updating AE and upload them to the Test CKM to see how we get on. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859tel:%2B44%20%280%29775%20209%207859 office +44 (0)1536 414994tel:%2B44%20%280%291536%20414994 skype: ianmcnicoll email: ian at freshehr.commailto:ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.orgmailto:openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/abd5a64a/attachment.html
Multiple translators
Right - exactly. Ideally, we need people who are developing archetypes and think there are limitations to say what they are. It isn't that hard to add more comprehensive meta-data to an archetype for translations, other_contributors etc. Of course, we don't want to go overboard - using links / addresses to other resources is good too. Once changes are agreed, they can be put in ADL 2, and the ADL Workbench and other tools can fairly easily upgrade the existing archetypes into new structures. - thomas On 17/03/2015 10:32, Sebastian Garde wrote: On 17.03.2015 11:25, Thomas Beale wrote: On 17/03/2015 10:17, Bakke, Silje Ljosland wrote: For now, the other_details attribute within TRANSLATION_DETAILS should do the trick. The main issue is to keep the different translators separated, which this seems to do: other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE The main issue is probably getting support for this in the tooling (ie Archetype Editor and the CKM)? If I add the equivalent of this to ADL/AOM 2, will it be enough for the future? There is also an older related issue on the specs tracker https://openehr.atlassian.net/browse/SPECPR-24 This issue highlights some potential problems as well, but doesn't have a clear solution yet. I believe it should be considered at the same time. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/0a0092b0/attachment.html
Multiple translators
Sebastian Garde wrote: There is also an older related issue on the specs tracker https://openehr.atlassian.net/browse/SPECPR-24 This issue highlights some potential problems as well, but doesn't have a clear solution yet. I believe it should be considered at the same time. Hmmm, yes, 2009 ... that is old. Here?s another oldie that we never got around to acting on as well. It talks about needing to know who the terminologist was ... https://oldocean.atlassian.net/browse/EDT-591 (Inaccessible to non-Ocean people, and probably most Ocean people would have lost their logins to this old Jira issue tracker too) ? 1. Archetype Editorhttps://oldocean.atlassian.net/browse/EDT 2. EDT-591https://oldocean.atlassian.net/browse/EDT-591 Need ability to enhance the archetype translator details and to add a Terminologist doing the bindings Reporter: HeatherLeslie Created: 21/Jan/10 7:25 PM Need ability to add Terminologist to the Archetype and enhance the metadata about the Translator to cater for CKM requirements re identifying the primary people doing the initial authoring of the translation/binding plus those who contribute to the reviews of translations/bindings These requirements are becoming a high priority in CKM development - Peter -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/1b0a7b57/attachment-0001.html
Multiple translators
Ian, is your proposal actually valid in 1.4? My understanding is that other_details is a HashString, String. secondary_translators is the key, but Ian... and Sebastian... are two values - which is not possible (and probably not really desirable fpr general other_details either) A further minor point, I would prefer other_translators over secondary_translators for consistency with other_contributors. Sebastian On 17.03.2015 11:25, Thomas Beale wrote: On 17/03/2015 10:17, Bakke, Silje Ljosland wrote: For now, the other_details attribute within TRANSLATION_DETAILS should do the trick. The main issue is to keep the different translators separated, which this seems to do: other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE The main issue is probably getting support for this in the tooling (ie Archetype Editor and the CKM)? If I add the equivalent of this to ADL/AOM 2, will it be enough for the future? - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. http://www.avast.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/e60d0fc6/attachment.html
Multiple translators
The way I see it the whole translation author block should ideally be repeatable, including separate elements for name, organisation, email and accreditation, which would of course require the accreditation element to ble moved inside the author block (why isn?t it there in the first place?). Regards, Silje From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Tuesday, March 17, 2015 11:53 AM To: openehr-clinical at lists.openehr.org Subject: Re: Multiple translators Right - exactly. Ideally, we need people who are developing archetypes and think there are limitations to say what they are. It isn't that hard to add more comprehensive meta-data to an archetype for translations, other_contributors etc. Of course, we don't want to go overboard - using links / addresses to other resources is good too. Once changes are agreed, they can be put in ADL 2, and the ADL Workbench and other tools can fairly easily upgrade the existing archetypes into new structures. - thomas On 17/03/2015 10:32, Sebastian Garde wrote: On 17.03.2015 11:25, Thomas Beale wrote: On 17/03/2015 10:17, Bakke, Silje Ljosland wrote: For now, the other_details attribute within TRANSLATION_DETAILS should do the trick. The main issue is to keep the different translators separated, which this seems to do: other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE The main issue is probably getting support for this in the tooling (ie Archetype Editor and the CKM)? If I add the equivalent of this to ADL/AOM 2, will it be enough for the future? There is also an older related issue on the specs tracker https://openehr.atlassian.net/browse/SPECPR-24 This issue highlights some potential problems as well, but doesn't have a clear solution yet. I believe it should be considered at the same time. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/d4936b40/attachment-0001.html
Multiple translators
The current block looks like the following (from a test archetype): language original_language = [ISO_639-1::en] translations = [fr] = language = [ISO_639-1::fr] author = [name] = Frederik Tyler [email] = freddy at something.somewhere.co.uk accreditation = British Medical Translator id 00400595 [ru] = language = [ISO_639-1::ru] author = [name] = Nina Alexandrovna [organisation] = Dostoevsky Media Services [email] = nina at translation.dms.ru accreditation = Russian Translator id 892230-3A Is this enough? language original_language = [ISO_639-1::en] translations = [fr] = language = [ISO_639-1::fr] author = [name] = Frederik Tyler [email] = freddy at medicaltranslation.co.uk [] = y *[accreditation] = British Medical Translator id 00400595* * other_contributors = Bonnie Tyler **bonnie at medicaltranslation.co.uk, **Yannick Guillouyg at francaistrad.fr* [ru] = language = [ISO_639-1::ru] author = [name] = Nina Alexandrova [organisation] = Dostoevsky Media Services [email] = nina at translation.dms.ru *[accreditation] = Russian Translator id 892230-3A* * other_contributors = Marcus Barakovmarcus**@medicaltranslation.co.uk, **Irina Pavlovairina at emias.ru, Iliana Markova iliana.markova at gorodskaya.ru* or do we need more? - thomas On 17/03/2015 14:38, Bakke, Silje Ljosland wrote: The way I see it the whole translation author block should ideally be repeatable, including separate elements for name, organisation, email and accreditation, which would of course require the accreditation element to ble moved inside the author block (why isn?t it there in the first place?). Regards,** -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/f7fad4d3/attachment.html
Multiple translators
this is doable as well, except not quite like that - multiples of the same thing have to have unique keys, so it would be more like the following. I also added in the 'version_last_translated' which was agreed in principle recently. translations = [fr] = language = [ISO_639-1::fr] authors = [frederiktyler] = [name] = Frederik Tyler [email] = freddy at medicaltranslation.co.uk mailto:freddy at medicaltranslation.co.uk [] = y *[accreditation] = British Medical Translator id 00400595 * [bonnietyler] = [name] = Bonnie Tyler [email] = *_bonnie at medicaltranslation.co.uk_* mailto:freddy at medicaltranslation.co.uk [] = *[accreditation] = Whatevs* [yannickguillou] = [name] = *Yannick Guillou* [email] = *_yg at francaistrad.fr_* mailto:freddy at medicaltranslation.co.uk [] = aabb *other_contributors = ?Jules Verne jules at nautilus.fr mailto:jules at nautilus.fr?, ?Victor Hugo vic at hunchback.net mailto:vic at hunchback.net?* version_last_translated = 2.0.1 However.. it's not clear who did the most recently translation, and who only did some old translation. How do we deal with representing what's a current picture of affairs? It might not matter - it's ok if we assume that the translation work is recorded in some registry for example. Finding the balance is the challenge. - thomas On 17/03/2015 19:53, Bakke, Silje Ljosland wrote: If given complete freedom (possibly not a good idea), I?d prefer something like the following: language original_language = [ISO_639-1::en] translations = [fr] = language = [ISO_639-1::fr] author = [name] = Frederik Tyler [email] = freddy at medicaltranslation.co.uk mailto:freddy at medicaltranslation.co.uk [] = y *[accreditation] = British Medical Translator id 00400595* author = [name] = Bonnie Tyler [email] = *_bonnie at medicaltranslation.co.uk_* mailto:freddy at medicaltranslation.co.uk [] = *[accreditation] = Whatevs* author = [name] = *Yannick Guillou* [email] = *_yg at francaistrad.fr_* mailto:freddy at medicaltranslation.co.uk [] = aabb *other_contributors = ?Jules Verne jules at nautilus.fr mailto:jules at nautilus.fr?, ?Victor Hugo vic at hunchback.net mailto:vic at hunchback.net?* -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150317/6565b8fa/attachment.html
Multiple translators
er hang on - can we see a clear proposal first for: * the ideal solution - what we would do in ADL/AOM 2 - preferably somewhere under this wiki page https://openehr.atlassian.net/wiki/display/ADL/ADL+2+Specifications * possible approaches to ADL 1.4 (preferably on this page https://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Change+Requests) o short term - e.g. 'other_translators' inside 'other_details' + does this include deeper structure or not o medium term - any kind of ADL 1.5/1.6 change that actually could be implemented in current tools like AE, with on-the-fly conversion of existing archetypes * CKM changes We don't want to create too much rework for later. - thomas On 13/03/2015 17:09, Ian McNicoll wrote: Hi Sebastian, I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc. I will have a crack at updating AE and upload them to the Test CKM to see how we get on. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com mailto:ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/7ab27c83/attachment.html
Multiple translators
Sure - happy to wait until Silje and other clarify the level of detail needed. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 14 March 2015 at 14:14, Thomas Beale thomas.beale at oceaninformatics.com wrote: er hang on - can we see a clear proposal first for: - the ideal solution - what we would do in ADL/AOM 2 - preferably somewhere under this wiki page https://openehr.atlassian.net/wiki/display/ADL/ADL+2+Specifications - possible approaches to ADL 1.4 (preferably on this page https://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Change+Requests ) - short term - e.g. 'other_translators' inside 'other_details' - does this include deeper structure or not - medium term - any kind of ADL 1.5/1.6 change that actually could be implemented in current tools like AE, with on-the-fly conversion of existing archetypes - CKM changes We don't want to create too much rework for later. - thomas On 13/03/2015 17:09, Ian McNicoll wrote: Hi Sebastian, I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc. I will have a crack at updating AE and upload them to the Test CKM to see how we get on. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/0579164d/attachment-0001.html
Multiple translators
Hi, At the Norwegian CKM http://arketyper.no, we've been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we're finding more and more translation isn't a one-person job, but usually there's a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it's not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, Silje Ljosland Bakke Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.nohttp://arketyper.no/ / Twitter: @arketyper_nohttps://twitter.com/arketyper_no -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/0de45df0/attachment.html
Multiple translators
Hi Silje, Having been in that position as a translator a couple of times, I think we put all our names in the field at that time. This of course isn't ideal if you have two or more translators that share the work equally. However, it is the same with the original_author field - no real-world archetype has very been created by one person only. Therefore, we have introdued the idea of other_contributors already where editors, reviewers etc. are given credit. This is where potentially other translators could be added as well, e.g. if there is a prime/lead translator and several who check the translation. BTW, for this checking translations, there is also the possibility to conduct translation reviews in CKM (ideally after the content has been published or it will be too burdensome I believe). Cheers Sebastian On 13.03.2015 16:06, Bakke, Silje Ljosland wrote: Hi, At the Norwegian CKM http://arketyper.no, we?ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we?re finding more and more translation isn?t a one-person job, but usually there?s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it?s not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, *Silje Ljosland Bakke* ** Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust ** Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.no http://arketyper.no// Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. http://www.avast.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/54bac489/attachment.html
Multiple translators
Hi Silje, The current AOM has an other_details attribute inside TRANSLATION_DETAILS which would allow something like other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE would that be enough, or do we need accreditation details for each translator? That would need a change to the Archetype Object model - easy to do but not until we get ADL 2.0 tooling. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 15:06, Bakke, Silje Ljosland silje.ljosland.bakke at helse-bergen.no wrote: Hi, At the Norwegian CKM http://arketyper.no, we?ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we?re finding more and more translation isn?t a one-person job, but usually there?s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it?s not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, *Silje Ljosland Bakke* Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.no / Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/5b9e57e2/attachment.html
SV: Multiple translators
Hi, If someone is interested in and would like to have some inspiration from how different IHTSDO member countries have dealt with translations of SNOMED CT descriptions (terms), the documents Translation Guidelines and Translation Management Guidelines can be found at the address http://www.ihtsdo.org/snomed-ct/snomed-ct-worldwide/translations-of-snomed-ct . (I guess that openEHR doesn't have similar documents?) Regards Mikael Fr?n: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] F?r Bakke, Silje Ljosland Skickat: den 13 mars 2015 16:07 Till: For openEHR clinical discussions (openehr-clinical at lists.openehr.org) ?mne: Multiple translators Hi, At the Norwegian CKM http://arketyper.no, we've been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we're finding more and more translation isn't a one-person job, but usually there's a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it's not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, Silje Ljosland Bakke Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.nohttp://arketyper.no/ / Twitter: @arketyper_nohttps://twitter.com/arketyper_no -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/b19e7352/attachment-0001.html
Multiple translators
Hi Ian, Yes, I agree that that is a better place - but I think you will find that while this is in the rm, tooling support for TRANSLATION_DETAILS/other_details it is rather poor at present. In CKM, we could add something like this to the translation pages, which would make it easy for the (main) translator to add this. Sebastian On 13.03.2015 16:38, Ian McNicoll wrote: Hi Silje, The current AOM has an other_details attribute inside TRANSLATION_DETAILS which would allow something like other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE would that be enough, or do we need accreditation details for each translator? That would need a change to the Archetype Object model - easy to do but not until we get ADL 2.0 tooling. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com mailto:ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 15:06, Bakke, Silje Ljosland silje.ljosland.bakke at helse-bergen.no mailto:silje.ljosland.bakke at helse-bergen.no wrote: Hi, At the Norwegian CKM http://arketyper.no, we?ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we?re finding more and more translation isn?t a one-person job, but usually there?s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it?s not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, *Silje Ljosland Bakke* ** Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust ** Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 tel:%2B47%2040203298 Web: http://arketyper.no http://arketyper.no// Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org mailto:openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. http://www.avast.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/d9f82bdf/attachment.html
Multiple translators
Hi Sebastian, I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc. I will have a crack at updating AE and upload them to the Test CKM to see how we get on. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 17:04, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: Hi Ian, Yes, I agree that that is a better place - but I think you will find that while this is in the rm, tooling support for TRANSLATION_DETAILS/other_details it is rather poor at present. In CKM, we could add something like this to the translation pages, which would make it easy for the (main) translator to add this. Sebastian On 13.03.2015 16:38, Ian McNicoll wrote: Hi Silje, The current AOM has an other_details attribute inside TRANSLATION_DETAILS which would allow something like other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE would that be enough, or do we need accreditation details for each translator? That would need a change to the Archetype Object model - easy to do but not until we get ADL 2.0 tooling. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 15:06, Bakke, Silje Ljosland silje.ljosland.bakke at helse-bergen.no wrote: Hi, At the Norwegian CKM http://arketyper.no, we?ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we?re finding more and more translation isn?t a one-person job, but usually there?s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it?s not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, *Silje Ljosland Bakke* Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.no / Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Ocean Informatics Skype: gardeseb -- http://www.avast.com/ Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. www.avast.com ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/8be9b1ad/attachment-0001.html
Multiple translators
Using LinkEHR you can define the other_details in translations. We added an export function in order to generate archetypes as the AE is expecting (i.e. parse), so using LinkEHR once should not really be a problem ;) 2015-03-13 18:09 GMT+01:00 Ian McNicoll ian at freshehr.com: Hi Sebastian, I have looked at the AE code and I think it may be a relatively simple fix that mirrors the work done for the general other_details section to support namespaces etc. I will have a crack at updating AE and upload them to the Test CKM to see how we get on. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 17:04, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: Hi Ian, Yes, I agree that that is a better place - but I think you will find that while this is in the rm, tooling support for TRANSLATION_DETAILS/other_details it is rather poor at present. In CKM, we could add something like this to the translation pages, which would make it easy for the (main) translator to add this. Sebastian On 13.03.2015 16:38, Ian McNicoll wrote: Hi Silje, The current AOM has an other_details attribute inside TRANSLATION_DETAILS which would allow something like other_details = [secondary_translators] = Ian McNicoll, freshEHR, UK, Sebastian Garde, Ocean Informatics, DE would that be enough, or do we need accreditation details for each translator? That would need a change to the Archetype Object model - easy to do but not until we get ADL 2.0 tooling. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 March 2015 at 15:06, Bakke, Silje Ljosland silje.ljosland.bakke at helse-bergen.no wrote: Hi, At the Norwegian CKM http://arketyper.no, we?ve been doing quite extensive translation of international (English language) archetypes into Norwegian. During this process, we?re finding more and more translation isn?t a one-person job, but usually there?s a primary translator and one or more secondary translators. As of now there seems to be only one field in which to put translator information, so to attribute more than one person as the archetype translator, we need to put more than one name, organisation, etc into the same fields. This sort of works, but it?s not exactly elegant. Is there a better way to do this, either right now or in the works? Kind regards, *Silje Ljosland Bakke* Special Adviser, RN RD dept, E-health section, Bergen Hospital Trust Coordinator, National Editorial Board for Archetypes, National ICT Norway Tel. +47 40203298 Web: http://arketyper.no / Twitter: @arketyper_no https://twitter.com/arketyper_no ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Ocean Informatics Skype: gardeseb -- http://www.avast.com/ Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. www.avast.com ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150313/c375c3fb/attachment.html
