Joining CORE as data provider
CORE uses information from various registries, such as OpenDOAR and DOAJ, to include new repositories and journals into CORE. If your repository or journal is already registered with some authoritative registry, you don't need to do anything. If your repository or journal has not been registered yet use the form to add it.
CORE is an international service and harvests repositories from various locations around the world. This information is displayed in a map at our data providers page.
CORE is a harvesting service and is not similar to research networking sites, e.g. ResearchGate or Academia.edu, where authors can deposit papers, so please do not email us the full text of your papers. If you have deposited your articles in a repository let us know the name of the repository. There are chances that we harvest it already and if we don’t we could start harvesting it.
CORE harvests DOAJ as a single entry, which means that each journal title does not appear separately in CORE. If you wish to have a separate entry for your journal in CORE, do send us the journal's OAI base URL and we will create a new entry.
CORE does not harvest all the repositories that exist in our database with the same frequency. Repositories are harvested as frequently as our HW infrastructure allows. The specific time of harvesting for a repository is determined by the CORE Scheduler. The CORE Scheduler is a software component that ensures that our harvesting cluster of machines is close to fully utilised 24/7 for 365 days every year. As soon as some resource is freed, the CORE Scheduler decides which repository needs to be harvested based on several criteria. These criteria include, but are not limited to, the previous time of the repository being harvested, the size of the repository, the location of the repository, the repository's harvesting performance and information about potential previous harvesting errors. We review the functionality of the scheduler on a regular basis to ensure that its decisions on what to harvest next maximise the number of ingested documents over a unit of time.
If you have a question regarding a specific repository do get in touch with us.
Depending on the size of the repository and the existing traffic in CORE's servers, the harvesting can last from a couple of hours to a couple of weeks. If we experience any technical issues during that period, we will get in touch.
CORE harvests all metadata records in a repository, but it is in position to harvest full text records in PDF only. We are working though to include other file types, such as HTML webpages, images etc.
My repository has plenty of metadata records, but not all of them have an open access full text. Can my repository be harvested by CORE?
Log in to the CORE Repository Dashboard and look under the issues tab. Examine whether CORE has the correct oai base url of your repository or if there are any technical issues listed there. If there are no technical issues or you do not have an account for the CORE Repository Dashboard contact us.
CORE works at the level of repositories and cannot update specific records. You can upload the new record into your institutional repository or journal and CORE will synchronise it at the next scheduled re-harvesting.
No, CORE follows an automated re-harvesting process and your repository will be re-harvested at the next automated re-harvesting.
Google Scholar is a search engine containing scholarly research papers but it is not designed to aggregate repository and journal systems. More specifically:
- Google Scholar crawls and indexes research papers that can be found on the web and links to the original source, while CORE harvests and caches the full text.
- Google Scholar limits its access only at the granularity level, i.e. its search engine, whereas CORE is in position to extend access to raw data and, apart from the CORE search engine.
- Google Scholar offers both closed access and open access resources, while CORE offers open access resources only, enabling immediate access to full text.
- The audience is different. Even though CORE has a search engine where users can retrieve scientific literature, it focuses also on other types of research stakeholders, such as text miners and repository managers, and offers services designed for them, such as the CORE API and Dataset.
CORE does not create the metadata, but rather harvests them from its content providers. If the metadata are wrong then contact the repository or journal where you had originally deposited or published your content.
CORE can offer repository or journal full text download statistics per month via the CORE Repository Dashboard but is not in position to offer single item downloads yet. If you do not have access to the Dashboard contact us.
Yes it does. CORE harvests content from repositories and journals. The first do not perform peer review of the deposited content but the latter do. In some occassions the content deposited in a repository is already published in a journal and is peer-reviewed. In addition, repositories may contain grey literature and these resources are not peer-reviewed.
CORE has created definitions with regards to the statistics it provided to OpenDOAR.
Metadata: The total number of metadata records with a unique OAI identifier provided by the repository as this appears in the application profile which CORE harvest - if CORE harvests from the RIOXX endpoint, CORE will provide RIOXX counts instead of Dublin Core counts.
Full text: Count of metadata records - as above - with a least one attachment provided by the repository being a pdf file, which a) is publicly downloadable (no-login required or output is not under embargo, etc.) and b) the full text is machine readable, i.e. it has an extractable text not via OCR.
CORE does not own any rights of the aggregated content and each resource has its own license, which should be respected by the CORE users.
I landed at a CORE URL linking to a full text PDF but the link gives a 404 error. How can I access this output?
You cannot access it – a 404 error indicates that the full text has been removed from CORE.
My repository contains a mix of OA and non-OA papers. Can I ask CORE to limit harvesting only to OA papers?
Yes, this is possible. Please contact us and we will enable this for your repository.
In order to realise the data transfer and regular data updates of CORE and your system, CORE uses a variety of protocols to ingest the content. The easiest way to get your content integrated with CORE is the OAI-PMH protocol. If you wish to join CORE get in touch.
OAI base URL looks similar to
http://journaldomain.com/oai/request when homepage URL is
http://journaldomain.com. CORE cannot harvest the
journal’s/repository’s content via its webpage URL.
If you are not sure whether your journal/repository has an OAI base
URL, contact our team and we will provide
technical support to you.
A more technical answer for https://support.core.ac.uk
Target audience: repository managers, Technical staff.
An OAI Identifier is a unique identifier which distinguishes items in a repository. It “unambiguously identifies an item within a repository; the unique identifier is used in OAI-PMH requests for extracting metadata from the item”
The Identifier contains 3 parts, split using:
“oai“ : Unique identifier oai. This describes the type of the identifier
“website address”: Where the item is hosted.
“Unique identifier”: An identifier of the object
Not all OAI Identifiers look like this, but they are non-standard and their use is discouraged. OAI Identifiers must follow the URI (Uniform Resource Identifier) syntax. For more information about how OAI Identifiers are formed, visit Specification and XML Schema for the OAI Identifier Format.
We would expect that harvesting could take from one hour to a couple of days for a typical repository. In some repository systems, such as EPrints, most of these recommendations are followed by default. Find more details how it works.
We mainly support oai_dc, the mainstream metadata format used in the OAI-PMH Protocol, utilising the Dublin Core vocabulary, a popular vocabulary for bibliographic data. We also support RIOXX, a richer metadata protocol, used mostly by the UK repositories.
To provide its service, it is essential for CORE to be able to store a cached copy of the harvested content. This is needed to verify open access sources, offer analytical services, support text and data mining, recommendation tools, etc. By cashing a copy of the harvested resource, CORE is not different from many commercial and non-commercial, academic and non-academic, search engines including Google or CiteSeerX. The primary difference from such systems is that CORE caches only copies of open access content. More information on the benefits of this approach is available in the “CORE: Three Access Levels to Underpin Open Access” article.
CORE uses information from various registries, such as OpenDOAR, to include new repositories, journals and archives into CORE. If the circumstances have changed in your repository, you can restrict harvesting and crawling activities by modifying your rules in your “robots.txt” file by using the Standard for Robots Exclusion. This will also guarantee the content cannot be cached by search engines and harvesting systems. In addition, you could withdraw your repository from all open access registries lists; when this takes place, please notify us.
Removing full text or metadata
CORE aggregates content from repositories registered in OpenDOAR, journals registered in DOAJ or those content providers that requested their content to be aggregated. This means that all the content sources aggregated by CORE must be open access as this is a requirement for the providers to be included in these registries. According to the official BOAI definition of open access, CORE is allowed to, "distribute, search, or link to the full texts of articles, crawl them for indexing, pass them as data to software, or use them for any other lawful purpose, without financial, legal, or technical barriers other than those inseparable from gaining access to the Internet itself. The only constraint on reproduction and distribution, and the only role for copyright in this domain is to give authors control over the integrity of their work and the right to be properly acknowledged and cited."
CORE’s system is fully automated and relies on data made available in a machine readable form. If your repository hosts full text with a restrictive license that prohibits harvesting, this needs to be properly communicated in a machine readable form. All non open access items should be blocked in the robots.txt file. If this information is provided in the metadata for each record and CORE exposes the full text, please get in touch with us.
An output's license is not consistently exposed by content providers in a machine readable form. In some circumstances it may be possible to extract this from the "fulltextUrls" field in the CORE API. However, this is subject to the license the data offered by the data provider.
CORE’s system is fully automated and relies on data made available in a machine readable form. Our system understands that the full text of a record was removed only when the record is marked as deleted in the metadata of your repository. See how to take down full text from CORE in the related FAQ.
If full text content appears in CORE but not in the hosting service your repository manager can take it down via the CORE Repository Dashboard anytime without notifying us. Alternatively, you can use the update or remove article form.
It is a CORE policy to remove only the full text and not the metadata. Only in limited cases - e.g. when a publication did not happen - it is possible that the metadata can be removed. In that case,email us.
In order for the metadata to be removed from CORE they need to be marked as "deleted/removed" in the repository. If the metadata are marked as "restricted" CORE will still display it.
If you plan to use the CORE API we kindly ask the following:
- attribute CORE by including in your website this snippet,
- send us an email with a brief summary on how you are using the CORE API,
- grant us permission to present this summary to our funders and/or display it on our website,
- allow us to list your company’s name, url and logo on our website.
Yes, this is possible but there is usually a cost associated with it. Please email us the name of your company or organisation, business entity, the number of requests you estimate to send and how often you will send them and we will get back to your with a quote.
Yes, you can use the CORE API for commercial purposes, (Terms & Conditions) apply. We provide 30 Day Free Trial for Institution and Enterprise. We will ask you for your circumstances during the registration process and we might contact you afterwards to clarify any points and assess your eligibility for a free licence. If your circumstances change, please let us know.
Please note the dataset has been created from information that was publicly available on the Internet. Every effort has been made to ensure this dataset contains only open access content. We have included only content from repositories and journals that are listed in registries where the condition for inclusion is the provision of content under open access compatible license. However, as metadata are often inconsistent, licensed information is often not machine readable, and repositories from time to time leak information that is not open access, we cannot take any responsibility for the license of the content in the dataset. It is therefore up to the user of this dataset to ensure that the way in which they use the dataset does not breach copyright. The dataset is in no way intended for the purposes of reading the original publications, but for machine processing only.
We aim to generate a new public dataset at least once a year. If you need a more recent dataset, please get in touch with us as we might be able to arrange it.
If you have access to the CORE Repositories Dashboard, log into the CORE Repository Dashboard and you will get the instructions on how to download the CORE Recommender. Otherwise, visit our recommender registration page, where you will also find the installation instructions. Repository managers are highly recommended to use the CORE Repositories Dashboard.
When I look at the papers I have authored, I am not pleased with the similar papers suggested by the CORE Recommender. How can I change that?
The CORE recommender uses the popular content-based filtering system. The similar resources that appear in the CORE Recommender and their quality are highly impacted by the metadata information supplied by the repository of origin. If that information is incorrect or incomplete, you should contact the repository of origin. To improve the CORE recommendations, you can use the feedback button, with which you can remove any undesirable articles.
Unfortunately CORE does not provide any language specific datasets at the moment. Users can use the CORE API to download individual PDFs.
- The organisation is a registered charity or a not-for-profit AND
- the use of the CORE service will not enable, contribute to or support the use of any paid-for service of the organisation or of another third party organisation linked to this organisation.
General information about CORE
You can use the below badges on your website to show that your content is indexed by CORE and that you are a part of CORE and Open Research community. Please chose the badges according to your membership tier and include the badges in your system by means of the supplied html tags.
CORE guidance on REF2021 Audit
Due to cross university collaborations some outputs that could be considered non-compliant due to a late deposit may be compliant due to a deposit that was made within the policy timeframe at another institution or subject repository. Individual institutions could benefit as they might not be fully aware of all compliant outputs and might consider some of their outputs non-compliant, while in fact they are compliant.
CORE captures data as explained in the CORE recommendations. By following our recommendations CORE should have the same deposit dates as the repository.
A metadata record with a full text PDF does not appear in CORE from my own repository but it has been harvested from another repository. What if the record was not deposited on time at the other repository. Will this have an impact with regards to the REF2021 compliance?
CORE can identify deposits of the same articles from across repositories. By doing so, an output deposited late in repository A could be technically compliant provided that it was deposited within the timeframe at repository B, i.e. the earliest deposit date irrespective of the repository could be used. However, for the time being, CORE agreed to supply the data to Research England and it will be up the discretion of Research England to interpret the data. We understand that the motivation is to mark outputs as non-compliant only in cases where there is clear evidence that they are truly non-compliant.
CORE harvests full text PDFs only. Does this mean that outputs with full text in other formats, e.g. word documents or text files, will not be considered as REF2021 compliant outputs?
CORE harvests both metadata and full texts, currently only in PDF format but we will include support for other formats in the future. While the presence of the full text is preferred, CORE has all information necessary to support the REF2021 audit as long as the metadata of your outputs are in CORE. To minimise the possibility of some of your outputs not being captured by CORE, please follow the CORE recommendations.
When I log into the CORE Repository Dashboard in the “Content” tab I see a date. Is this date the deposit date that CORE has for the output?
CORE captures data as explained in the CORE recommendations. By following our recommendations CORE should have the same deposit date as the repository. The date you see in the CORE API is the date the document was last seen in your repository and imported to CORE. The date exposed in the CORE Repositories Dashboard uses instead a new harvesting system that reads the “deposited date” exposed by your own repository system.
Deposit dates are available via the CORE Repositorу Edition. Repository managers can access the percentage of papers that are non-compliant, e.g. outputs that were deposited 90 days or more after publication, according to the REF 2021 Open Access Policy.
This is possible via a subscription to the CORE Repository Edition. Repository managers can access the percentage of papers that are non-compliant, e.g. outputs that were deposited 90 days or more after publication, according to the REF 2021 Open Access Policy.
The date that a metadata record was created may not be the same with the date that the full text record was attached to a metadata record. How does CORE know the date that the full text was attached?
How does CORE know that the version of the deposited full text is the correct and compliant version?
The validation that the deposited full text is the first compliant version is currently not in the scope of CORE's support for the REF2021 Audit. Research England might use other alternative methods to check this.