Continuous Article Publishing (CAP) is a publishing model for E-only journals. Main The 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 new 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)is added to an (existing) issue. 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 an issue, every article starts with page 1, similar to Advance articles.             

...

Consequences of the CAP-model and its implementation at Brill are:

...

1. Each year an annual volume

2. Within a volume Issue , issue 1 to publish all (general) articles

3. Upon request, a 2^nd 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 versionarticle is added to an issue.

Brill.com specifications

The information in KLOPOTEK is - as mentioned above - solely used for providing access. The volume and issue listing at brill.com is generated from the XML. To implement the CAP-model, the following elements and attributes are relevant:

As mentioned in the definition, the latest article should appear at the top of the

...

table of contents. To ensure

...

this, a separate meta-issue.xml file is necessary, listing the DOI's of the articles in the volume in the correct order. The structure of the meta_issue.xml file is explained hereafter.

Article File naming and Uploading

...

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. 

Image Removed

Production editor

With the request for final files, the following information should be passed to the typesetter:

1. Article number to be used in the name of xml and pdf file

2. Value for the @seq in the <fpage>-element

3. Publication date

4. 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 brill.com:

The main difference is in the naming of the files. The article number is replacing the issue number. Instead of a two-digit issue number, a three-digit article-number is used. Thus, a maximum of 999 articles in a volume is possible. Filenames:

• Article 1:

  • filenames: <issn>_<vol>_s001.xml / pdf (no issue number)

  • zip package: <issn>_<vol>_001_JATS.zip (the article number replaces the issue number)

• Article 2:

  • filenames: <issn>_<vol>_s002.xml / pdf

  • zip package: <issn>_<vol>_002_JATS.zip

• Article 3:

  • filenames: <issn>_<vol>_s003.xml / pdf

  • zip package: <issn>_<vol>_003_JATS.zip

• 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: 

...

Each zip-package contains besides the regular XML, PDF and - if applicable - image files an additional meta_issue.xml file. The zip-package can be handed over to Production for loading to brill.com. 

meta_issue.xml file

As mentioned before, the order of the articles can be set by listing the DOI's of each article in a meta_issue.xml file. The format of this file is shown in the next example.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE MetaIssue SYSTEM "http://schema.highwire.org/public/toc/MetaIssue.dtd">
<MetaIssue volume="14" issue="1">
	<Provider>PubFactory</Provider>
	<TOC>
		<TocSection>
			<Heading>Latest Article</Heading>
			<Resource><DOI>10.1163/22105832-bja00993</DOI></Resource>
    	</TocSection>
		<TocSection>
			<Heading>Articles</Heading>    
			<Resource><DOI>10.1163/22105832-bja10033</DOI></Resource>
			<Resource><DOI>10.1163/22105832-bja10032</DOI></Resource>
			<Resource><DOI>10.1163/22105832-bja10031</DOI></Resource>
			<Resource><DOI>10.1163/22105832-bja10030</DOI></Resource>
			<Resource><DOI>10.1163/22105832-bja10029</DOI></Resource>
		</TocSection>
	</TOC>
</MetaIssue>

Notes:

1. volume and issue number is according to the information in Klopotek and to the XML file of the articles in the volume and issue
2. DOI's are copied from the articles and listed in the right order, newest first, oldest and the end
3. For each new article, a new meta_issue.xml must be created, based on the previous one. The DOI listed under Latest Article should be moved to the top of the listing under Articles. The DOI of the new article should be listed under Latest Articles.

Implementing this procedure in the 2024 volume

The previous procedure was based on a decreasing numbering of articles starting with 999, 998 etc., in combination with the delivery of an issue package with all articles in the issue. The naming convention described above can be implemented by assigning 001 as the article number of the next article. The only important thing is to add a complete meta_issue.xml file to this first article package, listing all DOI's of the articles that have been published already in the 2024 volume.

Multiple issues

As mentioned earlier, it is possible to have multiple issues within the CAP model, for example a special issue on a specific topic. If used, the following guidelines should be followed:

1. the article number is incremental across all issues within a volume. The maximum number of articles for each volume is 999.   The article number is independent of the issue in which it is published.
2. the issue number is defined in the xml. if the issue has a specific title, the <issue-title>-element must be included in the XML as well.
3. each issue has its own meta_issue.xml file with the contents (and order) of the issue. A new meta_issue.xml file should be included in the zip-package of each new article.

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 AWS. 

...