Improving Translation details and other_contributors
Description
PR is addressed in
relates to
Activity
Thomas Beale November 12, 2019 at 1:34 PM
Re: the mis-spelling - I've fixed this in the UML model - don't know how it got there, but the change will flow through.
Sebastian Garde November 12, 2019 at 12:43 PM
As a side-note (and not sure if it warrants a separate PR): accreditat[i]on is misspelled in the latest https://specifications.openehr.org/releases/BASE/latest/resource.html#_translation_details_class - not sure this has not always been the case
Diego Bosca November 12, 2019 at 12:01 PM
+1, seems like a good proposal
Ian McNicoll November 12, 2019 at 11:58 AM
I would agree with that proposal @Sebastian Garde . This approach has worked well for the gneral archetype->Other contributors scenario. I suggest we add this to the next release, (and possibly do something similar for terminology authors, as it is bound to come up there also.
There is always going to be an issue of who is the primary translator (if any) but this is more about negotiation between the various parties, and an issue which seems to be working pretty well in terms of primary author of an archetype vs. other contributors.
Sebastian Garde November 12, 2019 at 11:44 AM
This is coming up as a problem again.
As soon as there are multiple translators (e.g. a new translator picking up an existing translation of an archetype in CKM and making minor or major changes.)
Re-reading this, I think - for minimum impact - it is best to
add the following to TRANSLATION_DETAILS:
0..1 other_contributors:List<String>
Whether it is called “other_contributors” or “other_translators” doesn’t matter much to me, but other_contributors is aligned with the other_contributors (used for the content) and is more flexibly worded.
This issue was created in 2009 and moved from 1.0.3 to be addressed in 1.1.0 in 2015. Can this be added to the next BASE release - or if nobody agrees that this is required - can we reject this issue? Then we will need to use workarounds such as adding multiple names to the TRANSLATION_DETAILS/author/”name” and TRANSLATION_DETAILS/author/”organisation”, etc. but at least we know where we are at.
Details
Details
Reporter
Components
Affects versions
Priority
Major
The Translator details in ADL seem to have some limitations, which should be looked into for a future release
What seems to be current practice is that a translation will be done by more than one person and the documentation of this is not really supported by the model:
TRANSLATION_DETAILS
accreditation : String 1 – Accreditation of translator, usually a national translator's association id author : Hash<String,String> 1 – Translator name and other demographic detailsOnly one translator is available.
The easiest change would be to make author repeatable, but accreditation (which seems to be somewhat detached from the author anyway) would need to be changed then as well - is accreditation that important that it couldn't be captured as part of the author Hash or what is the reason for having it separate?
The other problem we have is with other_contributors not sticking to the same format (i.e. we only have a list of contributors without more formal metadata):
RESOURCE_DESCRIPTION
original_author : Hash<String,String> 1 – Original author of this resource, with all relevant details, including organisation. other_contributors : List<String> 0..1 – Other contributors to the resource, probably listed in "name " form.I think I understand why it is modelled as it is, but why not allow other_contributors to be 0..* Hash<String,String> ?
Maybe, we need to look into formalising what an author/translator is a bit more in the model?