cOAlition S is committed to delivering content that informs and explains in a concrete manner the research and publishing community towards the aim of accelerating full and immediate open access. The following page provides practical advice and additional details about the Plan S principles, implementation and technical guidance in order to help researchers, institutions, publishers and others understand better the Plan S and its requirements. Further explanations will be added as necessary.

Requirements for Open Access Repositories

as described in Plan S | Technical Guidance and Requirements

 

The repository must be registered in the Directory of Open Access Repositories (OpenDOAR) or in the process of being registered. See https://v2.sherpa.ac.uk/opendoar for details.

Mandatory criteria  Practical advice
Use of PIDs for the deposited versions of the publications (with versioning, for example in case of revisions), such as DOI (preferable), URN, or Handle. For cOAlition S articles, all AAMs in repositories must have their own unique persistent identifier (PID) assigned to them (there may be a separate PID within the item metadata such as DOI that links to the publisher’s VoR). cOAlition S does not specify the choice of item PID. The PID should take the form of a recognised standard, for example, a DOI, Handle, or URN. The PIDs in use should comply with the requirements of that selected PID scheme.
High-quality article-level metadata in a standard interoperable non-proprietary format, under a CC0 public domain dedication. This must include information on the DOI (or other PIDs) both of the original publication and the deposited version, on the version deposited (AAM/VoR), and on the Open Access status and the license of the deposited version. Metadata must include complete and reliable information on funding provided by cOAlition S funders (including as a minimum the name of the funder and the grant number/identifier). Here, and elsewhere in the guidance, cOAlition S has left many detailed implementation decisions to those best placed to make them. We do not see cOAlition S as designing a detailed specification for the scholarly communications system, though the funders may facilitate some discussions in some cases. We would hope that communities can come to agreements and common practices on standard formats via the usual channels such as standards bodies, joint projects, etc.
The metadata should include the elements as listed in the requirements. cOAlition S expects that funding information is included, if not immediately, then as soon as possible. Metadata should include the PID assigned to the repository version. There may be a separate PID within the item metadata, such as a DOI, that links to the publisher’s VoR.
cOAlition S funders aim to maximise the discoverability and dissemination of the research they fund, and to this end prefer that a CC0 licence is assigned to item metadata. If a repository is not currently able to assign this particular license, repositories are strongly encouraged to make the metadata they provide as open and available for re-use as possible until they adopt CC0.
Machine-readable information on the Open Access status and the license embedded in the article, in a standard non-proprietary format. Plan S requires that publishers and repositories embed metadata describing the OA status and licence of that article within the article itself. cOAlition S recognises that some, particularly smaller publishers and some repositories, are not currently set up to facilitate this. In these cases metadata describing the OA status of the work and the licence assigned to it must be included in the item description metadata (such as repository item record or web page metadata for the item). Such item metadata should be in a common, non-proprietary format, and machine-readable.
Continuous availability (uptime at least 99.7%, not taking into account scheduled downtime for maintenance or upgrades). Repositories should minimize unscheduled downtime for both deposit and access as far as possible, and aim towards at least 99.7% uptime (which equates to approx maximum 27 hours p.a. unscheduled service outage), with performance comparable to or better than other services within their institution. If the service is unexpectedly down for any reason, the repository should provide helpful information for users, for example, workarounds and/or an estimate of when the service will be back in full operation.
Helpdesk: as a minimum, an email address (functional mailbox) has to be provided; a response time of no more than one business day must be ensured. Repositories must provide a channel for depositors and other users to submit queries. cOAlition S does not specify what format of contact is adopted – that decision remains with the individual repository.
The initial response to a query, should be sent no more than one business day from receipt, and may comprise an automated holding note that gives an indication of when the enquirer can expect to receive a more fulsome response.
Strongly recommended additional criteria  Practical advice
Manuscript submission system that supports both individual author uploads and bulk uploads of manuscripts (AAM or VoR) by publishers. Repositories are strongly encouraged to implement tools and services that enable authors, content brokers or other services or organisations to upload multiple items to the repository when appropriate (for example, Jisc Publications Router). The purpose of such a recommendation is to promote efficient management of large amounts of content and to minimize administrative burden.
Full text stored in a machine-readable community standard format such as JATS XML. Plan S aims towards provision of full text in a machine-readable community standard format to enable text and data mining (TDM) of articles. However, Plan S does not designate full text stored in a machine-readable community standard format, such as JATS XML, as a mandatory requirement for repositories. cOAlition S recognises that this feature is not currently commonly supported in institutional repositories. If repositories choose to store the full text of an article in a machine-readable format, the choice of standard machine-readable format is left to the repository owner.
Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities. Repositories are strongly encouraged to implement common standard persistent identifiers (PIDs) wherever possible, especially as global identifier schemes mature and become increasingly adopted. In particular, adoption and implementation of ORCIDs, rapidly becoming ubiquitous, for all authors is strongly recommended. Repositories should ensure that their implementation of such PIDs is achieved using common practices and in accordance with common guidelines so that metadata are interoperable. Most repository platforms currently support the adoption of PIDs or plan to do so in the future (COAR finding). For repositories that do not currently support the adoption of identifiers for these entities, they should aim to include the funder, grant number and institutional name in alternative metadata fields such as the “contributor” or “sponsorship” element. (COAR[1])
Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC). Although this is a highly desirable functionality, cOAlition S recognises that some repositories may currently have difficulty complying with the specific recommendations of the Initiative for Open Citations (I4OC) unless the version of the article being deposited has already been formatted appropriately. cOAlition S recognises that not all repository platforms support open citations at this time, plus the resources may not yet be available to process citations in each article. cOAlition S therefore encourages repositories to utilise other ways of supporting open citations in the context of repositories, through the development of network services that support this, such as Crossref/DataCite Event Data. (see also COAR report)
Open API to allow others (including machines) to access the content. A compliant API must be free to access without any barrier. A light authentication mechanism such as a token for ‘power users’ – e.g., high-traffic collaborators – is acceptable as long as there is a totally open/anonymous route too. Repositories are strongly encouraged to allow harvesting and indexing of metadata and full-text content using standard interoperability mechanisms such as OAI-PMH and OpenAPIs. Most commonly employed repository platforms support Open APIs and OAI-PMH. Access for the majority of users should be barrier-free (i.e. no payment, registration or authentication required)
OpenAIRE compliance of the metadata Many repository platforms are working towards compliance with OpenAIRE metadata guidelines for literature repositories). OpenAIRE metadata guidelines were designed to enable better tracking and reuse of open access literature: repositories should aim towards compliance with OpenAIRE (or similar – see below) metadata guidelines. cOAlition S recognizes that currently not all repositories are able to implement the guidelines and therefore, as a minimum, requests that the metadata record contain enough descriptive, interoperable metadata to ensure discovery and citation, and should include the funder affiliation, open access status, and license.
cOAlition S recognises that OpenAIRE guidelines were developed to support tracking of European Commission funding information and that repositories serving other user bases may prefer to adopt alternative guidelines that similarly ensure interoperability and discovery.
Quality assurance processes to link full-text deposits with authoritative bibliographic metadata from third-party systems, e.g., PubMed, Crossref, or SCOPUS where feasible. Although many repositories do not currently contribute their metadata to Crossref etc, repositories are strongly encouraged to use standard formats and protocols etc to enable their metadata to be harvested by national and regional aggregators such as OpenAIRE,  CORE, BASE, La Referencia and so on. Such aggregators play an important role in maximising the dissemination of works (see COAR repository platform survey).

[1] COAR (Confederation of Open Access Repositories) is an international association that brings together individual repositories and repository networks in order to build capacity, align policies and practices, and act as a global voice for the repository community. Repository service providers are also encouraged to refer to COAR Community Framework for Good Practices in Repositories