Joining CORE as data provider
To check whether your repository or journal is harvested by CORE, go to our data providers list.
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.
Yes it can, provided that the repository offers its content as Open Access.
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.
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.
Yes, this is possible. Please contact us and we will enable this for your repository.
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.
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.
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.
Use the registration form to retrieve your personal access key for the CORE API.
If you plan to use the CORE API we kindly ask the following:
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.
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
Download a high resolution logo of CORE.
You can find the most recent CORE brochure in our resources list.
Access the CORE’s flyer in our resources.
Visit our research page.
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.
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 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.
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.
CORE captures data as explained in the CORE recommendations.
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.