Continuous Article Publishing (CAP) is a publishing model for E-only journals. Main difference with existing models is that final articles are not published online ahead of a forthcoming issue (the Brill Advance option) but are immediately published online at their final location. Since registration of, loading of and access to journal content at Brill is volume and issue based, the implementation of CAP using the current procedures and possibilities, requires some special treatment. This is described in this document.
Continuous Article Publishing means that each article that is accepted and processed into a final format, is published online at its final disposition (so not first in Advance to be included in an issue later). As a result, the annual volume of published articles grows article-by-article instead of issue-based. All articles are added to an issue of the current volume. Within the issue every article starts with page 1, similar to Advance articles.
Definition
Consequences of the CAP-model and its implementation at Brill are:
Articles are published in a final format in an issue within the current volume. Order of the articles cannot be changed afterwards. In case of multiple issues in a volume, for example the default issue and a special issue, articles cannot be moved from one issue to another.
The list of articles in an issue is sorted on publication date with recent articles at the top of the listing. As a result, sections within the listing (articles, book reviews, etc.) are not used. This would conflict with the principle “newest-at-top”. If sections are required, it would be better to create separate “issues” for each section. Thus, we could create issue 1: Articles, Issue 2: Book Reviews, etc.
Each article starts with page number 1
Journal Setup
Since the registration of and access to journals at Brill is volume and issue based, a CAP-Journal is set up in KLOPOTEK like a regular E-only journal (no print version):
Each year an annual volume
Within a volume Issue 1 to publish all (general) articles
Upon request a 2nd issue can be added for special issue articles
With the first article(s) in an issue, the issue is released in KLOPOTEK, like a regular issue. The addition of next articles to the same issue does not have any consequences for the data in KLOPOTEK. Instead, as described in the next paragraph, the issue is replaced with a new version.
Article Publication Process
Each article follows, after acceptance, the regular process. Proofing versions are shared with the author(s) and editor(s). After implementing the corrections, final files are requested from the typesetter. A schematic overview of requesting and handling of final files is given in Figure 1. Additional information is given for each role in the process. All mentioned roles should of course be informed that this specific journal follows the CAP model.
Production editor
With the request for final files, the following information should be passed to the typesetter:
Article number to be used in the name of xml and pdf file
Value for the @seq in the <fpage>-element
Publication date
In case of a volume with multiple issues (general and special) the issue to which the article should be added
NOTES:
Ad 1: Ordering of articles within an issue is based on the snnn-numbering. To achieve a listing with a new article at the top of the listing, a descending numbering needs to be applied, starting with s999 in the name of the xml- and pdf-file. The snnn-string in the filename is internal used only and not visible at http://brill.com:
Article 1: <issn>_<vol>_<issue>_s999.xml / pdf
Article 2: <issn>_<vol>_<issue>_s998.xml / pdf
Article 3: <issn>_<vol>_<issue>_s997.xml / pdf
Etc. (over 999 articles in a volume/issue are not expected)
Ad 2: The @seq attribute starts with 1 for the first article in an issue and is incremented with 1 for each next article.
Ad 3: This could be the date of requesting final files or this date + 3 working days, considering the time necessary for delivering the final package and uploading the files.
The first issue package (containing only new articles) should be handed over to Production as a regular new issue. Each next package of the same issue replaces it with a new version that contains the already available articles followed by the new article(s).
Note that the xml and pdf versions of already published articles are not changed when these are copied into a new issue package. The standard Change Request procedure should be followed in case of changes in articles that are already published. Also note that an issue-print file is not necessary. CAP journals are E-only.
Typesetter
The proofing process for CAP journals is like that for other journals. After completion of the proofing, final files will be requested by the Production Editor. The typesetter should check:
The name of the files (especially the snnn-part) and @seq in the <fpage>-element. For snnn a descending numbering is used (s999, s998, s997, etc.). The numbering in the @seq is ascending.
A @specific-use is added to the <fpage>-element with the value “CAP”, replacing the default attribute specific-use="PDF":
Article 1: <fpage seq"1" specific-use="CAP"> - filenames: <issn>_<vol>_<issue>_s999.xml / pdf
Article 2: <fpage seq"2" specific-use="CAP"> - filenames: <issn>_<vol>_<issue>_s998.xml / pdf
- ...
Article n: <fpage seq"n" specific-use="CAP"> - filenames: <issn>_<vol>_<issue>_s<1000-n>.xml / pdf
Each article starts with page 1 both in the <fpage>-element in the xml and in the pdf.
Issue titles are inserted in the xml of each article:
<issue-title>General Articles</issue-title> the default setting for all articles that are added to issue 1 with general articles.
<issue-title>[special issue title]</issue-title> in case of addition to a special issue in the current volume. A first special issue has always issue number 2. Multiple specials issues are possible. These are numbered 2, 3, 4, etc.
The package with the final files contains all articles that are already published in the issue, together with the new article(s). Note that already published articles remain unchanged. In case of corrections in already published articles, separate instructions will be given.
Standard procedures are being used for the handover of final-files packages.
Production / Fulfillment
As mentioned before the first package of a new Volume/Issue is treated as a regular new issue. Release information in KLOPOTEK is set and the package is loaded to brill.com. Since KLOPOTEK is not (yet) used to store article information, the addition of new articles has no consequences for the information in KLOPOTEK.
Each next issue package is a replacement of the complete issue. To ensure that new articles are listed at the top of the table of contents, the previous version needs to be removed first, before loading the new issue. Therefore, the new packages is treated as a resupply and placed in the Sharepoint/Teams folder for Journal Resupplies:
Switch → General → Content_Processing → Production → JRNL_Resupply
Twice a week this folder is processed by Fulfillment. The existing issue is removed before the new version is loaded.
Closing remarks
The described process for CAP journals makes it possible to support the CAP-model with the existing procedures, routines and functionality. This does not mean that Brill has a fully article-based process in place. This would require changes in KLOPOTEK and other systems. Some consequences of using the issue-based process for CAP journals:
The publishing date of the issue in KLOPTEK is set as soon as the first articles are published. This date will not change with the addition of new articles to the same issue. Currently, Brill has no reporting possibility in place that shows the number of articles in an issue. Keeping track of the “growth” of an issue during the year will therefore require manual intervention.
The publishing date of the issue as shown at brill.com is taken from the first article in the table of contents. Due to the choice to list new articles at the top of the toc, the issue publishing date will change with each added article. For the CAP model the issue publishing date does not make sense. Through the @specific-use=”CAP” added to the <fpage>-element, CAP journals can be recognized, and the issue publishing date can be suppressed at brill.com.
The fixed issue publishing date might have consequences for Finance. For subscription-based journals turnover is taken as soon as the issue is published. Dividing turnover according to the “growth” of the issue will require also manual intervention.
The internal archiving procedures are issue based. As part of uploading an issue package to brill.com, the package is also archived in Brill’s digital vault. Since the filename of the issue only contains issn, volume and issue information, each next package will have the same name and – as a result – overwrite the previous version of the package. This is another reason – besides ordering new articles at the top of the table of contents – to include all earlier published articles in the package. Update of the archiving procedure is necessary to be able to load article-by-article. This update could be to include the number of the first article in the name of the zip-file, or – better – no to archive the zip-files, but to unpack these into a folder per issue. Additional articles can be added to the corresponding folder.
The alerting system implemented at brill.com is issue-based. For CAP-journals a different alerting system might be necessary.
Distribution of journal content to third parties, indexing services, etc. is also issue based. Most of the receiving parties do not appreciate to receive the same content multiple times. For CAP-journals an article-based distribution is more appropriate.
To implement an article-based production process at Brill will require:
An update of the platform to be able to set the sort order for CAP journals (Loading of separate articles is no problem, it is mainly a matter of ordering the articles. Based on the @specific-use in the <fpage>-element the sort order of articles could be set to descending on @seq for CAP-issues and ascending on @seq for regular issues).
An update of the archiving procedure to make sure that a new article package does not overwrite the previous version at Q:
