A pressed plant can cross the world without leaving its cabinet. Its photograph travels with a collector's name, a date, and a place—but those details need structure before another researcher can search them. The open-source tools around botanical collections divide that work among a collection portal, a publishing application, and a global index. Understanding how Symbiota, Darwin Core, and GBIF's Integrated Publishing Toolkit fit together begins with a small question: when somebody corrects the record, which copy should change first?
At the Smithsonian's National Herbarium, that question has a very physical backdrop. A conveyor carried sheets of dried plants beneath a camera, while labels were transcribed from the images. The museum reported completing the mass digitization project in May 2022, bringing 3.8 million sheets online.[1] The photograph preserves what was on the paper; searchable fields give its contents another life.
The distinction remains useful as larger collections come online. Davide Castelvecchi's 2026 reporting for Nature, republished by Scientific American, describes Kew's newly digitized specimens becoming accessible through both its own website and GBIF, the Global Biodiversity Information Facility.[2] My reading of that arrangement is simple: a collection needs a useful home for its records and a way for people elsewhere to discover them. Those jobs can share data without sharing an application.
Where the correction belongs
Symbiota is open-source software for managing and publishing biodiversity data. Its portals provide tools for editing, georeferencing, searching, and curating collection records.[3] A herbarium can use one as its working database, or use it to expose a copy of data managed elsewhere.
The documentation calls these live and snapshot collections. With live management, authorized users enter and edit records in the portal through a browser. With a snapshot, another system—such as Specify or Arctos—holds the working data, and Symbiota imports a copy. Saved import profiles support later updates, provided the source's unique identifier, called dbpk in Symbiota, remains consistent.[4]
Imagine a curator correcting a misread collecting date. In a live collection, the portal is the obvious place to make that correction. In a snapshot arrangement, the correction needs to reach the upstream collection database and then the next export. This is an operational implication of the two models: a public page can display a record without being the place responsible for maintaining it.
For a small herbarium with one part-time data manager, joining an existing portal may be more practical than operating another application. A larger institution with an established collection database may prefer a snapshot. Either arrangement needs someone who can identify the authoritative record and explain how corrections reach its public copies.
Give the fields a shared meaning
Darwin Core is a vocabulary, rather than a database product. Its terms let different systems describe comparable information: recordedBy for the collector, eventDate for the collecting event, and scientificName for the identification. A preserved specimen can be described using basisOfRecord with the value PreservedSpecimen.[5]
Some of its most useful fields preserve the limits of knowledge. verbatimLocality retains the original locality description. Coordinates can be accompanied by coordinateUncertaintyInMeters, which describes the radius needed to encompass the location; zero is not a valid value.[5] A historical label naming a valley should not silently become a claim that someone knew the plant's position to the nearest metre.
Identity deserves the same care. occurrenceID identifies the occurrence, rather than merely a particular digital record of it.[5] A corrected spelling or collecting date should therefore prompt an update to the existing occurrence's description. Treating every export as an opportunity to assign fresh identities makes it harder to follow that history.
Package the record for another system
A Darwin Core Archive, usually shortened to DwC-A, packages tabular data for exchange. In a typical specimen publication, an Occurrence core contains the main rows. Extension files can attach several related entries, such as images, to one core row. Each extension row points back to a core record.[6]
The archive's meta.xml describes the files, column mappings, and relationships. Dataset-level metadata supplies context such as authorship, methods, and description, commonly using Ecological Metadata Language. These files travel together in a compressed package.[6]
That design gives software a way to interpret a table whose local headings differ from its own. It also establishes a limit: an export is a representation prepared for sharing. Before treating it as a replacement for the collection database, a team would need to establish which local relationships and history it actually contains.
Two routes into the same search system
GBIF's Integrated Publishing Toolkit, or IPT, is an open-source web application for publishing biodiversity datasets. It connects published resources to the GBIF registry and can be configured to assign dataset DOIs through DataCite. Institutions can operate an installation themselves or use a trusted hosting centre.[7]
IPT belongs at the publication stage. It is useful when a team already maintains data elsewhere and needs a place to prepare and manage what it shares. Its manual recommends hosted access as the simplest starting point; maintaining a private installation also means keeping the software updated.[7]
But a Symbiota collection does not have to pass through IPT. A configured Symbiota portal can create a Darwin Core Archive and publish directly to GBIF. Its documentation places two conditions on using that route for snapshot collections: the same data must not already be published through another route, and the imported records must carry their occurrenceID values. Previously assigned identifiers must come along when records are republished.[8]
The choices are easier to compare by responsibility:
| Part of the ecosystem | Main responsibility | A collection still has to decide |
|---|---|---|
| Symbiota live collection | Maintain and expose working records | Who may edit them and review corrections |
| Symbiota snapshot collection | Expose records maintained elsewhere | How updates return to and arrive from that source |
| Darwin Core Archive | Carry structured records between systems | Which fields and relationships to publish |
| IPT or Symbiota's publishing tools | Make a dataset available to aggregators | Which route is responsible for this dataset |
| GBIF | Make records discoverable across datasets | Whether the resulting interpretation suits the research |
This is a map of available roles, not a claim that the Smithsonian or Kew uses every component. The warning about duplicate publication is especially practical: two delivery routes can make the same collection look like two datasets. More endpoints do not automatically provide better evidence.[8]
What comes back from GBIF
Publication does not end the transformations. GBIF's Darwin Core Archive downloads distinguish occurrence.txt, containing interpreted occurrence data, from verbatim.txt, containing data before GBIF's interpretation. The documentation qualifies even that latter description: Unicode conversion and whitespace changes may occur. Multimedia information has its own file.[9]
The separation makes disagreements investigable. If a name or location looks surprising, a researcher can compare the publisher's supplied value with the indexed interpretation. A successful download proves that information travelled; it does not establish that every collecting locality or identification is correct.
For a collection team, I would test this with one ordinary record and one awkward historical label before expanding publication. Follow both through the chosen route, compare the public fields with the source, then correct a value and verify the next published version. That exercise tests ownership, identifiers, mapping, and refresh together.
The reward is a longer useful life for the sheet in the cabinet. Someone far away can find it, inspect the evidence, and ask a better question. Open-source software helps that journey when the record retains both a stable identity and a route back to the people who can correct it.
Sources
- Jack Tamisiea, “2022 in Review: The National Herbarium Goes Digital,” Smithsonian Voices, December 20, 2022 — digitization workflow and Ingrid Lin's conveyor photograph.
- Davide Castelvecchi and Nature magazine, “London botanic gardens digitizes 7 million specimens,” Scientific American, June 30, 2026 — independent reporting on access through Kew and GBIF.
- Symbiota Support Hub, “Welcome to Symbiota Docs!” — open-source status, portal functions, and user roles.
- Symbiota Support Hub, “Management Types,” documentation version 3.4 — live and snapshot collections, source systems, and stable import identifiers.
- Biodiversity Information Standards (TDWG), “Darwin Core Quick Reference Guide” — definitions of record type, collecting information, locality uncertainty, and occurrence identity.
- GBIF Secretariat, “Darwin Core Archives — How-to Guide,” version 2.2 — core and extension files, identifiers, descriptor, and dataset metadata.
- GBIF, “Integrated Publishing Toolkit User Manual” — publication scope, registry integration, DOI configuration, hosted access, and maintenance.
- Symbiota Support Hub, “Publishing Data to GBIF,” documentation version 3.4 — direct publication, snapshot requirements, duplicate routes, and retained occurrence identifiers.
- GBIF, “Occurrence download formats” — interpreted records, verbatim data, multimedia files, and encoding qualifications.