Status: Published
Version: 1
License: this recommendation document is licensed under CC BY-ND 2.0
DOI: https://doi.org/10.3789/niso-rp-39-2021
ISBN: (13): 978-1-950980-12-3
Provenance
JATS4R subgroup. Subgroup members (listed in alphabetical order):
Rachel Carriere, EBSCO; Alf Eaton, Atypon; Stephen Flockton, IOPP; David Haber, ASM; Melissa Harrison, eLife (Chair); Melissa Jones, Silverchair; Alex Mendonça, SciELO; Rob O’Donnell, RUP; Sally Ubnoske, Aries; Cinthia Vieira, SciELO; Tina von Raesfeld, PLOS; Jonathan Watson, Emerald; Jeffrey Beck, NCBI;
Special guest help: Tiago Barros, Publons; Thomas Lemberger, Review Commons; Patricia Feeney, Crossref
Context
JATS 1.1 and earlier
<article>, <sub-article>, <front-stub>, <related-object>, <article-id>, <history>, <date>, <contrib>, <contrib-id>, <anonymous>, <role>, <article-title>, <custom-meta-group>, <meta-name>, <meta-value>, <title>, <anonymous/>
@article-type, @pub-id-type @contrib-type, @date-type, @contrib-id-type, @specific-use, @content-type, @xml:lang, @document-id-type, @document-type, @link-type, @source-id @source-id-type
JATS 1.2
<article>, <sub-article>, <front-stub>, <related-object>, <article-id>, <pub-history>, <event>, <event-desc>, <contrib>, <contrib-id>, <anonymous>, <role>, <article-title>, <custom-meta-group>, <meta-name>, <meta-value>, <title>, <anonymous/>
@article-type, @pub-id-type @contrib-type, @event-type, @contrib-id-type, @specific-use, @content-type, @xml:lang, @document-id-type, @document-type, @link-type, @source-id @source-id-type
Elements and attributes highlighted in bold indicate these are new to this version of the DTD.
Description
As the publication of peer review materials is increasing traction within scholarly content publication workflows this recommendation is designed to provide some guidance for how to tag this material using JATS. It is anticipated that as this practice increases this recommendation will require updating as new requirements emerge. This working group collaborated closely with Crossref and The STM Taxonomy working group, and based the initial work on their schema and taxonomy, respectively, although it is anticipated that they will also be updated in light of future adoption and changing publishing models. DocMaps has also provided some mapping from their schema to this, see here.
Please note we use the term reviewer throughout this document to map to the STM taxonomy, although some may be more familiar with the term referee, which is used by the Crossref schema. When delivering content to Crossref there should be a simple mapping from reviewer to referee.
The working group also had guest contributions from Publons and Review Commons, which gave important context to some situations.
Many philosophical as well as practical use-cases meant that sometimes the discussions steered away from pure JATS and JATS4R XML requirements. In the context of this recommendation this was important because publishing peer reviews is an emerging topic that hinges on emerging and changing publishing practice.
We also examined the main use cases for publishing peer review materials:
- Transparency in the peer review process.
- Ability for reviewers to gain credit for this work.
- Ability to cite peer review materials to support/refute research conclusions.
As such, some of our recommendations reflect publishing practices and are not based on pure XML requirements:
- The original working group that created the paper published at F1000 (see below) selected <related-article> as the method of linking peer review materials published as different documents. However, many platforms expect content using <related-article> tagging to be published on the same platform. Platforms for peer review materials, such as Publons, are used by many publishers and so this could cause a blocker to uptake. Therefore <related-object> was chosen instead to allow uptake of this recommendation.
- If the review exists elsewhere with another DOI, we recommend that you use that DOI and link to it from the parent XML document or from within the <sub-article> if there is other peer review material(s) being published, otherwise you may reproduce the content and register your own DOI.
- It is not yet clear whether standards will emerge for licensing of content from peer review platforms such as Review Commons or review transfers from other journals. At this time the recommendation cannot provide guidance on how to negotiate, manage and source this information.
Additional reading
Beck J, et al. Publishing peer review materials [version 1; referees: 2 approved] F1000Research 2018, 7:1655 (https://doi.org/10.12688/f1000research.16460.1)
Lin J. Peer review publications 2018. https://www.crossref.org/blog/peer-review-publications/
Crossref. Introduction to peer reviews. https://support.crossref.org/hc/en-us/articles/115005255706-Peer-Reviews
Publons. https://publons.com/about/home/
Jones, L., van Rossum, J., Mehmani, B., Black, C., Kowalczuk, M., Alam, S., Larkin, A. (2020, September 29). A Standard Taxonomy for Peer Review . Retrieved from osf.io/68rnz
Stein, G. DocMaps JATS4R Peer Review Materials Comparison. Doc Maps. Retrieved from https://docmaps.knowledgefutures.org/pub/8i39lrr6
Recommendation
This is a very comprehensive list of tagging recommendations. It is designed to cater to a range of use, from those who are publishing peer review materials as a single PDF with minimal XML tagging to those who are publishing their peer review materials as full text XML. For those not actually publishing peer review materials but wishing to indicate on the article that reviews were received from outside the specific journal please follow only the Parent article document guidance below.
Peer review documents
Minimal requirements: points 1 -11. Thereafter we provide further guidance should a publisher wish to include additional information and metadata
- <sub-article> or <article>. There are two ways in which peer review materials may be published – as <sub-article> (s) (sub-articles) of the research article they are related to OR as separate <article>(s) (independent articles). We have indicated where the recommendation differs for each of these options below.
- <front-stub>. When using <sub-article>, use <front-stub> to contain the metadata associated with the <sub-article>; if using <article>, the corresponding metadata will be held in <article-meta>.
- @article-type value (on
or ) MUST come from the following controlled values list: - reviewer-report
- editor-report
- author-comment
- community-comment
- aggregated-review-documents
[[Validator tool result: if @article-type is unallowed version of one of the controlled values (eg refereereport, Referee_report, reviewerreport, Reviewer_report, Reviewer-report) ERROR]]
- @xml:lang on <article> and <sub-article> SHOULD be used if a <sub-article> is in a different language to the main journal article it refers to or if the peer review material is published as another <article> and is in a different language to the main journal article it refers to.
- <article-id>. <article-id pub-id-type=”doi”> MUST be present.
Note: It is expected that peer review content published elsewhere with a DOI already assigned will not be republished and will instead be linked to with a <related-object>.
[[Validator tool result: if <article-id pub-id-type=”doi”> is missing ERROR]]
- <contrib>. <contrib> (within <contrib-group>) is REQUIRED.
[[Validator tool result: if no <contrib> found ERROR]]
- @contrib-type on <contrib> MUST reflect the contributor’s contribution to the document, not the role in the review process. It is assumed that “author” will be the value.
[[Validator tool result: if @contrib-type value is not “author” WARNING]]
- <anonymous/> is REQUIRED if capturing a <contrib> that is unnamed.
- There could be one <contrib> for each anonymous contributor.
Note: This data can be used to count the number of contributors in each role (eg, reviewers) even if they are not named.
- <role>. <role> is REQUIRED for every <contrib> (including <anonymous>)
[[Validator tool result: if <role> is not present in <contrib> ERROR]] - @specific-use on <role> is required and the value must be one of the following:
- reviewer
- reader
- author
- editor
[[Validator tool result: if @specific-use on <role> is missing or does not match a value from the controlled list ERROR]]
JATS4R has no opinion on what you display in the <role> element.
- <article-title> is required but the content within the field is not covered by this recommendation. Crossref guidance has provided suggestions for this (eg “Author response:” prefix before the title of research article) but we pass no comment on this as it is a display term and not related to machine-readability. It is a publisher’s choice.
[[Validator tool result: if <article-title> is not present ERROR]]
- <permissions>. If a <sub-article> is licensed under a different license to the main article OR the peer review material is published as an <article>, licensing information MUST be provided and follow the JATS4R Permissions recommendation.
[[Validator tool result: if peer review material <article> and no <permission> tagging found ERROR]]
- <pub-date>. Each peer review document MUST have a publication date. When tagged as individual articles, the pub-date must be present in the article metadata. When tagged as sub-articles, the peer-review document can have a publication date tagged explicitly in the article metadata or inherit its publication date from the main article.
[[Validator tool result: if <pub-date> is not found in peer review <article> ERROR]]
For dates other than publication date, follow recommendations 17-21 when using JATS 1.2 and later and follow recommendations 22-24 for JATS 1.1 and earlier.
End of minimal requirements
- <related-object> usage for linking (see above):
- If <article> contains editor or reviewer reports, they MUST link to the article they are passing judgement on. If <article> contains author replies, they MUST link to each editor/reviewer report they are addressing, unless that report has not been published. If <sub-article>s are used and arranged as siblings, links between them should be similarly applied, unless the addressed report has not been published.
[[Validator tool result: if <related-object> not found in editor report (@article-type=”editor-report”) or reviewer report (@article-type=”reviewer-report”) <article> ERROR]]
[[Validator tool result: if <related-object> not found in author reply (@article-type=”author-comment”) <article> ERROR]]
[[Validator tool result: if sibling peer review <sub-article>s exist and <related-object> not found in peer review material <sub-article> WARNING]] - If review material is published on another website, <related-object> link(s) SHOULD be used to reference that material.
- If <article> contains editor or reviewer reports, they MUST link to the article they are passing judgement on. If <article> contains author replies, they MUST link to each editor/reviewer report they are addressing, unless that report has not been published. If <sub-article>s are used and arranged as siblings, links between them should be similarly applied, unless the addressed report has not been published.
- <related-object> attributes:
- @document-id MUST be the DOI value, with a @document-id-type value of “doi”
[[Validator tool result: if @document-id-type value of “doi” not found ERROR]]
[[Validator tool result: if @document-id value does not conform to DOI structure ERROR]] - @document-type MUST use one of the following values:
- peer-reviewed-article
- reviewer-report
- editor-report
- author-comment
- community-comment
- aggregated-review-documents
- peer-review-report*
[[Validator tool result: if @document-type value does not match a value from the controlled list ERROR]]
*The “peer-review-report” value allows for generic linking from an author-comment to the report(s) it addresses without having to specifically indicate whether the linked document is an editor-report, reviewer-report(s), or an aggregate of the two types of reports.
- @source-id MAY be added to indicate the source of these reviews, which is especially relevant if being hosted elsewhere, eg “https://reviewcommons.org”
- @source-id-type SHOULD be added if @source-id is present, eg =”url”
- @source-type MAY be added if @source-id is present, eg “preprint-peer-review-host”
- @document-id MUST be the DOI value, with a @document-id-type value of “doi”
For JATS 1.2 and later
- Use <pub-history> and <event> for other dates related to the peer review document.
- <event>. Only one date is allowed in each <event>, but <event> can be repeated.
[[Validator tool result: if <event> contains more than one <date> ERROR]]
- @event-type on
is REQUIRED to indicate the type of event, from a suggested list: - reviewer-report-received
- author-comment-received
- editor-decision-sent
[[Validator tool result: if @event-type on <event> not present in peer review material document ERROR]]
[[Validator tool result: if @event-type does not match a value from the suggested list WARNING]]
- <event-desc>. There is no guidance on the content of this field and whether it is used as it is a display field for the publisher’s discretion. The metadata necessary for machine-readable purposes can be found in the @event-type value.
- <date>. It is expected that the @iso-8601-date attribute will be applied to the date and the seperate <day>, <month> and <year> fields will be used to display the date content.
For JATS 1.1 and earlier
- <history>. For XML using JATS 1.1 and earlier use <history> for other dates related to the peer review document.
- <date>. It is expected that the @iso-8601-date attribute will be applied to the date and the seperate <day>, <month> and <year> fields will be used to display the date content.
- @date-type is used to indicate the type of event, from a suggested list:
- reviewer-report-received
- author-comment-received
- editor-decision-sent
[[Validator tool result: if DTD is JATS 1.1 or earlier and if peer review material document, if @date-type on <date> does not match a value from the suggested list WARNING]]
- <institution> is not required in affiliations, but if included please follow JATS4R recommendation for Authors and affiliations
- Conflict-of-interest (COI) statements are not required, but if included please follow JATS4R recommendation for Conflicts of interest
- <contrib-id> is optional.
- @contrib-id-type on <contrib-id> is required if <contrib-id> is provided. The usual value for this will be “orcid” but other values may be used.
[[Validator tool result: if <contrib-id> present and no @contrib-id-type found ERROR]]
- Reviewer number. To indicate a referee number, use @content-type on <role> with a value of “reviewer-1”, “reviewer-2” and so on.
A <custom-meta-group> can be added to the XML document to include any of the below listed additional information you may wish to add.
- Peer review stage. Whether the peer review was done after publication or before use <custom-meta> with a <meta-name> of “peer-review-stage.” The <meta-value> can be one of two values: “pre-publication” OR “post-publication”.
[[Validator tool result: if <meta-name>peer-review-stage</meta-name> is in the document and corresponding <meta-value> NOT “pre-publication” OR “post-publication”. ERROR]] - Transfer. To indicate that the peer review was transferred from another journal/entity (ie, the single review that is this document) use <custom-meta> with a <meta-name> of “transfer”. The <meta-value> must be “yes”.
[[Validator tool result: if <meta-name>transfer</meta-name> is in the document and corresponding <meta-value> is NOT “yes” ERROR]]
Note: this can only be used if all of the content in the actual <article> or <sub-article> document is a transfer and does NOT contain any additional material that has been added to the process. If this is not the case and you wish to indicate peer review transfers have occurred for this article, please use the <custom-meta> values indicated at the parent article level (see Parent article document, below).
- Transferred from. To indicate where the document was transferred from, add the additional <custom-meta> with the <meta-name> of “transferred-from” and an identifying value for the transfer journal/entity in <meta-value> (use Anonymous if you do not want to identify the transfer journal/entity):
<custom-meta-group> <custom-meta> <meta-name>transferred-from</meta-name> <meta-value>Anonymous</meta-value> </custom-meta> </custom-meta-group>
- Revision round. To indicate the revision round of the peer review materials in the XML, use the following <custom-meta> tagging where the <meta-name> value must be “peer-review-revision-round” and the <meta-value> a numerical digit from 0.
[[Validator tool result: if <meta-name>peer-review-revision-round</meta-name> is in the document and corresponding <meta-value> is NOT a numerical value ERROR]]
Note: Publishers may vary on whether the revision value they apply to author comments refers to 1) the revision with which the comments were submitted or 2) the revision that contains the editor-/referee-reports to which the authors are responding. One can consult the supplied <related-object>s for clarity on the publisher’s approach.
- Recommendation. To indicate the recommendation of the author of the document (i.e., referee-report or editor-report), add the additional
with a of “peer-review-recommendation” and one of the following values in :
- revision
- major-revision
- minor-revision
- reject
- reject-with-resubmit
- accept
- formal-accept
- accept-in-principle
These values represent three broad groups of decisions, i.e. revision, reject and accept. Publishers may choose to add more detail to the three basic decision types using the values shown above. Accept, formal-accept, accept-in-principle all map to the Croosref schema term “accept”.
[[Validator tool result: if <meta-name>peer-review-recommendation</meta-name> is in the document and corresponding <meta-value> is NOT from the value list ERROR]]
- Peer review type. To indicate what type of peer review was done, <custom-meta> is proposed, with a <meta-name> of “PeerReviewType” and a controlled list of values for <meta-values>:
- all-identities-visible
- single-anonymized
- double-anonymized
- triple-anonymized
Note: These values aligned with STM’s A Standard Taxonomy for Peer Review.
[[Validator tool result: if <meta-name>peer-review-identity-transparency</meta-name> is in the document and corresponding <meta-value> is NOT from the controlled values list ERROR]]
Parent article document
A Standard Taxonomy for Peer Review is entering the pilot phase (2020) and so we have aligned the recommendation for the capture of this information on that taxonomy for publishers at the article level. Please see the Taxonomy for the different <meta-values> allowed, here we display one for each of the <meta-names>.
<custom-meta-group>
<custom-meta>
<meta-name>peer-review-identity-transparency</meta-name>
<meta-value>All identities visible</meta-value>
</custom-meta>
<custom-meta>
<meta-name>reviewer-interacts-with</meta-name>
<meta-value>Other reviewer(s)</meta-value>
</custom-meta>
<custom-meta>
<meta-name>review-information-published</meta-name>
<meta-value>Review reports reviewer opt in</meta-value>
</custom-meta>
<custom-meta>
<meta-name>post-publication-commenting</meta-name>
<meta-value>Open</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
Note: the vocabulary attributes are available on <custom-meta> in JATS 1.3d2 or later:
<custom-meta vocab=”A Standard Taxonomy for Peer Review” vocab-identifier=”https://osf.io/aynr5/”>
<meta-name>post-publication-commenting</meta-name>
<meta-value>Open</meta-value>
</custom-meta>
If a publisher wishes to indicate that a research article was transferred from another location (ie, cascade journal, review transfer agreement with another publisher, reviews from another server such as a preprint or Review Commons), we recommend that the publisher add a @specific-use attribute with the value “transfer” on the received date, if they publish this:
<date specific-use="transfer" date-type="received"> <day>29</day> <month>5</month> <year>2019</year> </date>
If the publisher does not publish a received date but wishes to indicate where that transfer came from, and/or wishes to indicate whether reviews were included, we suggest using the following <custom-meta> tagging:
<custom-meta-group> <custom-meta> <meta-name>transfer</meta-name> <meta-value>yes</meta-value> </custom-meta> <custom-meta> <meta-name>transferred-from</meta-name> <meta-value>BMJ Open</meta-value> </custom-meta> <custom-meta> <meta-name>transfer-includes-reviews</meta-name> <meta-value>yes</meta-value> </custom-meta></custom-meta-group>
Note: the second and third <meta-name> and <meta-value> s shown directly above are optional but build on the information provided in the first. This method is suggested if peer review materials are not published but the publisher wishes to internally track or indicate some limited transparency about the review process. There are further instructions on how to indicate this information on the peer review material <article>(s) or <sub-article>(s) themselves in the Peer review documents recommendation. That method provides more specific information at the peer review materials level and is more pertinent to this recommendation, which is about publishing peer review materials themselves.
Examples
Example 1: Minimal requirements for a sub-article
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN" "JATS-archivearticle1.dtd">
<article article-type="research-article" dtd-version="1.2"
xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
...
</front>
<sub-article article-type="reviewer-report">
<front-stub>
<article-id pub-id-type="doi">10.7554/eLife.53404blah</article-id>
<title-group>
<article-title>Peer Review #1 of "The original article title” (v0.1)</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<anonymous/>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
</front-stub>
</sub-article>
</article>
Example 2: Minimal requirements for an article
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN" "JATS-archivearticle1.dtd">
<article article-type="reviewer-report" dtd-version="1.2" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
<journal-meta>
...
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.7554/eLife.53404.sa1</article-id>
<title-group>
<article-title>Review</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<anonymous/>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
<pub-date publication-format="electronic" date-type="original-publication" iso-8601-date="2020-04-04" >
<day>04</day>
<month>04</month>
<year>2020</year>
</pub-date>
<permissions>
<ali:license_ref>http://creativecommons.org/licenses/by/4.0/</ali:license_ref>
</permissions>
<related-object document-id="10.1101/2020.06.22.165035" document-id-type="doi" document-type="peer-reviewed-article"
source-id="https://www.biorxiv.org/" source-id-type="url"/>
</article-meta>
</front>
</article>
Example 3: Maximum requirements for a subarticle
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN" "JATS-archivearticle1.dtd">
<article article-type="research-article" dtd-version="1.2"
xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
...
</front>
<sub-article article-type="reviewer-report">
<front-stub>
<article-id pub-id-type="doi">10.7554/eLife.53404_1</article-id>
<title-group>
<article-title>Reviewer report</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<anonymous/>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
<pub-history>
<event event-type="reviewer-report-received">
<event-desc>Reviewer report received</event-desc>
<date iso-8601-date="2020-02-01">
<day>01</day>
<month>02</month>
<year>2020</year>
</date>
</event>
</pub-history>
<related-object document-id="10.1101/2020.06.22.165035" document-id-type="doi" document-type="peer-reviewed-article"
source-id="https://www.biorxiv.org/" source-id-type="url"/>
<custom-meta-group>
<custom-meta>
<meta-name>peer-review-stage</meta-name>
<meta-value>pre-publication</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transfer</meta-name>
<meta-value>yes</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transferred-from</meta-name>
<meta-value>biorxiv</meta-value>
</custom-meta>
<custom-meta>
<meta-name>peer-review-recommendation</meta-name>
<meta-value>minor-revision</meta-value>
</custom-meta>
</custom-meta-group>
</front-stub>
<body/>
</sub-article>
<sub-article article-type="reviewere-report">
<front-stub>
<article-id pub-id-type="doi">10.7554/eLife.53404_2</article-id>
<title-group>
<article-title>Reviewer report</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<anonymous/>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
<pub-history>
<event event-type="reviewer-report-received">
<event-desc>Reviewer report received</event-desc>
<date iso-8601-date="2020-02-02">
<day>02</day>
<month>02</month>
<year>2020</year>
</date>
</event>
</pub-history>
<related-object document-id="10.1101/2020.06.22.165035" document-id-type="doi" document-type="peer-reviewed-article"
source-id="https://www.biorxiv.org/" source-id-type="url"/>
<custom-meta-group>
<custom-meta>
<meta-name>peer-review-stage</meta-name>
<meta-value>pre-publication</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transfer</meta-name>
<meta-value>yes</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transferred-from</meta-name>
<meta-value>biorxiv</meta-value>
</custom-meta>
<custom-meta>
<meta-name>peer-review-recommendation</meta-name>
<meta-value>accept</meta-value>
</custom-meta>
</custom-meta-group>
</front-stub>
<body/>
</sub-article>
<sub-article article-type="reviewer-report">
<front-stub>
<article-id pub-id-type="doi">10.7554/eLife.53404_3</article-id>
<title-group>
<article-title>Reviewer report</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname>Harrison</surname>
<given-names>Melissa</given-names>
</name>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
<pub-history>
<event event-type="reviewer-report-received">
<event-desc>Reviewer report received</event-desc>
<date iso-8601-date="2020-03-02">
<day>02</day>
<month>03</month>
<year>2020</year>
</date>
</event>
</pub-history>
<related-object document-id="10.1101/2020.06.22.165035" document-id-type="doi" document-type="peer-reviewed-article"
source-id="https://www.biorxiv.org/" source-id-type="url"/>
<custom-meta-group>
<custom-meta>
<meta-name>peer-review-stage</meta-name>
<meta-value>pre-publication</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transfer</meta-name>
<meta-value>yes</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transferred-from</meta-name>
<meta-value>biorxiv</meta-value>
</custom-meta>
<custom-meta>
<meta-name>peer-review-recommendation</meta-name>
<meta-value>major-revision</meta-value>
</custom-meta>
</custom-meta-group>
</front-stub>
<body/>
</sub-article>
</article>
Example 4: Maximum requirements for an article
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN" "JATS-archivearticle1.dtd">
<article article-type="reviewer-report" dtd-version="1.2"
xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
<journal-meta>
...
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.7554/eLife.53404_1</article-id>
<title-group>
<article-title>Reviewer report</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<anonymous/>
<role specific-use="reviewer">Reviewer</role>
</contrib>
</contrib-group>
<pub-date publication-format="electronic" date-type="original-publication" iso-8601-date="2020-04-04" >
<day>04</day>
<month>04</month>
<year>2020</year>
</pub-date>
<pub-history>
<event event-type="reviewer-report-received">
<event-desc>Reviewer report received</event-desc>
<date iso-8601-date="2020-02-01">
<day>01</day>
<month>02</month>
<year>2020</year>
</date>
</event>
</pub-history>
<permissions>
<ali:license_ref>http://creativecommons.org/licenses/by/4.0/</ali:license_ref>
</permissions>
<related-object source-id="https://www.biorxiv.org/" source-id-type="url" source-type="preprint-host" document-id-type="doi" document-id="10.1101.biorxiv.blahblah" document-type="peer-reviewed-article" />
<related-object document-id-type="doi" document-type="reviewer-report" document-id="1010.7554/eLife.53404_2"/>
<related-object document-id-type="doi" document-type="reviewer-report" document-id="1010.7554/eLife.53404_3"/>
<custom-meta-group>
<custom-meta>
<meta-name>peer-review-stage</meta-name>
<meta-value>pre-publication</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transfer</meta-name>
<meta-value>yes</meta-value>
</custom-meta>
<custom-meta>
<meta-name>transferred-from</meta-name>
<meta-value>biorxiv</meta-value>
</custom-meta>
<custom-meta>
<meta-name>peer-review-recommendation</meta-name>
<meta-value>minor-revision</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body/>
</article>
Example 5: Date tagging in JATS 1.1 or earlier
NOTE: All of the above examples use JATS 1.2 tagging for dates other than publication dates (ie, <pub-history>, <event>, <event-desc>, <date>). The following example shows the <history>, <date> tagging recommended for JATS 1.1 or earlier. This tagging is the only part of this recommendation that differs between the versions of the specs. All other tagging shown above applies to both JATS 1.2 and JATS 1.1 and earlier.
<history>
<date date-type="reviewer-report-received">
<day>30</day>
<month>6</month>
<year>2019</year>
</date>
</history>
History
Working: 11 April, 2019 – 15 July, 2020
JAS4R Steering Committee review: 15 July, 2020 – 1 September, 2020
Public review: 21 September 2020 – 30 October, 2020
Working: 2 November 2020 – 10 December 2020
JAS4R Steering Committee review: 11 December 2020 – 17 December 2020
NISO topic committee review: 13 January – 22 January 2021
Published: 27 January 2021
Was it deliberate not to include revision round as data to capture?
Hi there
We cover it in point 33 – it is captured in custom-meta. This was discussed and there is difference between systems and publishers as to what round 0 or 1 might be so we felt there might not be consistence across publishers, however! Capturing it another way to
<custom-meta>felt premature at this point in time.<custom-meta>tagging where the<meta-name>value must be “peer-review-revision-round†and the<meta-value>a numerical digit from 0.