Every biodiversity dataset published to GBIF (the Global Biodiversity Information Facility) is a collection of individual Darwin Core Occurrence records — each one documenting the presence of an organism at a place and time, whether that’s a live sighting, a camera-trap image, an eDNA sample, or a pinned museum specimen. occurrenceID is the Darwin Core term that identifies one specific record, distinct from the taxon it represents, the collection it lives in, or the dataset it was published through. Get occurrenceID wrong — or leave it out — and downstream aggregators, citing researchers, and even the publisher’s own future data updates lose the ability to reliably tell one occurrence record from another over time.
What occurrenceID actually identifies
Darwin Core, maintained by Biodiversity Information Standards (TDWG), defines occurrenceID in its official term list as “an identifier for the dwc:Occurrence (the object, instance, or record of the occurrence).” The Darwin Core Quick Reference Guide is explicit about what that identifier needs to be: recommended practice is to use “a globally unique and persistent identifier.”
That definition is doing two jobs at once. First, occurrenceID identifies the record, not the organism, the specimen lot, or the species — a single physical specimen could in principle be represented by more than one Occurrence record (for example, if it’s re-digitized or re-published), and each of those records is what occurrenceID distinguishes. Second, “globally unique and persistent” sets a bar that a lot of legacy biodiversity data doesn’t clear: an identifier that is unique across every collection and institution publishing to GBIF, not just unique within one museum’s own database, and one that does not change even as the record’s other fields — taxonomic determination, georeferencing, curatorial location — get corrected or updated over time.
How occurrenceID works in practice
Darwin Core deliberately does not prescribe a single required syntax for occurrenceID — the standard sets the persistence/uniqueness requirement and leaves the specific scheme to the data publisher. In practice, publishers commonly use one of a few patterns:
- A UUID — a machine-generated universally unique identifier with no embedded meaning, e.g.
96db9d09-596d-409c-8626-f4460078d0eb, the exact style of example GBIF’s own Integrated Publishing Toolkit (IPT) manual shows for this term. UUIDs are easy to generate in bulk, guaranteed unique without coordination, and don’t break if an institution reorganizes its catalog numbering. - A resolvable URL pointing to the record’s page on the publishing institution’s own collection-management system or portal, which has the advantage of being directly clickable/dereferenceable but depends on that institution keeping the URL stable indefinitely.
- A namespaced string built from the institution’s own stable internal record key, prefixed to avoid collisions with other publishers’ keys.
Whichever pattern a publisher chooses, the operational discipline is the same: mint the identifier once, attach it to the record, and never reassign it or reuse it for a different occurrence — including across re-publications, dataset version updates, or migrations to new collection-management software. An occurrenceID that silently changes between GBIF harvests breaks every external citation, dataset, or research workflow that referenced the old value.
The Darwin Core “triplet” — the fallback occurrenceID replaced
Before occurrenceID was widely adopted, the de facto way to identify a specimen record was the Darwin Core triplet: a concatenation of institutionCode, collectionCode, and catalogNumber (commonly written as urn:catalog:institutionCode:collectionCode:catalogNumber). GBIF still accepts triplet-based identification for datasets that don’t supply occurrenceID, and where occurrenceID is absent GBIF’s data-processing pipeline falls back to constructing an identifier from the triplet fields.
The triplet has a well-documented reliability problem. Institution and collection codes are administrative conventions that institutions change — through mergers, rebranding, or internal reorganization — and catalog numbers can be reassigned, corrected, or duplicated across collections that don’t coordinate with each other. A 2014 peer-reviewed analysis, “The Trouble with Triplets in Biodiversity Informatics” (PLOS ONE), documented how often triplet-based identifiers turn out to be non-unique or unstable in real aggregated data, which is a core part of why GBIF actively promotes occurrenceID as the more reliable alternative and why the IPT’s own release notes have specifically called out “promoting the use of stable occurrenceIDs” as a data-quality goal. In short: the triplet is a legacy fallback GBIF still has to support because so much historical data uses it, not a pattern to design new data-publishing workflows around.
occurrenceID vs. GBIF’s own internal record identifiers
It’s worth distinguishing occurrenceID — the Darwin Core field a data publisher assigns and controls — from the internal identifiers GBIF itself generates once a dataset is indexed. GBIF’s own data-processing documentation describes combining the publisher-supplied occurrenceID (or the triplet, when occurrenceID is absent) with dataset-level information to derive and maintain a stable internal record identifier used to track that occurrence within GBIF’s index across repeated harvests of the source dataset. The practical implication for a data publisher is that supplying a genuinely stable, unique occurrenceID up front gives GBIF’s processing the best chance of correctly recognizing “this is the same record as last time” on every future re-harvest, rather than risking the record being processed as new or orphaning citations that pointed at the prior version.
Why persistent identification at the occurrence level matters
Biodiversity data infrastructure is built on aggregation: GBIF alone republishes contributed datasets from a global network of national and thematic Participant Nodes, and the same underlying specimen or observation record can be referenced from a published paper, a national biodiversity portal, a museum’s own catalog, and a downstream research dataset all at once. A stable occurrenceID is what makes several things possible at that scale:
- Citation and reuse. A researcher who wants to cite the exact specimen record behind a species distribution model, rather than the dataset as a whole, needs a granular identifier that will still resolve to the same record years later.
- Deduplication and record-linking. When the same specimen is digitized by more than one institution, or the same occurrence is contributed to both GBIF and a thematic aggregator such as OBIS (the marine-focused Darwin Core aggregator), a persistent occurrenceID is one of the signals used to recognize that two records describe the same underlying occurrence.
- Data-quality tracking over time. Taxonomic determinations get revised, georeferencing gets corrected, and specimens get re-curated. A stable occurrenceID lets those corrections be applied to the same persistent record rather than creating an orphaned duplicate every time a dataset is republished.
- Machine-actionable linking. occurrenceID lets other Darwin Core terms — and external systems entirely — reference a specific occurrence unambiguously, which is what makes automated cross-referencing between collections, literature, and derived datasets possible at GBIF’s scale.
occurrenceID in the broader persistent-identifier landscape
occurrenceID is a domain-specific instance of a general pattern research infrastructure relies on throughout: a persistent identifier (PID) that stays constant for the life of the thing it identifies, independent of where that thing is currently hosted or how its metadata changes. It sits alongside, but serves a different scope than, the PIDs a research administrator more commonly works with — a DOI typically identifies a published dataset or article as a citable unit, an ORCID iD identifies the researcher, and an IGSN identifies a physical geoscience sample. occurrenceID fills the equivalent role specifically for individual biological and museum specimen occurrence records within the GBIF/Darwin Core ecosystem — a distinct identifier scope from any of those, and not a substitute for citing the dataset itself via its DOI when that’s what’s actually being referenced.
Practical guidance for data publishers
- Assign occurrenceID at the point of first digitization or record creation, before publishing to GBIF or an IPT instance — don’t leave it to be generated automatically downstream if you can help it.
- Use a scheme your own collection-management system can guarantee is unique across your entire institution, not just within one collection, and keep a record of how it’s generated so future staff don’t accidentally reuse values.
- Never change an existing record’s occurrenceID when correcting other fields (taxonomy, locality, dates) — update the record in place and keep the identifier stable.
- If migrating from triplet-based identification, mint real occurrenceIDs rather than mechanically deriving them from the triplet, since the triplet’s own instability is the problem being solved.
- Document your occurrenceID scheme in your dataset’s metadata so data users and aggregators understand how to interpret and, where relevant, dereference it.
Frequently asked questions
Is occurrenceID required in a Darwin Core Archive?
occurrenceID is not enforced as a hard schema requirement the way core terms like basisOfRecord are, but it is GBIF’s strongly recommended practice for every Occurrence record, precisely because the fallback (the triplet) is documented to be unreliable at scale. Data publishers should treat it as required in practice even where it isn’t mechanically enforced.
Can occurrenceID be a simple sequential number?
A sequential number can be unique within one institution’s own database, but it will not be globally unique once combined with other publishers’ data unless it’s properly namespaced (for example, prefixed with a stable institution identifier). A plain unqualified sequence number does not meet the “globally unique” half of Darwin Core’s recommended practice on its own.
What happens if a dataset doesn’t supply occurrenceID at all?
GBIF’s processing falls back to the Darwin Core triplet (institutionCode/collectionCode/catalogNumber) to construct an identifier, but that fallback is exactly the unstable pattern occurrenceID exists to replace — records identified only by triplet are more prone to being mismatched or duplicated across dataset re-harvests.
Does occurrenceID replace the need for a dataset-level DOI?
No — they operate at different levels. A dataset DOI identifies and makes citable the published dataset as a whole (typically minted through GBIF’s own dataset registration or a repository like an IPT-connected data host); occurrenceID identifies one Occurrence record within that dataset. A citation to a specific specimen record properly references both: the dataset DOI for the collection as a whole, and the occurrenceID for the specific record within it.
For related persistent-identifier and biodiversity-infrastructure coverage, see CASRAI’s Darwin Core and GBIF dictionary entries, the OBIS guide, and the Persistent Identifiers & Research Information Systems pillar.
