Multiple translators

Sebastian Garde sebastian.garde at oceaninformatics.com
Fri Mar 20 08:22:47 EDT 2015


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>>
>>                     ["xxxx"] = <"yyyyy">
>> *                    ["accreditation"] = <"British Medical Translator 
>> id 00400595">
>>                 >*
>>
>> ["bonnietyler"] = <
>>                     ["name"] = <"Bonnie Tyler">
>>                     ["email"] = 
>> <"*_bonnie at medicaltranslation.co.uk_*" 
>> <mailto:freddy at medicaltranslation.co.uk>>
>>                     ["xxxx"] = <"zzzz">
>> *                    ["accreditation"] = <"Whatevs">*
>>                >
>>
>> ["yannickguillou"] = <
>>                     ["name"] = <"*Yannick Guillou* ">
>>                     ["email"] = <"*_yg at francaistrad.fr_* 
>> <mailto:freddy at medicaltranslation.co.uk>">
>>                     ["xxxx"] = <"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
>
>
>
> _______________________________________________
> 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/20150320/cc0057d4/attachment-0002.html>


More information about the openEHR-clinical mailing list