Author affiliations

[fred-atherden]

Description

Structured affiliation information (department, institution, city, country).

User stories

Author

• (1) As an author, I want to be able to clearly see which affiliations are associated with an author so that I can check this information is correct.
• (2) As an author, I want to be able to see which authors are associated with an affiliation so that I can check they have been correctly assigned.
• (3) As an author, I want to be able to add or remove affiliations from an author so that I can correct any errors in affiliation attribution.
• (4) As an author, I want to be able to add or remove authors from an affiliation so that I can correct any errors in affiliation attribution.
• (5) As an author, I want to be able to edit an affiliation so that I can correct any errors.
• (6) As an author, I want to be able to create a new affiliation and associate it with existing authors so that I can correct affiliation information.
• (7) As an author I want to be able to delete affiliations so that I can remove any added in error.

Production staff

• (8) As production staff, I want to be able to clearly see the divisions between different parts of an affiliation so that I can check it has been structured correctly.

But what if . . . ?

Considerations

• We will have a list of authors and a list of multiple affiliations (in most cases) with a many-to-many relationship between them.
• Different journals divide affiliations up in different ways. eLife uses Department, Institution, City, and Country. Érudit will be using the more generic Organisation division 1, Organisation division 2, Organisation division 3 . . ., Organisation name, City, Country.
• The consortium has agreed to place affiliations within the contrib-group containing the authors, rather than outside it, and to using xref linking to connect authors to affiliations. This tagging will be use for non-author contrib-groups as well. E.g. for every contrib-group, there will be a unique set of affiliations.
• For eLife, we order the affiliations based on the order in which the authors appear e.g. the first author's affiliation will be aff1, the second authors' affiliation will be aff2 etc. [ translation layer ]
• Given the requirement that each ID be unique, affiliation IDs in other contrib-groups should follow on from the IDs in the author/first contrib-group.
• eLife adds labels to affiliations for PDF and PMC display. Érudit and other publishers do not do this. [ translation layer ]

XML requirements

<contrib-group content-type="author">
       <contrib>
              <name>
                     <surname>Surname</surname>
                     <given-names>First-name Middle name</given-names>
              </name>
              <xref ref-type="aff" rid="aff1">1</xref>
              <xref ref-type="aff" rid="aff2">2</xref>
              ...
       </contrib>
       <aff id="aff1">
              <label>1</label>
              <institution content-type="dept">Department of Production</institution>
              <institution>eLife</institution>
              <addr-line>
                     <city>Cambridge</city>
              </addr-line>
              <country>United Kingdom</country>
       </aff>
       <aff id="aff2">
              <label>2</label>
              <institution content-type="dept">Department of Technology</institution>
              <institution>eLife</institution>
              <addr-line>
                     <city>Cambridge</city>
              </addr-line>
              <country>United Kingdom</country>
       </aff>       
</contrib-group>      

The above example includes the eLife way to break affiliations down, using an institution[@content-type="dept"] and institution element.

Texture also needs to account for affiliations that can be broken down using orgdivX and orgname values for @content-type. For example:

<aff id="aff1">
      <institution content-type="orgname">German Primate Center GmbH</institution>
      <institution content-type="orgdiv1">Neurobiology Laboratory</institution>
      <city>Göttingen</city>
      <country>Germany</country>
</aff>

Mock ups

Proposal

[michael]

Looking good. I think we already address this (except for the translation layer requirements). Could you verify if the following fields we use currently are sufficient:

Organisation.schema = {
  institution: STRING,
  division1: STRING,
  division2: STRING,
  division3: STRING,
  addressLine: STRING,
  addressLine2: STRING,
  city: STRING,
  state: STRING,
  postalCode: STRING,
  country: STRING,
  phone: STRING,
  fax: STRING,
  email: STRING,
  uri: STRING
}