Ability to add present addresses

[JGilbert-eLife]

This is another enhancement that would definitely not be just eLife specific - we need the ability to add present addresses as well as main affiliations.

We include these as footnotes to the authors, link xref included in contrib.

 <xref ref-type="fn" rid="pa1">&#167;</xref>

               <fn fn-type="present-address" id="pa1">
                    <label>&#167;</label>
                    <p>Department of Wellcome Trust, Sanger Institute, London, United Kingdom</p>
</fn>

[michael]

@substance/texture-contributors are present addresses a requirement to all of you?

Suggestion: If we need this, it would be better to capture the info using an address element rather than a footnote, which does not carry semantics.

[michael]

This is how it would look like:

  <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>
    <!-- address with same fields as aff spec -->
    <address>
      <institution content-type="orgname">German Primate Center GmbH</institution>
      <institution content-type="orgdiv1">Neurobiology Laboratory</institution>
      <institution content-type="orgdiv2"></institution>
      <institution content-type="orgdiv3"></institution>
      <addr-line content-type="street-address">Hauptstrasse</addr-line>
      <addr-line content-type="complements"></addr-line>
      <city>Göttingen</city>
      <state></state>
      <postal-code></postal-code>
      <country>Germany</country>
      <phone></phone>
      <email></email>
    </address>
  </contrib>

NOTE: for a proper address record we need a lot of fields, this would clutter the edit author form but is the only way to store correct semantic information. Is there any address fields (according to example) that you are sure you don't need to capture?

[michael]

WAIT... shouldn't we better solve this by assigning an affiliation that has that present address data?

Like in <contrib>:

<xref ref-type="aff" rid="aff1"></xref>
<xref ref-type="aff" rid="aff2" specific-use="present-address"></xref>

Advantage would be that we don't clutter the edit author form so much. We'd not show that present-address affiliation in the main affiliation list, but still use the same mechanism for data keeping.

@substance/texture-contributors thoughts?

[JGilbert-eLife]

Absolutely agree about capturing this in affiliation tagging - for us, there's generally no difference in the kind of information we're capturing for affiliations and present addresses. However, I think the distinction between the two needs to be captured within a present address aff, not in the xref.

I think it would be relevant for both final display and data mining efforts to be able to distinguish whether an aff is a main affiliation or a present address. I know most journals display these two kinds of addresses in different ways (though not always separately) and since only institutions listed as main affiliations can generally claim ownership of the work done in an article, it's probably worth being able to distinguish whether an extracted address is a main affiliation or a present address.

It's also worth noting that in my experience, it's not usual for a present address to also be a main affiliation, although it does happen. In that regard, there's little to be gained by making the distinction at the level of the xref within contrib.

[michael]

Thank you @JGilbert-eLife very helpful!

How would you attach that info to the aff element then. If I understand correctly we need two flags:

• is main affiliation
• is present address

(sometimes both is true)

Can you provide an example tagging?

[JGilbert-eLife]

Taking you're suggestion from above using specific-use, I'd suggest something like (with labels included for PDF requirements):

Main affiliation:

<aff id="aff1" specific-use="main-affiliation">
          <label>1</label>
          <institution content-type="dept">Department of Biology</institution>
          <institution>University of Tübingen</institution>
          <addr-line>
                    <named-content content-type="city">Tübingen</named-content>
          </addr-line>
          <country>Germany</country>
</aff>

Present address:

<aff id="pa1" specific-use="present-address">
          <label>&#167;</label>
          <institution content-type="dept">BioMedicine Design</institution>
          <institution>Pfizer Inc.</institution>
          <addr-line>
                    <named-content content-type="city">Cambridge</named-content>
          </addr-line>
          <country>United States</country>
</aff>

This would then be cross-referenced from the author name as

<contrib contrib-type="author" id="author-00002">
          <name>
                    <surname>Gilbert</surname>
                    <given-names>James F</given-names>
          </name>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="pa1">1</xref>
          <xref ref-type="fn" rid="conf1"/>
          <xref ref-type="fn" rid="con1"/>
</contrib>

This seems to most straightforward solution from the XML point of view. It would mean that is some cases we have the same details present once as a main affiliation and a second time as a present address - though this should be rare - but I think this would be appropriate insofar as we probably don't want an aff tagged as both a present address and a main affiliation.

I'd definitely like to propose that the IDs follow separate patterns (aff1, aff2, aff3; pa1, pa2, pa3) for ease of distinction.

[michael]

That's an ok solution I think. I just thought if we had the specific use on the xref we could elegantly solve the case where present-address = main affiliation. For Texture we have an internal JS API (I'm just documenting this) and then we could replicate that structure to the XML.

Here's how the internal JSON record looks like:

  {
    id: 'author1',
    type: 'person',
    surname: 'Schaffelhofer',
    givenNames: 'Stefan',
    suffix: 'Phd',
    email: 'stefan@schaffelhofer.com',
    // affiliations related to this paper
    affiliations: ['aff1'],
    presentAffiliation: 'aff1',
    // awards related to this paper
    awards: ['fund1'],
    equalContrib: true,
    corresp: true,
  },

[michael]

You used a different tagging for aff elements. The latest Dar proposal looks like this:

https://github.com/substance/dar/blob/master/DarArticle.md#aff

[michael]

Tracked in requirements document. Closing.