1. Getting Started with Zipline

1. Zipline Overview Features Role Based Access Control Bulk Loading Content Validations Content Management Downstream Deposits API Integration Getting Started with Zipline Sign into Zipline URL Sign In Creating a Zipline username and password to access the tool Log Out of Zipline Log Out Zipline Landing Page

1. Zipline Overview

Zipline is a content loading tool for loading journal articles and books content for clients on the newest version of the Silverchair Platform. The user interface allows for users to load content in zipped packages, preview their content, observe warnings and errors from their packages and schedule the content to be published. Upon publication, the content tool loading is configurable to deposit full text information or metadata to a wide range of downstream providers, including Crossref, PubMed Central, OVID, and others. The catalog section of the content loading tool allows users to filter and navigate to view details between different books or all articles present within a specific volume/issue of a journal.

Features

Below are some of the high level features available within the Zipline tool for all clients on the newest version of the Silverchair Platform:

Role Based Access Control

Clients can regulate and control access to certain aspects of the Zipline tool for qualified users. For example, a user with the Content Loading role can only view content they have individually loaded, while a user with the Content Production Manager role has additional permissions to view all content loaded to the tool and can make changes to content, like publishing newly loaded content.

Bulk Loading

Clients using the Zipline tool can choose to load content packages one at a time or queue up an entire set of content using an FTP (file transfer protocol).

Content Validations

Zipline offers a robust set of errors and warnings used to protect the integrity of content loaded in XML format. Each package loaded will display warnings and error messages (if applicable) on the overall structure, formatting, and use of features in the XML files.

Content Management

Users of Zipline have the ability to conduct a series of actions to the content, including but not limited to: previewing newly loaded content, publication, unpublishing articles, opening and closing issues, and scheduling a book for expiration/deletion.

Downstream Deposits

Once published, content loaded to Zipline can be sent to a variety of downstream deposit partners. The choice of submitting metadata or full text XML can be designated prior to enabling the downstream deposit service.

API Integration Users of Zipline have the ability to upload, search for, and perform actions on content using the API interface if they prefer making API calls over using the UI. This can be particularly efficiently when searching for specific information or performing a series of actions to the content.

Getting Started with Zipline Sign into Zipline

Zipline can be accessed by any browser. For the most friendly experience, we recommend using either Chrome or Firefox.

URL

URLs are specific to the client using the tool. Please visit the URL provided by Silverchair and you can then sign in from any computer with proper credentials.

Sign In

1. Go to given URL a. Below is a table describing the production URL for each client i. Client URL

OUP https://zipline.academic.oup.com/

GSW https://zipline.geoscienceworld.org/

DUP https://zipline.read.dukeupress.edu/

IWA https://zipline-iwa.silverchair.com/ 2. Enter your given Username and Password Credentials

Example: Oxford University Press: https://zipline.academic.oup.com/

Note: The 08 Mar 2018 release of Zipline adjusted the authentication page of Zipline to always redirect users to https if they attempt to access http first. This ensures the tool complies with more secure authentication standards used widely by websites and applications.

Creating a Zipline username and password to access the tool

If an individual needs to access the Zipline tool, anyone with the role of Super User can create new individual accounts for staff members and modify existing accounts via the Access & Subscriptions module in the SiteManager application. Please keep in mind that you need to proper user role set up in Sit eManager to create a new user account. For more information on SiteManager, please reference that user guide for more details.

From the SiteManager application, click 'Create a new individual account': On the next page, enter the username, password (and confirm password), email address (and confirm address) of the new user. After creating the new user, navigate to the roles tab and click edit role:

Select the role that is right for the new user. A Zipline user needs to have one of the following roles assigned: Content Loader, Content Production Manager, Content Administrator, Taxonomy Manager, or Super User. For more information on these roles, please navigate to: 7. Access and User Roles. Once you have selected the role, press save changes. The new individual user will now be able to log into Zipline and access the tool, performing actions specific to their assigned role:

Log Out of Zipline

You can log out of Zipline from any interface once you have logged in.

Tip: Zipline will automatically log you out if you have been idle for 30 minutes.

Log Out

1. In the top right corner, click your name 2. Click Log Out Zipline Landing Page

Once logged into Zipline, you will have access to the landing page. The landing page is also the same as the Upload Page.

Menu Bar

The menu bar provides links for:

Upload - allows users to upload content packages Packages - allows users to view status of loaded and in process packages Catalog - allows users to view, filter, preview and publish groups of content. There are separate menus for each content type Journals Books Proceedings 2. Upload Content Packages

2. Uploading Content Content Types Zipline Upload Interface Upload Interface Recent Changes FTP Interface Zipline Flowsteps Process Database Storage Scalability and Performance of Package Upload Funding Information Associated with Journal Articles Package Requirements ZIP Package File Size ZIP Package File Name ZIP Package Folder Structure Note for Mac OS X Users

2. Uploading Content

To upload zipped content packages to the Zipline tool, you can choose to select files via the UI (as seen below) or you can use the FTP to queue up an entire set of content to be loaded automatically. The file size limitations for uploading packages through the interface or the API is 1.5 GB. However, we offer the option to split a package into two or more separate ZIP files, where they can be loaded individually without issue.

Within the interface, users can select the relative priority of a select package against others currently in the queue, in order to more quickly process packages of higher priority. Zipline currently accepts zipped files with XML in SCJATS or SCBITS format. Journals content uses the SCJATS model, while books content will use the SCBITS format. To see more details on the Silverchair Platform Content Specifications for SCBITS and SCJATS, please reference the below specifications: documentation:

SCJATS SCBITS

Content Types

The following types of content can be loaded to Zipline:

1. Journals a. Articles in an issue b. PAPs (publish ahead of print), JAMs (just accepted manuscript) c. Issue meta files 2. Books a. book files and book part wrapper files b. can contain parts and chapters, front-matter and book-back 3. Conference proceedings a. Proceedings articles 4. Taxonomies a. content that is not a part of an issue nor is it an article (detailed in https://confluence.silverchair.com/display/Z3/15.+Taxonomy) b. Creates categories in the database 5. OxMeta Files a. file that can exist along with article xml files as part of a package (detailed in https://confluence.silverchair.com/display/Z3/22. +Loading+OxMeta+Files+to+Zipline) b. links articles to categories Zipline Upload Interface

Within the Upload Interface, these are three aspects of the user interface that you can interact with:

Choose Files: This allows you to choose files to upload Priority: this dropdown menu allows you to choose the priority that the content should be upload on a scale of 0-9, with 9 as top priority in the system. Please reference the table on priority levels:

QueuePriorityLevelId Name Description

0 ScheduledBatch Scheduled Batch

1 Batch Batch (Default priority for submissions deposited to the FTP server.)

2 Low Low

3 BelowNormal Below Normal

4 Normal Normal (Default priority for submissions made through the API.)

5 AboveNormal Above Normal

6 High High

7 Urgent Urgent

8 Critical Critical

9 Realtime Realtime System Request

Upload .ZIP Files: this button allows users to upload .ZIP packages that they have loaded

Upload Interface Recent Changes

Queue Prioritization The 19 Jul 2018 release to Zipline addresses improvements to Queue Prioritization of packages to ensure ZIP files processing in the system with the highest priority will be processed prior to other packages in the system. During times of peak usage, the queue prioritization feature allows for ZIP packages of the highest priority to be processed ahead of lower priority packages. During sparse usage (when less than 8 packages are loading at one time), the packages are processed sequentially (in the order they are loaded). This is due to the fact that there are 8 concurrently running instances of Zipline that pick up and process packages as they are loaded. Therefore, the prioritization feature is most useful during times of peak usage. Perform Upload Action: The 19 Jul 2018 release to Zipline ensures that users are authenticated in Zipline before they attempt to upload a package. If their session has expired when they press the upload button, then they will be logged out of the tool immediately. If the user has a current session, then the package loading animation will occur normally.

FTP Interface

If users would prefer an alternative to uploading packages via the upload interface, they can use the FTP service to load a batch of ZIP files over the FTP. This may be beneficial in cases of bulk loading, where there are multiple packages that need to be loaded at one time. Another benefit to the FTP interface over using the Zipline UI or API is the limit to the size of the ZIP files loaded with this method (1.5 GB on the FTP, whereas a limit of 1 GB is set on the API action). The WatchFTP service will draw from ZIP files loaded over the FTP on a schedule, and transfer them to the Zipline UI, where they will appear in process on the Packages page. One way that users can load packages to Zipline using the FTP is by connecting to FileZilla. The Bulk FTP loading tool is part of the suite of Zipline Content Tools.

For all clients with the exception of Oxford University Press, the server is sftp://securefiles.silverchair.com and the credentials are only accessible via a support ticket to Client Services (or emailing [email protected]) For clients using Zipline for Oxford University Press, the server is sftp://oupsecurefiles.silverchair.com and the credentials are only accessible via a support ticket to Silverchair Client Services Accessing the FTP is only for temporary uploads to Zipline before the packages are processed. Due to storage restrictions, only 100GB can be loaded via the FTP at one time.

The 24 May 2018 release solved an issue for some clients where the Watch FTP loader did not pick up new ZIP packages for processing. If you have any concerns about packages being picked up by the service, please do not hesitate to reach out to [email protected].

Zipline Flowsteps Process

Whenever a person uploads content (it could be a book, journal article, proceeding, etc) to Zipline, the submission will go through several stages in the content loading workflow to validate and store the package's contents. The steps range from validating the package structure, to importing sections of the XML into the database, storing images in Amazon Web Services, and archiving the content to be sent to downstream deposit services. For more information, please reference the following diagram:

Workflow Description Step

Transfer This workflow step uploads the content the client selected for loading and unzips it. The package is structured to have one XML folder Package and one Asset folder. The assets folder contains media files such as images and PDFs

The 24 Jan 2019 newly began tracking the actions and time associated with this flowstep for throughput measurements

Package Does XML validation against an XML schema (such as SCJATS-journalpublishing.xsd or SCBITS-book.xsd) and makes sure the Validation structure is valid.

Business A service that tests against business rules, which could be Silverchair standards and/or rules that clients specify. These rules are things Rule that are not enforceable by the XSD validation. Validation

Loader Transforms the XML contents so that it can be deserialized and stored in the database in the next flow step. XSLT Zipline Validates the data extracted from the transformed XML. If all tests pass, all the content will be written to the database. Issue-level media assets will get stored in AWS S3's 'backfile' bucket (cover images only will be resized), which is a static file storage solution Amazon Web Service offers.

The 24 May 2018 release Refactored Zipline Section Loading for articles to ensure packages process more efficiently The 14 Jun 2018 release greatly reduced the number of database queries associated with the Zipline flowstep, enabling content XML to more efficiently be stored in the database.

Asset Transforms uncompressed type such as files ending with ".tif" into types that could be compressed such as files that end with ".png". Any Transform XML references to the asset get changed so that they match the asset they reference. The service stores any non-issue level assets to the S3 backfile, resizing any images to create small and medium versions.

The 24 Jan 2019 release made improvements to this flowstep to use the UploadAsync method of AWS so that packages could load more efficiently The 21 Mar 2019 release made improvements to this flowstep to reduce the number of queries to the database when locating multimedia records and more efficiently copying asset files when loading them

Semantic This step is optional. If the client chose this service, it makes a call to Semedica to import and autotag the content. If successfully Tagging imported and tagged, the semantic content will be staged for export to the database. If a client does not require Semantic tagging, then the content skips this flowstep and it is not marked for semantic enrichment.

Archive Stores all assets and XML to another section located in S3 ('ContentArchive'), so that it can be reused further, such as for downstream Content deposits. It also serves as a record so that it can be found by web crawlers such as Google Scholar.

With the 14 Feb 2019 release to Zipline, we began tracking the system throughput average for Journals Content Submissions. The measurement calculation is Daily Minimum System Throughput Avg. (mbit/s) = Total daily size of compressed packages / Active processing seconds

Database Storage

In addition to storage or the asset files in AWS, one of the Zipline workflow steps is to convert each element of the content's XML into specific database fields. This allows for a uniform presentation of content on the front end site, whether it belongs to a journal article, a book chapter page, the Issue Table of Contents, or the Book Table of Contents. The tagging structure in the XML will define how the content is imported into the database. For more information, please reference the SCJATS and the SCBITS narrative. Below are some details about the most recent releases that involved database changes to how content is stored:

The 05 Oct 2017 release included logic that would translate how users tagged the license-type of their content. This change allows users to set and modify the access level of a book and associated book parts (whether they are free/not for sale/private) to determine how anonymous and subscribed users can view their content on the front end. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 16 Nov 2017 release modifies the Zipline tool to import abstracts with abstract-type="precis" in book-meta or book-part-meta The 04 Jan 2018 release adjusted the database storage logic so that books tagged with front-matter and book-back as free in the XML to be stored in the database as freely available to read. This ultimately allows users to access the content without authentication on the front end website. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 04 Jan 2018 release modified the Zipline tool to allow users to specify difference between author contributors and editor contributors for books. This will store them separately in the database, allowing them to be separated out on the front end book pages of the website. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details on the tagging structure. The 15 Feb 2018 release allows valid ISBN10 values with a check digit of X to continue Zipline validation and be imported into the database. ISBN10/ISBN13/EISBN values with digit other than numbers 0-9 or X still fails with error message code 50166. Please see 8. Zipline Error and Warning Codes for more details. The 15 Feb 2018 release allows values up to 255 characters to be imported successfully without truncation. If you find that your publisher-name exceed 255 characters, please contact your PDM (Product Delivery Manager) and we can develop a solution to meet your needs. The 15 Feb 2018 release adjusted Zipline to import supplementary material for books where the content-type is 'disclosure' or 'data-supplement'. It also modified the import process so that when a book is loaded to Zipline and there is supplementary-material with no content-type, the supplementary material defaults to data supplement. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 15 Feb 2018 release adjusted Zipline to import a book with a custom-meta-group designating it as an 'In Progress' book The 08 Mar 2018 release adjusted the database schema to prepare Zipline to import a book part with version information. New columns that will be used to store version information for a book include: Version Date, Version XML, Version Number, CurrentVersion ID, original publication date The 08 Mar 2018 release adjusted Zipline to import additional elements of edition information for a book. This will allow books tied by the same editionSet to be linked together, so that users can more easily navigate between them on the front end. Order of the among other collection-meta attributes does not matter, they will be imported and processed in any order they are supplied in the XML. The 08 Mar 2018 release adjusted Zipline to import book level publication dates in different locations, depending on if the value of publication- format was "ppub" or "epub". Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 28 Mar 2018 release adjusted Zipline to import affiliate logos to the database as book level supplementary material. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 28 Mar 2018 release adjusted Zipline to import the contents of book-app-group in book-back. Example XML snippet is below:

Every node in the database is required to have ...

The 03 May 2018 release adjusted Zipline to import supplementary material at the chapter level for books content. This change allows content to be stored in the database and have the asset stored within AWS Example tagging for a book part:

The 24 May 2018 release allows users to set issue publication date and issue cover date when loading an issue meta file for the first time, or update the issue publication date/issue cover date for an existing issue. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The order of importing issue publication date from the issue meta is if present, and then if not present The order of importing issue cover date from the issue meta is if present, and then , and then is neither are present The 24 May 2018 release allows users to specify license-type="cc-by-igo" in their XML to allow the access type to be stored in the database for the article. This license type will make the content available on the site without authentication. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 24 May 2018 release adjusted content import for users to include Sketchfab 3D models in their XML. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 14 Jun 2018 release allows users to specify license-type="publisher-standard" in their XML to include with paywalled articles. This enables submission and discovery of the license information on Crossref. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 09 Aug 2018 release allows users to optionally include abstract-type="video", abstract-type="audio", content-type="featured-video", and content-type="featured-audio" in their XML. This allows featured video/audio content and video/audio abstracts to be stored in the database for journals articles. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 04 Sep 2018 release allows users to set issue title when loading an issue meta file for the first time, or update the issue title for an existing issue. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details. The 04 Sep 2018 release allows users to import a publisher location value for a book, known in SCBITS as . Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details Kluwer Academic Publishers Norwell, MA

The 04 Oct 2018 release allows users to load a book or a book part wrapper file with a fig nod that has a graphic with license-type=" NoElectronicRight" to designate a restricted image. Users will not include this image in the package load to Zipline, but instead this indication will be stored in the database so that sites configured to display it will provide a message to users stating that they must purchase the print book to view the image. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 25 Oct 2018 release allows users to import chapter level keywords for books content where the kwd-group-type is a value other than "author". A user loading a package can specify a value other than "author" when loading author assigned keywords for a book chapter. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 25 Oct 2018 release allows users to specify in either article meta or issue meta to specify who might have sponsored the issue. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The 15 Nov 2018 release to Zipline resolved an issue where fig-group/caption/p was not being imported/saved to the database for books content. Going forward all books loaded with this detail will have the information stored and appropriately displayed where configured for a client site. The 24 Jan 2019 release to Zipline imported collection-type="collection" into the database as a new category, so that we can import information supplied in SCBITS

In the 14 Feb 2019 release to Zipline, the following elements of Zipline storage were adjusted:

Introduced two new author types in the system, chair and translator. Users can specify these values in the XML to designate authors as a chair or a translator. Clients who have specific author types that they would like configured in addition to the standard types accepted by Crossref should contact Silverchair Client Services and their PDM directly. A regression was resolved that enabled books to be imported with book series with either of the following XML formats:

In the 21 Mar 2019 release to Zipline, the following elements of Zipline storage were adjusted: Importing of in the element for books content into the database. The following content-types are supported:

Importing values for book-part-type in front-matter-part and book-part in book back, in order to distinguish between front matter and back matter pieces in a search filter on the front end Values do not need to be pre-configured, they can be stored in the database based on the value in the XML Importing preview PDFs for monographs (books authored wholly by the same contributors) to be indexed by Google Scholar The client may choose to generating the Preview PDFs in the format that Google Scholar will accept Then these can be loaded into the database and displayed on the front end site with configuration from the team supporting the books site Importing book type for book loaded to Zipline, to differentiate between edited volumes and monographs Chapters from edited volumes - in which each chapter is authored by folks not the editor(s) - function very much like journal articles. Each chapter is able to "stand alone" for indexing and be disassociated from the overall volume without compromising the user experience in search results. Paywall monographs, however, due to their make up as mature works & separate user-experience, do not fit within the full-text indexing model for journals. For the monographs - which again would focus on the "preview pdfs" for restricted-access - the setups would be slightly different from other models: Import self-uri in book-part-meta This enables users to load end notes PDFs in book-back to Zipline so that they will display in the proper location in the back matter of a book Import keywords in book-meta This enables users to specify book level keywords in the book meta so that they can be associated with the book In the 11 Apr 2019 release to Zipline, the following elements of Zipline storage were adjusted: An issue was resolved that prevented contributors with tagging from being imported to Zipline Resolved issue that prevented Arabic characters in a book title from being displayed. The cause was due to the use of varchar in the storage of the book's title. Changing to nvarchar resolved the issue. Support 'indexed' attribute on front-matter-part and book-back. This enables content to be optionally excluded from search Support for importing book indexes into the database In the 02 May 2019 release to Zipline, the following elements of Zipline storage were adjusted: Silverchair now distinguishes between similar sections that exist in both front-matter and book-back. This enables a clear way to determine which parent node the data came from originally, and allows for sorting of these section the front end. The parts that are similar are listed below: Acknowledgement //book/front-matter/ack //book/book-back/ack AuthorExtra //book/front-matter/bio //book/book-back/bio Dedication //book/front-matter/dedication //book/book-back/dedication FootNoteGroup //book/front-matter/fn-group //book/book-back/fn-group Books with XML /book/book-back/dedication is saved to the database and all assets are saved to S3 Enabled all child elements under to be parsed correctly into the database Resolved issue that incorrectly assigned heading levels to chapters and parts Imported inline-graphic when placed inside of related-object to the database Imported related-object where an external link is referenced in the book or book part. This creates a link in the database to be displayed on the front end website if configured appropriately Imported related-object where multimedia is referenced as the destination Import authors with a contrib-type value that is configured for the the client's Eligible Author Types Import for books Import for books and book parts with book and section as a destination Import with page number specified In the 06 Jun 2019 release to Zipline: Adjust import logic to create multimedia records in the database when there is inside of

Every node in the database is required to have ...

our system.

Nullam semper pretium porta. Nunc dignissim bibendum enim.

25 Oct 2018 50126 The category This error will occur when the category indicated in the XML is not present in the database. Please consult with your {0} could not Silverchair PDM if you would like to add additional categories to the database that were not set up during the build and be found. they can consult on what is necessary. Ensure the category is correctly represented in the xml file. Note: A category loaded as part of a taxonomy file takes about 10 minutes to process.

25 Oct 2018 50127 The category This error will occur if the entire category hierarchy is not indicated in the XML (see example screenshot where this {0} specified is might happen). To resolve, adjust the package to include the entire category hierarchy. too vague to map to a single category. Please include the entire hierarchy in the xml. 9. Publish Content

8. Publish Content Future Publishing Individual and Bulk Publishing Book Publishing Publishing via the API Criteria for publishing via the API Book Publishing Structure Publishing a Book Publishing a Book Part Book Part Structure Book Part Actions Publishing a Book Chapter Publishing via the UI Clicking the Publish button Display of Publish Statuses Reloading and Replacements Downstream Deposits

8. Publish Content

Specified Zipline users will be able to publish content loaded to the Zipline tool once the content has been loaded successfully. For articles, this can be done one article at a time on the Package Detail page, or one at a time on the Catalog Detail page if the article is in an issue. Alternatively, an entire issue can be published at one time on the Catalog page. For books, a book can be published with all front matter, top level sections, parts, and chapters in the Catalog Page. Alternatively, specific parts and chapters can be published, which publishes the book and children of that part/chapter, but not all other chapters. Publishing a specific part or chapter where the original part or chapter was already published will cause a replacement (update) to that content.

Future Publishing

Zipline Users have the ability to publish content at a later date in the future. This can be done for both options mentioned above. To publish into the future, a user can click on the publish button and then schedule the future date of publication:

Individual and Bulk Publishing

To publish content in Zipline, you have two options to do so:

OPTION 1 (Individual Publish, most commonly used for journals content): Pieces of content on the 4. Zipline Packages Page: Go to the Packages page, click into the package ID link and click publish on a specific piece of content. Only content that has completed with warnings or has completed successfully can be published. Content that displays content level errors cannot be published. For journals: you can publish one article at time this way For journals: the packages page is also where you can publish ahead of print content that is not part of an issue For books: if a user would like to load multiple chapters of a book, but only publish one or two, they can choose to publish a single chapter at one time and leave the others unpublished. This also makes the book page live (where the title, authors, permissions, and table of contents live) OPTION 2 (Bulk Publish): Container of content 5. Zipline Catalog Page Go to the Catalog page and click publish. For journals: publishing an issue this will publish all articles within the issue For books: this will publish all top level sections of the book like the front matter, all parts, all chapters, and all multimedia, as well as the book. This is the recommended method to publish a book, rather than publishing a book part on the package details page (so that all sections of the book will be published at once)

Please note that publishing a book or an article/issue will set the Active Date of the content and it will appear live on the site.

Book Publishing

Publishing via the API

Users can publish a book or book parts using the API with postman. The operations are:

UpdateBook "PUT /books/{ContentKey}" for publishing UpdateBookPart "PUT /book-parts/{ContentKey}" for publishing

Criteria for publishing via the API

A user must be authenticated and using the right environment for the calls to work A user must have the access role of Content Production Manager, Content Administrator, or Super User to publish a book the content key must be supplied (the book or book parts have to be loaded) The date of the publication must be set for immediately or the future (not the past) If the date of the publication is set for the past, then the active date will be set for immediately and not the past

Book Publishing Structure

Unlike an issue, which only contains articles not not additional nesting below an article, a book can have several levels of subsections:

Publishing a Book

Publishing a book will publish all details in the book meta (such as permissions, abstract, all supplementary material), all details in front-matter (such as dedication, foreword, preface), all details in a book-part (which includes chapters, front matter inside of a part), and all details in book-back (such as appendix and acknowledgements). This also includes making the assets included with a book live on the site such as graphics and figures and pdfs. If the book is broken out into a book xml file and one or more book part wrapper files, then all of the files that have been loaded will be published if the book is published.

When a book is published using the API: The book's activeDate is set to the UtcDate associated with the publishDate (either in the future or immediately) And the book's multimedia records' activedates are set to the utcDate The sections should get the same activeDate as the book (activeDate on the sectionAttributes table) The API returns a message indicating what is published or an error message if the criteria is not met Publishing a book publishes it and any unpublished child of the book (including book parts and chapters) When an activeDate is set on the book, it is also set recursively on the descendant book parts, chapters, and sections If the book is already published, then it follows the processes listed here: 10. Update or Replace Content When a book is published, downstream deposit services are queued upon publication Note: This behavior can be compared with publication of issues. When an issue is published, the articles within that issue are likewise published

In some scenarios, a book that has been loaded with outstanding errors will display a modal prevent a user from continuing on to publish a book. This case will only occur when the content package is corrupted and causes an error upon upload. In this scenario, a screenshot similar to the below will be presented to the end user. This can be resolved by reloading the package following Silverchair Specifications and ensuring all book parts are processed without errors: Publishing a Book Part

When publishing the entire book is not an option, users may choose to publish one or more book parts via the API. "Book Part" here is used loosely to mean any chapter- and part-like content, including a Part, Chapter, Section, Foreword, etc. When book parts content is published, the parents of the book part (including all top level sections in the book meta) are likewise published and the children, but not the siblings. Publishing book parts set an Active Date recursively on the descendant sections, stopping at the next book part. If part contains multiple chapters and the part is published, then all chapters below are published. If the other sections of the book such as front matter were unpublished at this point, then the book and top level sections in book-meta would also be published.

Book Part Structure

Example:

Book Copyright Front Matter Back Matter Dedication Part 1 Chapter 1 Chapter 2 Chapter 3 Part 2 Chapter 4 Chapter 5 Chapter 6 Part 3 Chapter 7 Chapter 8 Chapter 9

If a user published part 1, all children (Chapters 1-3) are published, as well as the Book. The 'Book' includes all of the top level sections that would be included in the book meta file, like the copyright, dedication, or permission statement. However, Parts 2-3 are not published. If a user published Chapter 1 only, Part 1 and the book is published. But Chapter 2-3 are not, nor are Parts 2-3. Publishing book parts set an activeDate recursively on the descendant sections, stopping at the next book part. If part contains multiple chapters and the part is published, then all chapters below are published. If a chapter is under a book part and only the chapter is published, then only that chapter is published and siblings (other chapters are not).

Note: This behavior can be compared with articles within an issue. When an article is published with volume and issue information, the issue is also published A user cannot choose to publish solely the copyright, dedication, or other top level sections of a book on their own. These sections are included in the book meta file. Publishing the book publishes these 'chapteresque' top level sections.

Book Part Actions

When a book part is published using the API: The book part's activeDate is set to the utcDate (either in the future or immediately) And the book part's multimedias' activedates are set to the utcDate The sections should get the same activeDate as the book part (activeDate on the sectionAttributes table) The API returns a message indicating what is published or an error message if the criteria is not met Publishing a chapter of an unpublished book part and book will automatically publish the book part and book (including the element in book-meta, such as permissions and abstract). publishing a book part would publish the book part and all unpublished chapters within it, along with the book if the book is unpublished.

When a book part gets an activeDate, then descendants of the section receive the activeDate, stopping at the next book part E.g.: Given nothing has an activeDate, when BookPart 1 gets an activeDate, then "stuff", "content", and "more content" also get the activeDate. Given nothing has an activeDate, when Chapter 1 gets and activeDate, then "words" and "more words" also get the activeDate, but "Chapter 1.2", "things", and "smartness" do not. BookPart 1 ---stuff ---content ---more content ---Chapter 1 ------words ------more words ------Chapter 1.2 ------things ------smartness BookPart 2 ---etc

If the book part is already published, then it follows the processes listed here: 10. Update or Replace Content When a book part is published, downstream deposit services are queued upon publication

Publishing a Book Chapter

Publishing a chapter only publishes sections above that chapter. For example, if a chapter is under a book part and only the chapter is published, then only that chapter is published and siblings (other chapters) are not. The part above the chapter will be published, as well as the top level sections of that book (such as permissions, and abstract). If a user chooses to publish a single book chapter, the other chapters would not be published unless they decided to press the publish button as well.

Notes

The 28 Mar 2018 release resolved an issue when a Zipline user replaced an unpublished book and attempted to publish a single chapter. With this change, Zipline users are now able to publish a chapter for an unpublished book, the book will be published, as well as the top level sections of that book (such as permissions, and abstract). The chapter will also be successfully published.

Publishing via the UI

Users can publish a book or book parts in the UI. The same criteria and effects as the API apply to the UI. One book part can be selected at a time for publication.

Clicking the Publish button

User can click the button to publish a book or book parts in the UI. When the user clicks the button to publish, a modal appears to publish the content immediately or into the future Depending on when they schedule the content for publication, the activeDate is set and the status of the content will change If the user clicks the publish button and then presses cancel, nothing will happen. The activeDate will not be set and and status will not change

Display of Publish Statuses

Both books and their content items can show three statuses, as well as issues and articles. The three statuses are: Published, Unpublished, and Scheduled

Published: If a book part, book, journal article, or issue has an activeDate that is not in the future, it will show as published Scheduled: If a book part, book, journal article, or issue has an activeDate that is in the future, it will show as 'Scheduled' with the time of publication Unpublished: If a book part, book, journal article, or issue has an activeDate of NULL, it will show as 'Unpublished'

Reloading and Replacements

For more details on updating or replacing content loaded to Zipline, please reference: 10. Update or Replace Content Downstream Deposits

When content is published, it is queued for downstream deposit as part of the Radiate service to the specified services mentioned in the Downstream Deposit configurations 17. Edit Journal Publishing Information. For more information, please reference the downstream deposit section of this user guide 17 . Downstream Deposit Services. 10. Update or Replace Content

9. Update or Replace Content Reloading and Replacements Details More Detailed Reloading and Replacement Scenarios Recent Changes Zipline Article Replacements

9. Update or Replace Content

Users have the ability to revise and re-upload content after the original has loaded to Zipline, either before it is published, or after it is published and live on the site. Content is matched for replacement on the basis of the unique identifier for the content. For journal articles, the unique identifier is the DOI if the article has one, or by the publisher ID and the journal if there is no DOI. For books, the unique identifier is the ISBN value, or a combination of ISBN10, ISBN13 and electronic ISBN. Additionally, the 'replaceable units' of a book can be replaced, by using the unique publisher ID on the section's content in the XML. Replaceable units within books refers to:

Parts Chapters Front-Matter (elements ack, bio, dedication, fn-group, toc, front-matter-part, foreword, preface, notes) Book-Back (elements app-group, ref-list, ack, bio, dedication, fn-group, toc, notes)

For this reason, it is very important for Zipline users to include unique publisher ids on all replaceable units and as much of their content as possible when loading a possible. This ensures content will be replaced effectively.

Reloading and Replacements Details

If a Zipline user would like to make a change to content they have loaded to Zipline (before or after publication), they may do so by updating or replacing the content. The below scenarios demonstrate at a high level what happens when reloading of previously loaded content happens in Zipline. The details of replacements are more complex within the system, and can be explained in further if there is a specific question raised about how to replace content. For journal article replacements, please refer to the first diagram on 19. Zipline Visual Diagrams.

Scenario Details

Original Loading a replacement piece of content will automatically replace the original content. Publishing the replacement will show the content is replacement content on the front end. Not publishing anything will result in the content not showing on the site. loaded, never published

Original Given that replacement content is loaded, both pieces of content will exist in Zipline. The original content is still visible on the front end. content is Nothing is replaced until content is actually published. The original will remain on the front end until the replacement is published. loaded and published When the replacement is published, the replacement overwrites the data on the original, and the replacement ultimately gets deleted. through Zipline The new content's values replace the original content in the database (with the exception of the unique identifier). The action of overwriting occurs once every 5 minutes in the system for replacement content that has been published. Many pieces of content can be set to be replaced at one time across the whole system.

More Detailed Reloading and Replacement Scenarios

Please note that this does not cover all possible replacement scenarios. If you have a specific question with regard to a piece of content, please reach out to Silverchair Client Services and we can work with you to resolve any issue at hand.

Current State Action Result

Books

Nothing in Zipline New book Book is imported, provided that it meets criteria of package requirements is loaded

Existing book in Replaceme Full swap of the book is completed, existing book has new values and is still unpublished Zipline, nt book is unpublished loaded The 03 May 2018 release resolved an issue with loading a replacement for certain books containing a self-uri element pointing to a PDF in a front-matter section or in a chapter. When there is an unpublished book in the database and a replacement book is loaded, then the unpublished replacement is processed and swaps the original with the replacement

Existing book in Replaceme Additional content items are created for the replaceable units of the book. The new content items are not published, Zipline is nt book is but will display on the catalog details page. Any changes in the book-meta update the book immediately. Loading a published loaded book as a replacement can have changes for a specific part or chapter or a book, which will create content items with the changed information for that replaceable unit. Existing book in Replaceme Additional content items are created for the replaceable units of the book. The unpublished replacement content Zipline is nt book is items are removed immediately, and the new content items take their place. The newest content items are not published, loaded published, but will display on the catalog details page. Any changes in the book-meta update the book immediately. replacement content items exist unpublished

Existing book in Replaceme Active Date is set on the replacement content items. The replaceable units (parts and chapters) that match on the Zipline is nt content publisher ID (legacySectionID) will trigger a swap of the content. Immediately on the Catalog Details page, the published, item is original content items will display (not the new ones) for up to 5 minutes. Within or by a 5 minute time period, the replacement published content will be swapped so that the new content items display for the book, and the former content items are content items removed from the front end. exist unpublished

Existing book in Replaceme Active Date in the future is set on the replacement content items. In the Zipline Catalog Details page, the original Zipline is nt content content items are removed from view, and the replacement content items are displaying with a scheduled status. published, item is When the scheduled time occurs, the content will be triggered for swap based on a match on publisher ID. For up to replacement scheduled 5 minutes, the original content items may display on the Catalog Details page. After or within 5 minutes, the content content items to be will be swapped, the new items will display for the book, and the former content items are removed from the front exist unpublished published end.

Nothing in Zipline Load book File import fails. A book file first has to be loaded with book meta. The book part wrapper can only be loaded if the part book file has been loaded previously wrapper

Existing book in Replaceme Replacement book part wrapper swaps the original content items with the new content items on the basis of Zipline, nt book publisher ID. Any changes in values in the book meta in the book part wrapper do not update the book immediately. unpublished part Book meta updates can only happen with a book file replacement is loaded to Zipline. wrapper is loaded

Existing book in Replaceme Additional content items are created for the replaceable units of the book. The new content items are not published, Zipline is nt book but will display on the catalog details page. Any changes in the book-meta from the book part wrapper do not update published part the book immediately. Book meta updates can only happen with a book file replacement is loaded to Zipline. wrapper is loaded

Existing book in Replaceme Additional content items are created for the replaceable units of the book. The unpublished replacement content Zipline is nt book items are removed immediately (provided that they match the newest replacement on publisher id), and the new published, part content items take their place. The newest content items are not published, but will display on the catalog details replacement wrapper is page. Any changes in the book-meta from the book-part-wrapper do not update the book immediately. Book meta content items loaded updates can only happen with a book file replacement is loaded to Zipline. exist unpublished

Existing book in New book The file is imported, the book part will be added to the end of the book. The book-meta is updated automatically if Zipline is part is there are any values in book-meta that have changed in the replacement (only in the book file load, not book part published loaded wrapper) (either through book or book part wrapper)

Journal Articles

Nothing in Zipline New Articles are imported, provided that it meets criteria of package requirements Article is loaded, or a group of articles are loaded

Existing article in Replaceme Full swap of the article is completed, article has new values and is still unpublished Zipline is nt article is unpublished loaded

Existing article in Replaceme Additional content items are created for the article. The original article is still published. The new content items are Zipline is nt article is not published, but will display on the catalog details page if the article is part of an issue. published loaded

Existing article in Replaceme Additional content items are created for the article. The unpublished replacement content items are removed Zipline is nt article is immediately, and the new content items take their place. The newest content items are not published, but will display published, loaded on the catalog details page if the article is part of an issue. replacement content items exist unpublished Existing book in Replaceme Active Date is set on the replacement content items. This triggers a swap of the content, so that the original Zipline is nt content published article will be removed and replaced with the new article details on the front end. published, item is replacement published content items exist unpublished

Existing article in Replaceme Additional content items are created for the article. The original PAP is still published. The new content items are not Zipline is a nt article published, but will display on the catalog details page published PAP part of an issue is published

Existing article in Replaceme Active Date is set on the replacement content items. This triggers a swap of the content, so that the original Zipline is a nt content published PAP will be removed and replaced with the new issue article details on the front end. The Catalog Details published PAP, item is page for the issue will show the replacement article with a status of published. replacement published article is unpublished and part of an issue

Issue Meta

Nothing in Zipline Issue-Meta Given that issue-meta is loaded concurrently with referenced articles or loaded after referenced articles have been is loaded loaded, then issue-meta loads and is published successfully to Zipline

Issue-meta exists Issue-Meta The replacement issue-meta replaces the original issue-meta. There is nothing needed from the Zipline user to published is reloaded publish the replacement. The asset files on the issue level are immediately live on the site as a replacement

OxMeta

Nothing in Zipline OxMeta is When a category is not present in the database or when the articles have not been loaded to Zipline, OxMeta cannot (no articles, no loaded associate categories to articles. Taxonomies need to be first be loaded and articles have to be present in the taxonomies) database before the association can be made.

Articles already OxMeta is Articles are associated with categories upon load of OxMeta file. This is no action needed from the Zipline user to loaded to Zipline, loaded publish this piece of content to take effect. taxonomy has already been loaded

Articles already OxMeta is Any associations between article DOI and categories are wiped out upon a subsequent OxMeta load. An article is associated to loaded only connected to categories of categoryTypeID = 50 based on the most recent OxMeta file load categories from a previous OxMeta load

Recent Changes

The 14 Feb 2019 release to Zipline adjusted replacements job for books to more efficiently remove original sections that have been replaced in a bulk loading scenario. This enables books to be replaced more efficiently in the system. Up to 25 books will be replaced at once within a 5 minute period. The 06 Jun 2019 release to Zipline ensure that loading a replacement book part with child sections does not create duplicates. The logic of the change is as follows: Given a book or a book part wrapper that is loaded to Zipline And then that book or book part wrapper is loaded again The replaceable units are completely replaced And the child sections of those replaceable units are completely replaced and there are no duplicate sections for children of the replaceable unit Given a book or a book part wrapper that is loaded and published to Zipline And a replacement is loaded and published After the swap runs, the child sections of those replaceable units are completely replaced and there are no duplicate sections for children of the replaceable unit The 27 Jun 2019 release to Zipline made a change to ensure that when replacement book parts are loaded, the chapters below the bookpart maintain their hierarchy, and after the swap process there is only one version of the sections that are published. In the 22 Aug 2019 release to Zipline Resolved an issue that was preventing some users from loading packages and viewing the correct error message. When users import a content with an existing publisherId but with a different doi to what we have in our database then the submission fails and it displays the user with the correct message. When an issue article is replaced, and the replacement article is contained within a different issue, Then the contentItem for the original article is marked outdated And the issue page in Zipline 3 does not show the original article And the newly loaded issue's content items are marked isOutdated = false Loading new articles does not set the isOutdated flag to true (PAP and Issue) In the 12 Sep 2019 release to Zipline, an issue was resolved that was causing some duplicate sections to display on the book catalog details page Given a book that is published with published section When a user loads a full replacement of that book and publishes the section After the swap job runs across the sections There is not greater than one published section for each legacySectionID without a hardexpireDate And any duplicate sections have a hardExpireDate Book parts of sectionType 'Appendix' display on the Zipline packages page and Zipline Catalog Details page and can be published and deleted In the 13 Feb 2020 release to Zipline, an issue was resolved that would sometimes create duplicate issues when multiple zip packages were loaded concurrently to Zipline and processed by different Zipline services. Now when issue ZIP files are loaded concurrently, they are compared against other concurrently loaded packages to see if any of the ZIP files contain content that belong to the same issue. If they do, then only one issue record is created in our database. A replacement issue does not create a duplicate issue and instead replaces an existing published issue Given a Zipline user that loads a replacement for an issue article When they republish the replacement It is tied to the same issue record as the original article

Zipline Article Replacements

This diagram describes how articles are replaced on Zipline: 11. Preview Content

10. Preview Content Preview Mode Details Access to Preview Mode Preview Content Actions What content can be previewed?

10. Preview Content

Before files are published / made available on the front-end site, they are hidden or "cloaked" to end users. However, the files are accessible for view on the front-end site by "previewing" through Zipline. Either prior to publication or after publication of content, users can preview their content on the front end to ensure all of the relevant content is present and if any details need to be changed. To preview files in Zipline interface, there are two options to do so:

OPTION 1: Individual pieces of content on the Package Details page Depending on their access permissions, users will be able to see individual pieces of content on the Package Detail page and press the preview button to preview the content OPTION 2: Catalog Details page Depending on their access permissions, users will be able to to see individual pieces of content on the Catalog Detail page and press the preview button to preview the content.

Previewing content is available for both Unpublished and Published content in Zipline. A user simply has to click on the Preview button to preview the content. Clicking the preview button will open a separate tab or window depending of browser preferences. Preview content has a header displaying the message 'Preview Mode is enabled!' to remind you that this content is being viewed in preview mode and not on the live site.

Below is a picture of how the Preview button is displayed on the Catalog Details page for a book:

Preview Mode Details

Not all users of Zipline will have the ability to preview content. For more information, please reference 7. Access and User Roles. Additional users must have the appropriate SiteManager role assigned to their account, and they must be logged into the front-end site with active subscriptions in order to preview content and their SiteManager account. For more information, please reference the SiteManager User Guide that is available in the SiteManager tool. For journal articles, a user can click preview for a specific article, and for books, a user can click preview on a replaceable unit (part, chapter, or section) of a book.

Access to Preview Mode

The following must be true to use Preview:

Users must have the appropriate SiteManager role assigned to their account Users must have active subscriptions to the content in order to preview it Users must be logged into the front-end site (in addition to being logged into Zipline) to preview the content.

Preview Content Actions

The following actions are disabled on the front-end when a user is in preview mode:

Saving to My Stuff Email a friend Print Set an alert Navigation within the site - you cannot navigate from the TOC to an article or proceeding or from an article or proceeding to the TOC when in this mode.

What content can be previewed?

Articles Book sections (including chapters, book front and book back matter) The 14 Jun 2018 resolve an issue when users attempted to preview book front and book back matter. Prior to the change, the preview action was not functional because the resourceTypeID value was 0. After the change, the resourceTypeID value was corrected to 5, allowing users to preview these sections. Released 04 Sep 2018: Book Table of Contents Page and Issue Table of Contents Page Please reference 5. Zipline Catalog Page for information on where this is accessible on the Catalog Page 12. Unpublish or Remove Content

11. Unpublish or Remove Content Articles Proceedings Articles Books Issue Meta OxMeta Screenshots Unpublish Content Details Expire and Delete Content Details

11. Unpublish or Remove Content

Depending on the content type, Zipline allows for users to unpublish or remove it from the live site after it has been loaded and published. The actions available to unpublish or remove content depends on the content type selected.

Articles

Articles have the option to be unpublished after publication. This happens by removing the active date from the system and removing the content from the front end. Users should take precaution not to unpublish any content unless they are absolutely sure that it can be removed from the site. For articles, this can be accomplished on either the Zipline Package Detail Page or the Zipline Catalog Page.

Proceedings Articles

Proceedings Articles have the option to be unpublished after publication. This happens by removing the active date from the system and removing the content from the front end. Users should take precaution not to unpublish any content unless they are absolutely sure that it can be removed from the site. For articles, this can be accomplished on either the Zipline Package Detail Page or the Zipline Catalog Page.

Books

Unlike articles and proceedings, there is no notion of 'unpublishing' a book. Zipline will only offer two options to remove the content: expire and delete. This functionality will apply to both published and unpublished books. On the Zipline tool, Expire will mean the book cannot be found in search results or navigation, but it will still be accessible from a bookmark or link. Delete will mean that the book will no longer exist on the site, and it will have to be reloaded to Zipline to be added back on the front end.

Issue Meta

After Issue Meta is loaded, it can be unpublished or removed. However, it can be completely replaced by reloading the Issue Meta file with changes. This can help to remove or change issue level assets on the front end.

OxMeta

After Oxmeta is loaded, it cannot be removed or unpublished. However, since OxMeta marks associations between Taxonomy and article DOIs, the associations can be modified or changed by reuploading OxMeta values.

Screenshots

Below are sample visuals of the buttons available to unpublish, expire, and delete content. Unpublish Content Details

To unpublish journals content in Zipline, you have two options to do so:

OPTION 1: Individual pieces of content (articles) on the 4. Zipline Packages Page: Go to the Packages page, click into the package ID link and click unpublish on a specific piece of content. Only content that has been published can be unpublished. Content that is scheduled for publication can also be unpublished OPTION 2: Container of content (Issues) 5. Zipline Catalog Page If the content has already been published, go to the Catalog page and click unpublish. On the Zipline Catalog Page, you can also click on the title hyperlink to go to the Catalog Details page and click unpublish on an individual piece of content

After the action, a message will display to show that the content has been unpublished successfully. Here is an example of what happens when the content is unpublished: Expire and Delete Content Details

Before choosing delete on a book or book part/chapter, please understand that this action cannot be undone. The only way to add this information back to Zipline is to reload the XML content in a ZIP package again. A deleted book or book part will not display on Zipline or on the front end site after this action. Please refer to the table below for a full list of actions that apply to expire and delete books:

Status of Delete Action Expire Action Book

Book

Deleted Delete action not available for an already deleted book Action not available for a deleted book

Expired Please refer to whether or not the book was published/unpublished: Action not available for a book that is expired

Published Some database information retained, book will not display on Database information retained, book only will show via Zipline or site bookmark and link, not search or navigation

Unpublished All data is removed from the database Action not available for an unpublished book

Book part /chapter

Deleted Delete action not available for an already deleted chapter/part Action not available for a deleted chapter/part

Expired Please refer to whether or not the book part/chapter was published User cannot expire a chapter/part /unpublished:

Published Some database information retained, book part/chapter will not User cannot expire a chapter/part display on Zipline or site

Note: If there is a scheduled replacement, action will not be available until replacement has been published

if the delete is scheduled earlier than the replacement publish, it will fail if the delete is scheduled after the replacement publish, it will succeed

Unpublished All data associated with chapter/part is removed from the User cannot expire a chapter/part database 13. Issue Meta Files

12. Issue Meta Files Issue Meta Details Making Updates to Issue Metadata BR459: BR460: Example Issue Meta Example: Issue TOC Type Example

12. Issue Meta Files

Zipline users have the option to upload a separate issue metadata XML file to provide issue-level data that is not specified in the article XML. This file is optional, and the main purpose of the file is for designating asset files at the issue level and the ordering of the content in the Table of Contents. Issue Meta can be loaded separately from articles for an issue or in the same package. The issue-meta will only load successfully if referencing articles are loaded concurrently or already exist in the database. For more information, please reference the SCJATS Specifications narrative.

Issue Meta Details

Below are the details on formatting for issue-meta files. Included in this file would be an issue TOC to order the articles and place them under headings if desired. This is a meta-data model and not a presentation model; the specific content that should appear on the site's TOC (e.g. title, authors, citation) will not need be included in the issue-meta file. Issue Meta is not required inside of a package. Loading an issue meta completely replaces the previous load of issue meta and any assets that were loaded previously that were associated with Issue Meta. Issue meta XML and assets are not deposited to any third party indexers like Pubmed or Crossref.

Making Updates to Issue Metadata

Recent production releases of Zipline now enable users to update the issue title and issue publication date in the issue meta file:

The 04 Sep 2018 release allows users to set issue title when loading an issue meta file for the first time, or update the issue title for an existing issue. For more information, please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details Logic: New Issue Scenarios

1. Given a new issue that has never been loaded into Zipline: When a user loads the ZIP file for that issue And the ZIP file contains issue_meta with information Then the issue title value is populated with the value from the issue_meta

Replacement Scenarios

1. Given an existing issue that has been loaded to Zipline previously When a user loads a second ZIP file for that issue And the ZIP file contains issue_meta with information Then the issue title value is populated with the value from the issue_meta And the issue title of the existing issue is immediately changed (no swap process) And all articles and all multimedia in that issue are updated to reflect the time of the changed issue title (current Date) so it can be indexed in search The 24 May 2018 release allows users to set issue publication date and issue cover date when loading an issue meta file for the first time, or update the issue publication date/issue cover date for an existing issue. Please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The order of importing issue publication date from the issue meta is if present, and then if not present The order of importing issue cover date from the issue meta is if present, and then , and then is neither are present Logic New Issue Scenarios

1. Given a new issue that has never been loaded into Zipline:

When a user loads the ZIP file for that issue And the ZIP file contains issue_meta with pub-date information Then the issue publication Date value is populated with the pub-date value from the issue_meta 2. Given a new issue that has never been loaded into Zipline: When a user loads the ZIP file for that issue And the ZIP file contains issue_meta with pub-date information Then the issue value is populated with the pub-date value from the issue_meta

Replacement Scenarios

1. Given an existing issue that has been loaded to Zipline previously When a user loads a second ZIP file for that issue And the ZIP file contains issue_meta with pub-date information Then the issue publication Date value is populated with the pub-date value from the issue_meta 1.

And the issue publication date of the existing issue is immediately changed (no swap process) And all articles and all multimedia in that issue are updated to reflect the time of the changed issue publication date (current Date) so that it can be indexed in search 2. Given an existing issue that has been loaded to Zipline previously When a user loads a second ZIP file for that issue And the ZIP file contains issue_meta with pub-date information Then the issues publication date value is populated with the pub-date value from the issue_meta And the issue cover date is immediately changed (no swap process) And all articles and all multimedia in that issue is updated to reflect the time of the changed issue cover date (current Date) so that it can be indexed in search The 25 Oct 2018 release allows allows users to specify in either article meta or issue meta to specify who might have sponsored the issue. For tagging guidance, please see the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details The logic for importing Issue Sponsor information is as follows: In Zipline 3, when a new issue is uploaded and the issue-sponsor element exists within issue-meta with free text only, then the issues.issueSponsor field in the database for that issue contains the free text within the issue-sponsor node and the issue-sponsor element does not exist within issue-meta, then the issues.issueSponsor field in the database contains a null value for that issue In Zipline 3, when a replacement issue is uploaded and the issue-sponsor element exists within issue-meta with free text only, then the issues.issueSponsor field in the database for that issue is updated with the free text within the issue-sponsor node and the issue-sponsor element does not exist within issue-meta, then the issues.issueSponsor field in the database does not change In Zipline 3, when a new article is uploaded and the issue-sponsor element exists within article-meta with free text only, then the issues.issueSponsor field in the database for that issue contains the free text within the issue-sponsor node and the issue-sponsor element does not exist within article-meta, then the issues.issueSponsor field in the database contains a null value for that issue In Zipline 3, when a replacement article is uploaded and the issue-sponsor element exists within article-meta, then it is ignored, and the issues.issueSponsor field in the database does not change In Zipline 3, given a ZIP package for an issue containing at least 1 article XML file and an issue meta When the issue sponsor element is present in both issue meta and the article XML But the value between issue meta and article XML is different Then the value imported into the issues.issueSponsor is the value in the issue meta In Zipline 3, given a ZIP package for an article that belongs to a previously loaded issue When the issue sponsor element is present in the article meta Then the issues.issueSponsor value in the database remains unchanged The 15 Nov 2018 release to Zipline built upon the existing feature by adding a business rule to enforce proper formatting of the XML with this element. We check to make sure that all articles in a package have the same value for issue-sponsor (error) and that issue-sponsor has a value (warning) BR459: 1. Given an issue ZIP package that is loaded to Zipline containing > 1 article XML And > 1 article contains the element But the value of does not match between two articles Then BR459 is displayed as an error message And the package does not complete processing 2. Given an issue ZIP package that is loaded to Zipline containing > 1 article XML file And 1 article contains the element, but the other XML file does not contain Then BR459 is displayed as an error message And the package does not complete processing

BR460: 1. Given a ZIP package that is loaded to Zipline containing either article XML or issue meta or a combination And one or more of the XML file(s) contains the element But the value for is empty or only contains whitespace Then BR460 is displayed to the user as a warning And the package continues processing The 18 Dec 2018 release to Zipline resolved an issue that created duplicate issue records in the database from the following cases: The issue (or volume) was empty in the XML. This created a new issue every single load. A PAP was loaded into an issue and had different information from the issue-meta.xml (e.g. issue-title or publication date) Articles within the same package referencing the same issue number and volume had differing issue-meta information (e.g. issue-title or publication date) The 14 Feb 2019 release to Zipline remediated duplicate issue records created prior to 18 Dec 2018. This ensured that there were no articles tied to the duplicate issue, and the duplicate issues were removed from the database.' The 27 Jun 2019 release introduced new feature self-uri PDFs for the full issue. Users can specify a PDF for the full issue and load it as part of the issue meta file. The 22 Aug 2019 release resolved an issue that was causing some duplicate PDFs to be created upon replacement.

Example

Example package: SCM.newIssueMeta.Articles.MM.2.zip

Issue Meta Example:

123456789 123456789 999 111 Issue Title Issue sponsor August 2012 21 9 2012 regular Canis Dule Miss 1Wrightii Coastal Ecology Lab

Issue TOC Type Example

alpha page A alpha ordinal x ordinal 1 2

14. Continuous Publishing

13. Continuous Publishing Continuous Publication Module in Zipline Continuous Publishing Details Closing and Opening Issues

13. Continuous Publishing

Some journals hosted by Silverchair utilize a Continous Publication model. That means that issues can remain open while additional articles are added to the journal issue over time. When an issue is closed, articles no longer can be added to the issue marked for Continuous Publication. Continuous Publishing is set at the Journal level; therefore all issues in a journal will either be 'traditional' or 'continuous.'

Continuous Publication Module in Zipline

A Continuous Publication can be distinguished on the Top Level Catalog Page by the existence of the button to Open or Close the Issue. For example, a screenshot of a Journal marked open is displayed below:

Below is a screenshot of a continuous publication marked closed:

Continuous Publishing Details

Not all users of Zipline will have the ability to Open and Close issues marked for Continuous Publication. For more information, please reference 7. Access and User Roles.

A Zipline User can click on the Issue title to navigate to the Catalog Detail page and view additional details about the Continuous Publication. Below the Zipline Header, a detail will display that marks the issue as a Continuous Publication:

Closing and Opening Issues

Zipline Users with the relevant roles specified on 7. Access and User Roles will have the ability to either Open and/or Close Issue marked for Continuous Publication. Once an issue is closed, content cannot be added to the issue unless it is reopened. Articles can only be published to an Open issue marked for Continuous Publication.

The 15 Nov 2018 release to Zipline allows users with the proper permissions to add articles into a closed issue. This is important for users who have alerts integrated with the action of opening and closing an issue and would like to publish an additional article into a closed issue without triggering an alert. The following users may publish an article into a closed issue without any errors:

Super User Content Production Manager Content Administrator

For users with role other than Super User or Content Production Manager or Content Administrator: Attempting to publish an article contained in an issue which is closed for continuous publishing returns a 400 Bad Request error from the API

15. Taxonomy

14. Taxonomy Taxonomy Details Taxonomy File Requirements Uploading Taxonomy Considerations with Taxonomy Files Database Considerations

14. Taxonomy

Zipline will allow a user to upload an RDF formatted taxonomy file, save the file, filename, and Taxonomy name to the taxonomies table in the database. This is most commonly used for creating new categories to which articles can be associated with at a later point in the content upload process. Taxonomies are loaded via the API interface of Zipline, which is covered in the subsequent section of the guide.

Taxonomy Details

Not all users of Zipline will have the ability to view or upload taxonomy files. For more information, please reference 6. Access and User Roles.

Taxonomy File Requirements

In order to have a taxonomy file ingestion in Zipline, it must meet the following standards listed below. If you are not sure if your file will be accepted, please contact your Silverchair PDM and they will work with you to determine what is required in order to import your taxonomy file.

The file is an rdf file The file will use rdf, skos, rdfs xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" The file must contain exactly one rdf:Description of type ConceptScheme

preferably at the top for readability, but not required The concept scheme must contain an rdfs:label identifying the taxonomy The concept scheme must contain a skos:prefLabel, this will be the name of the taxonomy that is shown to end users the top concepts must refer to Concepts with the document, these are the first level of your taxonomy eg:

Silverchair Taxonomy Silverchair Taxonomy

each topConcept will be defined in an rdf:Description of type Concept

skos:prefLabel is required, this will be the name of the taxonomy node that is shown to end users skos:note is optional and for readability eg:

Level 1 Taxonomy Creation

each new level of nodes will be defined by an rdf:Description of type Concept

Parentage is defined using skos:broader. A child may only have 1 parent. skos:prefLabel is required, this will be the name of the taxonomy node that is shown to end users skos:note is optional and for readability There is no limit to the number of levels supported, however Usability should be kept in mind when defining the depth of the tree eg

Level 2 Create a Child

Uploading Taxonomy

Uploading Taxonomies can only be completed through the API of Zipline. For more details, please reference that section of this user guide: 16. Using the API Taxonomy Managers for certain clients that have opted into loading taxonomy files will be the only ones who can upload taxonomies. If you are not sure if you are one of those clients, please contact Silverchair Client Services and we can confirm these details for you Taxonomy Manager must first authenticate via the API. This user guide explains how to authenticate using the Postman web application Under 'Content' POST Submit Taxonomy File REPLACE '{ProvideATaxonomyName}' with the taxonomy name. (User must have Taxonomy permissions to perform this call.) SELECT 'Body' and locate the taxonomy file and SEND the request

Considerations with Taxonomy Files

A user must have the user role of 'Taxonomy Manager' before they are able to upload taxonomies Taxonomy file can be imported independently of a content submission (non Zip) Taxonomy file can be replaced in the system by providing the same taxonomy name as an already existing taxonomy The user with a taxonomy manager role may see the taxonomy files uploaded to the system via the API call: http://{{ApiHost}}/taxonomies Database Considerations

Once Taxonomy files are loaded, categories are created in the database using a combined value of the schemeIdentifier and subjectCode.

These can then optionally be associated with specific articles by loading an OxMeta file to Zipline. See 22. Loading OxMeta Files to Zipline for more details If a category does not exist in the database prior to loading an OxMeta file linking category to article DOI, then the article cannot be associated with that category. Categories cannot be deleted with subsequent reloads of taxonomies, only created 16. Using the API

15. Using the API Using the API Using Postman Setup Example PostMan Script Manage your environment Logging In Journals API Useful Calls Get Orphan Report Retry an Orphaned Submission Publish an Issue Unpublish an Issue Publish (or unpublish) an article Books API Useful Calls Publish a Book Publish many book parts Delete a Book Expire a Book Query Book by Author, Title, or ISBN Query All Books: Query by Title Query by ISBN (any of the ISBN values of the book) Query by Authors Trigger Book Deposit Query by Book Parts Query by User via API Query who has loaded a book Query by Submissions Taxonomy API Useful Calls See all taxonomies loaded Load a Taxonomy File Proceedings API Useful Calls

15. Using the API

The Zipline Content tools API (appliation program interface) provides content submission and management services. Having this functionality rather than using the Zipline user interface can prove beneficial and save time when reviewing, loading, or publishing a entire set of content. Some of the actions that you can take in the API include, but are not limited to:

Import new content Track the status of active submissions. Search for specific book and journals content, such as by ISBN, title or author You can update the status of content, such as publishing, unpublishing journals content, or expiring/deleting books content. Finally, the API is the key access point for Zipline content tools. Trigger deposit of a specific piece of content

Using the API

The Content API is directly accessible. Most uses of an API tend to involve writing a custom program, but there are a few tools that let you accomplish custom requests. The API provides content submission and management services. Using the API, you can import new or updated content, and you can track the status of active submissions. Most uses of an API tend to involve writing a custom program, but there are a few tools that let you accomplish custom requests. Silverchair recommends utilizing Postman (a Chrome extension). Another very popular tool is Curl. Other tools may be utilized based on the publisher's preference. If a Zipline user has trouble accessing or setting up the API after reading through the documentation, they can contact Silverchair Client Services for help on configuring the service. Please note that questions on the specific application used to interact with the API (using Postman, using Curl, etc) should be directed to the support group for that piece of software.

Using Postman

This guide will describe how to interact with the Content API using the Postman application. Not all users of Zipline will have the ability to perform all actions in the API. For more information, please reference 6. Access and User Roles. If a user does not have a Zipline account, then they will not be able to interact with the Content API.

Setup

Get Postman (via Chrome) Download Postman here: https://www.getpostman.com/ You can also search for it on the Chrome Web Store, however we don't recommend using this non-native Chrome version.

Import the collection Open Postman Import both the the latest ".postman_collection" file and the postman_environment file into the postman application - you can find it here: I:\Client Services\Postman\Environments

If you do not have either of these, please contact Silverchair Client Services at [email protected] NOTE TO CLIENTS (especially superusers): Be careful when using these calls - please refrain from depositing via the API. If you would like to see all possible API calls, please navigate to the following URL

{{Content API URL that you receive from Client Services}}/docs/index#/ Below is an example:

New installs of the native Postman app come with SSL Certificate verification switched ON in settings. Environments may not connect correctly if this is ON. If you're performing a new install of Postman, switch this OFF in settings.

Example PostMan Script

You can find environment scripts here: PROD_contentAPI_postman_environment.json then load files into the PostMan Environment

Click on the import button and choose each file to be imported into the environment

Click Import You should now have a Harness API collection.

Manage your environment

Press the gear button on the top right and click 'Manage Environments' Click on the environment that you just imported You will need to update the following values to be specific to you instance of Zipline: Environment Name Title (the name of your environment) YourPassword (Your Zipline password) YourUsername (Your Zipline username) YourClientID (request from Client Services for the specific client) APIHost (request from Client Services for the specific API Host)

Change the 'UPDATETHIS' fields to values so that you can log into the API For example, if you were using the Content API for a given client, you would change them to something like this:

Logging In

Click on the Collections Tab and click Log In under the Authentication folder: Click the send button to get a response. You should see values for both the access_token and the refresh_token If you are getting an error message like this...

you should check what you have for the authentication values for the environment. Is your username/password incorrect? Do you have the correct ApiHost? Is https:// used in the hostname? If not, you may need to include it in the authentication

Keep track of the 'access_token' and 'refresh_token' values. You will need these when performing further actions with the API. access_token value must be copied into the 'Token' field in manage environments refresh_token value must be copied into the 'RefreshToken' field in manage environments To finish logging in, select the access token (everything within the “”) and right click it to pull up a modal. From there, you can set the value as the Access Token. You can do the same for the Refresh Token.

Journals API Useful Calls

This does not describe the full list of actions that can be done in the API for Journals. If you need more information or have a question about a particular call, please reach to Silverchair Client Services and we can work with you to resolve any questions.

Get Orphan Report

Click on the Collections Tab and click Log In under the Authentication folder: Click Send to log in Copy the refresh_token and access_token values and put them into the RefreshToken and Token values respectively in Manage Environments Click on the Collections Tab and click Orphan Report under the Content Submission folder Press the send button You should see output like this:

Retry an Orphaned Submission

Click on the Collections Tab and click Log In under the Authentication folder: Click Send to log in Copy the refresh_token and access_token values and put them into the RefreshToken and Token values respectively in Manage Environments Click on the Collections Tab and click Retry an Orphaned Submission under the Content Submission folder You need the SubmissionKey value to retry an orphaned submission. Go into the database (or ask a member of Client Services) and use this query (you'll need the package ID): -- update this statement based on the client shortname USE Content_Submissions_CLIENT SELECT submissionID,submissionKey,[FileName] FROM submissions -- replace package ID below with the value you need WHERE submissionID = 135813 Click Manage Environments and paste the submissionkey into your environment. Press send and you should see a status code of '200' (OK) as a result. This screenshot means it worked

Publish an Issue

Click on the Collections Tab and click Log In under the Authentication folder: Click Send to log in Copy the refresh_token and access_token values and put them into the RefreshToken and Token values respectively in Manage Environments Click on the Collections Tab and click Update (publish) an Issue under the Content Folder In the center of the screen, copy the content item key from the catalog in Zipline and paste it over the value

You should receive a message like this:

Refresh Zipline and see that the issue is published Unpublish an Issue

Click on the Collections Tab and click Log In under the Authentication folder: Click Send to log in Copy the refresh_token and access_token values and put them into the RefreshToken and Token values respectively in Manage Environments Click on the Collections Tab and click Update (publish) an Issue under the Content Folder In the center of the screen, copy the content item key from the catalog in Zipline and paste it over the value Click on the Body tab in the center of the screen and change the value to 'null' Press the Send command Refresh Zipline and see that the Issue is unpublished

Publish (or unpublish) an article

Click on the Collections Tab and click Log In under the Authentication folder: Click Send to log in Copy the refresh_token and access_token values and put them into the RefreshToken and Token values respectively in Manage Environments Click on the Collections Tab and click Update (publish) an article under the Content folder

In the center of the Postman application, you'll need to enter a ContentItemKey. If you're not sure, please contact Silverchair ClientServices at sup [email protected] and provide the DOI for the article. Copy the ContentItemKey and paste over the value in Postman Press Send and you should see a screen like this:

If you want to unpublish the article, just click on body in postman and change the value to 'null' for ActiveDate Check Zipline and confirm that the article has been unpublished: Books API Useful Calls

This does not describe the full list of actions that can be done in the API for Journals. If you need more information or have a question about a particular call, please reach to Silverchair Client Services and we can work with you to resolve any questions.

Publish a Book

The API call to publish a book is http://{{ApiHost}}/books/{{ContentKey}} with a PUT command, where the ContentKey is the book's suffix part of the URL in the Catalog Details Page. Simply press the gear box icon and paste ContentKey into the field for the environment that you are using, after you have refreshed authentication and pasted the updated Token and RefreshToken. After sending the command in the API, refresh the books catalog page to see the change in status.

Publish many book parts PUT command: {{ApiHost}}/book-parts/update and list the ContentKeysIDs as a comma separated list

It is possible to update a listing of book parts by adding query parameters to the API command. Examples are below:

/book-parts/update?ActiveDate=now&BookId=241&PublisherId=bio1 /book-parts/update?ActiveDate=2019-06-28&BookId=241&PublisherId=ack1

Delete a Book

The API call to publish a book is http://{{ApiHost}}/books/{{ContentKey}}/delete with a PUT command, where the ContentKey is the book's suffix part of the URL in the Catalog Details Page. Simply press the gear box icon and paste ContentKey into the field for the environment that you are using, after you have refreshed authentication and pasted the updated Token and RefreshToken. After sending the command in the API, navigate to the Books Top Level Catalog Page to see that the book has been removed from the UI.

Expire a Book The API call to publish a book is http://{{ApiHost}}/books/{{ContentKey}}/expire with a PUT command, where the ContentKey is the book's suffix part of the URL in the Catalog Details Page. Simply press the gear box icon and paste ContentKey into the field for the environment that you are using, after you have refreshed authentication and pasted the updated Token and RefreshToken. After sending the command in the API, refresh the books catalog page to see the change in status.

Query Book by Author, Title, or ISBN

Like you can search for Author, Title, or ISBN on the Catalog Top Level Page, you can accomplish the same searches in the API. The below screenshots show the queries in GET format that you can use to query by title, author, or ISBN.

Query All Books:

{{ApiHost}}/books/? as a GET command

Query by Title

{{ApiHost}}/books/?title='Enter Title Here' as a GET command Query by ISBN (any of the ISBN values of the book)

{{ApiHost}}/books/?ISBN='Enter ISBN here' as a GET command

Note: the full ISBN must be entered as it was formatted in the XML. Partial ISBN searches will fail

The 18 Jul 2019 to Zipline update this API command so that when users query using this call, there is additional information returned: Collections (one or more) Example: {{ApiHost}}/books/?Collections=OSO Publisher Example: {{ApiHost}}/books/?publishers=University of Chicago Press Series (one or more) Publisher ID () (you can search by more or more using comma separated values) Example: {{ApiHost}}/books/?publisherids=med-9780195,med-978234,med-978567 ISBN (displaying the ISBN13 value if there is not ISBN13 value present, then the EISBN value is displayed, If there is neither ISBN13 nor EISBN, then the ISBN10 value is displayed) User (one or more, comma separated list of who loaded a package belonging to the book Example: {{ApiHost}}/books/?users=6071397 Load Date (UTC) Contains Versions (a boolean value to indicate if the book contains versioned book parts)

Query by Authors

{{ApiHost}}/books/?author='Enter Author Name' Trigger Book Deposit

{{ApiHost}}/books/{{ContentKey}}/deposit

The content Key can be obtained from the URL when viewing the book's Catalog Details page

Query by Book Parts

GET command: {{ApiHost}}/book-parts/{{BookID}}?{{filteringparameter}}={{value}}

You can use the following filtering parameters when querying this way: version publisherID users submissionProcessedDateFrom submissionProcessedDateTo

Examples:

Query by User via API

Query who has loaded a book

GET command: {{ApiHost}}/users/contentItem?contentItemID={{ContentItemID}} Query by Submissions

GET command: {{ApiHost}}/submissions?{{parameter}}={{parametervalue}}

Available parameters to filter submissions include: Collections (one or more) (categorytype = "collection") Publisher(s) (books.publisher) Series (one or more, categorytype="series") Publisher ID ( or ) User (one or more, comma separated list of who loaded a package belonging to the book ISBN (one or more, comma separated list of ISBN13, EISBN, or ISBN10 values) Example: query by submissions belong to book collections:

Example: query by publisherID of book and publisher: Example: query submissions by users

Taxonomy API Useful Calls

See all taxonomies loaded

Use the "Retrieve all taxonomies" call to see all taxonomies loaded to the system.

GET command: {{ApiHost}}/taxonomies

Sample response: { "FileName": "adapta.rdf", "TaxonomyName": "adapta", "LastModifiedDate": "2016-10-22T02:09:37.413" }

The TaxonomyName field shows you the taxonomy name that was assigned to the taxonomy when it was first loaded. If you plan to load a replacement taxonomy, it's a good idea to check the existing TaxonomyName to ensure the replacement works, and you do not inadvertently create a brand new taxonomy.

The lastModifiedDate field is an indicator of the last time a file was uploaded, which is a useful way to confirm that a taxonomy file has been successfully loaded (see "Load a Taxonomy File" below).

Load a Taxonomy File

POST command: {{ApiHost}}/taxonomies?taxonomyName={{EnterNameofTaxonomyFile}}

If you plan to load a replacement taxonomy, it's a good idea to check the existing TaxonomyName using the to ensure you replace the correct taxonomy, and you do not inadvertently create a brand new one. Refer to "See all taxonomies loaded" above for instructions on how to do this.

Remember to authenticate first before performing this post command. Also adjust the Body and choose your Taxonomy file using the file picker:

The 18 Jul 2019 release resolved an issue where users with role of Taxonomy Manager were unable to authenticate and successfully upload a taxonomy file

Proceedings API Useful Calls

The 24 Jan 2019 release to Zipline modified the Zipline API to perform requests to query and display volumes, proceedings, and conference series. Below are the following actions that you can make to search and filter for proceedings information:

/volumes - Will be used after clicking the "Conferences" dropdown - A list of all volumes is returned (paginated by default of 20) that contains at least the following information: - ConferenceVolumeTitle - ContentItemId - ActiveDate - OpenStatus - UpdatedDate - ContentItemKey - ShouldContain ConferenceVolumeContentItem with the ConferenceVolume with data from SCM6

/volumes/{contentKey} - Used to load the conference volume information after clicking on a specific volume from the catalog page - Should return at least the following information: - ConferenceVolumeTitle - ContentItemId - ActiveDate - OpenStatus - UpdatedDate - ContentItemKey - ShouldContain ConferenceVolumeContentItem with the ConferenceVolume with data from SCM6

/volumes/{contentKey}/HasProceedingWithError - Used for front end checks - Should contain the object ConferenceVolumeHasProceedingWithError, which contains a boolean value

/volumes/{contentKey} PUT - Used to publish/unpublish - Sending with the ActiveDate key and either null, now, or a date as the value - Value returned should be contentItemEntity for the published version - Should publish all proceedings within volume - Unpublishing will not unpublish any child content items

/volumes/{contentKey}/deposit - Adds depositQueue record for that proceeding - Must pass in "DepositTypeIds" key, containing a comma delimited list for the value

/proceedings - Used to get list of proceedings (paginated by default of 20) - Can pass in conferenceVolumeId to retrieve the proceedings for a specific conference volume - Should return the contentItemEntity for the proceeding

/proceedings/{contentKey} PUT - Used to publish/unpublish - Sending with the ActiveDate key and either null, now, or a date as the value - Value returned should be contentItemEntity for the published version - Should publish all parent content items including session, volume, and conference. - Unpublishing will not unpublish any parent content items

/proceedings/{contentKey}/deposit - Adds depositQueue record for that proceeding - Must pass in "DepositTypeIds" key, containing a comma delimited list for the value

/conferences/series - Returns all conference series for a client

/conferences/{conferenceSeriesId} - Returns all conferences for a particular series

PUT

{{instance}}/issues/{{issueContentKey}}/open {{instance}}/issues/{{issueContentKey}}/close Header: [{"key":"Authorization","value":"Bearer {{token}}"}] No parameters need to be passed in the body. This will close or open an issue associated with a proceeding 17. Downstream Deposit Services

16. Downstream Deposit Services Radiate Service Available services Other Details Other Details Notes Notes Notes Notes Journals Books Radiate Workflow Depositing New Content Depositing Replacement Content Triggering Deposits

16. Downstream Deposit Services

When content is published within the Zipline tool, the source XML as well as assets (PDF, images, supplementary material) can be queued up for deposit to a number of downstream deposit services. Silverchair currently supports downstream deposit of journals content to the following services: AGI (American GeoSciences Institute), ADS (Astrophysics Data System), CDS (Centre de Données astronomiques de Strasbourg), Crossref, EBSCO GVPi, Pubmed, Pubmed Central, Portico, Proquest, PTEP SCOAP-3, OVID, and RSuite. Other services can be configured based on a publisher's specific needs.

Based on the services established with the downstream provider, Silverchair deposits metadata about the content (such as title, DOI, authors) or full text XML (all relevant content) during deposit. This deposit tool exists to support full-text archival and citation services. Each downstream deposit provides batch mode with structured delivery formats. The details and formatting of the content may change based on the endpoint utilized.

Radiate Service

Zipline utilizes the "Radiate" service to make full text and metadata deposits for specified services for content, after the content has been published on Zipline. Downstream Deposits are dependent on publication of content in Zipline and correct configuration of deposit services in the Sitebuilder configs. For more information, please reference 6. Access and User Roles, 9. Publish Content, and 17. Edit Journal Publishing Information.

Available services

Below is the list of available services on the Silverchair Platform. This list may change as services are added or modified. The FTP Configuration Details list additional information on where the submissions are deposited. The username and passwords used to make the deposit are excluded from the user guide for security reasons, but if you would like more information, please submit a request to Silverchair Client Services.

Name Endpoint Content What's Documentation/Details Types Deposited Supported

ADS ftp://adsftp. Journal Articles Full-text - the ADS is a Digital Library portal for researchers in Astronomy and Physics, operated by the Smithsonian. ADS tracks citations and usage of its records to provide advanced harvard.edu full body of the discovery and evaluation capabilities. Integrated in its databases, the ADS provides access and pointers to a wealth of external resources, including electronic articles available XML and all from publisher's websites, astronomical object information, data catalogs and data sets hosted by external archives. ADS currently have links to over 11.1 million records assets maintained by its collaborators.

Other Details

The 07 Dec 2017 release modified the deposits of ADS and CDS to package issue articles into separte zip files with a naming convention change to include the articleID and revision history filename allowing deposit submission name to be unique and continuous publication articles to be sent on their own and not with other articles that have been sent already. CDS ftp://cdsarc.u- Journal Articles Full-text - the CDS Stands for (Centre de Données astronomiques de Strasbourg) strasbg.fr full body of the XML and all assets Other Details

The 07 Dec 2017 release modified the deposits of ADS and CDS to package issue articles into separte zip files with a naming convention change to include the articleID and revision history filename allowing deposit submission name to be unique and continuous publication articles to be sent on their own and not with other articles that have been sent already.

CrossRef http://doi. Journal Metadata in http://help.crossref.org/deposits crossref.org articles, Crossref format /servlet proceedings http://help.crossref.org/deposit_schema /useragent? articles, books func=showHo me Notes

The 05 Oct 2017 release modified submission of XML with string (eg 'September') cover dates so that when cover date is provided as a string in the XML, the submission to Crossref converts the string into into an integer. For more details, please see https://data.crossref.org/reports/help/schema_doc/4.3.0/4_3_0.html and search for 'Element month' The 04 Jan 2018 release modified Crossref submission to specify editors tagged with in the XML as contributor_role="editor" in the Crossref submission. This differentiates editors from author contributors. For more information, please reference: https://support.crossref.org/hc/en-us/articles /214567746-Authors-and-editors The 25 Jan 2018 release adjusted the Crossref deposit service for journals content, including changes to resolve submission failures for a.) funding information, b.) multiple tags in article references, c.) multiple elements, d.) multiple in the original XML, e.) and a change to use the organization element when tags are used in the XML. An issue was also resolved in the Crossref deposit service for the GSW client to use the proper resource URL associated with the DOI The 15 Feb 2018 release updated the Crossref deposit service to include author affiliations and break down each affiliation in a separate affiliation element tagging to comply with Crossref specifications The 28 Mar 2018 release redeposited article content that had previously failed based on issues that were resolved in the prior production releases, and because of duplicated published DOIs. This allows a greater amount of content to be indexed by Crossref and available by querying the API. Lastly, this production release also adjusted Crossref submissions to include license metadata in the AccessIndicators section of the submission. For more information, please reference the Crossref support article The 03 May 2018 release Implemented a scheduled task to update the database daily with a list of the funders on the Crossref Open Funder Registry and funding agencies with Public Access Plans. For more information, please reference this Crossref support article. The release also included an activity to supply license metadata for applicable content as part of the submission to Crossref. The 14 Jun 2018 release resolved an issue where a blank element was included for volumes with no issue. After the change, the element was excluded and related Crossref submissions were successful The 19 Jul 2018 release resolved an issue causing some Crossref submissions to fail by encoding the URLs associated with submissions that were tied to spaces in the issue number The 04 Oct 2018 release improved deposits to use a timestamp value that includes milliseconds. This allows the service to deposit submissions with higher priority than previous submissions from other platform providers The 25 Oct 2018 release to Zipline improved submissions by encoding special characters and using Crossref designated face markup in the submission files. The 18 Dec 2018 release to Zipline removes sub-nodes from in so that the submission is accepted by Crossref The 21 Mar 2019 release to Zipline improves logging of Crossref deposits and stores additional information on failures and warnings in the Silverchair database, to continue to improve existing downstream deposit processes In the 11 Apr 2019 release to Zipline: Crossref deposits for proceedings and articles were adjusted so that URLs are included that allows funders to index the content In the 02 May 2019 release to Zipline: Crossref deposit support for proceedings content is released Crossref submissions will include the Electronic Location Identifier for articles that do not have traditionally printed page numbers, for example, “E70.” This change enhances support for online-only and online-optimized journal content. For more information on the markup to be included, please reference this Crossref support article. The Crossref deposit service is updated to include Crossmark metadata, whenever a Crossmark-enabled client loads content with Crossmark-valid tagging. Please see https://support.crossref.org/hc/en-us/articles/115000108983-Getting-started for more details Start_date logic in Crossref license metadata was adjusted so that: When content contains license metadata that maps to an article or proceeding that is free, the 'free_to_read start_date' and the license ref applied to start_date both match the activeDate of the article When content contains license metadata that maps to an article or proceeding that is private, then: if the content is tied to a funder with a 12 month embargo, then calculate 1 year from the article date and use that date for the 'free_to_read start_date' and the license ref applies to start_date If the content is not tied to a funder with a 12 month embargo, then the element is excluded from the Crossref deposit and the license ref applies to start_date matches the article active_date In the 06 Jun 2019 release to Zipline: Proceedings: submissions were updated to include conference_sponsor element from the use of (default), and (if conf-level-2 is not present) Ensure that element in the submission includes the full range of dates described in the XML Include author affiliations in submissions when present in the XML Include ISBN value in proceedings and element if there is not an ISBN value Journals: The Crossref XSLT now lists ISSN values from article references only once per reference in Crossref submission XML. In the 27 Jun 2019 release to Zipline: JATS formatted abstracts are now included for both proceedings and journals in the format defined by Crossref: https://support.crossref.org/hc/en-us/articles /213126186-NLM-JATS-abstracts Removed self closing tags from Crossref submissions Include DOI in citations when it is present in the XML Enabled supplying more than 1 conference sponsor (up to 10) in proceedings deposit files For articles that do not contain a PDF, the property containing the iParadigms URL uses the URL for the full text article Updated deposit service to supply all supported contributor types: author, editor, chair translator Resolved a bug where more than one in the XML was causing deposit failures. This was resolved by combining the elements into one citation list element in the submission. In the 18 Jul 2019 release to Zipline Journals and Proceedings: 1. Silverchair now includes for ORCID authenticated authors when present in the XML Proceedings 1. Designate media_type for ISBN values in proceedings 2. Limit use of conference_number element to top level conferences only Journals: 1. Exclude media-type="online" attribute from the submission when the journal belongs to a continuous publication model, 2. Exclude elocation ID belonging to the references of the article from the In the 22 Aug 2019 release to Zipline Proceedings: Given a proceeding article that is loaded to Zipline And the article does not include as a child of Then a Crossref deposit is generated successfully without the element And the xml submission passed the Crossref XML validator Given a proceeding article that is loaded to Zipline And the article does include as a child of Then a Crossref deposit is generated successfully with matching the value in the XML And the xml submission passed the Crossref XML validator In the 12 Sep 2019 release to Zipline Articles that are configured for Crossmark deposits without a node matching one of the related-article-types that Crossmark accepts will not have an element as part of the submission. This is valid with Crossref standards Articles and proceedings that specify , or will have their abstract supplied to Crossref in valid JATS format. In the 03 Oct 2019 release to Zipline: Update Crossref deposits to handle ali:license_ref and ali:free_to_read If the article xml contains the xpath article/front/article-meta/permissions/ali:free_to_read the CrossRef transform renders the ai:free_to_read node using the start_date from the source xml and end_date (optional if provided) otherwise use free_date XSLT parameter if it's not empty else use the article_activedate Given the source article xml contains the Xpath /article/front/article-meta/permissions/license/ali:license_ref the CrossRef transform renders the ai: license_ref and is populated using license_ref inner node text. Resolve an issue where the iParadigms element was not present for PAP articles. With this change, both PAPs and Issue articles have the following structure in the element: DOI Full text article URL PDF URL (article URL if PDF is not present) PDF URL (article URL if PDF is not present)

In the 07 Nov 2019 release of Zipline: Resolved an issue that prevented some articles from generating valid Crossmark metadata with a date value in node when the article belongs to an accepted Crossmark type Improved Crossref deposit submissions to use the journal title aligned with the article publication date (instead of always picking the latest journal title on hand in the database). This ensures that the ISSN and Journal title used in the submission will match In the 05 Dec 2019 release of Zipline When a CrossRef deposit has an exception thrown during the transform, the exception is logged in the database and the deposit is marked as failed. This helps to identify the causes of some Crossref deposit failures due to how the XML was constructed Resolved Crossref issue causing some Crossmark valid articles with information to use the incorrect date in the node In the 09 Jan 2020 release of Zipline Improved the Crossref XSLT for clients using the latest interface of Zipline so that: 1. when the dash of the ISSN value is encoded in the references section of an article or a proceeding, the ISSN value is generated using a dash and accepted by Crossref 2. If an article contains >1 ali:license_ref element, then the URLs are separated into their own elements and accepted by Crossref 3. if an article contains both a teaser and an abstract, then the abstract is supplied to Crossref 4. proceedings exclude the eISBN value unless no ISBN is provided In the 13 Feb 2020 release of Zipline Additional clients were set up to receive daily submissions to a specified email address of all of the successful and all of the unsuccessful Crossref submissions made in the previous day. This can be helpful to end users because the unsuccessful submissions include the error message that was supplied by Crossref. It can indicate changes in the sourceXML that are required before the content can be deposited (for example, an invalid ORCID for an author) The following elements under contributors are stripped from the deposit if they are blank or empty: ,, , and . Previously content failed to deposit to CrossRef with a minLength error if there are self-closing or empty tags for these elements. This reduces the number of unsuccessful submissions that we receive. When a client uses related-article-type = "corrected-article," we did not deposit it to CrossRef with an node because this is not a Crossmark valid type ("correction" is valid). With this change, we treat "corrected-article" as "correction" and that enables the Crossref deposit to include important Crossmark metadata PMC-Full ftp://ftp- Journal articles Full-text - the private.ncbi. full body of the Tagging Guidelines: https://www.ncbi.nlm.nih.gov/pmc/pmcdoc/tagging-guidelines/article/dobs.html#dob-procinst nlm.nih.gov/ XML and all https://www.ncbi.nlm.nih.gov/pmc/pub/filespec/ assets

The 08 Mar 2018 release resolved an issue where users with Unix systems were unable to correctly extract the ZIP files. This applies to PMC-NIH and PMC-Selective services as well. The 18 Jun 2018 release resolved an issue where invalid credentials caused submissions to fail deposit to the external FTP. Adjusting the credentials to their proper values resolved the issue.

PMC-NIH ftp://ftp- Journal Articles Full-text - the private.ncbi. full body of the Tagging Guidelines: https://www.ncbi.nlm.nih.gov/pmc/pmcdoc/tagging-guidelines/article/dobs.html#dob-procinst nlm.nih.gov/ XML and all https://www.ncbi.nlm.nih.gov/pmc/pub/filespec/ assets

PMC- ftp://ftp- Journal Articles Full-text - the Selective private.ncbi. full body of the Tagging Guidelines: https://www.ncbi.nlm.nih.gov/pmc/pmcdoc/tagging-guidelines/article/dobs.html#dob-procinst nlm.nih.gov/ XML and all https://www.ncbi.nlm.nih.gov/pmc/pub/filespec/ assets

Portico ftp://ftp. Journal Articles Full-text - the http://www.portico.org/digital-preservation/services/preservation-approach/preservation-step-by-step#step5 Article portico.org/ full body of the XML and all This is specific to PAP (Advance Articles) assets

Portico ftp://ftp. Journal Articles Full-text - the http://www.portico.org/digital-preservation/services/preservation-approach/preservation-step-by-step#step5 portico.org/ in an issue full body of the XML and all This is specific to Issue Level Content assets

Portico ftp://ftp. Books Metadata in 27 Jun 2019 begun support for Portico ebook deposits, supplied as Crossref XML metadata and PDFs if available Book portico.org/ Crossref format + PDF

PTEP ftp://ukftp.oup. Journal Articles Full-text - the SCOAP3 com/ full body of the “SCOAP3 Articles” shall mean: have ‘Funded by SCOAP3’ included in their xml that comes in with the permission tagging XML and all assets

PubMed http://ftp- Journal articles Metadata in private.ncbi. Pubmed format https://www.ncbi.nlm.nih.gov/books/NBK153385/#PubMed.Electronic_Data_Submission nlm.nih.gov/ XML Tagging Format: https://www.ncbi.nlm.nih.gov/books/NBK3828/#publisherhelp.PubMed_XML_Tagged_Format

Notes

The 28 Mar 2018 release adjusted the submission files for Pubmed to supply the EISSN value when a journal does not include an ISSN value. Pubmed deposits a different format for PAPs/JAMs than issues When content is published in Zipline in production, it will be queued for deposit to Pubmed if it meets the following criteria:

Journal is configured to deposit to Pubmed Article is an eligible article type If the article is a PAP, it does not already exist on Pubmed If the article is in an issue, it does not already exist on Pubmed The tool will not generate replacements for PAP content which already exists in the aheadofprint status, nor will it generate replacements for issue content which already exists in ppublish status. The 24 Jan 2019 release ensures that articles with more than one abstract only receive the authored abstract in the deposit. It also ensures the publication dates follow Pubmed logic requirements The 14 Feb 2019 release to Zipline enabled automated Pubmed deposits ensuring that content supplied to the Pubmed FTP endpoint is compliant with the Pubmed DTD. The 02 May 2019 release to Zipline: resolved an issue were multiple in the article XML created >1 element and also supported the use of tagging for collaborators belonging to a group. Upgraded the Pubmed DTD to the latest version (2.8) In the 18 Jul 2019 release to Zipline Added support for the element in article submissions when there is an abstract with specific-use="layperson" present. The corresponds with Pubmed's directive that the OtherAbstract element can contain a plain language summary if the type attribute is "plain-language-summary" In the 22 Aug 2019 release to Zipline: the logic of the Pubmed deposit service was changed so that if a 429 error is returned when deposits are occurring, we save the error message to the database and attempt to supply them again 6 hours in the future. XSLT logic was adjusted to remove empty self closing element when there are no GroupList members to deposit to Pubmed In the 07 Nov 2019 release to Zipline: Improved Pubmed submissions to include Conflict of Interest and Equal Contribution elements In the 13 Feb 2020 release to Zipline: An improvement was added to the deposit service to prevent backfile content from being sent to Pubmed. If the article publication date for content is greater than 2 years in the past, then it will not be sent to Pubmed. This was completed in order to comply with Pubmed's request to not supply backfile content expept under special circumstances. This applies to submissions for PAPs/JAMs as well as issue submissions OVID http://producer Journal Articles Full-text - the Article .ovid.com/ full body of the http://www.ovid.com/site/platforms/ovidsp.jsp XML and all This is specific to PAP (Advance Articles) assets OVID http://producer Journal Articles Full-text - the .ovid.com/ in an issue full body of the http://www.ovid.com/site/platforms/ovidsp.jsp XML and all This is specific to Issue Level Content assets RSuite ftp://ukftp.oup. Journal Articles Full-text - the Article com/ full body of the This is a specific deposit service that is then used to send content to other services. XML and all This is specific to PAP (Advance Articles) assets

RSuite ftp://ukftp.oup. Journal Articles Full-text - the com/ in an issue full body of the This is a specific deposit service that is then used to send content to other services. XML and all This is specific to Issue Level Content assets Notes

The 24 May 2018 release investigated an issue where some ZIP files delivered to the location contained 0 bytes. These files were re-delivered with their full contents. The likely root cause was that the service could not connect to ftp://ukftp.oup.com during the time of the issue. The 05 Feb 2019 release will resolve an issue where issue level deposits were not being sent for this service. This fix will also resend the failed issues since 12/18/2018

AGI ftp://ftp.georef. Journal articles Metadata in org/ Pubmed format AGI stands for American Geological Institute - article metadata is deposited to AGI when new content is published and configured for this service.

Crossref http://doi. Books Metadata in Book crossref.org Crossref format Crossref Documentation /servlet http://help.crossref.org/deposits /useragent? http://help.crossref.org/deposit_schema func=showHo https://support.crossref.org/hc/en-us/articles/213125186-Books-and-book-chapters me To see an example of a book metadata submission, scroll to the examples section Additional Details Deposits to Crossref will include both book level metadata and chapter level metadata A DOI must be included for a successful deposit to Crossref. It is not possible to submit DOI information for individual chapters without assigning a DOI to the entire work. If a book's title, DOI, or publisher prefix needed to change after submission to Crossref (publication to Zipline), you would need to contact Crossref directly to make a change to their system. Notes The 03 May 2018 release adjusted book deposits to include the subtitle element outside of the title element and in accordance with the Crossref specification

The 09 Aug 2018 release to Zipline enabled users with the role of Super User to trigger book deposits to Crossref by running an API command. For more information, please reference: 16. Using the API The 25 Oct 2018 release to Zipline improved the Crossref Book deposit service to include details behind a book deposit failing XML validation. This is especially helpful when troubleshooting the cause for a book deposit that doesn't successfully resolve yet This release also includes citation list and citation name in Crossref books submissions, which are references included with the book The 18 Dec 2018 release to Zipline resolves an issue where published books were not being submitted to the Crossref endpoint The 27 Jun 2019 release updated deposit service to supply all supported contributor types: author, editor, chair translator The 07 Nov 2019 release to Zipline aggregates Crossref book deposits when chapters are published one at a time so that the resource URLs are valid. With this change, one book deposit is generated after a series of chapters are published (as opposed to many Crossref book deposit submissions when chapters are published individually)

Crossref http://doi. Journal articles Metadata in Secondary crossref.org Crossref format Crossref Documentation URL /servlet https://support.crossref.org/hc/en-us/articles/215776423-Getting-started-with-multiple-resolution /useragent? Additional Details func=showHo When articles belonging to a journal flagged for secondary deposit to Crossref, they are compiled into a specific format matching https://www.crossref.org/xml- me samples/mr_secondary.xml The Radiate service first queries CrossRef to determine whether the DOI is registered before attempting to register a secondary URL. CrossRef supports multiple URL registrations per DOI, but the primary content deposit must be performed before a secondary URL registration is possible.

Notes

The 28 Mar 2018 production release adjusted the user credentials to utilize the silver_mr username, which has permissions to make DOI references deposits. This allows content where Silverchair is designated as the secondary depositor to be accepted by Crossref sucessfully The 07 Nov 2019 release to Zipline ensures secondary DOI deposits for articles are supplied when published The 05 Dec 2019 released a new deposit feature to register secondary URLs for books and book chapters where the Silverchair platform is designated as the secondary depositor of the content. In the umbrella config for Sitebuilder, clients can specify DOI prefixes for books that will be deposited with secondary URLs and can also specify the label associated with the secondary deposit. Please notify Silverchair if you intend to use this feature and we can consult with you on the requirements. GVPi ftp.gvpi.com Journal and Full-text - the Contact information: http://www.gvpi.com/ (Global Books full body of the Village XML and all Publishing) assets Journals

ZIP files can be provided for each journal article, with the following naming conventions:

PAP: JournalShortName_pap_publisherID JAM: JournalShortName_jam_publisherID Articles in an Issue: JournalShortName_volumenumber_issuenumber_publisherID Articles in an Issueless issue: JournalShortname_vol_volumenumber_publisherID Articles in an Volumeless issue: JournalShortname_iss_issuenumber_publisherID

Each zip file contains XML and Asset folders containing the assets and XML for a given journal article

Subdirectory structure:

journals subdirectory Publisher subdirectory Journal subdirectory ZIP file for each article

Books

ZIP files can be provided for each book, with the following structure and naming conventions:

books subdirectory Publisher subdirectory ZIP file for each book package, titled with the ISBN number If ISBN is Null, use EISBN value If EISBN is Null, use ISBN10 value

Proquest ftp://ftp. Books Full text book 18 Dec 2018 Service supported on Zipline summon. XML, no serialssolution assets, s.com separated by:

part chapter replaceable units in: front-matter book-back EBSCO mft. Books Full-text - the 18 Dec 2018 Service supported on Zipline ebscohost. full body of the com XML and all /EFTClient assets /Account /Login.htm EBSCO ftp://192. Journal articles Metadata in 24 Jan 2019 service first supported on Zipline. The service deposits article metadata for articles in an issue only, in a format similar to Pubmed. Assets are not provided. The Articles 73.31.75 in an issue Pubmed format file structure is as follows:

DUP folder

Journal shortname folder Volume and Issue folder (Journal short name + v + volume number + i + issue number) Articles within the issue Azure Configuration Journal Third locations to articles, Full text Released Third Party deposits tool 06 Jun 2019, which can be set up to deposit 4 types of metadata to an external FTP location upon request Party an external Proceedings, XML In the 07 Nov 2019 release to Zipline: Deposit FTP Books and Set up Azure full text articles and assets, and full text books and assets for a new client Service assets Set up Azure support of article metadata submissions for Proquest and OCLC for an existing client for For Portico book deposits (using the metadat + PDF option), the DOI will be included in the PDF filename if the chapter or book has a DOI journals In the 05 Dec 2019 release to Zipline: and Enable existing client to deposit full text issue level content to OCLC and Proquest during the Azure Functions Third Party deposit service proceedi In the 09 Jan 2020 release to Zipline: ngs and Enabled new client to deposit Full Text + All Assets to a specified FTP endpoint via the Azure Functions Third Party deposit service books In the 13 Feb 2020 release to Zipline: Full text Resolved issue preventing the deposit services using CrossRefMetadataAssetsConferenceVolume from receiving content deposits to the designated endpoint. XML for Previously, deposits were failing due to a required parameter, 'articleDate'. Removing this requirement enabled the deposits to continue as intended journals and proceedi ngs XML metadat a only for journals (in Pubmed format) and proceedi ngs (in Crossref format) XML metadat a + PDFs for journals (in Pubmed format) and proceedi ng (in Crossref format) XML metadat a + PDFs (in Crossref format) for books

Radiate Workflow

Please 19. Zipline Visual Diagrams for a detailed workflow process on how content is deposited via Radiate.

Depositing New Content

For new content, content is deposited to the applicable deposit services it is set up for when it is published. The above workflow describes the process in detail The 14 Nov 2018 release resolved an issue where new journal articles (belonging to PAP/JAM/Issue) do not trigger a deposit on publication. Scenarios resolved are described below: Given a PAP or JAM package that is loaded to Zipline for the first time And the content is published Then a deposit queue record is inserted into the database for the affected content And the content is deposited to the various deposit services for which the journal is configured Given a new issue ZIP file with one or more articles When the issue article or the full issue is published in Zipline Then publication inserts the issue articles into the depositqueue for deposits enabled for the journal

Depositing Replacement Content

For replacement content, the process is the same. When a replacement package is loaded for published content and the replacement is published, then the replacement is queued for deposit to the services the journal or book is configured for. The above workflow is followed for the same process. The 03 May 2018 release resolved an issue for some clients where replacing content and publishing the replacement was not queuing the content for deposit The 11 Apr 2019 release resolved an issue that prevented some issue content from being deposited if the issue replaced a published PAP article and the user published the individual replacement article in an issue

Triggering Deposits

Content can be triggered for deposit in one of two ways:

Unpublish the piece of content via Zipline 3.0 and then publish it Update the IsProcessed value to 0 for the piece of content in the depositQueue table. The scheduler will then pick up the piece of content and re-schedule it. 18. Importing Categories

17. Importing Categories TOC Heading Categories XML Example (for articles) Hierarchical Categories Book Series Details (for all CategoryTypes) Details (for 'toc-heading' only) Categories Diagram

17. Importing Categories

TOC Heading Categories

The Zipline interface accepts TOC Heading categories and allows them to be imported with journals and books content as part of content loading. This prevents the task of scripting in TOC Heading categories into the database before content can be loaded successfully. This is loaded as part of the journal article XML and book XML. For more information, please reference the most recent version of the Silverchair Content XML Specifications for journals. The only categories that will be imported on the fly and do not require database set up before hand are subjects of the following tagging: . If is loaded and there is not a category in the database, then the content will fail content loading.

XML Example (for articles)

... ARTICLES ...

The 21 Mar 2019 release to Zipline improved the overall importing logic associated with category-toc-headings. Previously, loading a large package with many articles has some amount had a chance of writing duplicate toc headings to the database when the toc headings aren't yet in the database. This caused the unintended effect of displaying duplicate TOC headings on the Issue Table of Contents Page. After this release, when a user is loading issues through multiple packages, or a large package with multiple articles, and the articles all contain category-toc- headings that do not yet exist in the database, the action of loading this content does not create duplicate category headings in the database. The 02 May 2019 release to Zipline resolved an issue where Parent Categories were not being created for multi-level category-toc-headings.

Hierarchical Categories

Users can include the and elements to designate categories for the book or chapter. Each category should be placed in a element within the element.

The following content can be assigned to categories using :

articles books chapters

Wireless Sensor Networks Alternative Energy Harvesting Systems

These categories must be set up in the database before importing, unlike TOC heading categories. If they are not set up prior to loading, then content loading will fail with the message that the categories could not be found. The 21 Mar 2019 release to Zipline resolved an issue where books were failing to load with there was more than 1 set of nested categories. These categories were correctly in the database, but the book would not pass successfully through the business rule validator flowstep. After making a change, the books once again loaded successfully.

Book Series

To assign a Book Series to a book (optional), use with the with a child element

In this section you may find more details on how Zipline processes categories and imports TocHeadings into the database. For more information, please reach out to Silverchair Client Services at [email protected].

Details (for all CategoryTypes)

Zipline assumes the top level category in the XML is a top level category in the database If it can match the whole category tree found in the XML to a category tree in the database (with matching categoryTypes at each level), it will consider that a match and assign the content to the lowest level category that was in the XML. If the tree in the database has further children, that's still considered a match. If the entirety of the category tree from the XML doesn't match a tree in the database, starting from the top level, then Zipline rejects the article. So: XML: A/B db: A/B article is assigned to B XML: A db: A/B article is assigned to A XML: B db: A/B no match - reject (this is new behavior) XML: A/B/C db: A/B no match - reject

Details (for 'toc-heading' only)

Zipline will add new categories during import if the category doesn't exist already in Zipline. So: XML: A/B db: A/B article is assigned to B XML: A db: A/B article is assigned to A XML: B db: A/B no match - Add new category B at top level, article is assigned to new B (not the B in A/B) (this is new behavior) XML: A/B/C db: A/B no match - Add new category C under A/B, article is assigned to C (the C in A/B/C) (this is new behavior)

Categories Diagram

19. Zipline Visual Diagrams

18. Zipline Visual Diagrams Zipline Article Replacements Zipline FlowSteps Zipline Flowsteps - Another View Zipline Workflow Radiate Workflow

18. Zipline Visual Diagrams

In this section you may find a collection of visual diagrams about Zipline that aid in understanding the process of Content Submissions. For more information, please reach out to Silverchair Client Services at [email protected].

Zipline Article Replacements

This diagram describes how articles are replaced on Zipline:

Zipline FlowSteps

At a high level, this diagram explains how content is submitted through Zipline and the various steps taken to process each ZIP package. Zipline Flowsteps - Another View

Zipline Workflow

This diagram describes that steps that occur from authentication to Zipline through to downstream deposit of content. Radiate Workflow

Please view the below diagrams for details on how content is deposited via Radiate:

22. Loading OxMeta Files to Zipline

21. Loading OxMeta Files to Zipline Uploading OxMeta Files Journals OxMeta Loading Viewing OxMeta files associated with articles Viewing OxMeta Error Messages OxMeta Replacements

21. Loading OxMeta Files to Zipline

Uploading OxMeta Files

OxMeta is a proprietary schema containing core bibliographic and semantic metadata fields describing digital content. It doesn’t contain the text structure or full text display elements captured in the Full Content XML. It is used primarily for:

For journal content: associating categories with journal articles.

Sometimes the Full Content XML contains values that are not consistently expressed or that are not harmonized across content sets for the platform display and behavior requirements – generating OxMeta provides a way of tidying and making these values consistent which is why it is often the best source.

Journals OxMeta Loading

OxMeta files can be loaded to Zipline as part of a journals zip package or in a zip package separate from any journals content. Please follow the instructions on 3. ZIP Package Contents to prepare your package with OxMeta The OxMeta file can be saved as an XML document and stored in the XML folder of the package Simply upload the file to and wait for the package to complete processing. When complete, navigate to the Packages page and click on the Package ID for the package containing OxMeta. For more information on what happens when OxMeta is loaded successfully as part of a package, please reference the sections below:

Viewing OxMeta files associated with articles

Below is a screenshot of what the Package Details page looks like when OxMeta is loaded to Zipline. Notice how the action buttons are not present - this is because a user cannot 'publish' or 'preview' an OxMeta. An OxMeta file for journals simply matches articles to categories (taxonomy nodes) in our database: When OxMeta is loaded to Zipline successfully, the file itself inherits a special resourceType in the database of OxMeta. This allows categories to be associated with the journals content. A journal article DOI has to be loaded to Zipline prior to loading any OxMeta associated with the DOI. Otherwise, the file will fail to associate OxMeta to DOI. If a specific, already existing taxonomy has already been added, OxMeta can associate that taxonomy to the article itself. If the taxonomy exists and there is an already present category in the database, then the article loaded with OxMeta will be associated with the category and specific name.

Categories must already exist in the database with a value of the concatenated schemeIdentifier and the subject code. If the categories do not exist, the must be loaded prior to loading OxMeta. This can be done by using the API to load new categories: 14. Taxonomy. Here is an example of a real OxMeta file: 10_1093_omcr_omu002.xml.

Zipline does not parse the entire OxMeta, but rather specific parts of it. Here is a snippet of the parts of OxMeta that the tool parses (this is not an actual OxMeta file, just a snippet of what Zipline looks for):

adapta 17

The tool looks for http://purl.org/dc/terms/identifier and validates that the associated DOI is present in the database. Then Zipline looks for

Viewing OxMeta Error Messages

If a category is loaded as part of an OxMeta file and the category does not yet exist in the database, a warning will display similar to the following picture: When the subject name is not present in the database, that article cannot be associated with those categories.

OxMeta Replacements

If a user has loaded OxMeta previously for an article, any associations between an article DOI and categories are wiped out upon a subsequent OxMeta load. An article is only connected to categories of categoryTypeID = 50 based on the most recent OxMeta file load. For example, if you load an article, then load some categories into the database with the 14. Taxonomy instructions, and then load an OxMeta file with 3 oxdc:subjectScheme nodes (that all had schemeIdentifier and subjectCode in the database), then the article DOI will be associated with three categories. But if you reload the OxMeta file and modify it so that there is only 1 oxdc:subjectScheme node, then the category associations are wiped out and the article is now only connected to one category (belonging to the most recent file). 23. Zipline Glossary

Quick Links 21. Zipline Glossary 21. Zipline Glossary A Term Meaning Related B Documentation C D A F G H ADS Astrophysics Data System: refers to a downstream deposit service I supported by Silverchair http://adsww J w.harvard. O edu/ P 17. R Downstream S Deposit T Services U W API The API (appliation program interface) to Zipline provides content 16. Using the API X submission and management services. Using the API, you can import Z new content, and you can track the status of active submissions.

AGI AGI stands for American Geological Institute - relevant article metadata 17. Downstream is deposited to AGI when new content is published Deposit Services

Assets Refers to all files referenced by the XML in a .ZIP page that are 3. ZIP Package imported to Zipline. These files include figure images, videos, audio, Contents data supplements, issue cover images, book cover images, and other issue- and book-level ancillary files. Assets may include XML files; for example, a data supplement that is an XML file should be included in the Assets folder, not the XML folder. B

Book “Book Part” here is used loosely to mean any chapter- and part-like part content, including a Part, Chapter, Section, Foreword, etc. C

CDS CDS Stands for (Centre de Données astronomiques de Strasbourg) 17. Downstream and is a downstream deposit service supported by Silverchair Deposit Services

Conten Refers to the messages that appear to users of Zipline. Content Level 8. Zipline Error t Level Errors prevent packages from being completely loaded and published and Warning Error in Zipline. Codes

Conten Refers to the messages that appear to users of Zipline. Content Level 8. Zipline Error t Level Warnings inform users of potential display issues but packages with and Warning Warning only warnings can still be published to Zipline. Codes

Conten Refers to a specific user role within Zipline that has specific 7. Access and t permissions within the tool. Please refere to the Access section of the User Roles Admini user guide. strator

Conten Refers to a specific user role within Zipline that has specific 7. Access and t permissions within the tool. Please refere to the Access section of the User Roles Loader user guide.

Conten Refers to a specific user role within Zipline that has specific 7. Access and t permissions within the tool. Please refere to the Access section of the User Roles Produc user guide. tion Manag er

Contin Refers to a publication model of some journals where issues can 14. Continuous uous remain open while additional articles are added to the journal issues Publishing Publica remain open over time. When an issue is closed, articles no longer can tion be added to the issue marked for Continuous Publication. Continuous Publishing is set at the Journal level; therefore all issues in a journal will either be 'traditional' or 'continuous.' Crossr Crossref refers to a downstream deposit service supported by ef Silverchair. http://help. crossref.org /deposits 17. Downstream Deposit Services

D

Downst Please refer to Radiate in this Glossary 17. Downstream ream Deposit Services Deposit F

FTP Refers to the interface that Zipline users may log into to upload ZIP 2. Upload packages, in cases of bulk loading with many packages. The server Content Packages used is either sftp://oupsecurefiles.silverchair.com or sftp://securefiles. silverchair.com G

Gigaby A unit of information used to describe the size of a package. The 2. Upload te maximum file size for a .ZIP package is capped at 1.5 G. Content Packages H

HTTP Refers to the different response codes that are sent to the user for Respo different loading scenarios. Some messages deliver a relevant HTTP 8. Zipline nse Response Code after an action taken by the user, either in the API or Error and Code the UI Warning Codes http://www. restapitutorial .com /httpstatusco des.html http://getstat uscode.com /419

I

ISBN An ISBN is an International Standard Book Number. ISBNs were 10 2. Upload digits in length up to the end of December 2006, but since 1 January Content Packages 2007 they now always consist of 13 digits. ISBNs are calculated using a specific mathematical formula and include a check digit to validate the number. Books loaded to Zipline must have a unique ISBN.

Issue This describes the file structure of the issue level file loaded as part of 13. Issue Meta Meta a package. Files J

JAM JAM = Just Accepted Manuscript

Manuscripts that are accepted for publication may be promoted on a website before they are incorporated into an issue, and in many cases, before the full text is available. See also: PAP. O

Orphan Refers to a state during package load where a fail has failed asset ed transform and cannot be loaded. This will either cause a fatal error or the package will appear to be 'stuck' in the In Process status. In order to resolve this, the user should attempt to reload the package again after reviewing the original files.

OVID Refers to one of Silverchair's downstream deposit services http://www.ovid. com/site/platforms /ovidsp.jsp OxMeta OxMetaML is a prioprietyary schema containing core bibliographic and 2. Upload semantic metadata fields describing digital content. It doesn’t contain Content Packages the text structure or full text display elements captured in the Full Content XML. it is used primarily to associating categories to articles in Zipline P

PAP PAP stands for 'publish ahead of print'.

A publishing model where journal articles are put online before they are incorporated into a specific journal issue. Some publishers call this Online First. It can also be called 'ahead of print' or 'advance articles' or JAM (Just accepted Manuscript).

PMC PMC stands for Pubmed Central and is one of Silverchair's supported downstream deposit services. Within PMC there are specific Full, NIH, 17. and Selective services Downstream Deposit Services

Portico Portico refers to one of Silverchair's downstream deposit services 17. Downstream Deposit Services

Postman Refers to the recommended API client when using the Content API 16. Using the API https://www. getpostman. com/

Priority Also know as QueuePriority Levels, this allows Zipline users to 2. Upload designate the priority of loading their specific package against others in Content Packages the queue.

PTEP Refers to one of Silverchair's downstream deposit services 17. Downstream SCOA Deposit Services P3

Pubmed Refers to one of Silverchair's downstream deposit services 17. Downstream Deposit Services R

Radiate Refers to Silverchair's Downstream Deposit service 17. Downstream Deposit Services

RSuite Refers to one of Silverchair's downstream deposit services 17. Downstream Deposit Services S

SCJATS This refers to the set of specifications that were developed alongside http://specificatio the version of Zipline that was created as part of the Content Tools ns.silverchair.com Expansion, specific to Journals content only /xsd/1/9 /XMLSpecJournPr oc.html

SCBITS This refers to the set of specifications that were developed alongside http://specificatio the version of Zipline that was created as part of the Content Tools ns.silverchair.com Expansion, specific to Books content only /xsd/1/9 /XMLSpecBook. html

SiteMa The back-end application that clients use to manage their site, 1. Getting nager including content association, publishing, product management, static Started with code authoring, user management, and usage statistics. Zipline Users Zipline must exist within SiteManager before they can access Zipline.

Submis This refers to the unique identifier of the loaded package. If possible 11. Reviewing sion please use this submission key when raising an issue with Silverchair Uploaded Key Client Services Packages Super Refers to a specific user role within Zipline that has specific 7. Access and User permissions within the tool. Please refere to the Access section of the User Roles user guide. T

Taxono Refers to files with extension .xml or .rdf that can be loaded to Zipline 15. Taxonomy my via the API by users having the role 'Taxonomy Manager'.

Taxono Refers to a specific user role within Zipline that has specific 7. Access and my permissions within the tool. Please refere to the Access section of the User Roles Manag user guide. er

TOC Refers to categories that can be accepted by Zipline through loading of 18. Importing Heading packages Categories

Traditio Refers to the opposite model of Continuous Publication, where issues 14. Continuous nal cannot be opened or closed as articles are added to the issue. See Publishing Publish 'Continuous Publication' ing U

UI UI Stands for User Interface. It refers to the visible features that can be clicked on or user by Zipline users when loading content. Users can utilize the API if they do not require the UI.

UTC UTC refers to Coordinated Universal Time. This 24-hour time standard is kept using highly precise atomic clocks combined with the Earth's rotation. W

Watch The WatchFTP service frequently checks for packages loaded to the 2. Upload FTP FTP by clients on a schedule and transfers them to In Process on the Content Packages Zipline Packages page. X

XML XML = eXtensible Markup Language XML definition on Webopedia Extensible Markup Language defines a set of rules for encoding documents in a format that is both human-readable and machine- readable. Journal, proceedings, and book content hosted on SCM6 is stored in XML files. Z

.ZIP Refers to the required file extension of packages loaded to Zipline

Zipline Refers to Silverchair's proprietary tool for loading content. 3.0 24. Zipline Frequently Asked Questions

22. Zipline Frequently Asked Questions

22. Zipline Frequently Asked Questions

Below are a series of questions and their respective answers about Zipline 3.0. You can search through the existing questions before submitting a Salesforce ticket to the Client Services team by emailing [email protected].

Question Answer

1 Zipline is stuck. How do I get my The package currently displays as in Process and hasn't moved to another status. This signals that the package to be submitted? submission has failed asset transform. This could be due to invalid XML in the original ZIP file, or that the submission has become orphaned. Users should attempt to retry loading the package.

2 I can't login. How do I access Zipline? The user may not have an account set up in SiteManager. If you have not had an account set up before with the proper permissions, you will need to contact Client Services by emailing support@silverchair. com.

3 I can't see everything that has been Please refer to 7. Access and User Roles to see what permissions your user role has. Not all users can submitted in Zipline. How do I see view all content in Zipline 3.0. If you require additional permissions, please email support@silverchair. other packages that have been com and specify what permissions you need in order to complete your job responsibilities. uploaded?

4 How do I get to see the list of Please follow the steps here 16. Using the API to access the API and get the orphan report. This will packages that are stuck in process? display a list of packages that have this status.

5 It looks like duplicate content is Zipline has a replacements functionality that you can read more about in 9. Publish Content. There is an published twice in Zipline - what automatic job running that executes every 5 minutes. If your content is published and you published a should I do about this? duplicate, this will be resolved after the automatic job executes.

6 I'm trying to load content for a new First, check to make sure the journal has been set up in Sitebuilder. Does the journal have a record in journal and it's failing. What do I do? the database yet? Does the smUpload Configs record exist for the journal? Both of these actions can be done in Sitebuilder.

7 How do I publish issue meta for an Issue meta content does not have a status of published in Zipline. Issue meta is published automatically issue in Zipline? when it is loaded. A user does not have to modify the status in Zipline. 25. Zipline Conference Proceedings

25. Conference Proceedings Zipline Display of Proceedings Content Loading Considerations Publishing Proceedings Database Schema Using the API

25. Conference Proceedings

With the 15 Nov 2018 release, users may use the SCJATS XML specification to load conference proceedings content. For details on XML tagging, please reference the SCJATS narrative.

Zipline Display of Proceedings

Proceedings ZIP packages that are loaded to display will display on the packages page like ZIP files for Issues or Books. Clicking on the package to see the package details will display the conference proceedings articles that make up the package It is possible to view the conference proceedings rolled up by conference volume. This is described in more detail on 5. Zipline Catalog Page

Content Loading Considerations

A conference session is not required to be loaded with a conference proceeding article. If an article is loaded without one, it will proceed through Zipline and will be stored with a blank value in the conferenceSessions.name column. An important prerequisite that is needed before conference proceedings can be loaded is that the conf-level-1 (indicating the conference series information) must first be added to the Sitebuilder data config file ConferencePublishingInformation If the the package contains at least one proceedings article with a conference element with a content-type of "conf-level-1" But conf-level-1 value does not equal any conference series in the database Then the package fails with BR 463 " in must match a series value in the database." And the package does not complete processing Unlike journals content loading, there is no ISSN validation logic. Loading proceedings with an self closing ISSN element or an ISSN value that does not match the database will be imported to Zipline Conference sponsor can be imported under and Additional business rules that require proper formatting for a conference proceeding file include: BR 461 Proceeding article has exactly one conference element with content-type="conf-level-1" and exactly one conference element with content-type="conf-level-2" BR 40 Has conference volume name. BR 43 Has conference name BR 46 Has conference short name BR 47 Has conference session name BR 86 Has conference number with value

Publishing Proceedings

Publishing a conference proceeding on the package details page of Zipline sets the activeDate (publishes) the following information The conference proceeding article The conference session (if tied to the conferences table and not yet published) The conference (if tied to the conferencesessions table and not yet published) The conference volume (if tied to the conferences2volumes table and not yet published)

Database Schema

The following database diagram describes how the conference proceedings information is stored in the client database: Using the API

It is possible to use the Content API to query and perform actions on proceedings such as search, publish, and open an issue. Please reference 1 6. Using the API for more details 26. CHORUS Implementation Guidelines

26. CHORUS Implementation Guidelines What Publishers need to do What Silverchair does as part of the integration

26. CHORUS Implementation Guidelines

With the 02 May 2019 release, publishers may choose to integrate with CHORUS to make their funded content available to funders and publicly accessible after the embargo period. There are several steps to compliance and a close collaboration between the publisher and Silverchair is required before CHORUS can be fully enabled. Please see the latest version of the CHORUS publisher implementation guide for more details: https://www.chorusaccess. org/wp-content/uploads/CHORUS-Publisher-Implementation-Guide-2018-v2.2.pdf

What Publishers need to do

While Silverchair bears joint responsibility on all 7 steps associated with CHORUS compliance as documented in the section "Simple Guide to Participating in CHORUS", page 3 https://www.chorusaccess.org/wp-content/uploads/CHORUS-Publisher-Implementation-Guide-2018-v2.2.pdf, the client bears some degree of responsibility for steps 1, 4, and 7 on the implementation guide.

1. Collect funder information (via your manuscript tracking system or by extracting from your articles) and map it to entries in the Crossref Open Funder Registry a. Include information about funding of the research in the tag. Zipline can import the funder’s name, funder’s identifier, and associated award identifiers, and SCM6 can deposit this information to FundRef. Inside the element, use the and t ags to designate the funder name and identifiers, respectively.

National Science Foundation 10.13039/100000001 psychoceramics-1152342

If an embargo period is stored in SCM6 for a funder, articles associated with an award from that funder will automatically become available outside the paywall after that embargo period. Embargo periods for funding agencies are maintained in SCM6 and are not included in the XML.

b. A publisher can reference https://support.crossref.org/hc/en-us/articles/214360886-The-Open-Funder-Registry to determine what funders to place in their content 2. Choose a license for content reuse for each article reporting on funded research, either a common public license such as Creative Commons (CC) or a publisher proprietary license and register the license with CHORUS a. https://www.chorusaccess.org/wp-content/uploads/CHORUS-Publisher-Implementation-Guide-2018-v2.2.pdf i. The choice of license is up to the publisher: it can be either a standard open license such as one of the Creative Commons licenses or a proprietary publisher-specific license. Best practice information and sample publisher licenses are available from STM at https://www.stm-assoc.org/copyright-legal-affairs/licensing/open-access-licensing/ b. This will be included in the XML that you upload to Zipline 3. Archive the AM or VOR at a recognized archive service (CLOCKSS or Portico) a. Choose which of the archiving services that are needed - then Silverchair can work with the publisher to implement

What Silverchair does as part of the integration

1. Collect funder information (via your manuscript tracking system or by extracting from your articles) and map it to entries in the Crossref Open Funder Registry 2. Include funder information in deposits to Crossref 3. Make at least one version of your articles reporting on funded research openly accessible on your website, either Version of Record (VOR) or Accepted Manuscript (AM), with an appropriate embargo period 4. Choose a license for content reuse for each article reporting on funded research, either a common public license such as Creative Commons (CC) or a publisher proprietary license and register the license with CHORUS 5. Include license metadata in deposits to Crossref that identifies the openly accessible version, the reuse license, and the start date for open access commensurate with the selected embargo period 6. Include a URL for a full text version in deposits to Crossref and make it available to be harvested for indexing by funders from date of publication (funders will link back to you by the DOI and only harvest articles reporting on research that they funded) 7. Archive the AM or VOR at a recognized archive service (CLOCKSS or Portico) 27. Reference Enhancements Guidelines

27. Reference Enhancements Guidelines Example of XML post reference enhancements Google Scholar Reference Enhancements Recent Changes

27. Reference Enhancements Guidelines

As part of package loading, Zipline queries external third party integrations such as Pubmed and Crossref to locate external links that aid in content discoverability. Reference Enhancements send queries to content in external databases and retrieve data sufficient to create a link to the external site on our site on content load in the Zipline flowstep. Reference enhancements can also be after content load. We currently integrate with the Pubmed and the Crossref API to query for the PMID and the DOI respectively if the information is not provided as part of the reference. This enables references at the end of an article or book section to contain links to each reference to browse on Pubmed and Crossref. The Reference Enhancements stored procedure uses API calls to send queries to content in external databases and retrieve data sufficient to create the external link to the site. If a result is returned from the API call, then Silverchair stores the identifying information in the database along with the reference. Then users are able to see the hyperlink on the references section of the content and click on the hyperlink to navigate to the content in Pubmed or navigate to the source content.

Sometimes the information in the reference is not detailed enough to locate a valid reference and perform the enhancement. In this case, the reference is still stored in the database, but the link to the external site is not returned. This can be resolved by including additional data in the reference and reloading the package. Silverchair recommends following the latest Minor Version of the SCBITS and SCJATS Narrative Specifications for more details.

For journal articles referenced in the references section, Zipline can create links to PubMed and Crossref as long as the @publication-type="journal" attribute is included in the or element.

For books referenced in the references section, Zipline can create links to PubMed and Crossref as long as the @publication-type="book" attribute is included in the or element.

Example of XML post reference enhancements Google Scholar Reference Enhancements

Unlike Pubmed and Crossref reference enhancements, Zipline does not inject text into the database in order to form a hyperlink that links out to Google Scholar. Instead we follow the logic described here to generated a hyperlink on the references section on the front end: https://scholar. googleblog.com/2016/01/quickly-lookup-references.html. To construct a Scholar lookup URL for an article title or a full reference, URL-escape the text of the reference and append it to https://scholar. google.com/scholar?q=.

Recent Changes

The 07 Nov 2019 release to Zipline resolved an issue saving reference enhancements for book references. When a book is loaded to Zipline with a reference section and that reference is for a book (but no DOI is included with that reference), then the Crossref API is utililized to query the title, author, publisher, and year. If a match is found in the Crossref API for the book reference, then a Crossref DOI is injected into that reference in sectionXML in the format: 28. AWS and CDN Integration

28. AWS and CDN Integration Destination of Content Packages Content Archive Source XML Recent Changes

28. AWS and CDN Integration

As part of package loading, Zipline stores several files in the cloud using Amazon Web Services. The original package, XML and all assets are captured individually and stored so that they can be retrieved at a later point during a deposit or when a user views the content. This section of the Zipline User Guide describes the relevant details associated with storing Zipline packages in AWS.

Destination of Content Packages

Once uploaded to Zipline, packages travel to Amazon Web Services (AWS) S3 buckets (S3 stands for Simple Storage Service). The assets of a package, like PDF files, images, and figures are stored in the database with a specific path to their location in AWS, which is used by the site to serve the content to the end user to access. While the assets and the XML are divided out into specific locations within the S3 bucket structure based on the content type and other metadata, the original, unedited package is archived in AWS S3 and used for tracing a submission back to the original file. If you need assistance with locating a specific package loaded to Zipline, please content Silverchair Client Services and we will locate the original ZIP file for you. Providing the submission key associated with the submission (see 4. Zipline Packages Page) will greatly help with reducing the time needed to locate the original package.

Content Archive

The Content Archive Service is the final step in the flowsteps process of loading a package to Zipline. When a package is processed through the Archive service, the xml and assets are loaded with the proper versioning in S3. This is used for displaying the assets on the front end. The ContentArchive is also the location where the source XML is available for crawling by Google Scholar (if citation_xml_url has been set up on the site). ContentArchive is also how files are generated for downstream deposit services.

Source XML

SourceXML is what Google Scholar uses to crawl the original XML for the content. This is stored in the Content Archive and a multimedia record is created whenever new content is loaded. A new multimedia type called sourceXML references the path of the content that is stored. This is page in the source of the content page and Google Scholar is granted access so that they can index the content.

Recent Changes

The 16 Nov 2017 release for Zipline further optimized the storage service tooling by removing redundant storage locations in AWS and the network file share. Once a package is loaded successfully to Zipline, AWS S3 serves as the system of record for a submission and the replicated ZIP file is removed from any internal network shares, allowing for more temporary file space for other services. The 25 Jan 2018 release to Zipline modified the Content Archive in AWS to store different parts of the book separately, which can then be used for metadata updates and depositing content to downstream providers. If a book is loaded as one package, the Content Archive separates that book into the book metadata in book-meta and the separate book part replaceable units (which include chapters, front matter sections, and book back sections). For more information on replaceable units, please reference this section: 4. Zipline Packages Page. The 15 Feb 2018 release to Zipline modified the Content Archive to store sourceXML reference for books, so that they can be used for metadata updates and display the raw XML for web crawlers The 08 Mar 2018 release to Zipline adjusted the Asset Transform flowstep of Zipline to store parts of books under the subfolder 'parts' rather than the subfolder 'chapters'. This was done because not all book parts are considered chapters. This changes does not have any impact on the state of existing book parts in Zipline or the front end display of book parts. The 28 Mar 2018 release to Zipline resolved an issue where some PDFs loaded for book chapters were not available for download from the website. With this change, the PDFs were saved to the proper location in the content_public folder of AWS The 04 Oct 2018 release to Zipline ensured that the sourceXML destination in our database matches with the casing conventions of the XML in AWS, so that this content can be crawled by indexers The 25 Oct 2018 release to Zipline improved the content archive flowstep for books loading to more efficiently prepare books xml package for full text deposit services The 18 Dec 2018 release to Zipline ensures that the XML files in the content archive folder for books and book part wrappers files have asset references that match the assets in the asset folder. Extension of the files and the case should match. All references should be lowercase. The 24 Jan 2019 release to Zipline made an adjustment so that when a replaceable unit contains child sections below it, the content archive associates the child sections with the replaceable unit in AWS. This allow full text book deposits to function successfully The 21 Mar 2019 release to Zipline made an adjustement to the Content Archive service so that is accurately stored in AWS when it's included in Book XML. This element is within the original book XML. Previous it was not included because only and child nodes are archived in the sourceXml file, with a parent wrapper element. The 11 Apr 2019 release to Zipline resolved an issue when loading a book-part-wrapper file in zipline 3. Previous, the asset trasformer service did not saves its assets to the correct S3 path. With the fix, the service now saves assets and ties them to the multimedia record in the database.

In the release to Zipline: In the 22 Aug 2019 release to Zipline: resolved an issue where loading a replacement issue meta file did not save the self-uri pdf associated with it. The logic was changed so that only one self-uri PDF is associated with each issue meta file after it is replaced a book that has a single XML file that references the same pdf file more than 1 time has the pdf saved in AWS each time that it is mentioned. This enables the PDF to be visible from all of the places where it is referenced. In the 12 Sep 2019 release to Zipline: users that specify in their article XML and include a peer review PDF will be able to load these PDFs to Zipline and have the supplementary material stored. In the 03 Oct 2019 release to Zipline: a fix resolved an issue where reloading a book prevented the cover image and pdf from displaying. The cause was due to the fact that the database and AWS filepath for the book cover image and pdf did not match.