Publishing Data to OBIS

Dataset preparation and export

Elizabeth Lawrence

2026-07-24

Publishing workflow

Integrated Publishing Toolkits (IPT) are hosted by OBIS nodes — you do not need to run your own server. OBIS has nodes covering most world regions. Find yours at obis.org/nodes.

OBIS has nodes covering most world regions. Find yours at obis.org/nodes. The IPT has a built-in metadata editor for EML so you do not need to write XML by hand. Emphasize that once published, the dataset gets a DOI and can be cited in papers.

Before exporting files

✅ QC checks passed

Quick self-check before moving on:

• No duplicate occurrenceID/eventID
• Coordinates & dates validated
• Taxonomy matched against WoRMS
• Required fields complete

This is a deliberately light recap — the room already did QC in an earlier session, this is just to make sure nobody’s about to export a file that still has issues. Keep this fast; the point is the transition from “QC done” to “now let’s package it,” not re-teaching QC.

What files are needed?

Every dataset = 1 core table + 0 or more extensions

For eDNA data → typically minimum of 3 DwC files:

Plus emof.csv for environmental/biotic measurements!

This is a good moment to have people physically check their own folder against this list before moving forward — “do you have 3 files, correctly named, sitting in one place?” Occurrence-core-only datasets (no Event core) would be just 2 files (occurrence + dna_derived) — worth a quick check-in on which structure people chose back in the core-table slide.

Before you publish: term checklist

Required

• eventID (if using Event core)
• occurrenceID
• eventDate
• decimalLatitude, decimalLongitude
• scientificName (+ scientificNameID/AphiaID)
• occurrenceStatus
• basisOfRecord

Strongly recommended

• organismQuantity + organismQuantityType
• samplingProtocol
• coordinateUncertaintyInMeters
• associatedSequences (DNA data)

OBIS term checklist

This deliberately echoes the key-fields slides from earlier — the goal is to give people one clean pre-flight checklist right before they touch the IPT. If a field’s missing, the IPT mapping step will surface it as unmapped, but it’s much less stressful to catch it beforehand.

Preparing your files

• Format: delimited text (.csv or .txt preferred) → not .xlsx
• Encoding: save as UTF-8
  • matters especially for accented/special characters!
• File names: short, no spaces or special characters → matches your table role (event.csv, occurrence.csv…)
• Column names: mapped to Darwin Core terms
• Large files? zip them first — IPT can unzip archives!

Saving as UTF-8

Excel: Save As → “CSV UTF-8 (Comma delimited)”

Numbers (Mac): File → Export To → CSV → Advanced Options → Unicode (UTF-8)

The 100MB IPT upload limit is per file, not per archive — zipping helps but if a single table is genuinely huge, mention there are workarounds (database connection, chunked upload) documented in the IPT manual, not something to solve live here.

A head start on metadata

Drafting metadata beforehand saves time!

Have ready before the IPT session:

• Title, abstract, citation text
• Contact + creator names & affiliations, ORCiDs
• Sampling methodology text or links
• Relevant project information (name, identifier)
• Funding or other acknowledgement statements
• Keywords, license choice (CC0 / CC-BY)

The IPT has a built-in metadata editor you can paste information into

Keep this light — the goal is just “come to the IPT session with a doc of these answers ready to paste in,” not teaching EML XML structure. We’ll cover the metadata editor itself, and what’s technically required vs. recommended, in the IPT walkthrough.

Looking ahead: automatic pipelines

Manual export → IPT works well for most datasets — especially one-off or periodically-updated ones

But…

Good to know

For institutions publishing continuously or at scale, you can set up a pipeline that pushes formatted data from an internal database → Darwin Core → the IPT via the API

This is a “know it exists” pointer, not a how-to — if it’s relevant to your institution, your node manager is the right first contact. Flagging this honestly as something to explore later rather than teaching it live — good to mention institutions with recurring monitoring data (e.g. long-term time series) sometimes go this route, but it’s a bigger lift (needs IPT API/database connection setup) than what we can responsibly cover in this workshop.

Getting started on the IPT

1. Contact node mananager to create IPT account

2. Log in to account

3. Manage resources → Create new → (= your dataset)

• Give it a short, unique shortname (no spaces/special characters — this can’t be changed later!)
• Choose a type: Occurrence or Sampling-Event

Testing?

Add _test to the end of your shortname, and let your node manager know before you delete it.

Shortnames become part of the resource’s URL and folder structure, hence the “can’t change it later” warning. Type selection here maps directly to what we covered this morning: Occurrence core vs. Event core. We’ll create a real (test) resource together in the live demo.

Uploading & mapping your data

Upload: Overview → Source Data → Choose File

Map: for each source file, click + Add and match columns to Darwin Core terms

• Double check IPT’s auto-matches
• Unmapped fields sit at bottom — check if they need to be included or leave them (they just won’t be published)
• Repeat for each table: Event, Occurrence, DNA extension, eMoF…

Watch for “redundant terms”

If a field like eventDate appears in both Occurrence and Event, the IPT will flag it - pick one table for it!

This is the step where all the field-mapping work from this morning (the key-fields slides) actually gets applied. Good moment to remind people: if they did the “map your columns to DwC terms in a documentation sheet” prep work already, this step is mostly mechanical.

Filling in metadata

OBIS/GBIF use Ecological Metadata Language (EML) — filled in through the IPT’s metadata editor, no XML needed by hand!

Bare minimum required:

• Title
• Description (abstract)
• License
• Contact
• Citation

Also worth completing: keywords, sampling methods, project information, geographic/temporal/taxonomic coverage

Good metadata is what makes your dataset discoverable and understandable (FAIR) — think about what you’d want to know before reusing a dataset

Only 4 fields are technically required, but strongly encourage completing more — geographic/temporal/taxonomic coverage in particular makes a dataset much easier to find via OBIS’s search/filter tools. This is filled in via Resource Overview → Metadata → Edit on the IPT, which we’ll show live.

Choosing a data license

License	Meaning
CC0 (preferred)	No restrictions, full public domain
CC-BY	Free use, with attribution required
CC-BY-NC	Free non-commercial use, with attribution

Check with your institution if there are copyright concerns before choosing.

OBIS lists these in order of preference — CC0 is preferred because it maximizes reuse/interoperability, but CC-BY is very common and totally fine. This is a quick, low-drama slide; most participants will already know which one their institution requires.

Publishing & keeping it updated

Publish → packages data + metadata into a Darwin Core Archive (.zip)

⚠️ Publishing ≠ public!

Visibility defaults to Private. Set Visibility → Public when ready

After publishing:

• A DOI can be assigned to your dataset for citation
• Datasets are versioned — re-upload + republish to update
  • Old versions stay accessible (&v=n in the URL)
• Never delete + recreate a resource to “start over” — just publish a new version!

This is the step people get nervous about — reassure them the Private → Public toggle is a deliberate safety net, and test datasets should just get _test in the shortname and a heads-up to the node manager rather than being made public. Versioning means mistakes are very recoverable — nothing is destroyed by re-publishing.

Publish once, reach both networks

Your dataset can also be registered with GBIF — no separate upload needed!

• Publication section, set Registration → Registered
• Not required for OBIS — OBIS already harvests your IPT independently
• Skip if dataset is already published in GBIF by another publisher
  • Ideally there is only one IPT resource per dataset
• IPT itself must also be registered with GBIF (ask your node manager)

Publish once, use many times

OBIS and GBIF collaborate to ensure biodiversity data reaches both networks. Data providers only need to upload once to reach both!

Good moment to name the OBIS/GBIF relationship explicitly: OBIS focuses on marine data with WoRMS as its taxonomic backbone, GBIF is broader biodiversity with Catalog of Life — but they share the same underlying IPT infrastructure and Darwin Core standard. Worth flagging one real gap though: OBIS-specific extensions (eMoF, DNA-derived data) aren’t currently included when a dataset is viewed/downloaded through GBIF — so eDNA-specific detail may not carry over even though the core occurrence data does.

Let’s see it live

We’ll now walk through a real IPT instance together:

1. Create a (test) resource
2. Upload source data & map to Darwin Core
3. Fill in minimum metadata
4. How to publish → set visibility → done ✅
5. Add to GBIF network!

This slide is just a checkpoint to move into live demo