OAI-PMH

OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), current version 2.0 published in 2002, is a lightweight HTTP/XML protocol that lets a ‘data provider’ — typically a repository or CRIS — expose its metadata records for incremental harvesting by ‘service providers’: aggregators, search services, and national portals. It defines six verbs (Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords, GetRecord) issued as simple HTTP GET requests, with responses returned as XML. The protocol is metadata-format-agnostic: unqualified Dublin Core is the one mandatory format every OAI-PMH endpoint must support, but a provider can expose additional schemas — CERIF-XML, MODS, RIOXX, JATS, and others — in parallel for the same records.

What problem OAI-PMH solves

A large aggregator (a national open-access portal, a subject repository, a search index like BASE or CORE) needs to pull updated metadata from thousands of independently run repositories without re-crawling each one’s full contents on every pass. OAI-PMH’s resumption token and selective-harvesting-by-date mechanics let a service provider ask a repository for “everything changed since my last harvest” rather than everything, which is what made repository-scale metadata aggregation practical at web scale in the early 2000s and is still how most of it works today.

How a research office encounters OAI-PMH

• An institutional repository (DSpace, EPrints, or a CRIS’s public interface) almost always exposes an OAI-PMH endpoint even when nobody in the office has configured it directly — it is default infrastructure the repository platform ships with.
• National and disciplinary aggregators (OpenAIRE, BASE, CORE, many national open-access monitors) harvest institutional repositories via OAI-PMH to build their combined indexes; if a repository’s OAI-PMH endpoint is broken or set is misconfigured, that institution’s outputs can silently disappear from those aggregators’ coverage.
• Compliance checks for green open-access mandates often depend on an aggregator correctly harvesting the repository record via OAI-PMH, which means troubleshooting a “missing from OpenAIRE” complaint frequently starts with checking the repository’s OAI-PMH feed and set configuration.

Why a twenty-year-old protocol is still the default

OAI-PMH’s simplicity (plain HTTP GET, XML, six verbs) is also its longevity: it needs no authentication for open metadata, is trivial for repository software to implement, and every major repository platform and aggregator already speaks it, which creates strong network effects against switching to something newer. It remains the dominant repository-harvesting protocol in research-information ecosystems even though it predates REST/JSON API conventions and has known limitations — XML-only responses, no push notifications (harvesting is always pull-based and periodic), and no built-in authentication layer.

How it relates to other terms in this cluster

• ‘Crossref DOI‘ and ‘DataCite DOI‘ — both registration agencies expose an OAI-PMH endpoint alongside their REST APIs, so their full metadata corpora can also be harvested this way.
• ‘OpenAIRE EXPLORE‘ — the public discovery front-end for the OpenAIRE Graph, much of which is built from OAI-PMH-harvested repository and CRIS records.
• ‘OAI-ORE‘ and ‘ResourceSync‘ — related and successor protocols addressing gaps OAI-PMH does not cover (compound-object description, and more efficient/near-real-time synchronisation, respectively).

Frequently asked questions

Is OAI-PMH the same as an RSS feed? No — a plain RSS feed lacks OAI-PMH’s resumption-token semantics for reliably harvesting large, changing collections in batches, and lacks its set-based selective harvesting; RSS is a much simpler, non-standardised mechanism for “what’s new.”

Does a REST API returning JSON count as OAI-PMH? No, unless it also implements the actual OAI-PMH verbs and XML responses — a modern JSON API is not a substitute for an OAI-PMH endpoint from an aggregator’s point of view unless the aggregator specifically supports that alternative.

Why would our outputs be missing from an aggregator like OpenAIRE if our repository is working fine for human visitors? The two are separate systems — a repository’s OAI-PMH endpoint can be misconfigured, blocked, or missing required metadata fields (like funder or licence information) even when the human-facing website works normally, since harvesting depends entirely on the OAI-PMH interface, not the site’s HTML pages.

References

• Lagoze C., Van de Sompel H., Nelson M., Warner S., ‘The Open Archives Initiative Protocol for Metadata Harvesting, Version 2.0’ (openarchives.org/OAI/openarchivesprotocol.html), 2002.