How will you represent attribution for retranslations/updates over the course of time?
over the lifetime of an archetype you could end up with quite a long list of translators, some of whom would have done the original full translation, and others may only have done a small update or changed a single word. I agree that some form of external registry might solve this more elegantly than encapsulating it inside the archetype, but in that case why put any of it inside the archetype - you could instead include URLs to appropriate part of the translator registry.
For everything to do with history of authorship and translation - probably that is the ultimate future. And we do have full version control auditing in CKMs of course, and to date, all CKMs that I know of are publicly open. However, we are so far away from reliable standards for that kind of thing, and more importantly for standardised registry implementations (i.e. with something like reliable, publish REST URI structures for accessing this kind of info) that we just have to ‘do our best’ for now. Usually the ISO 11179 brigade wants to own all this, but we never see any concrete progress that I’m aware of… So all the author/contributors/translator meta-data in the archetype is an attempt to provide the highest value information in the smallest space, without relying on a registry / CKM-like tool. For example, knowing the current primary translator for e.g. the BP measurement archetype for language X is probably useful, also knowing what the last version of the original EN-language archetype was the language X translation based on… I think for now we just have to try to strike a reasonable balance between practical needs (who to contact) and attribution requirements. It might be worth exploring putting in a ‘full version history’ URI into an archetype… - 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.
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?
You can upload an archetype that uses TRANSLATION_DETAILS/OTHER_DETAILS and this will be maintained and displayed in the appropriate places in CKM.
However, if we need special support for any TRANSLATION_DETAILS/OTHER_DETAILS items, e.g. a key other_contributors with a value string that has multiple lines (one for each contributor as a convention), that is explicitly exposed during online translation of an archetype in CKM, the we need to agree on this very soon.
I would suggest that we either leave this as a feature for next-gen ADL (1.5/2.0) and then do it properly as to be agreed or agree on this other_contributors multi-linestring and convert this to multiple entries for next-gen ADL.
Apart from this - is there any other pressing needs that need any special support during CKM online translation and than can be expressed with the ADL1.4 other_details fields?