Non-author contributor names

[JGilbert-eLife]

trafficstars

Description

The displayed name for a non-author contributor on the article.

User stories

Author

• (1) As an author, I would like to be able to see (but not edit) the names of non-author contributors (e.g. editors, reviewers) so that I can confirm this information is correct.
• (2) As an author, I would like to be able to distinguish non-author contributors (editors, reviewers) from the main author list so that I do not confuse the two.

Production staff

• (3) As production staff, I want to be able to delete non-author contributors so that I can remove any added in error.
• (4) As production staff, I want to be able to add new non-author contributors so that I can include any missed in error.
• (5) As production staff, I want to be able to see which parts of a non-author contributor's name have been designated first name(s) + initials, and which surname(s) so that I can make sure this has been done correctly.
• (6) As production staff, I want to be able to edit the name of a non-author contributor so that I can ensure that the information is correct and conforms to house style.
• (7) As production staff, I want to be able to add a prefix/suffix to a non-author contributor so that I can ensure they are distinguishable from a parent or child with the same name (e.g. Fred Smith Jnr).
• (8) As production staff, I want to be able to remove a prefix/suffix from a non-author contributor so that I can correct any mistakes.

But what if . . . ?

Consideration

• It needs to be absolutely clear that the non-author contributors are not part of the main author list!
• At eLIfe, editors are required for research content; they are optional for Feature content; they will not be present for Corrections/Retractions. Reviewers are entirely optional as not all reviewers agree to revel their identity
• eLife only allows suffixes and then only a select few (we don't allow PhD or MD for example, just Roman numerals, Jnr and Snr). Other publishers may allow other suffixes and may also allow prefixes.
• There can be more than one set of non-author contributors. How many and what they are is likely a configuration issue per journal. So far, it does not sound like they should be added on the fly.

XML requirements

Non-author contributors are captured as contrib elements inside a contrib-group element which is distinct from the author list. In the article front/article-meta, this distinction is currently handled with an appropriate value for the contrib-group/@content-type.

Editors and reviewers should be captured in a contrib-group[@content-type="peer-review"]. Translators should be captured in a contrib-group[@content-type="translators"].

<article-meta>
   …
   <contrib-group content-type="peer-review">
 	<contrib>
                    <name>
                        <suffix>III</suffix>
                        <surname>...</surname>
                        <given-names>....</given-names>
                    </name>
                    <role>Senior Editor</role>
                    <xref ref-type="aff" rid="aff5">5</xref>
 	</contrib>
 	<contrib>
                    <name>
                        <surname>...</surname>
                        <given-names>...</given-names>
                    </name>
                    <role>Reviewing Editor</role>
                    <xref ref-type="aff" rid="aff5">5</xref>
 	</contrib>
 	<contrib>
                    <name>
                        <surname>...</surname>
                        <given-names>....</given-names>
                    </name>
                    <role>Reviewer</role>
                    <xref ref-type="aff" rid="aff5">5</xref>
 	</contrib>
        <contrib>
                    <name>
                        <surname>...</surname>
                    </name>
                    <role>Reviewer</role>
                    <xref ref-type="aff" rid="aff6">6</xref>
 	</contrib>
 	<contrib>
                    <name>
                        <surname>...</surname>
                        <given-names>....</given-names>
                        <prefix>Dr.</prefix>
                    </name>
                    <role>Reviewer</role>
                    <xref ref-type="aff" rid="aff6">6</xref>
 	</contrib>
 	<aff id="aff5">
 	 	<institution>...</institution>
 	 	<country>...</country>
         </aff>
 	<aff id="aff6">
 	 	<institution>...</institution>
 	 	<country>...</country>
         </aff>
   </contrib-group>
   <contrib-group content-type="translators">
 	<contrib>
                    <name>
                        <surname>...</surname>
                        <given-names>....</given-names>
                    </name>
                    <role>English Translator</role>
                    <xref ref-type="aff" rid="aff7">7</xref>
 	</contrib>
 	<aff id="aff7">
 	 	<institution>...</institution>
 	 	<country>...</country>
         </aff>
   </contrib-group>
…
</article-meta>

The name of reviewers, editors, and translators may contain the same elements as author names:

• surname (the only one that must be present in name)
• given-names
• prefix
• suffix

Custom Vocabulary

Texture needs to allow for customisable contrib-groups in addition to the three outlined above. A publisher may want to distinguish between other forms of non-author contributors, and these should be able to be accounted for with some form of customization that would allow the user/publisher to capture these contributors in their own distinct contrib-group with an appropriate @content-type value.

Mock ups

Proposal

[michael]

Texture needs to allow for customisable contrib-groups in addition to the three outlined above. A publisher may want to distinguish between other forms of non-author contributors, and these should be able to be accounted for with some form of customization that would allow the user/publisher to capture these contributors in their own distinct contrib-group with an appropriate @content-type value.

Isn't this something we could agree on as a group? Even if we had 10 different contrib-groups it would be better to have them built-in and optional than having publisher-specific values. The content would no longer be exchangeable, as the semantic meaning is not defined for the custom groups.

Few general questions:

• what are the reasons to sub-group non-author contributors? Where is this information used (except for display)
• What if we used just two groups "authors" and "other" (non-authors) and use the roles for sub-grouping? (it's kind of redundant to put a translator into a "translators" group and then pick the role "Translator")

[fabiobatalha]

@michael

I agree with you. We can have the authors and others contrib-group only. The element role should be enough to distinguish from reviewers, translators and others.

In this approach:

• the role element should be flexible enough. It means it can have a controlled vocabulary but still needs to allow users to define their own valid values and it can not be mandatory.
• will not be possible to implement the Elife rule where every reviewer should be signed with a role once the role element can not be mandatory.

[michael]

I've started a complete feature proposal in which I'd like to address all required feature-requests in the end. I came up with 2 sections Authors and Contributors (all other contributor types, such as reviewer translator etc.)

See: https://github.com/substance/texture/issues/1269

@fabiobatalha any chance we can maintain a collaborative list of role values that are available. By doing that content would be compatible among different journals. We are happy to add as many roles as needed, but think it would be beneficial if all journals used the same values.

[Melissa37]

I agree with you. We can have the authors and others contrib-group only. The element role should be enough to distinguish from reviewers, translators and others.

I agree, but would like @FAtherden-eLife and @JGilbert-eLife to confirm for eLife

@fabiobatalha any chance we can maintain a collaborative list of role values that are available. By doing that content would be compatible among different journals. We are happy to add as many roles as needed, but think it would be beneficial if all journals used the same values.

I like the idea of an extensible list of role values. I think some might need that field to be completely open and editable, but we at eLife would have defined roles that we'd need to add to/change over time

[fabiobatalha]

@fabiobatalha any chance we can maintain a collaborative list of role values that are available. By doing that content would be compatible among different journals. We are happy to add as many roles as needed, but think it would be beneficial if all journals used the same values.

@michael At Érudit we do not have all this variety of roles because the ÉruditArticle Schema doesn't support this. But considering we are moving to JATS and we will start to have control of this information it is totally acceptable to have a pre-defined list of possible values for authors and non-authors roles.

I would say some journals will adopt the terms of this list but we can not assure all the journals will accept it so by this reason to avoid the need of future custom developments I think it is important to have the possibility to assign custom values for authors and non-author roles.