Core metadata

Core metadata is the minimal, standard set of descriptive fields a research output — most often a dataset — needs before it can reliably be found, identified, and cited. It is the baseline every repository or catalog record must carry regardless of discipline, distinct from the richer, discipline-specific metadata that describes what the data actually contains (species names, sequencing platform, survey instrument, geospatial projection, and so on). A record can be missing every discipline-specific field and still be discoverable and citable if its core metadata is complete; a record with rich discipline-specific detail but no core metadata generally cannot be found or cited at all.

The classic reference point: Dublin Core

The most widely cited framing of “core” metadata is the Dublin Core Metadata Element Set — fifteen elements (Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights) standardized in ISO 15836:2009, ANSI/NISO Z39.85-2012, and IETF RFC 5013. The Dublin Core Metadata Initiative describes these explicitly as “core” — not because they are the only fields worth recording, but because they are “broad and generic, usable for describing a wide range of resources,” in contrast to a domain schema built for one type of resource. This is the origin of “core metadata” as a term of art in resource-description practice, and it is the reference point most later research-data schemas were built against or crosswalked to.

The applied version for research data: DataCite’s mandatory properties

For datasets specifically, the practical, enforced instantiation of core metadata is the DataCite Metadata Schema‘s mandatory property set: Identifier, Creator, Title, Publisher, PublicationYear, and ResourceType. A repository cannot mint a DataCite DOI without supplying these six — they are the fields a dataset genuinely cannot be cited without. DataCite’s own citation format (Creator (PublicationYear): Title. Publisher. ResourceType. Identifier) is built directly from them. DataCite additionally defines a “recommended” tier (Subject, Contributor, Date, RelatedIdentifier, Description, GeoLocation, and others) that improves discoverability and interoperability but is not required to register a record — a useful working line between “core” and “extended” metadata for a dataset specifically.

Why the distinction matters

The FAIR Guiding Principles make the same split load-bearing: F1 requires that “(meta)data are assigned a globally unique and persistent identifier,” and F2 requires that “data are described with rich metadata,” which R1 elaborates as “a plurality of accurate and relevant attributes.” Core metadata is what satisfies F1/F2 at the point of deposit — persistent identifier, creator, title, date, subject/keywords, format, rights — before any discipline-specific enrichment happens. It is also what most cross-repository infrastructure actually reads: OAI-PMH harvesting, aggregators (OpenAIRE, BASE, Google Dataset Search), and cross-repository citation linking all key off the core fields, because that’s the only layer guaranteed to exist across every repository regardless of discipline. Discipline-specific schemas — Darwin Core for biodiversity occurrence records, Ecological Metadata Language (EML) for ecological datasets, DDI for social-science survey data — sit on top of this core layer; they extend it, they don’t replace it.

Worked examples

• A dataset deposited in a generalist repository carries Title (“Soil moisture readings, Site 4, 2024–2025”), Creator(s) with ORCID iDs, an Identifier (a minted DOI), a PublicationYear, a ResourceType of “Dataset,” a Publisher (the repository), Subject/keyword terms, a Format (CSV), and a Rights statement (CC-BY-4.0). That is core metadata satisfied — the record is findable and citable — even before any soil-science-specific fields (instrument model, sampling depth, calibration method) are added.
• A national research-data aggregator harvesting thousands of repositories via OAI-PMH can build a working cross-repository search index from core metadata alone, because it is the one layer every source repository is guaranteed to expose in a common shape — it cannot assume any given discipline-specific or project-level field is present.

Counter-example

A dataset landing page that shows only a filename and an upload timestamp — no named creator, no persistent identifier, no title beyond the filename, and no rights or reuse terms — does not meet core metadata, regardless of how well-documented the data itself is in an accompanying README. It can be downloaded by someone who already has the link, but it cannot be reliably found by search or harvesting, cannot be formally cited, and cannot be trusted for reuse terms. This is the gap CASRAI’s Dictionary and standards like Dublin Core and the DataCite schema exist to close: making the minimum findable/citable field set explicit and consistent, rather than left to each repository’s own convention.

Related CASRAI content

For the decision framework on layering a richer, discipline-specific schema on top of this core layer, see How to Choose a Metadata Schema for a Dataset. For the fields specific to describing a research project rather than a dataset, see Project metadata and PID metadata. This term sits within CASRAI’s Research Data Management (RDM) cluster.

References

• Dublin Core Metadata Initiative, “Dublin Core Metadata Element Set, Version 1.1” (dublincore.org/specifications/dublin-core/dces/); ISO 15836:2009; ANSI/NISO Z39.85-2012.
• DataCite Metadata Working Group, “DataCite Metadata Schema Documentation,” current version (datacite-metadata-schema.readthedocs.io) — Mandatory Properties section.
• Wilkinson, M.D. et al., “The FAIR Guiding Principles for scientific data management and stewardship,” Scientific Data (2016); go-fair.org/fair-principles.