CORE support for UK HEIs for REF 2029
As UK institutions’ focus begins to turn to REF2029, we continue our efforts to provide CORE members and UK HEIs with the most up to date information possible. The purpose of this document is to provide advice and recommendations to UK HEIs with regards to exposing data to CORE through their repositories to ensure optimum discoverability for Open Access scholarly articles.
In this document, we use the term repository to refer to a system that the HEI will use for the purposes as defined in the Open Access Policy for REF2029
It is important to note that for all in-scope outputs submitted to REF 2029 published between 1 January 2021 and 31 December 2025, the open access policy requirements for REF 2021 still apply.
The revised policy requirements for REF2029 came into force for all journal articles and conference contributions on 1st January 2026.
"Journal articles and conference contributions (with an International Standard Serial Number (ISSN) published between 1st January 2026 and 31st December 2028 are in-scope outputs for REF2029 and will be subject to the revised open access policy requirements for submission for REF in effect from 1st January 2026."
The REF2029 Guidance makes a clear distinction between 'Published Open Access' (aka Gold, Diamond, Platinum) and 'Outputs shared by Deposit' (Green OA)
For Published Open Access, where an output is made fully open access on publication (commonly termed 'Gold' open access, also 'Diamond' or 'Platinum'), conditional to it also fully meeting discovery, access and licensing criteria there is no further action required.
There is however some nuance in the REF guidance regarding 'outputs shared by deposit'
From 3.3.2: "Deposit: outputs subject to a post-publication embargo which are shared through institutional repositories ("Green" open access) are required to be deposited on publication rather than on acceptance for publication, which was the case in REF 2021."
However, 7.2.3 then says: "Outputs shared by deposit: Where an output will be compliant via deposit in a suitable repository or other appropriate platform, a copy of such output should be deposited within three months of publication. This includes outputs subject to an allowable embargo requirement"
This therefore indicates that ALL Green OA outputs must be deposited within 3 months of publication, not acceptance as was the case for REF2021.
Changes in allowed embargo periods
There has been a significant reduction in the allowed embargo periods for REF2029:
Another notable change repository managers should be aware of concerns the grace period' previously allowed for REF2021; "Where the output has no or a 'zero' embargo period it must meet the access requirements as soon as possible and no later than one month after deposit."
In the current REF2029 guidance, section 7 removes the explicit one-month grace period. From 1 January 2026, once deposited, outputs must be made fully accessible at the point of deposit, unless an embargo applies, in which case it must be made available after the embargo period has elapsed.
Changes in Licensing requirements
Currently, the funding bodies do not mandate any specific licence format or standard and recognise that researchers and institutions may choose from a variety of formats suitable for their output subject to meeting minimum standards identified. The current REF2029 guidance states:
"Outputs should be shared as openly as possible; the funding bodies' strong preference is for licensing as CC-BY or other licence formats meeting this standard of openness. However, licensing outputs at CC-BY-NC or CC-BY-ND (including CC-BY-NC-ND) or licences meeting an equivalent standard of openness are also permitted."
For the period 1 January 2026 to 31 December 2028 outputs shared by deposit (AAM), where subject to terms of a publication agreement limiting sharing and/or use of downloaded materials (embargo period) will not need to fully meet these licensing standards. They will however need to meet all other conditions for deposit, discovery and access.
However, from 1 January 2029 all future in-scope outputs will need to fully meet open licensing standards, subject to any permissible exceptions.
Having the correct licences clearly described in the metadata for your outputs is already an important step in making sure your content is as widely distributed and used as possible, from 2029 this will be an additional requirement to ensure compliance with REF policy.
The final guidance for how the Open Access audit will be undertaken has not yet been publicly released. The current official statement is as follows:
"The full audit guidance for REF 2029 is being developed. For open access, audit processes will broadly mirror the risk-based approach for REF 2021, subject to further review and potential adjustments."
The previous guidance is accessible via the REF website, however the relevant sections from it are given below:
46. We will assess each HEIs' overall compliance with the REF 2021 open access policy by …. : iv. Using CORE, comparing the datePublished and depositedDate and identifying where the number of days between the two dates is greater than 92.
49. Where there is insufficient evidence to demonstrate a robust and well-managed process for open access, we will identify a set of outputs from each submission made by the HEI, and request further information to verify whether they are compliant with the policy, or whether an exception applies. Outputs may be selected randomly, or based on information in unpaywall.org or CORE, or a combination of the two. We will select outputs that have been returned as compliant with the policy, and/or outputs that have been returned with exceptions.
Consequently, at this time we are advising UK HEIs and CORE Members to follow the previous guidelines and the recommendations given below.
We are currently engaging in dialogue with the REF Team (Research England), so we can continually keep you up to date with any and all changes to the published guidelines and how they may affect your institution.
The following points are recommendations we make to institutional repositories to ensure their data is well represented in CORE. While these recommendations are not mandated by Research England, implementing them will both improve the quality of the data held by CORE to support REF2029 as well as increase the discoverability and visibility of the institutions' research outputs.
We encourage institutions to expose their metadata using the Rioxx v3 metadata schema which provides native support for exposing deposit dates. CORE provides a metadata validator for Rioxx v3 in the CORE Dashboard and can provide methodological advice to Supporting and Sustaining members for implementing Rioxx v3.
1. Make sure that your institutional repository/ies are registered in CORE:
We are constantly working towards CORE indexing all repositories available. However, as repositories sometimes change their web locations, platforms or some institutions introduce multiple repositories, we advise institutions to check that their repositories are registered and listed on the CORE's data providers page.
2. Adopt Rioxx as a data format:
One of the key reasons for the development of the Rioxx metadata profile was to help institutions achieve compliance with the original REF 2021 Open Access Policy. While CORE can capture the data from repositories not supporting Rioxx, supporting Rioxx greatly reduces the complexity of the algorithm through which CORE acquires the data. The below recommendations detail which information should be shared in the metadata and how this information should be exposed in Rioxx. We further provide an example Rioxx metadata record with all information needed for REF 2029 correctly set.
3. Release deposit dates publicly, so that they are indexable by CORE:
4. We encourage repositories to expose the deposit date for each research output:
Even when Rioxx is not implemented, and ideally to mark it as "Date Deposited:". For example, EPrints repositories typically display the deposit date on the page of a given record (an example at Open Research Online). This date must be the date of the first compliant deposit. We rely on the following definition of first compliant deposit.
5. Ensure that all records to be submitted to REF have a full text linked directly from the metadata:
There are various ways of describing the link in the metadata and you can follow the guidelines for each one. In particular, we recommend storing the full text link in the dc:relation field with all the dedicated attributes if you are using the Rioxx v3 profile. In many other profiles the most appropriate place is the dc:identifier field. CORE supports most of the common profiles, so as soon as the data is stored according to the standards, it will be automatically checked.
6. Ensure that your repository OAI-PMH endpoint is operational:
The OAI-PMH endpoint in your repository enables aggregators to collect data from your repository. The Confederation of Open Access Repositories (COAR) states that the real benefits of repositories come from interoperability which gives us the ability to exchange data within a network. This is currently realised by the OAI-PMH protocol. In the majority of cases, the OAI-PMH endpoint will be correctly working in your repository by default. To check its operation there are freely available validators that ensure the correct response of the endpoint. However, the validator does not fully ensure that the data from the repository could be indexed without issues, which could be a potential problem, especially for larger repositories. Any repository can register freely for the CORE Repository Dashboard account which enables the repository to check its indexing status.
7. Ensure outputs have a registered permanent identifier (PID):
To ensure the REF research outputs can be unambiguously matched to the metadata in the repository, we recommend that institutions ensure that outputs have a permanent identifier (PID). An OAI identifier can be linked directly to each research output by the repository. CORE provides a global OAI Resolver built on top of the CORE research outputs aggregation system. Other permanent identifiers such as DOIs or PubMed IDs can also be made accessible via the record's metadata whether using Dublin Core or Rioxx V3.
Below is a minimal example of a Rioxx record with the recommended fields populated:
<!-- Example minimal Rioxx V3 record excerpt -->
<rioxx xmlns="http://www.rioxx.net/schema/v3.0"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<!-- Core identifier for the resource -->
<dc:identifier>
https://repository.example.org/handle/123456789/9876
</dc:identifier>
<!-- Related file(s) with deposit and exposed dates -->
<dc:relation
rel="item"
type="application/pdf"
deposit_date="2024-01-15"
resource_exposed_date="2024-02-01">
https://repository.example.org/bitstream/123456789/9876/1/published_article.pdf
</dc:relation>
<dc:relation
rel="item"
type="application/xml"
deposit_date="2024-01-15"
resource_exposed_date="2024-02-01">
https://repository.example.org/bitstream/123456789/9876/1/article_metadata.xml
</dc:relation>
</rioxx>Key points from the example:
<dc:identifier>: Identifies the main record (usually a landing page URI for the item).
<dc:relation ... deposit_date="YYYY-MM-DD">: Each related resource (e.g., full-text file) carries a deposit_date — the date the repository first accepted/deposited that resource.
resource_exposed_date: When the file was made publicly accessible (often same as deposit date, unless embargoed).
For further information please refer to the full Rioxx V3 schema.
1. Individual HEIs have a local and incomplete view of compliance:
An output deposited late to a repository maintained by one institution can still be compliant due to a timely deposit at another repository. Research collaborations are international, i.e. the first compliant deposit can be to an overseas repository and this could also include non-institutional subject repositories, such as arXiv. While a few institutions are involved in cross-institutional checking for possible external deposit, this practice requires human labour and is limited only to cooperating institutions. CORE has a global and more complete view over the data and can provide technology that will effectively support institutions in better understanding which outputs are compliant and which are not even prior to the REF submission.
2. Open Access uptake monitoring:
A key intention of the original REF 2021 OA Policy was to increase the proportion of OA outputs and decrease the time lag between acceptance and deposit. As a significant proportion of web transactions for accessing research papers is to recent papers, if research becomes available earlier in repositories than on publisher platforms and is, in addition, available without a paywall, this will a) significantly increase the importance of the repository infrastructure, b) accelerate research dissemination by making the scholarly communication process more efficient and c) provide better value to citizens. Citing Lord Kelvin's “If you cannot measure it, you can not improve it,” it is crucial, for any policy, that its uptake can be monitored and improvements measured at any time. By capturing this information at an aggregation level, we are enabling precisely that. For example, if institutions were to deliver deposit dates to Research England as a one-off in csv only at the time of REF submission, this would not allow such monitoring, as it would only provide deposit dates for a small subsample of content in repositories and only at one point in time. It is crucial to realise that the importance of the REF Open Access policy goes far beyond REF. The practice of depositing early should prevail beyond the REF as we should be able to monitor our journey to not just open access but also to fast open access. In the future, similar policies (e.g. due to Plan S) will require similar monitoring, so it makes sense to get ready now.
3. Audit transparency:
Exposing deposit dates and other important information in a machine readable format in support of the audit through repositories ensures transparency of the audited data. Everyone can check the data that not only gets submitted but also that is about to get submitted, ensuring good preparation leading to no surprises. Overall, transparency is a key to good research practices and open science. It also often leads to more attention resulting in improvement of processes and better quality data.
4. Efficiency:
Collecting data through an aggregation is by far the most efficient method of assembling the data. Where systems are already in place, it does not require any manual work or action. Any work likely to be conducted improves the repository infrastructure resulting in a positive change across the sector. As it is expected that similar audits might need to be carried out in the future, it is sensible to automate this process now.
5. Verifiability:
Assembling data at an aggregation level offers verifiability of the declared data. While this hasn’t been implemented so far, it will be possible to test both the presence and machine availability of the full text, which is key to many use cases, including text and data mining. Exposing data, such as deposit dates, will also be seen as a positive development by publishers. From the perspective of CORE, our intention to test these points is motivated purely by our strive to feedback any issues back to repositories and support them in creating a better and more interoperable repository infrastructure, which we all deserve.
CORE regularly indexes data from repositories in a permanent and ongoing cycle. If all the recommendations described above are followed, then the procedure is straightforward. If any deviations are present, CORE will try to collect the data in alternative ways. These include:
if Rioxx is not supported: CORE will gather metadata, such as information about the identifiers, using standard DC.
If identifiers are not available for some records, CORE will use available metadata to match these records against several key databases, including Crossref to discover those identifiers. The best way is to ensure that your repository supports the CORE OAI resolver.
If the date of publication is not supplied by the repository or it doesn't have the desired granularity (we prefer ISO 8601 (post–2004 versions) which follows the following format: YYYY-MM-DD), CORE will collect the publication date from Crossref. Where the publication date is supplied by the repository but the date is not the same as in Crossref, the decision as to which one will be used in the audit will be up to the discretion of Research England.
As deposit dates are not part of standard DC, CORE therefore implements the following two methods for collecting them:
Where deposit dates are visible through the web pages in the repository, CORE attempts to collect them by scraping them, i.e. extracting the data from the web page of the record, using custom built scrapers for a variety of repository platforms.
Where deposit dates cannot be obtained using scraping, CORE makes use of the record’s Datestamp provided in the record’s metadata. This is done in the following way. CORE stores the first Datestamp it receives for a given record, i.e. the first time CORE indexes the record, as the deposit date. Subsequent changes to the Datestamp, which could be due to the record’s updates, will not affect the deposit date. Due to the frequent indexing, this provides a close estimation of the deposit date.
This describes the method we use to collect data from repositories that currently do not support Rioxx. We might update this method if we identify a way of improving it, such as to make the data we collect more accurate.
When on rare occasions the collected data might be incomplete, it will be up to the discretion of Research England performing the audit to interpret the data. We believe that if a record present in the repository has not been indexed by CORE or it was not possible to capture some metadata, this should not negatively affect the audit result. To this end, our aim is to support institutions to identify and resolve any issues prior to the audit.
We offer a free REF review and analysis for CORE Sustaining Members.
Additionally, the CORE Dashboard, available for all data providers, provides useful information to check that your repository is being properly indexed. We also offer a free CORE Discovery repository plugin which can help repositories discover Open Access full text versions of articles for metadata records in repositories which do not have a full text manuscript attached.
If you have any further questions, please contact the CORE team for support and we will be happy to help.
CORE MembershipCORE is a mission-driven not-for-profit endeavour and a signatory of the Principle of Open Scholarly Infrastructure (POSI) and we rely on the generous support of our members to support and sustain the service.
CORE DashboardThe Repository Dashboard is a service provided to CORE Members. It offers a range of tools for repository management, content enrichment, metadata quality assessment and open access compliance checking.