Types of DNA-derived data

DNA Data and Darwin Core: The DNA Derived Data Extension

Elizabeth Lawrence, Emilie Boulanger, Saara Suominen

2026-07-22

Five DNA data categories

Which one fits your data?

#	Category	Example
1	DNA-derived occurrences	Metabarcoding (ASVs/OTUs assigned to taxa)
2	Enriched occurrences	Voucher specimen + barcoded
3	Targeted species detection	qPCR / ddPCR assays
4	Name references	Sequence in GenBank only
5	Metadata only	Dataset without sequences

🔎 Use the GBIF decision tree to confirm your category

We won’t go into details on this slide - just reiterating that Categories 1 and 3 are by far the most common for eDNA researchers. Category 1 covers metabarcoding; Category 3 covers targeted detection methods like qPCR/ddPCR where no sequences are produced. Be aware that there are other possible types but they are outside the scope of this workshop.

eDNA data standards

Two major eDNA data standards exist

1. MiXS
   (Minimum Information about any (x) Sequence) — for raw sequences in NCBI

2. Darwin Core (DwC)
   Community vocabulary for biodiversity data — species, location, date, basis of record

OBIS + GBIF + ALA accept genetic data linked to spatial coordinates and time

🔜Developing landscape

• Rapidly changing field
• For OBIS future directions include the DWC-DP and FAIReDNA terms

Raw sequences deposited in NCBI lack coordinates and dates — they cannot answer where or when a species was detected. OBIS, GBIF, and ALA now accept DNA-derived occurrences linked to space and time. DNA data requires special care: it is derived, depends on reference databases, and often produces many unknown sequences. The Darwin Core DNA extension preserves methodological context for future re-analysis.

Darwin Core + DNA Derived Data Extension

• Darwin Core: shared vocabulary for biodiversity data
  
• DNA Extension: adds MIxS terms for sequences, primers, methods
  
• Developed jointly by GBIF, OBIS, and the genomics community

meta.xml ← links all tables
eml.xml ← metadata (who, what, where, when, how)
occurrence.csv ← the occurrence records
dna_derived.csv ← the DNA extension

MIxS = Minimum Information about any (x) Sequence. The extension incorporates these community standards so the same fields used in INSDC/GenBank submissions can be reused here.

Core table for DNA data

DNA data can be published with either core type:

• Occurrence core + DNA extension
• Event core + Occurrence extension + DNA extension

This wasn’t always true

Previously guidance required Occurrence core only for DNA data. Event core support was added recently!

Both options link the DNA extension via occurrenceID. Event core additionally lets you record sample-level metadata (location, date, method) once per event instead of once per sequence — see the next slide for why that matters at scale. A caveat worth mentioning live: even with Event core, some duplication is unavoidable because of the star schema (DNA extension still needs occurrenceID, so each occurrence still carries a full sequence/sample link). A newer GBIF/OBIS data model in development aims to remove this constraint entirely, but it isn’t implemented yet (as of late 2025).

Key DwC fields to include: Event

Event core (mandatory fields)

• eventID — unique, stable ID
• eventDate — YYYY-MM-DD
• decimalLatitude, decimalLongitude
  

Event table (strongly recommended fields)

• minimumDepthInMeters, maximumDepthInMeters
• sampleSizeValue (volume of sample)
  
• sampleSizeUnit (units of volume sampled)
• samplingProtocol - (link to your field sampling SOP)

Key DwC fields to include: Occurrence

Occurrence (core) table (mandatory fields)

• occurrenceID — unique, stable ID
• scientificName — taxon name to lowest possible taxon rank
• basisOfRecord = “MaterialSample”
  
• occurrenceStatus = “present”

If Occurrence core, also: eventDate, decimalLatitude, decimalLongitude

Occurrence table (strongly recommended fields)

• scientificNameID (WoRMS AphiaID)
  
• organismQuantity (read count of sequence)
  
• organismQuantityType = “DNA sequence reads”
• sampleSizeValue (total read count in sample)
  
• sampleSizeUnit = “DNA sequence reads”
• samplingProtocol - (link to your SOP)
• associatedSequences (link to e.g. GenBank or ENA accession)

Key fields to include: DNA Extension

DNA Extension (example key fields)

• DNA_sequence — ASV/OTU sequence
• target_gene — e.g. “COI”, “18S rRNA”
• pcr_primer_name_forward — and reverse
• seq_meth — e.g. “Illumina MiSeq”
• otu_class_appr — e.g. “DADA2 v1.18”
• otu_db — reference database
• sop — link to your protocol

manual.obis.org/dna_data.html#quick-start-guide

WoRMS = World Register of Marine Species. Every marine occurrence should have a WoRMS AphiaID as the taxonID. For freshwater / terrestrial taxa use the appropriate backbone (CoL, etc.). Unidentified sequences should still be included — they can be assigned taxon later.

From raw outputs → long format

DNA data is more complex than a lat/lon + species name

Your typical metabarcoding outputs:

File	Content
OTU/ASV table	Sequences × Samples (read counts)
Taxonomy table	Sequence [ID] → taxon assignment
Sample metadata	Location, date, method
FASTA file	Actual DNA sequences

The transformation:

One row = one unique sequence in one sample = one occurrence record

The most common stumbling block is this “wide to long” transformation. The OBIS manual has a clear diagram. The Metabarcoding Data Toolkit (MDT) can automate this for common pipeline outputs.

Example transformation

Table structure options

Option A — Occurrence Core

occurrence.csv 
  └── dna_derived.csv  (linked via occurrenceID)
  └── emof.csv         (linked via occurrenceID)

---

Option B — Event Core (recommended for eDNA)

event.csv
  └── occurrence.csv        (linked via eventID)
       └── dna_derived.csv  (linked via occurrenceID)
  └── emof.csv              (linked via eventID or occurrenceID)

Why Event Core? Sample-level metadata (location, date, method) is recorded once per sampling event rather than repeated in every row.

For a survey with 500 samples × 2000 ASVs = 1M rows, repeating location and date for every row is wasteful and error-prone. The Event Core avoids this. A new GBIF/OBIS data model is under development that will be even more flexible but is not yet implemented (as of 2025).

Dataset Structure: Three Linked Tables

Event Core

• eventID
• eventDate
• decimalLatitude
• decimalLongitude
• samplingProtocol

→ the 📍where, 🕒when & 🧪how of collection

Occurrence Extension

• occurrenceID
• eventID
• scientificName
• taxonID (WoRMS)
• basisOfRecord
• occurrenceStatus

→ what organism was detected 🐠🪸🪼

DNA Derived Data Ext.

• occurrenceID
• DNA_sequence
• target_gene
• pcr_primer_forward
• pcr_primer_reverse
• seq_meth

→ 🧬the molecular context

Tables linked by eventID and occurrenceID

Optional 4th table: eMoF for measurements and facts

Your published dataset consists of up to three linked tables. The Event core captures sampling events — where, when, and how. The Occurrence extension records each taxon detection. The DNA Derived Data extension carries all molecular metadata. The tables are joined by eventID and occurrenceID. This avoids repeating sampling metadata for every sequence.

eMoF extension table

• Table to record all types of measurements (abiotic, biotic, environmental, sampling…)
• Measurements recorded in long format
  • measurementType, measurementValue, measurementUnit
• Linking sampling info to eventIDs decreases duplication
• Use controlled vocabulary whenever possible!

eventID	occurrenceID	measurementType	measurementValue	measurementUnit
YEARsite1samp1		temperature	25	C

measurementTypeID	measurementUnitID
http://vocab.nerc.ac.uk/collection/P01/current/TEMPPR01/	http://vocab.nerc.ac.uk/collection/P06/current/UPAA/

As some of us may already be familiar, eMoF is the extension table that holds ALL kinds of measurement or fact data including measurements on organisms, information about the sampling gear used, or environmental variables measured. A reminder that this data is organized in LONG format. All the measurements are organized in rows within the columns measurementType, measurementValue, and measurementUnit

Controlled Vocabulary

Identifiers for each eMoF column

• measurementUnitID
• measurementValueID
  • non-numeric values
• measurementTypeID

→ Facilitates data understanding

→ Enables data aggregation

→ Decreases misuse potential

What should vocabulary terms capture?

OBIS recommends using NERC vocabulary terms

Emof lets you attach vocabulary identifiers to each of the emof columns. This makes our measurement data are more easily comparable and interoperable, more easily aggregated for analysis, and can decrease misuse potential!

When selecting a vocab it’s important to think about what information needs to be included in the definition for the users to understand your measurement so you should consider the property/attribute (e.g. length, concentration), what’s the object/entity of interest (a organism, a chemical), whether enviro context is important, and whether a user needs to know the methods used to properly understand the measurement OBIS recommends the NERC vocabular collection and the OBIS manual has much more detail on controlled vocabulary

DNA Derived Data Extension Summary

Managing DNA data with Darwin Core uses:

• Event core (sampling event info)
• Occurrence extension (taxon observation and identification)
• DNA derived data extension (DNA sequences, primers, methods)
• eMoF extension (other measurement or fact information)