Passage Data

Check a file →

How to publish a species checklist to GBIF

Species list → Darwin Core Archive (Taxon core)

What you are seeing — you have a species LIST — a site inventory, a park's flora, a survey checklist — and every instruction you can find assumes occurrence records, with dates and coordinates your list never had.

The short answer

A checklist is not a thin occurrence dataset; it is a different dataset class with its own core. GBIF ingests it as a Darwin Core Archive whose table is the Taxon core — one row per name, with taxonID, scientificName and taxonRank — and whose meta.xml declares that row type. The occurrence fields you keep being asked for (eventDate, decimalLatitude, basisOfRecord) simply do not apply.

The trap is forcing a list through an occurrence template anyway. An occurrence asserts that somebody observed this taxon at this place on this date. Your checklist asserts none of that — so every date and coordinate added to make a template validate is a small fabrication, and it will be indexed as if it were a field observation. A list published as occurrences pollutes exactly the record it was meant to enrich.

Three things decide whether a checklist archive loads cleanly. The names: scientific names, one per row — common names belong in their own column, never mixed into scientificName. The rank: a list that mixes families, genera and species must say which is which, or every downstream match is a guess. The identifiers: each row needs a taxonID that is stable within the file, because that is what the archive's internal links hang off.

This corridor is measured, not described: we built a checklist archive this way and put it through GBIF's own validator. It finished, reported the archive indexable — their word, their bar — indexed 426 records, and raised zero issues. Being indexable is the structural gate, not publication itself: getting a dataset onto gbif.org still requires a registered, endorsed publisher account, which no file tool can shortcut and we do not claim to.

Getting a list ready

  1. Keep it one name per row, and keep vernacular names in their own column — they travel in the archive's VernacularName extension, beside the science, never inside it.
  2. State the rank. If your list mixes levels — a family here, three species there — a taxonRank column is what stops a matcher treating them as siblings.
  3. Keep any higher taxonomy you have (kingdom, family): homonyms are real, and a genus name alone can match two kingdoms.
  4. Drop the file here. Columns are confirmed from their values; what the values cannot support is refused with a coded reason rather than guessed into the archive.
Bring the list — it comes back as a Taxon-core archive

Upload the spreadsheet or CSV as it is. We read the names, confirm each column from its values, refuse what the values cannot support, and emit the Taxon-core Darwin Core Archive — the same construction GBIF's validator finished on with 426 records indexed and zero issues raised. Free until 1 September 2026, 00:00 UTC · no account · your rows are discarded after the check.

Check the file you have →

Why we can say that

5,064records already published to GBIF
0findings in GBIF's vocabulary
4,268findings from ours
31.7%came back clean

Measured on a file GBIF had already accepted and served — their validator asks will this load, and it had. Every figure is read from ops/data.json, never typed here. We issue no rating and no seal — each finding names the rule it applied.

Related