<event> Event in Publishing History

An event in the publication history of an article, for example, reprinting or publishing a revised online edition. This element may contain information such as a description of the event (<event-desc>), copyright information for a reprint or edition, a publication date, a URI for the article, etc.


An <event> can be the description of a pre- or post-publication event including dates, link(s), an article version, and/or descriptive commentary. An <event> element can also be used to describe earlier versions of an article. As an example, one publisher has an article that was posted on a preprint server, then one version of the author’s accepted manuscript was published, then a subsequent version revising this document was published, then the version of record was published, and then an updated version of record was published. No official “corrections” were published with any of these documents, but each new document can be described with an <event> element.
Related Elements
An <event> provides a more complete description of a date in the lifecycle of an article than can be provided by merely putting a <date> element inside <history>.
Role of <date>: Inside both <history> and <event>, the <date> element can identify the type of date using the attribute @date-type (“received”, “accepted”) and the format of the publication using the @publication-format attribute (“print”, “electronic”).
Role of <event>: In addition to one or more dates, the <event> inside <pub-history> can provide:
  • a human readable description of the publishing event,
  • article version and article identification numbers,
  • the publication date associated with the event,
  • and ISSN or linking ISSN,
  • copyright and licensing information,
  • one or more URIs, and
  • additional notes.
Best Practice: An <event> may include those things that are usually handled by <history>, such as when the manuscript was received or accepted, but an <event> need not be recorded for any particular date in history. However, the JATS Standing Committee recommends that, within a single XML document, either the <history> or the <pub-history> element be used. In other words, if some of your significant dates need to be described as events, all your dates should be inside <event> in <pub-history> and any existing <date> elements within <history> made into pub-history/event dates.

Base Attributes

Models and Context
May be contained in
Content Model
<!ELEMENT  event        %event-model;                                >
Expanded Content Model

(event-desc?, article-id*, (article-version | article-version-alternatives)?, ((pub-date)* | pub-date-not-available?), (date | string-date)*, issn*, issn-l?, isbn*, permissions?, notes*, self-uri*)

Tagged Samples
Simple events
Using <pub-history> and <event>s for an elaboration of or a replacement for <date> elements inside <history>.
  <event event-type="received">
   <event-desc>Received: <string-date iso-8601-date="2017-09-12">
    <month>September</month> <day>12</day>, <year>2017</year></string-date></event-desc>

  <event event-type="accepted">
   <event-desc>Accepted: <string-date iso-8601-date="2018-05-26">
    <month>May</month> <day>26</day>, <year>2018</year></string-date></event-desc>

  <event event-type="pub">
   <event-desc>Accepted Manuscript published: <string-date iso-8601-date="2018-05-30">
    <month>May</month> <day>30</day>, <year>2018</year></string-date> (version 1)</event-desc>

  <event event-type="pub">
   <event-desc>Version of Record published: <string-date iso-8601-date="2018-06-13">
    <month>June</month> <day>13</day>, <year>2018</year></string-date> (version 2)</event-desc>
Detailed event description
  <event event-type="revision">
   <event-desc>The first version of this article was 
    enhanced considerably between versions of the XML 
    instance. These changes can be seen <ext-link
   <date date-type="accepted-manuscript-r1" 
   <self-uri content-type="accepted-manuscript"
Related Resources