Handling of Editors

[JGilbert-eLife]

At the moment, the Editor block completely replicates the Author block. eLife doesn't require this as we would never mark an editor as deceased, include their email or funding etc.

At the moment, we just collect the editor's name and affiliation. Would other journals need more than that?

We also distinguish different kinds of editors (Reviewing Editor, Senior Editor) and reviewers (currently we use the contrib-type attribute) so we'll need a way of handling these multiple kinds of editorial people in articles.

[fabiobatalha]

@JGilbert-eLife

We also manage this kind of information in the XML files.

In our case:

• The contrib-group for editorial board is placed in the journal-meta element
• We don't need all the detailed information we expect for authors
• We don't control the affiliation for the editorial board

Maybe the kinds of editors should be a open field.

[gustavofonseca]

SciELO also doesn't require detailed information about editors.

[michael]

@JGilbert-eLife in Texture we consider authors and editors as 'contributors' thus both share the same fields. Is it a problem that too many fields are available? You could just leave them blank right? Maybe some other journal wants to tag affiliations of an editor.

What is missing currently is a field that allows you to tag as Reviewing Editor or Senior Editor. How to call that field in Texture? Should it be a pre-populated list to select from or a free form text field?

[Melissa37]

Is it a problem that too many fields are available? You could just leave them blank right? Maybe some other journal wants to tag affiliations of an editor.

From a UI point of view it would create too much additional space and effort to skip them, but I guess eLife could deal with that in our version by hiding the fields we don't want to be visible? We also have the additional issue that we actually don't want that extra metadata to be published in the XML so we'd need to hide the fields so nobody filled them in and we accidentally published it. @gmaciocci do you agree?

What is missing currently is a field that allows you to tag as Reviewing Editor or Senior Editor. How to call that field in Texture? Should it be a pre-populated list to select from or a free form text field?

Currently, it just states "Editors", we'd need to indicate which editor role as well.

Are reviewers also considered 'contributors'? We need a place for them too.

[michael]

Yes we would also consider reviewers as contributors. They would be added just like Editors. Are there any additional fields that reviewers would need?

[Melissa37]

Yes we would also consider reviewers as contributors. They would be added just like Editors. Are there any additional fields that reviewers would need?

For eLife

• given-names
• surname
• role
• institution
• country

Sample snippet:

<contrib-group>
                <contrib contrib-type="reviewer">
                    <name>
                        <surname>Darian-Smith</surname>
                        <given-names>Corinna </given-names>
                    </name>
                    <role>Reviewer</role>
                    <aff>
                        <institution>Stanford University</institution>
                        <country>United States</country>
                    </aff>
                </contrib>

[michael]

@Melissa37 that means we have sufficient fields. Thanks!

Just note, that we don't store inline aff records, they must be linked via xref as done with authors and editors. We need to have all <contrib> elements structured exactly the same.

[Melissa37]

Just note, that we don't store inline aff records, they must be linked via xref as done with authors and editors. We need to have all elements structured exactly the same.

OK thanks. We'll do some testing make sure that works.

[JGilbert-eLife]

So, I think the big stumbling block for storing all <aff>s as linked xrefs will be delivering to end-points like PMC. @FAtherden-eLife and I modified an existing article to place the group author member affiliations at the same level as the first author's affiliation and have included the Reviewing editor's affiliation as an xlink-ed <aff> within her ` block, like so:

           <contrib-group>
                <contrib contrib-type="author" id="author-33484">
                    <name><surname>Repass</surname><given-names>John</given-names></name>
                    <xref ref-type="aff" rid="aff1">1</xref>
                    <xref ref-type="fn" rid="con1"/>
                    <xref ref-type="fn" rid="conf1"/>
                </contrib>
                <contrib contrib-type="author" corresp="yes">
                    <email>tim@cos.io</email>
                    <email>nicole@scienceexchange.com</email>
                    <collab>Reproducibility Project: Cancer Biology<contrib-group>
                        <contrib contrib-type="author">
                            <name><surname>Iorns</surname><given-names>Elizabeth</given-names></name>
                            <xref ref-type="aff" rid="aff2">2</xref>
                        </contrib>
                        <contrib contrib-type="author">
                            <name><surname>Denis</surname><given-names>Alexandria</given-names></name>
                            <contrib-id contrib-id-type="orcid" authenticated="true">http://orcid.org/0000-0002-1210-2309</contrib-id>
                        </contrib>
                        <contrib contrib-type="author">
                            <name><surname>Williams</surname><given-names>Stephen R</given-names></name>
                            <xref ref-type="aff" rid="aff3">3</xref>
                        </contrib>
                        <contrib contrib-type="author">
                            <name><surname>Perfito</surname><given-names>Nicole</given-names></name>
                            <xref ref-type="aff" rid="aff2">2</xref>
                        </contrib>
                        <contrib contrib-type="author" id="author-16276">
                            <name><surname>Errington</surname><given-names>Timothy M</given-names></name>
                            <xref ref-type="aff" rid="aff3">3</xref>
                            <contrib-id contrib-id-type="orcid" authenticated="true">http://orcid.org/0000-0002-4959-5143</contrib-id>
                        </contrib>
                    </contrib-group>
                    </collab>
                    <xref ref-type="other" rid="fund1"/>
                    <xref ref-type="fn" rid="con2"/>
                    <xref ref-type="fn" rid="conf2"/>
                </contrib>
                <aff id="aff1">
                    <label>1</label>
                    <institution>ARQ Genetics</institution>
                    <addr-line><named-content content-type="city">Bastrop</named-content></addr-line>
                    <country>United States</country>
                </aff>
                <aff id="aff2">
                    <institution>Science Exchange</institution>
                    <addr-line><named-content content-type="city">Palo Alto</named-content></addr-line>
                    <country>United States</country>
                </aff>
                <aff id="aff3">
                    <institution>Center for Open Science</institution>
                    <addr-line><named-content content-type="city">Charlottesville</named-content></addr-line>
                    <country>United States</country>
                </aff>
            </contrib-group>
            <contrib-group content-type="section">
                <contrib contrib-type="editor" id="author-17615">
                    <name>
                        <surname>Sears</surname>
                        <given-names>Cynthia L</given-names>
                    </name>
                    <role>Reviewing Editor</role>
                    <xref ref-type="aff" rid="aff4">4</xref>
                </contrib>
                <aff id="aff4">
                    <institution>Johns Hopkins University</institution>
                    <country>United States</country>
                </aff>
            </contrib-group>

This results in the following:

(For comparison, this is the PMC display for the live article:

)

As you can see, in the modified version, the editor's affiliation shows in much the same place but with the confusing addition of the '4' superscript on her name, which I have included in the XML because it is required for main author affiliations for PMC display.

More of a problem are the group author member affiliations: with the <aff> elements at the same level as the first author's, they show in the author information, but because the member names are themselves within the group, the linking superscripts are entirely missing and the affiliations just sort of float there.

I would suggest that if we can drop indicators like the '4' from editor affiliations, there won't be too many technical problems with using xref linked <aff>s for these. HOWEVER - this represents a difference between main author affiliations and those for other people included in the XML (editors, reviewers etc) which must be captured in Texture, and I have concerns about the human readability of the revised display since it might potentially be misleading to readers. The present duplication of names is a bit inelegant (see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5798933/ for example) but it does make it instantly clear that the affiliations belong to the editors, not the authors. That seems like a question for PMC though, @Melissa37?

On the other hand, this does raise a serious question about how we are going to handle group author member affiliations (distinct from those directly associated with the group author itself), since placing them at the same level as those for top-level authors leads to this detached render and, I would argue, is inappropriate anyway.

[Melissa37]

That seems like a question for PMC though, @Melissa37?

I have emailed Jeff and Laura at PMC for their input.

I hope it is clear @michael that from the work @JGilbert-eLife and @FAtherden-eLife did, the affiliations are all <x-ref>s as you've requested, but are not in one block, they are still contained within the respective <contrib> groups otherwise editor, individuals in a group authorship, and reviewer affiliations would be treated with the same level of importance as the author affiliations and this cannot happen.

[Melissa37]

Message from Laura Randall (PMC):

I think the route of using the <xref> element to link contributors to the affiliations is a solid method that should provide what you need in most cases. Since PMC, as a rule, only generates text in a very select number of cases, including the number in the <xref> is an unfortunate necessity—if you’re concerned with PMC display. Personally, when wearing my “what’s best in JATS” hat and using the <xref> linking approach, I’d keep the <contrib> and their associated <aff> elements within the same <contrib-group>. So where you currently have aff2-aff3 in the first-level , the purist in me would place it in the second-level <contrib-group>, the one that contains only the expanded list of the collab members. I tried that and ran the content through the PMC Article Previewer, only to discover that we don’t display affiliations at that level. We’ll output the <xref>, but they don’t point or link to anything. That’s something we would have to address here because it’s a valid tagging option (and one that makes sense for JATS) and that shortcoming on our end shouldn’t influence anyone’s decision on tagging. Generally speaking, though, I don’t have any reservations about using the <xref> linking method. It’s really common in the data we receive, so—with the exception of the 2nd level aff display issue—it’s a solid practice that works.

[michael]

@Melissa37 We would like to stick with the global affs in the Dar source format, as it is the most generic representation. E.g. it allows to share an aff record between an author and an editor.

Regarding PMC: I understand this is important but I'd suggest to rather develop a Dar -> PMC converter, then we get the freedom to define our model after best engineering practices (reducing redundancy and ambiguity) while being able to 'optimise' the PMC display separately.

I think it's valid that we have a source format (Dar) and a generated archive format (PMC JATS) as they serve different use-cases.

Does that sound reasonable?

[Melissa37]

Does that sound reasonable?

Can we talk about it in more detail so we can get a better understanding of what you mean? We cannot risk affiliations of non-authors somehow getting mixed with those of authors in our output from Texture (it's not a PMC requirement but a basic XML requirement we and many publishers would share with PMC). That's why we thought it was a good compromise on our part that all affiliations could be xref linked, but as long as they are contained within their relevant contrib group.

[michael]

Covered in requirements document. Working on a proposal.

[fabiobatalha]

Continue at: https://github.com/substance/texture/issues/1263 https://github.com/substance/texture/issues/1261