Group author support

[michael]

Here's our latest proposal, for modelling group authors in combination with regular authors:

<contrib-group>
  <!-- regular author -->
  <contrib contrib-type="person" equal-contrib="yes" corresp="yes" deceased="no">
    <name>
        <surname>Schaffelhofer</surname><given-names>Stefan</given-names>
    </name>
    <email>stefan@schaffelhofer.com</email>
    <xref ref-type="aff" rid="aff24" />
    <!-- Associate with award-group -->
    <xref ref-type="award" rid="fund1" />
  </contrib>

  <!-- group author with members -->
  <contrib contrib-type="group" equal-contrib="yes" corresp="no" deceased="no">
    <collab>
      <named-content content-type="name">The Mouse Genome Sequencing Consortium</named-content>
      <xref ref-type="aff" rid="aff2"/>
      <xref ref-type="award" rid="fund1" />
      <contrib-group contrib-type="group-member">
        <contrib contrib-type="person">
          <name>
            <surname>Kelly</surname><given-names>Laura A.</given-names>
          </name>
          <!-- role can be used to group members into subgroups, note that role element
          is used on contrib level not contrib-group level. -->
          <role>Writing Group</role>
          <xref ref-type="aff" rid="aff2"/>
        </contrib>
        <contrib contrib-type="person">
          <name>
            <surname>Randall</surname><given-names>Daniel Lee</given-names>
            <suffix>Jr.</suffix>
          </name>
          <role>Lab Group</role>
          <xref ref-type="aff" rid="aff3"/>
        </contrib>
      </contrib-group>
    </collab>
  </contrib>
</contrib-group>

UI Proposal (QC Panel):

Requirements to sign off (according to sample above):

• [ ] Find agreement on roles for group members (spec proposal ok?)
• [ ] Consider present addresses of authors (and groups? can we model this as affiliations like present affiliation? #561)
• [ ] Groups can have affiliations, as well as group members
• [ ] Affiliations of group members must not go into main affiliation list
• [ ] Associate authors with grant numbers #551 (see spec proposal above)

Requests (by Texture developers):

• Can we avoid multiple email addresses per author? this complicates UI/UX; shouldn't there be a primary email for correspondence?

[Melissa37]

If keeping it simple is important, I'd suggest equal contribution option be dropped from group author if this is causing complexity on the UI side.

Not all group authors have members of the group listed out. Some group authors are simply a group author name and an affiliation.

The reason why members of a group are listed out (not in the author list but associated with it) is generally to give individuals credit for contribution to a paper, beyond being mentioned (and not explicitly tagged) in the acknowledgments, but they are not "primary" authors in their own right. I think the main reason in our area is that you can search for these individual authors on PubMed and the paper in which they are a member of a group author comes up.

Here is a perfect example of how your chosen method of affiliation tagging as an xref does not work :-) If a member of the group has an affiliation that is not shared by primary authors, their affiliation does not belong in the main affiliation list. It cannot go there. If a publisher lists members of a group and allows them their own affiliations, those affiliations have to be separate from the main affiliation list.

I hope that helps?

[michael]

Thank you @Melissa37 !

Good suggestions. Regarding your last point, I think the correct way to derive the main affiliations list is going through the list of authors and capture only those. What we can do is putting something like a specific-use=primary attribute to mark those main affiliations explicitly.

[michael]

Group says:

• allow group author names + people of that group
• no subgroups
• no affiliations for groups

[michael]

eLife examples:

... from #552

Dummy example, email on member:

<contrib contrib-type="author" equal-contrib="yes" corresp="yes">
                    <collab>eLife Technology Group
                    <contrib-group>
                        <contrib>
                            <name>
                        <surname>Nott</surname>
                        <given-names>Graham</given-names>
                    </name>
                    <aff>
                        <institution>Graham Nott Enterprises</institution>
                        <addr-line>
                            <named-content content-type="city">Victoria</named-content>
                        </addr-line>
                        <country>Canada</country>
                    </aff>
                </contrib>
                        <contrib>
                            <name>
                                <surname>Wilkinson</surname>
                                <given-names>Chris</given-names>
                            </name>
                            <email>c.wilkinson@elifesciences.org</email>
                            <contrib-id contrib-id-type="orcid"  authenticated="true">https://orcid.org/0000-0003-4921-6155</contrib-id>
                            <aff>
                                <institution>eLife</institution>
                                <addr-line>
                                    <named-content content-type="city">Cambridge</named-content>
                                </addr-line>
                                <country>United Kingdom</country>
                            </aff>
                        </contrib>
            </contrib-group>
            </collab>
                    <xref ref-type="aff" rid="aff2">2</xref>
                    <xref ref-type="fn" rid="equal-contrib2">&#x2021;</xref>
                    <xref ref-type="other" rid="fund2"/>
                    <xref ref-type="fn" rid="conf3"/>
                    <xref ref-type="fn" rid="con4"/>
</contrib>

Live example, corresponding author with multiple email addresses:

<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><aff><institution>Science
                                        Exchange</institution><addr-line><named-content
                                            content-type="city">Palo
                                        Alto</named-content></addr-line><country>United
                                        States</country></aff></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><aff><institution>Center
                                        for Open Science</institution><addr-line><named-content
                                            content-type="city"
                                        >Charlottesville</named-content></addr-line><country>United
                                        States</country></aff></contrib><contrib
                                contrib-type="author"
                                        ><name><surname>Williams</surname><given-names>Stephen
                                        R</given-names></name><aff><institution>Center for Open
                                        Science</institution><addr-line><named-content
                                            content-type="city"
                                        >Charlottesville</named-content></addr-line><country>United
                                        States</country></aff></contrib><contrib
                                contrib-type="author"
                                        ><name><surname>Perfito</surname><given-names>Nicole</given-names></name><aff><institution>Science
                                        Exchange</institution><addr-line><named-content
                                            content-type="city">Palo
                                        Alto</named-content></addr-line><country>United
                                        States</country></aff></contrib><contrib
                                contrib-type="author" id="author-16276"
                                        ><name><surname>Errington</surname><given-names>Timothy
                                        M</given-names></name><contrib-id contrib-id-type="orcid"
                                    authenticated="true"
                                    >http://orcid.org/0000-0002-4959-5143</contrib-id><aff><institution>Center
                                        for Open Science</institution><addr-line><named-content
                                            content-type="city"
                                        >Charlottesville</named-content></addr-line><country>United
                                        States</country></aff></contrib></contrib-group></collab>
                    <xref ref-type="other" rid="fund1"/>
                    <xref ref-type="fn" rid="con2"/>
                    <xref ref-type="fn" rid="conf2"/>
                </contrib>

[michael]

Hi @substance/texture-contributors and especially @Melissa37 and @JGilbert-eLife. I've spent time to study the requirements for group authors and I've come up with more complete example that covers the requirements described in the main issue text. I've also come up with user interface mockup that fulfills QC requirements.

Please have a close look and let me know what's missing. This is one of the most challenging topics to get right in terms of data modelling and UI. So I hope we can sign this off and start implementing this as the first QC-Panel.

Looking forward to your feedback! :)

[Melissa37]

@gmaciocci and @JGilbert-eLife can we chat about this?

[Melissa37]

We've chat chatted about this in eLife and think a call with @JGilbert-eLife and @gmaciocci would be good. @michael could you do a call with them on Friday afternoon?

[michael]

Hey @Melissa37 yes we can do Friday. Not too late if possible. :)

[michael]

@Melissa37 I guess for group authors we don't need the equal-contrib, deceased, corresp attributes right?

[JGilbert-eLife]

Hi @michael - Melissa's out of the office today so I thought I should jump in. I can certainly do a call on Friday; not sure what time would be good for @gmaciocci as he's out as well. I'll check with him tomorrow.

From our discussion earlier this week, we might actually want the extra tags you mention after all, since we're erring towards a different way of handling group authors in the XML.

[michael]

Ok, let's discuss in the call then.

[JGilbert-eLife]

Hi again @michael - @gmaciocci is free from 14:00-16:00 UK time tomorrow. Would 14:00 UK time work for you?

James

[michael]

Hi @JGilbert-eLife @gmaciocci! 14:00 UK time works fine. Can you send a calendar invite to everyone?

[JGilbert-eLife]

Few quick notes from the call today:

• Change the way in which group authors work so that each member of a group author is added in an identical fashion as a 'main' author (with all the same information) and is then added to an author group.
• This would require the creation of a batch operation function so that multiple authors could be selected and have some property applied or changed. This would also work very well for adding affiliations to multiple authors, adding multiple authors to a funder etc etc
• The above changes would flatten the UI, removing the hierarchy of group author -> group author member, but there would still need to be mapping to a hierarchy in the XML e.g.

  <contrib contrib-type="author">
                  <collab>Group author name<contrib-group>
                                      <contrib contrib-type="author">
                                      ....
                                      </contrib>
                                      <contrib contrib-type="author">
                                      ....
                                      </contrib>
                                      ....
                  </collab>
  </contrib>

• Giuliano outlined the idea of having a compact view (a list of capsules, one for each author) vs an expanded view for editing. Batch operations could be performed on the compact view, then individual edits could be made on the expanded view. (side note - each capsule would display all the author information for each author, and this sounds like something that could easily be enhanced to allow author order to be adjusted, dragging and dropping capsules up and down the list)

[michael]

If we use the flat UI with tagging as proposed, we won't be able to model sub-groups. Is that still a requirement, or could we challenge that?

[JGilbert-eLife]

That was one thing we forgot to say; we think if we model members of groups as normal authors, we can handle the sub-groups by means of the author contributions, since that's basically all that sub-groups are - ways of demonstrating different contributions from different segments of the group.

I would say that idea might be affected by any effort JATS4R puts into groups, but for now, we're happy to proceed without sub-groups.

[Now posted from the correct account!]

[michael]

Contribution is modelled using the <role> element right?

[JGilbert-eLife]

No, it's modelled using footnotes:

<contrib contrib-type="author">
....
                    <xref ref-type="fn" rid="con2"/>
....
</contrib>

<fn-group content-type="author-contribution">
                <title>Author contributions</title>
                <fn fn-type="con" id="con1">
                    <p>Completed the XML mapping exercise and wrote this XML example</p>
                </fn>
                <fn fn-type="con" id="con2">
                    <p>Contributed to the XML mapping exercise and quality checked all the tagging and content</p>
                </fn>
                <fn fn-type="con" id="con3">
                    <p>Reviewed the PDF product</p>
                </fn>
</fn-group>

In our case, the content of each contribution footnote is populated from preset text, though we allow free-form text to be appended to the preset options.

[michael]

To be able to assign multiple contribution descriptions to one author will make the UI quite complex (same as associating affiliations etc.). I wonder if we could just have one contribution field per author (e.g. role) that could become easier. Is it an option?

[JGilbert-eLife]

I should have been clear that there is only ever one contribution footnote per author. (Although saying that there probably needs to be a wider discussion about contributions with @Melissa37).

The role tag is not really appropriate for contributions because it means something else - it's basically a title rather than a list of what the person actually did. At present, I don't think JATS has a single tag for contributions. They recommend the footnote method instead.

[michael]

I see. Hm, too bad there's no element. Do you use the <role> tag at eLife?

[michael]

Here's another attempt on the UI (using a flat structure).

Considerations:

• All field values are editable directly (no extra click needed to switch context to edit mode)
• Only required and filled out fields are shown by default (more compact cards); can be expanded so all available fields are shown
• no batch actions modelled yet: think we could add them later, as it's a bit hard to program those workflows, and we should not optimise for the edge cases (very long author lists) first

Generally I think flattening group authors during editing makes the interface much cleaner. Only concern: It may be hard to mentally map the picture you see in the editing interface to how it's gonna be presented eventually. Like you need to somehow understand how a long list of authors maps to a shorter list of authors and groups. But maybe this is acceptable.

Let me know your thoughts. We won't reach a perfect state next week, but it would be nice if we could achieve a first functional version and let some people try it out.

[michael]

Maybe after assigning a regular author to a group, we could group them together visually and use a different rendering so the user can see how things will appear on the paper.

(maybe not so trivial to implement such a custom interface... but curious what you think)

[JGilbert-eLife]

Hi @michael - very sorry for the delay in replying.

• eLife uses <role> to denote specific kinds of editor, e.g. 'Reviewing editor':

            <contrib-group content-type="section">
                <contrib contrib-type="editor" id="author-10">
                    <name>
                        <surname>Collings</surname>
                        <given-names>Andrew</given-names>
                    </name>
                    <role>Reviewing Editor</role>
                    <aff>
                        <institution>eLife Sciences</institution>
                        <country>United Kingdom</country>
                    </aff>
                </contrib>
</contrib-group>

• The new interface looks like a good start to me. I think I'm perhaps having a little trouble imagining how it will work without being able to click around and see, however, so I might have more feedback after doing that.
• I'd agree that grouping the authors visually sounds like a good idea, if it can be done.

[michael]

@JGilbert-eLife we will soon be able to provide a clickable prototype (end of week I hope).

Could you discuss at eLife wether it would be feasible to use the role element to hold a contribution instead of the xref strategy. I'd propose this tagging (at least until there's a dedicated contribution tag)

<contrib>
  <role content-type="role">Researcher</role>
  <role content-type="contribution">Completed the XML mapping exercise and wrote this XML example </role>
</contrib>

[JGilbert-eLife]

Hi @michael - I understand that the JATS4R group is currently discussing contributions, so I think we need to wait for them to complete their recommendation before we can make a decision on this.

Looking forward to the prototype!

[fabiobatalha]

@michael @JGilbert-eLife @Melissa37

The <collab> element allows the use of <fn> elements. It may help to solve the issue of xrefs between authors and fn-contribution.

The bad thing is that the use of <collab> will become overloaded.

<contrib-group>
  <contrib contrib-type="author">
    <collab collab-type="contributor">
      <fn fn-type="con">
          <p>Completed the XML mapping exercise and wrote this XML example</p>
      </fn>
      <fn fn-type="con">
          <p>Contributed to the XML mapping exercise and quality checked all the tagging and content</p>
      </fn>
    </collab>
    <name>
      <surname>Collings</surname>
      <given-names>Andrew</given-names>
    </name>
    <role>Reviewing Editor</role>
    <aff>
      <institution>eLife Sciences</institution>
      <country>United Kingdom</country>
    </aff>
  </contrib>
</contrib-group>

[dalapeyre]

I realize that I am new to this group, so forgive me if this is all settled and I am speaking out of turn.

The initial example in this thread confused me. The contrib-type attribute in JATS is made to describe the 'type of contribution' made by the individual (for example, “author”, “editor”, “translator”, “research-assistant”. "photographer", "genome-sequencer") so "person" or "group" does not make sense to me. Thankfully, this idea seemed to be dropped.

The final example makes a bit more sense, in that I understand both contrib and collab type attributes, but a collaboration, as defined in JATS, is a group such as Lab or named individuals. This collab describes a single person and contains a bunch of footnotes. Excuse me? If the collab is just a workaround to get footnotes into a contrib, then xref elements pointing to footnotes are allowed inside a contrib. The footnotes themselves can be elsewhere.

Sorry, what am I missing?

[Melissa37]

@michael @JGilbert-eLife I think I can safely say at this point that what eLife determines as author contributions will be using role in the future, as per your request Michael :-) See below JATS4R proposal tagging (This has not yet been reviewed or gone out for public comment, but the updates in the recent DTD point to this as being the most appropriate tagging:

<contrib-group>
    <contrib>
        <string-name><given-names>Barbara</given-names>
            <surname>Johnston</surname></string-name>
        <role vocab="CRediT" vocab-identifier="http://dictionary.casrai.org/Contributor_Roles" vocab-term="Conceptualization" vocab-term-identifier="http://dictionary.casrai.org/Contributor_Roles/Conceptualization"> study designer</role>
    </contrib>
    <contrib>
        <string-name><given-names>Brooke</given-names>
            <surname>Jackson</surname></string-name>
        <role vocab="CRediT" vocab-identifier="http://dictionary.casrai.org/Contributor_Roles" vocab-term="Writing - Original Draft" vocab-term-identifier="http://dictionary.casrai.org/Contributor_Roles/Writing_%E2%80%93_original_draft"> writer</role>
    </contrib>
</contrib-group>

@JGilbert-eLife we'll need to think about non-Credit contributions and how we prevent them from getting mixed up with other <roles>

[JGilbert-eLife]

My immediate question is, does this allow multiple roles per author? I've not seen any examples of multiple role elements in a single contrib block.

[Melissa37]

@JGilbert-eLife Yes.

[dalapeyre]

I agree. Contributors can take multiple roles.

It would be perfectly possible to tag three role elements:

• author
  • Completed the XML mapping exercise and wrote this XML example
  • Contributed to the XML mapping exercise and quality check

[obuchtala]

Ok, thanks. This is on the radar, but not implemented yet.

[dalapeyre]

Good to hear will be used.

================================================================ Deborah A Lapeyre mailto:dalapeyre@mulberrytech.com Mulberry Technologies, Inc. https://www.mulberrytech.com 17 West Jefferson Street Phone: 301-315-9631 (USA) Suite 207 Fax: 301-315-8385 Rockville, MD 20850

Mulberry Technologies: Consultancy for XML, XSLT, and Schematron

[JGilbert-eLife]

Unfortunately, @michael , @oliver----, the UI for Group authors is not working as we need it to - the group is not being displayed in the author list and the members of the group are. I think there may still be a gap in understanding of what is needed here, though I think individual elements of the interface could work. I guess we might need to have another call/discussion on this!

Do we want to keep this in this issue, or should the UI and the XML be split out into separate issues?

[michael]

We have a lot of topics mixed up here. In our new requirements document I will track separate positions for role (aka contribution) and Group Authors generally. I'll send the document by end of week for review.

[Melissa37]

@michael great, thanks!

[michael]

Tracked in requirements document.