Multiple translators

David Moner damoca at gmail.com
Fri Mar 20 09:46:13 EDT 2015


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 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"
> <freddy at medicaltranslation.co.uk>>
>                     ["xxxx"] = <"yyyyy">
>
> *                    ["accreditation"] = <"British Medical Translator id
> 00400595">                 >*
>
>                 ["bonnietyler"] = <
>                     ["name"] = <"Bonnie Tyler">
>                     ["email"] = <"*bonnie at medicaltranslation.co.uk*"
> <freddy at medicaltranslation.co.uk>>
>                     ["xxxx"] = <"zzzz">
> *                    ["accreditation"] = <"Whatevs">*
>                >
>
>                 ["yannickguillou"] = <
>                     ["name"] = <"*Yannick Guillou* ">
>                     ["email"] = <"*yg at francaistrad.fr*
> <freddy at medicaltranslation.co.uk>">
>                     ["xxxx"] = <"aabb">
>                >
>             >
>            *other_contributors = <"Jules Verne <jules at nautilus.fr
> <jules at nautilus.fr>**>**", "Victor Hugo <vic at hunchback.net
> <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 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
>
>
> ------------------------------
>   [image: Avast logo] <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
>



-- 
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia - 46022 (España)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150320/66730368/attachment-0002.html>


More information about the openEHR-clinical mailing list