jats_publishing: author affiliation is missing?

[denismaier]

The author affiliation is missing in the current jats templates. Is that on purpose?

See:

pandoc/data/templates/article.jats_publishing

Line 88 in 34151e8

$if(author.email)$

It currently reads:

$if(author.email)$
<email>$author.email$</email>
$endif$
$if(author.aff-id)$
<xref ref-type="aff" rid="aff-$contrib.aff-id$"/>
$endif$

Shouldn't that be:

$if(author.email)$
<email>$author.email$</email>
$endif$
$if(author.affiliation)$
<aff>$author.affiliation$</aff>
$endif$
$if(author.aff-id)$
<xref ref-type="aff" rid="aff-$contrib.aff-id$"/>
$endif$

Should I start a PR, or am I missing something?

[jgm]

I don't know a lot about JATS -- pinging @tarleb, @mfenner.

[tarleb]

Might be an oversight, but I'm not sure. Could also be because there is no commonly accepted way of specifying this info, or because adding the same affiliation repeatedly would be undesirable. A separate, top-level affiliation field would probably be better to avoid duplication. Beamer, on the other hand, uses institute instad of affiliation, so that could lead to confusion. Maybe the current state is the result of having no clear solution to all that.

This is probably a good place to mention a new effort to agree on a method to specify this kind of metadata in YAML headers: https://github.com/jam-schema/jams. @mfenner already pointed us to https://github.com/datacite/bolognese which could be extremely handy in this context.

[hubgit]

It does seem to be a bug/oversight that the affiliation is referenced by id (the rid attribute) but not added to the output. I'd expect author.aff-id to be an array of affiliation identifiers, as well.

The affiliations should be listed separately in aff elements, ideally inside the article-meta element.

An alternative would be to add each author's affiliations in aff elements inside the relevant author's contrib element, in which case they don't need identifiers.

[hubgit]

I've had a go at this, but it's not particularly easy as the data model isn't really there yet.

I think the document needs a list of affiliations, each with a label and address property, and each author needs to be an object rather than a string, with a name property and a list of cross-references, each being the label of a referenced affiliation (or author note, or other referenced item).

The authblk package can then be used in the LaTeX template, and the data will be preserved enough for writing back out to JATS.

\author[1,*]{Alice Author}
\author[2]{Bob Author}
\author[1,2,+]{Christine Author}
\author[2,+]{Derek Author}
\affil[1]{Affiliation, department, city, postcode, country}
\affil[2]{Affiliation, department, city, postcode, country}

\affil[*]{corresponding.author@email.example}

\affil[+]{these authors contributed equally to this work}

[denismaier]

An alternative would be to add each author's affiliations in aff elements inside the relevant author's contrib element, in which case they don't need identifiers.

That's what I have in my local template currently. Looks like the easiest solution to me.

[hubgit]

I think I'd like to see the JATS reader normalise the affiliations so that they're all items under an affiliation property, referenced by id from an author.affiliation property:

affiliation:
  a: Affiliation A
  b: Affiliation B
author:
 - name: Author 1
   affiliation: [a]
 - name: Author 2
   affiliation: [a, b]

That would allow the template used by the JATS writer to choose whether to group the affiliations all together, referenced from each author, or to add the affiliations directly to each author by getting the value from affiliation using the id.

As for author names, affiliations would need to be allowed to be either a string or an object with separate fields for department, institution, etc.

[tarleb]

It seems that the JATS reader populates the institute metadata field with the equivalent of

institute:
  - Affiliation A
  - Affiliation B

but does not preserve any link between authors and their affiliation.

[tarleb]

Please have a look and comment on #6867.
The data model is close to what has been suggested by @hubgit, with one exception: affiliations must be given as arrays, not maps. Identifiers have to be specified via an id field. This is done for technical reasons.
For more details, see the proposed changes to doc/jats.md in that PR.

[jgm]

@tarleb sorry I merged the PR before seeing from this issue that you wanted comment.
Comments still would be good; we can always have a new PR to revise if needed.

[denismaier]

Sorry for being so late to the party. I'll try to do some testing and come back to this then.