texture
texture copied to clipboard
substance
Non-author contributor affiliations
Description
Affiliations for non-author contributors, to be considered separately from the affiliations for the authors.
User stories
Author
- (1) As an author, I would like to be able to see the affiliations for non-author contributors (reviewers, editors etc) so that I can confirm this information is correct.
- (2) As an author, I want to be able to clearly distinguish the affiliations for non-author contributors from those for authors so that I do not confuse the two.
Production staff
- (3) As production staff, I want to be able to delete the affiliations for non-author contributors so that I can remove any added in error.
- (4) As production staff, I want to be able to add new affiliations for non-author contributors so that I can include any missed in error.
- (5) As production staff, I want to be able to edit the affiliations for non-author contributors so that I can ensure that the information is correct and conforms to house style.
But what if . . . ?
Consideration
- We need to make sure it's not possible to associate an editor/reviewer affiliation with an author and vise versa.
- It is possible, though unlikely given how peer review is supposed to be independent, that an editor or reviewer will have the same affiliation as an author (possible in Feature content for eLife). Additionally, it seems plausible that this case could occur with translators. In these cases, the shared affiliation will need to appear twice, once for the author list and once for the non-author contributor list.
XML requirements
Affiliations for editors are currently captured as children of the editor's contrib (in variance to how authors are captured)
<contrib-group content-type="peer-review">
<contrib>
<name>
<surname>Harrison</surname>
<given-names>Melissa</given-names>
</name>
<role>Senior Editor</role>
<xref ref-type="aff" rid="aff6">6</xref>
</contrib>
<contrib>
<name>
<surname>Collings</surname>
<given-names>Andy</given-names>
</name>
<role>Reviewing Editor</role>
<xref ref-type="aff" rid="aff6">6</xref>
</contrib>
<aff id="aff6">
<institution>eLife Sciences</institution>
<country>United Kingdom</country>
</aff>
</contrib-group>
This is because it's very unlikely for more than one affiliation needed to be captured for them in eLife's use-case.
Flexibility
eLife are happy to be flexible in how these are captured, provided that the distinction between author affiliations and editor affiliations is maintained - these should never be listed in the same place and conflated! - and that the capture is one of forms recommended by JATS4R.
Mock ups
Decisions
- [x] We will use two contrib-group types: authors and contributors (= non-author contributors), the role element will be used to distinguish the different types of contributors (reviewer, translator, editor, ...)
It is possible, though unlikely given how peer review is supposed to be independent, that an editor or reviewer will have the same affiliation as an author (possible in Feature content for eLife). Additionally, it seems plausible that this case could occur with translators. In these cases, the shared affiliation will need to appear twice, once for the author list and once for the non-author contributor list.
If we choose to have dedicated affiliations per contrib group, sharing an affiliation is not possible. The information needs to be entered twice or even 3 times, if an author, an editor and a translator have the same affiliation (and given we have three groups). Is that acceptable?
The contrib-group authors and others should be enough for Érudit use cases using role to distinguish reviewers from translators.
If we choose to have dedicated affiliations per contrib group, sharing an affiliation is not possible. The information needs to be entered twice or even 3 times, if an author, an editor and a translator have the same affiliation (and given we have three groups). Is that acceptable?
That is correct. It mitigates against the risk of one being updated and updating the others without the user seeing - as we think they will be displayed in different places. It is unlikely they will share the affiliations for eLife and we think it is better they are repeated than risk one group updating for another accidently.
I appreciate your concern from the point of view of initial data entry for the use case of an authoring tool, but for our current use case that data will be pre-filled from the XML. I thought there was a discussion about potential autofill of affiliations already in the article?
The contrib-group authors and others should be enough for Érudit use cases using role to distinguish reviewers from translators.
@fabiobatalha are you saying you won't have affiliations for non-author contributors
@Melissa37 there is always an option for prefill an entity for sake of convenience. After that, things would be treated as separated entities, in this case.
Note: please add a user story if you want to have a convenience prefill of something.
The contrib-group authors and others should be enough for Érudit use cases using role to distinguish reviewers from translators.
@fabiobatalha are you saying you won't have affiliations for non-author contributors
No @Melissa37, This comment concerns to the Awaiting Decision above.
@Melissa37 there is always an option for prefill an entity for sake of convenience. After that, things would be treated as separated entities, in this case. Note: please add a user story if you want to have a convenience prefill of something.
@oliver---- thanks. I don't think we need to add that user story for eLife now as it does not affect our use case. If we feel we should add it for Texture as a tool and it slots in here we should do it. Everyone should decide on that I guess?