Difference between revisions of "Plan S"
m (→Mandatory technical conditions for all publication venues) |
(Added info for D points) |
||
(12 intermediate revisions by 2 users not shown) | |||
Line 12: | Line 12: | ||
A1. Use of persistent identifiers (PIDs) for scholarly publications (with versioning, for example, in case of revisions), such as DOI (preferable), URN, or Handle. | A1. Use of persistent identifiers (PIDs) for scholarly publications (with versioning, for example, in case of revisions), such as DOI (preferable), URN, or Handle. | ||
* EPrints provides an ''Identification number'' (''id_number'') field to store DOIs as well as other PIDs such as PubMed ID, etc. There are also separate fields for storing ISSNs and ISBNs. | * EPrints provides an ''Identification number'' (''id_number'') field to store DOIs as well as other PIDs such as PubMed ID, etc. There are also separate fields for storing ISSNs and ISBNs. | ||
+ | * Each publication record in EPrints is assigned is own URI in the format: ''http://HOSTNAME/id/eprint/NUMBER'', (e.g. http://eprints.example.org/id/eprint/1234 ). | ||
* There are plans to introduce a IDs, IDs, IDs Bazaar plugin similar to the [http://bazaar.eprints.org/449/ Dates, Dates, Dates] that will allow multiple PIDs to be stored with their types to make recording PIDs more extensible. | * There are plans to introduce a IDs, IDs, IDs Bazaar plugin similar to the [http://bazaar.eprints.org/449/ Dates, Dates, Dates] that will allow multiple PIDs to be stored with their types to make recording PIDs more extensible. | ||
Line 18: | Line 19: | ||
A3. High-quality article level metadata in standard interoperable non-proprietary format, under a CC0 public domain dedication. 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). | A3. High-quality article level metadata in standard interoperable non-proprietary format, under a CC0 public domain dedication. 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). | ||
* EPrints most comprehensive metadata export format is its EP3 XML for which an XML schema for any particular archive is available at /cgi/schema to support interoperability. EPrints also provides metadata export in many other standard interoperable non-proprietary format such as: BibTeX, EndNote, CSV, JSON, Dublin Core, RDF to name but a few. EPrints is extensible to allow repository maintainers to add additional export plugins as necessary. | * EPrints most comprehensive metadata export format is its EP3 XML for which an XML schema for any particular archive is available at /cgi/schema to support interoperability. EPrints also provides metadata export in many other standard interoperable non-proprietary format such as: BibTeX, EndNote, CSV, JSON, Dublin Core, RDF to name but a few. EPrints is extensible to allow repository maintainers to add additional export plugins as necessary. | ||
+ | ** For repositories connected to other data sources (e.g. CRIS systems, or paid-for services) the 'CC0' aspect may require a metadata profile that excludes some information such as abstracts, subjects or keywords. | ||
− | A4. Machine-readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format. | + | [[Plan S - A4 - Embedding data into an article|A4]]. Machine-readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format. |
* EPrints generates a ''full_text_status'' value by analysing the content of a publication record to determine whether this value should be: ''none'', ''public'' or ''restricted''. Each document added to a publication record can be assign a license from a list of available options. Both metadata values are shown in the machine-readable EP3 XML export format and can be used. | * EPrints generates a ''full_text_status'' value by analysing the content of a publication record to determine whether this value should be: ''none'', ''public'' or ''restricted''. Each document added to a publication record can be assign a license from a list of available options. Both metadata values are shown in the machine-readable EP3 XML export format and can be used. | ||
+ | ** The page [[Plan S - A4 - Embedding data into an article]] contains details of some possible approaches to this requirement. | ||
=== Strongly recommended additional criteria for all publication venues === | === Strongly recommended additional criteria for all publication venues === | ||
B1. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities. | B1. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities. | ||
+ | * EPrints Bazaar's [http://bazaar.eprints.org/581/ ORCID Support] and [http://bazaar.eprints.org/1138/ ORCID Support Advance] plugins allow ORCIDs to be associated with publication creators and editors and user profiles. The latter also allows EPrints to connect with ORCID's platform for publication metadata interchange. | ||
+ | * EPrints Bazaar's [http://bazaar.eprints.org/1149/ IDs IDs IDs] plugin allows a highly configurable IDs field to be added to publication record. This can store multiple IDs, such as DOIs, PubMed IDs, ISSNs, ISBNs, etc. along with their types an associations with the publication record (e.g. ISSN for an article's journal). It allows bespoke rendering for different types to link to URLs for DOI, PubMED, etc. lookup services. | ||
+ | * EPrints provides autocomplete functionality with backing lists for various fields to ensure accurate IDs are recorded for existing fields such as funders and projects. Additional fields with autocomplete can be added for funding programmes, grants, institutions andotehr relevant ednities. | ||
B2. Registering the self-archiving policy of the venue in SHERPA/RoMEO. | B2. Registering the self-archiving policy of the venue in SHERPA/RoMEO. | ||
+ | * EPrints default policy page links to SHERPA/RoMEO's OpenDOAR policy tool and recommends this is used to build and ultimately register the repository's self-archiving policy. | ||
B3. Availability for download of full text for all publications (including supplementary text and data) in a machine-readable community standard format such as JATS XML. | B3. Availability for download of full text for all publications (including supplementary text and data) in a machine-readable community standard format such as JATS XML. | ||
+ | * EPrints currently does not provide any direct support for download the full-text of publications in a machine-readable format such as JATS XML. However, users could upload such formats and make available for download and abstract/summary page templates can be modified to highlight the availability of such formats for download. | ||
B4. Direct deposition of publications (in a machine-readable community standard format such as JATS XML, and including complete metadata as described above) by the publisher into author designated or centralised Open Access repositories that fulfil the Plan S criteria. | B4. Direct deposition of publications (in a machine-readable community standard format such as JATS XML, and including complete metadata as described above) by the publisher into author designated or centralised Open Access repositories that fulfil the Plan S criteria. | ||
+ | |||
B5. OpenAIRE compliance of the metadata. | B5. OpenAIRE compliance of the metadata. | ||
+ | |||
B6. Linking to data, code, and other research outputs that underlie the publication and are available in external repositories. | B6. Linking to data, code, and other research outputs that underlie the publication and are available in external repositories. | ||
+ | * EPrints by default provides a Related URL field that allows linking to external repositories. This field also allow the type of relationship to be defined. | ||
B7. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC). | B7. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC). | ||
+ | * All live EPrints publication items allow for openly accessible export of citations in various formats (HTML, XML, BibTeX, EndNote, etc.) | ||
=== Mandatory criteria for repositories === | === Mandatory criteria for repositories === | ||
C1. 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. | C1. 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. | ||
+ | * Same as A1, see above. | ||
+ | * Clarification is provided in the [https://www.coalition-s.org/faq-theme/technical-requirements/ Plan S FAQs]: | ||
+ | ** Q: Does the Author’s Accepted Manuscript (AAM) of an article deposited into an institutional repository have to have a DOI assigned to it? | ||
+ | ** A: For cOAlition S articles all AAMs in repositories must have a unique persistent identifier (PID) assigned to them. | ||
+ | |||
C2. High quality article level metadata in standard interoperable non-proprietary format, under a CC0 public domain dedication. This must include information on the DOI (or other PIDs) both of the | C2. High quality article level metadata in 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). | 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). | ||
+ | * Mostly the same as A3, see above. | ||
+ | * With regard to deposited version the ''Content'' field for a document within a publication record can store version of the file such as: ''Draft Version'', ''Submitted Version'', ''Accepted Version'', ''Published Version'', etc. This field could be modified to use the values such as AAM, VoR, etc. | ||
+ | ** The [http://bazaar.eprints.org/1113/ REF Compliance Checker for EPrints] Bazaar plugin provides a mapping from EPrints standard content version for documents to the standardised Open Access versions like VoR and AAM. | ||
+ | * With regard to funder information, by default EPrints provides a field a ''Funders'' field that can indiviually store multiple different funders entered free-hand. | ||
+ | ** The [http://bazaar.eprints.org/390/ RIOXX2] Bazaar plugin provides more detailed entry to submit the project ID (i.e. grant reference) and the funders name and ID (as a DOI or ISNI ID). | ||
C3. Machine readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format. | C3. Machine readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format. | ||
+ | * Same as A4, see above. | ||
C4. Continuous availability (uptime at least 99.7%, not taking into account scheduled downtime for maintenance or upgrades). | C4. Continuous availability (uptime at least 99.7%, not taking into account scheduled downtime for maintenance or upgrades). | ||
+ | * EPrints cannot be responsible for the maintenance of the infrastructure on which it runs. However, EPrints has been demonstrated as stable software over a number of years and should not fail and lead to unscheduled downtime in normal circumstances. | ||
C5. 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. | C5. 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. | ||
+ | * By default EPrints requires an admin email address to be set its configuration and this address can be found on the About page of the repository linked off EPrints default main menu. | ||
+ | * EPrints cannot provide any guarantees that the email address has a functional mailbox, as that is the responsibility of the organisation managing the repository. | ||
=== Strongly recommended additional criteria for repositories === | === Strongly recommended additional criteria for repositories === | ||
D1. Manuscript submission system that supports both individual author uploads and bulk uploads of manuscripts (AAM or VoR) by publishers. | D1. Manuscript submission system that supports both individual author uploads and bulk uploads of manuscripts (AAM or VoR) by publishers. | ||
+ | * EPrints supports web-based user submission but also an API that allows mass upload by publishers and third parties (e.g. ORCID). | ||
D2. Full text stored in a machine-readable community standard format such as JATS XML. | D2. Full text stored in a machine-readable community standard format such as JATS XML. | ||
+ | * Similar to B3, see above. | ||
D3. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities. | D3. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities. | ||
+ | * Same as B1, see above. | ||
D4. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC). | D4. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC). | ||
+ | * Same as B7, see above. | ||
D5. 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. | D5. 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. | ||
+ | * EPrints has OAI-PMH enabled by default that allows comprehensive read-only access to content. EPrints has is own open API that allows third-party applications read/write access to submit and modify content through CRUD-based RESTful requests. | ||
D6. OpenAIRE compliance of the metadata. | D6. OpenAIRE compliance of the metadata. | ||
+ | * Same as B5, see above. | ||
D7. Quality assurance processes to link full-text deposits with authoritative bibliographic metadata from third party systems, e.g., PubMed, Crossref, or SCOPUS where feasible. | D7. Quality assurance processes to link full-text deposits with authoritative bibliographic metadata from third party systems, e.g., PubMed, Crossref, or SCOPUS where feasible. | ||
+ | * EPrints can be configured to make the fields (e.g. ID number, official URL, etc.) compulsory to ensure these are set so the items are linked to authoritative bibliographic metadata from third party systems before that are put live. | ||
+ | * EPrints provides an issues audit tool that could be used to test full-text deposits for authoritative bibliographic metadata from third party systems. | ||
+ | |||
+ | [[Category:Plan S]] |
Latest revision as of 11:04, 8 March 2021
Plan S is an initiative for Open Access publishing that was launched in September 2018. The plan is supported by cOAlition S, an international consortium of research funders. Plan S requires that, from 2021, scientific publications that result from research funded by public grants must be published in compliant Open Access journals or platforms.
Contents
Requirements of Open Access Repositories
EPrints as an Open Access repository must meet a number of requirements. Below are the mandatory and recommended conditions across all publication venues as well as specifically for Open Access repositories. EPrints already meets a lot of the requirements. This page is a work in progress but information will be added to each of the requirements below, including information on one of more of the following categories:
- How EPrints already meets the requirement.
- What plugin or other additional component could be installed to meet the requirement.
- How EPrints could or will be modified to meet (or better meet) the requirement.
- Why it is inappropriate or not possible for EPrints to meet the requirement.
Mandatory technical conditions for all publication venues
A1. Use of persistent identifiers (PIDs) for scholarly publications (with versioning, for example, in case of revisions), such as DOI (preferable), URN, or Handle.
- EPrints provides an Identification number (id_number) field to store DOIs as well as other PIDs such as PubMed ID, etc. There are also separate fields for storing ISSNs and ISBNs.
- Each publication record in EPrints is assigned is own URI in the format: http://HOSTNAME/id/eprint/NUMBER, (e.g. http://eprints.example.org/id/eprint/1234 ).
- There are plans to introduce a IDs, IDs, IDs Bazaar plugin similar to the Dates, Dates, Dates that will allow multiple PIDs to be stored with their types to make recording PIDs more extensible.
A2. Deposition of content with a long-term digital preservation or archiving programme (such as CLOCKSS, Portico, or equivalent).
A3. High-quality article level metadata in standard interoperable non-proprietary format, under a CC0 public domain dedication. 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).
- EPrints most comprehensive metadata export format is its EP3 XML for which an XML schema for any particular archive is available at /cgi/schema to support interoperability. EPrints also provides metadata export in many other standard interoperable non-proprietary format such as: BibTeX, EndNote, CSV, JSON, Dublin Core, RDF to name but a few. EPrints is extensible to allow repository maintainers to add additional export plugins as necessary.
- For repositories connected to other data sources (e.g. CRIS systems, or paid-for services) the 'CC0' aspect may require a metadata profile that excludes some information such as abstracts, subjects or keywords.
A4. Machine-readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format.
- EPrints generates a full_text_status value by analysing the content of a publication record to determine whether this value should be: none, public or restricted. Each document added to a publication record can be assign a license from a list of available options. Both metadata values are shown in the machine-readable EP3 XML export format and can be used.
- The page Plan S - A4 - Embedding data into an article contains details of some possible approaches to this requirement.
Strongly recommended additional criteria for all publication venues
B1. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities.
- EPrints Bazaar's ORCID Support and ORCID Support Advance plugins allow ORCIDs to be associated with publication creators and editors and user profiles. The latter also allows EPrints to connect with ORCID's platform for publication metadata interchange.
- EPrints Bazaar's IDs IDs IDs plugin allows a highly configurable IDs field to be added to publication record. This can store multiple IDs, such as DOIs, PubMed IDs, ISSNs, ISBNs, etc. along with their types an associations with the publication record (e.g. ISSN for an article's journal). It allows bespoke rendering for different types to link to URLs for DOI, PubMED, etc. lookup services.
- EPrints provides autocomplete functionality with backing lists for various fields to ensure accurate IDs are recorded for existing fields such as funders and projects. Additional fields with autocomplete can be added for funding programmes, grants, institutions andotehr relevant ednities.
B2. Registering the self-archiving policy of the venue in SHERPA/RoMEO.
- EPrints default policy page links to SHERPA/RoMEO's OpenDOAR policy tool and recommends this is used to build and ultimately register the repository's self-archiving policy.
B3. Availability for download of full text for all publications (including supplementary text and data) in a machine-readable community standard format such as JATS XML.
- EPrints currently does not provide any direct support for download the full-text of publications in a machine-readable format such as JATS XML. However, users could upload such formats and make available for download and abstract/summary page templates can be modified to highlight the availability of such formats for download.
B4. Direct deposition of publications (in a machine-readable community standard format such as JATS XML, and including complete metadata as described above) by the publisher into author designated or centralised Open Access repositories that fulfil the Plan S criteria.
B5. OpenAIRE compliance of the metadata.
B6. Linking to data, code, and other research outputs that underlie the publication and are available in external repositories.
- EPrints by default provides a Related URL field that allows linking to external repositories. This field also allow the type of relationship to be defined.
B7. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC).
- All live EPrints publication items allow for openly accessible export of citations in various formats (HTML, XML, BibTeX, EndNote, etc.)
Mandatory criteria for repositories
C1. 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.
- Same as A1, see above.
- Clarification is provided in the Plan S FAQs:
- Q: Does the Author’s Accepted Manuscript (AAM) of an article deposited into an institutional repository have to have a DOI assigned to it?
- A: For cOAlition S articles all AAMs in repositories must have a unique persistent identifier (PID) assigned to them.
C2. High quality article level metadata in 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).
- Mostly the same as A3, see above.
- With regard to deposited version the Content field for a document within a publication record can store version of the file such as: Draft Version, Submitted Version, Accepted Version, Published Version, etc. This field could be modified to use the values such as AAM, VoR, etc.
- The REF Compliance Checker for EPrints Bazaar plugin provides a mapping from EPrints standard content version for documents to the standardised Open Access versions like VoR and AAM.
- With regard to funder information, by default EPrints provides a field a Funders field that can indiviually store multiple different funders entered free-hand.
- The RIOXX2 Bazaar plugin provides more detailed entry to submit the project ID (i.e. grant reference) and the funders name and ID (as a DOI or ISNI ID).
C3. Machine readable information on the Open Access status and the license embedded in the article, in standard non-proprietary format.
- Same as A4, see above.
C4. Continuous availability (uptime at least 99.7%, not taking into account scheduled downtime for maintenance or upgrades).
- EPrints cannot be responsible for the maintenance of the infrastructure on which it runs. However, EPrints has been demonstrated as stable software over a number of years and should not fail and lead to unscheduled downtime in normal circumstances.
C5. 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.
- By default EPrints requires an admin email address to be set its configuration and this address can be found on the About page of the repository linked off EPrints default main menu.
- EPrints cannot provide any guarantees that the email address has a functional mailbox, as that is the responsibility of the organisation managing the repository.
Strongly recommended additional criteria for repositories
D1. Manuscript submission system that supports both individual author uploads and bulk uploads of manuscripts (AAM or VoR) by publishers.
- EPrints supports web-based user submission but also an API that allows mass upload by publishers and third parties (e.g. ORCID).
D2. Full text stored in a machine-readable community standard format such as JATS XML.
- Similar to B3, see above.
D3. Support for PIDs for authors (e.g., ORCID), funders, funding programmes and grants, institutions, and other relevant entities.
- Same as B1, see above.
D4. Openly accessible data on citations according to the standards by the Initiative for Open Citations (I4OC).
- Same as B7, see above.
D5. 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.
- EPrints has OAI-PMH enabled by default that allows comprehensive read-only access to content. EPrints has is own open API that allows third-party applications read/write access to submit and modify content through CRUD-based RESTful requests.
D6. OpenAIRE compliance of the metadata.
- Same as B5, see above.
D7. Quality assurance processes to link full-text deposits with authoritative bibliographic metadata from third party systems, e.g., PubMed, Crossref, or SCOPUS where feasible.
- EPrints can be configured to make the fields (e.g. ID number, official URL, etc.) compulsory to ensure these are set so the items are linked to authoritative bibliographic metadata from third party systems before that are put live.
- EPrints provides an issues audit tool that could be used to test full-text deposits for authoritative bibliographic metadata from third party systems.