1. Home
  2. Recommendations
  3. Article publication and history dates
Searching...

Article publication and history dates

Contents

Status: Pending decision
License: this recommendation is licensed under CC BY-ND 2.0 UK

This recommendation requires a new subgroup to be formed based on the JATS 1.2 update

Context

<article>, <history>, <pub-date>, <date>

@specific-use, @date-type, @iso-8601-date

Description

These recommendations contain best practices for capturing the publication dates associated with an article and how to indicate the version of the article being viewed.

Objectives of these recommendations:

  • to enable the machine reader to find out how many times this article has been published previously and in what forms
  • to enable the machine reader to find out the stage of the article that this XML instance represents

Additional reading

Recommendation

Note: The following recommendation is for JATS v 1.1 and backward, and will change as a result of the publication of JATS v1.2. See the Pending Notice at the top of this page.

  1. Use @specific-use on <article> to indicate ‘this’ instance of the article, the version. If a publisher already uses this attribute, ensure that you tokenise the attribute to include both value types (see the example). The terms permitted on this attribute are in accordance with the Recommendations of the NISO/ALPSP the Journal Article Versions (JAV) Technical Working Group, as follows:
    • authors-original
    • submitted-manuscript-under-review
    • accepted-manuscript
    • proof
    • version-of-record
    • corrected-version-of-record
    • enhanced-version-of-record
    • pre-print (Added by JATS4R)

      If the publisher publishes a revision of any of these stages, the subsequent revisions should be labelled with suffixes, as follows: ‘-r1’, ‘-r2’, etc.

  2. <pub-date>. An article XML document will typically (but not necessarily) contain two elements; however, an article should never contain more than two elements. The first and second instances of <pub-date> within the article XML should be used as follows:


    Usage for the first instance of <pub-date>:


    The first instance of <pub-date> in the article XML should contain the date that the article was first (originally) published. Since “published” means different things to different publishers, it is at the publisher’s discretion to decide which stage of the publication is represented within this first instance of <pub-date>.

    For example, some publishers post the accepted manuscript form and consider the article to be published; therefore, for those publishers, the date that the accepted manuscript was published would go in the first element.

    On the other hand, other publishers may post the accepted manuscript version but do not consider such a posting to mean the article has been published. For these publishers, the article is considered published when it is posted at a later stage, such as at the version-of-record stage, in which case the first element would contain the date that the article was first published at that later stage. Regardless of which stage the publisher considers the article to be ‘published’, when the article is first (originally) published, the article XML should only contain one element.

    Some publishers may publish pre-print versions of the article on their site and consider this the first publication event. For the purposes of the publisher XML, any pre-print published on a different site is not considered to be published by the publisher of this XML instance and so publication of that instance is not recorded within the publisher.

    Usage for the second instance of <pub-date>:

    The second instance of <pub-date> should always contain the most current date of publication for the article after the article has already been published for the first time (see the note above). If the publisher wishes to retain any publication dates that occurred between the original date of publication (contained in the first instance of and the most current date of publication (contained in the second instance of <pub-date>), then these other dates should be contained within in <history>.
  3. @date-type on <pub-date>. Use value ‘original-publication’ to indicate that the date is the original date of publication, and ‘update’ for dates that represent published updates to the publication.
  4. @iso-8601-date on <date> and <pub-date>. Use this attribute to contain the date in ISO format.
  5. <history>. Any other publication dates not retained in <pub-date> can be stored in <event> within the <history> section. It is not required, but is best practice to indicate the alternative publications of the article in this section. Other article processing dates (for example ‘accepted’) can also be retained in <history>, but NOT within <event>. The items should be stored sequentially, starting with the oldest date in the article’s history.
  6. <event>. 
    Note: This recommendation is pending the inclusion of in in JATS V1.2d1. See the Pending Notice at the top of this page. 
    Use this element to collect all the information about a previous publication event. The following tags can be optionally used within :
    • Use <self-uri> to provide a link to the version of content being described in this section
    • Use @content-type on <self-uri> to indicate what stage of publication this version was. Please use the values listed in recommendation 1
    • Use <date> to record the publication date of an event, with the @iso-8601-date attribute as described in recommendation 4
    • Use @date-type on <date> to indicate what stage of publication this version was in. Please use the values listed in recommendation 1
    • <event-desc>. This is an optional element, which can be used to provide a textual description of the changes made between it and the next version of publication
  7. Do not include an <event> for the current version of the article within <history>, but you can include an <event> for the original publication in this section.

Examples

Example 1

<article article-type="research-article" specific-use="version-of-record" dtd-version="1" xmlns:ali="http://www.niso.org/schemas/ali/1.0"
 xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">
     <pub-date publication-format="electronic" date-type="update" iso-8601-date="2016-07-07" >
         <day>07</day><month>07</month><year>2016</year>
    </pub-date>
    <pub-date publication-format="electronic" date-type="original-publication" iso-8601-date="2016-04-04" >
        <day>04</day><month>04</month><year>2016</year>
    </pub-date>
    <history>
      ...
      <event>
         <self-uri content-type="accepted-manuscript” xlink:href="https://elifesciences.org/content/5/e00666v1"/>
         <date date-type="accepted-manuscript" iso-8601-date="2016-04-04">
             <day>04</day><month>04</month><year>2016</year>
         </date>
        <event-desc> The first version of this article was published as an accepted manuscript. The article has since been copy edited and table 3 has been added.</ext-link>.</event-desc>
     </event>
   </history>
...
</article>

Example 2

Initial submission and rejection by Journal A (and is available on Journal A’s preprint server); subsequent submission and acceptance  to Journal B (with original MS on Journal B’s preprint server); final publishing event as VoR on Journal B (with VoR link).

<history>
 <event>
 <self-uri xlink:href="http:/journala.puba.com/preprints/abcd12390" content-type="preprint"/>
 <date date-type="submitted" iso-8601-date="2001-01-29">
 <day>29</day>
 <month>01</month>
 <year>2001</year>
 </date>
 <date date-type="rejected" iso-8601-date="2001-02-15">
 <day>15</day>
 <month>02</month>
 <year>2001</year>
 </date>
 <event-desc>The first version of this work was submitted to Journal A and rejected because "the subject matter is outside the editorial scope of the journal"</event-desc>
 </event>
 <event>
 <self-uri xlink:href="http:/journalB.pubB.com/preprint/abrft6789" content-type="preprint">
 <date date-type="submitted" iso-8601-date="2001-03-03">
 <day>03</day>
 <month>03</month>
 <year>2001</year>
 </date>
 <date date-type="accepted" iso-8601-date="2001-02-15">
 <day>15</day>
 <month>02</month>
 <year>2001</year>
 </date>
 <event-desc>A slightly reworked manuscript of this article was accepted at Journal B</event-desc>
 </event>
 <event>
 <self-uri xlink:href="http:/journalB.pubB.com/content/45/journb.a788889" content-type="VoR"/>
 <date date-type="epub" iso-8601-date="2001-06-06">
 <day>06</day>
 <month>06</month>
 <year>2001</year>
 </date>
 <event-desc>Extra figures and a table reworked for clarity after editorial review. Final version published in Journal B</event-desc>
 </event>
 </history>
Updated on October 20, 2023
Tagged:

Related Articles

Comments

  1. I notice that in Example 2 content-type=”preprint” is used for the <self-uri> elements.

    Is that a mistake, or is `preprint` preferred over `pre-print` (the latter outlined in Recommendation 1)?

  2. Re: “This recommendation is pending the inclusion of in in JATS V1.2d1. See the Pending Notice at the top of this page. ”

    doesn’t include . Can the examples here be updated please.

Provide feedback on this recommendation

Please note you are commenting on this specific recommendation. To suggest a new recommendation, please follow the link on the homepage. By proceeding with your comment here, you understand that your comment will be publicly visible and you may be contacted by JATS4R in case of further clarification.

You may use markdown to format your comment. For example, to allow <> tags to display, please start and end that portion of your comment with three backtick characters, ```.