Choosing a Metadata Schema for a Dataset

Most researchers never “choose” a metadata schema in any conscious sense — they deposit into a repository, and the repository generates a metadata record in whatever schema it was built around. That’s the right outcome most of the time. But a real choice does show up in a handful of common situations: picking between several eligible repositories partly on the strength of their metadata output, describing data for a domain repository that layers a discipline-specific schema on top of a generic one, exposing a dataset through an institutional CRIS that has to satisfy a harvesting protocol, or self-hosting a dataset somewhere that doesn’t generate rich metadata automatically at all.

This guide is a decision framework for those situations, not a field-by-field reference for any one schema. If you need the full property list for a specific schema, its own documentation (linked throughout) is the authority. What follows is how to decide which schema — or, more often, which combination of schemas — actually fits your repository, your discoverability goals, and your data.

The three questions that actually decide it

Before comparing schemas, answer these. In practice they eliminate most of the decision before you get to the comparison table below.

1. What does your repository already require?

If you’re depositing into a DOI-minting repository — the large majority of generalist and institutional repositories — the repository almost certainly generates a DataCite Metadata Schema record automatically at deposit. You aren’t choosing that schema; you’re choosing how completely you fill in its fields, which is a real and consequential choice covered in how to choose an open data repository. The live decision starts one level up: are you also required, invited, or able to layer a second, richer schema on top of that baseline — usually because the repository is a discipline-specific repository that expects it?

2. Where do you actually need the dataset to be discoverable?

These are different targets and no single schema serves all of them equally well:

General web search / Google Dataset Search — needs schema.org/Dataset JSON-LD on the landing page. Most repositories generate this automatically from the DataCite record; see making your dataset discoverable in Google Dataset Search for the mechanics.
Cross-institutional aggregators (OpenAIRE, BASE, CORE, national portals) — harvest via OAI-PMH, typically reading the same DataCite (or Dublin Core) record.
A subject-specific index (GBIF for biodiversity occurrence records, an ecological or environmental data repository, a social-science data archive) — these generally will not index a dataset usefully without the discipline schema they’re built around, no matter how complete the generic record is.
Your own institution’s CRIS/RIM system — usually consumes CERIF or a CERIF-compatible feed, not the dataset’s public-facing schema directly.

3. What kind of data are you describing?

A flat generalist dataset (a spreadsheet, a set of images, model output with no established community standard) is well served by DataCite plus schema.org and doesn’t need more. Structured survey or interview data, biodiversity observations, ecological data packages, and array/sequencing data all have mature, widely-adopted discipline schemas built specifically to capture what a generic schema can’t — variable-level codebooks, taxonomic occurrence fields, experimental design metadata. Using the generic schema alone for this kind of data is technically valid and genuinely under-describes it.

The schema families, and the problem each one actually solves

Dublin Core / DCMI Metadata Terms

The fifteen-element Dublin Core Metadata Element Set (Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights) is the oldest and most widely implemented general-purpose metadata vocabulary in existence, standardized as ISO 15836. Current guidance points to the fuller DCMI Metadata Terms, which extends the original fifteen with several dozen additional properties, refinements, and encoding schemes, all expressed as an RDF vocabulary usable in XML, JSON, or a relational schema.

What it’s actually good for: the lowest common denominator that almost every repository platform, library catalog, and institutional system can read and write. It’s what you fall back to when there’s no DOI-minting repository generating a richer record for you — a self-hosted departmental archive on a bare DSpace or Fedora instance, an institutional records system, or any context where cross-system interoperability with non-specialist tools matters more than dataset-specific richness. It deliberately does not have dataset-specific fields (no native concept of variables, geospatial extent, or funding — Coverage and Relation can be pressed into service, but only loosely).

DataCite Metadata Schema

Now at version 4.7 (released March 2026), the DataCite Metadata Schema is the de facto standard for citable research data because it’s the schema behind DOI registration at essentially every generalist and most discipline repositories — Zenodo, Dryad, figshare, most institutional repositories, and the majority of domain repositories that mint DOIs. It has six mandatory properties (Identifier, Creator, Title, Publisher, PublicationYear, ResourceType), six recommended (Subject, Contributor, Date, RelatedIdentifier, Description, GeoLocation), and eight further optional properties (including FundingReference and RelatedItem) for richer description.

What it’s actually good for: citation, persistent identification, and being the record most other discoverability channels (schema.org, OAI-PMH-based aggregators) are generated from rather than authored separately. If you deposit through a DOI-minting repository, this schema isn’t optional — the real decision is whether you fill in only the six mandatory fields or also the recommended ones (FundingReference and RelatedIdentifier in particular are what connect a dataset to its grant and its associated publication for anyone harvesting on those fields, including your own institution).

DDI (Data Documentation Initiative)

The DDI Alliance maintains a family of standards built specifically for social-science and survey microdata, where the unit that needs describing isn’t just the dataset as a whole but every individual variable in it. DDI-Codebook is the lighter-weight member, aimed at documenting a single, relatively simple survey dataset. DDI-Lifecycle extends it to cover an entire study across its full lifecycle — from questionnaire design through data collection, processing, and archival. DDI-CDI (Cross-Domain Integration) is a newer, more general product aimed at describing data and process across any domain, not only surveys. The whole DDI product family has been recognized as an international standard via ISO/PAS 25955:2026.

What it’s actually good for: variable-level documentation — question wording, response categories, coding, universe/skip logic — that no generic schema captures at all. If your dataset is survey or interview microdata destined for a social-science archive (ICPSR-style repositories, national data archives), DDI is almost never optional; a DataCite record alone tells a reuser the dataset exists but nothing about what any individual variable actually measures.

schema.org/Dataset

The schema.org Dataset type is what general web crawlers, including Google’s, actually read to index a dataset for discovery — it’s JSON-LD (or RDFa/Microdata) embedded directly in the HTML of a dataset’s landing page, not a deposit-time schema at all. As covered in detail in making your dataset discoverable in Google Dataset Search, the large majority of researchers never write this markup by hand; the repository generates it from the underlying DataCite (or Dublin Core, or DCAT) record.

What it’s actually good for: web discoverability specifically, and only that. It’s not a deposit format, has no versioning or provenance model of its own, and shouldn’t be thought of as competing with DataCite or a discipline schema — it’s the crosswalk output, not a source of truth. The one place it becomes a live decision rather than an automatic byproduct is self-hosted data on a page with no repository behind it at all, where someone has to add the markup manually for the dataset to be indexable.

Discipline-specific schemas

A number of research communities have built metadata standards around exactly what a generic schema can’t express for their kind of data. A few well-established examples: Darwin Core for biodiversity occurrence and taxonomic data (the standard GBIF is built around); the Ecological Metadata Language (EML) for ecological and environmental data packages; the CF (Climate and Forecast) Conventions for gridded climate/earth-system model output, typically embedded directly in NetCDF files rather than as a separate record; and the ISA (Investigation/Study/Assay) framework for structured life-science experimental metadata, covering experimental design and sample-to-data relationships that neither DataCite nor Dublin Core attempt to capture. Each of these typically sits alongside, not instead of, a DataCite record when the repository also mints DOIs.

What they’re actually good for: the fields a specialist reuser in that field actually needs to evaluate and reuse the data correctly, and — often more practically — acceptance by the subject repository that community has standardized on. If a domain repository requires one of these, it isn’t a competing option to weigh against Dublin Core; it’s a prerequisite for deposit. The RDA Metadata Standards Directory and FAIRsharing are the two most useful places to check whether your field already has one before assuming it doesn’t.

A practical decision table

Your situation	Prioritize	Why
Generic dataset (spreadsheet, images, model output with no community standard), depositing into a DOI-minting generalist repository	DataCite (complete the recommended fields, not just mandatory) + auto-generated schema.org	The repository handles both automatically; the only real decision is field completeness
Survey, interview, or other structured microdata, headed to a social-science archive	DDI-Codebook or DDI-Lifecycle, alongside the repository’s DataCite record	Only DDI documents individual variables, coding, and skip logic
Biodiversity occurrence or taxonomic data, headed to GBIF or a similar aggregator	Darwin Core, alongside DataCite if the repository mints DOIs	Darwin Core is what the aggregator actually indexes on
Ecological or environmental data package with sampling design/protocol detail	EML	Captures methodology and sampling structure a generic schema omits entirely
Gridded climate, atmospheric, or oceanographic model output	CF Conventions embedded in the NetCDF file itself	The convention is how the analysis tooling in that field reads the file, not just an external record
Structured life-science experiment (multi-assay, multi-sample design)	ISA-Tab or ISA-JSON, alongside DataCite	Only ISA models the investigation/study/assay relationships
Self-hosted dataset with no repository generating any record for you	Dublin Core / DCMI Terms as the baseline, plus manually-added schema.org/Dataset markup on the landing page if web discoverability matters	Nothing else will be generated automatically; Dublin Core is the most universally-supported fallback
Feeding your institution’s CRIS/RIM system for reporting	Whatever the repository’s DataCite output crosswalks to CERIF, typically via OAI-PMH harvesting	The CRIS layer is a downstream consumer of the deposit metadata, not a separate authoring step in most setups

Schemas layer — this is rarely an exclusive choice

The table above should make one thing clear: in most real deposits, the question isn’t “which one schema,” it’s “which schema is the record authored in, and which others is it crosswalked or exposed to.” DataCite offers a documented, machine-executable crosswalk from its own schema to schema.org/Dataset — both content negotiation (requesting a DOI’s metadata as schema.org JSON-LD directly) and a published field-by-field mapping — specifically so repositories don’t need a human to re-author the same facts twice. Real repositories confirm this works in practice: Dryad has published its own account of generating schema.org markup from DataCite metadata for Google Dataset Search inclusion, and figshare’s documentation states an item becomes discoverable there once it’s typed as a dataset, public, and carries the generated JSON-LD — neither requires the depositing researcher to write markup by hand.

The same layering logic applies to discipline schemas: a biodiversity dataset deposited through a DOI-minting repository commonly carries both a DataCite record (for citation and general discovery) and a Darwin Core-formatted occurrence dataset (for GBIF indexing) — one doesn’t replace the other, and neither is complete on its own for that dataset’s full set of discoverability goals.

A worked example

Consider a research team depositing an environmental sensor dataset — hourly water-quality readings from a set of monitoring stations over several years, generated during a grant-funded project, with an eventual journal article citing it. Applying the three questions:

Repository requirement: they choose a generalist DOI-minting repository, so a DataCite record is generated automatically at deposit — they make sure to complete FundingReference (linking the grant) and RelatedIdentifier (linking the eventual article), not just the six mandatory fields.
Discoverability goals: they want the dataset indexed in Google Dataset Search (handled automatically via the repository’s schema.org output) and picked up by their funder’s OAI-PMH-harvesting aggregator (also automatic, from the same DataCite record) — no extra work needed for either.
Data type: because it’s time-series sensor data without an established discipline schema as demanding as EML or Darwin Core, they judge the DataCite record — completed thoroughly — sufficient on its own, and skip adding a discipline-specific layer.

This scenario is illustrative, not a documented case study of any specific institution or project — it’s meant to show the framework applied, not to report a real outcome.

Common mistakes

Treating “which schema” as a single, exclusive choice. Almost every real deposit uses more than one, whether or not anyone chose that consciously.
Filling in only the mandatory DataCite fields. A record with no FundingReference or RelatedIdentifier is valid but effectively invisible to anything — including your own institution’s reporting — that harvests on those fields.
Assuming a discipline schema is optional when the target repository or aggregator actually requires it. Check the destination repository’s submission guidelines before assuming a generic record will be accepted or indexed.
Hand-authoring schema.org/Dataset markup when a repository already generates it. Verify what the repository outputs (view the landing page’s JSON-LD, or run it through Google’s Rich Results Test) before duplicating work.
Picking a schema before checking whether the field already has a de facto standard. The RDA Metadata Standards Directory and FAIRsharing exist precisely so this isn’t a guess.

Frequently asked questions

Do I need to choose only one metadata schema for my dataset?

No. Most datasets end up described by more than one — a base schema from the repository (usually DataCite or Dublin Core), often a discipline schema layered on top if the field has one, and a web-discoverability schema (schema.org/Dataset) that’s typically generated automatically from the base record rather than authored separately.

What’s the actual difference between Dublin Core and the DataCite Metadata Schema?

Dublin Core is a general-purpose, fifteen-element vocabulary usable for almost any kind of resource, not just research data, and predates DOI registration. The DataCite Metadata Schema is dataset- and citation-specific, built around DOI registration, with dedicated fields (FundingReference, RelatedIdentifier, GeoLocation) that Dublin Core has no direct equivalent for. In practice, DataCite is the schema behind DOI-minting repositories; Dublin Core is the fallback for contexts without one.

Which metadata schema does my repository actually use?

Check the repository’s own documentation, or look for its DOI registration agency — if it mints DOIs via DataCite (true of most generalist and many discipline repositories), it’s generating a DataCite record. Repositories built on bare institutional-repository software (older DSpace/Fedora instances without a DOI integration) more commonly default to Dublin Core.

Is schema.org/Dataset the same thing as the DataCite Metadata Schema?

No. schema.org/Dataset is markup embedded in a dataset’s landing page HTML for web crawlers to read; DataCite is the deposit-time record tied to DOI registration. They frequently describe the same dataset, and the schema.org version is usually generated automatically from the DataCite record rather than authored independently — see making your dataset discoverable in Google Dataset Search for how that mechanism actually works.

What metadata schema should I use for survey or interview data?

DDI-Codebook or DDI-Lifecycle, in addition to whatever your repository generates automatically. Neither DataCite nor Dublin Core has fields for documenting individual survey variables, response coding, or skip logic — DDI exists specifically to fill that gap, and social-science data archives generally expect it.

How do I find out if my discipline already has a standard metadata schema?

Check the RDA Metadata Standards Directory and FAIRsharing before assuming none exists — both catalog community-adopted standards by subject area, and a domain repository’s own submission guidelines will usually state directly what it requires.

How to Choose a Metadata Schema for a Dataset