Descriptive metadata is the set of dataset-level information that answers a single question: what is this, and who made it? It covers fields such as title, creator, date, subject keywords, and description/abstract — the information a repository search interface, a catalog like DataCite Search, or a human browsing a landing page actually reads to decide whether a dataset is relevant. It is one of several functional types of metadata used in research data management, and it is deliberately narrower than the other types: it does not describe how a dataset’s internal files or variables are organized (that is structural metadata), and it does not record rights, funding, or provenance (that is administrative metadata). See Types of Metadata: Descriptive, Structural, Administrative, and Preservation for the full four-way breakdown; this guide goes deep specifically on the descriptive layer — what belongs in it, which standards define it, and how to write it well for a dataset.
What makes a field ‘descriptive’ metadata
A metadata field is descriptive when its job is discovery and identification rather than structure, rights, or preservation. Concretely, descriptive metadata for a dataset answers: what is it called, who created it, when, what is it about, and how would someone describe it in a sentence. Every major dataset metadata standard is built around some version of this same short list, even though the exact field names differ:
- Title — a human-readable name for the dataset, specific enough to distinguish it from other outputs of the same project (Dublin Core:
Title; DataCite:Title, mandatory). - Creator — the person(s) or organization(s) responsible for producing the dataset, ideally identified with a persistent identifier rather than a bare name string (Dublin Core:
Creator; DataCite:Creator, mandatory). - Date — when the dataset was created, collected, or made available; DataCite requires
PublicationYearspecifically, while Dublin Core’s more generalDateelement can represent creation, collection, or coverage dates depending on the schema built on top of it. - Subject / Keywords — terms describing what the dataset is about, ideally drawn from a controlled vocabulary or subject-classification scheme so that the same concept is tagged consistently across datasets, rather than free text alone (Dublin Core:
Subject; DataCite:Subject, recommended). - Description / Abstract — a prose summary of the dataset’s content, scope, and collection context, long enough that a reader can judge relevance without opening the data files (Dublin Core:
Description; DataCite:Description, recommended).
Beyond these five, both schemas define further descriptive fields — Publisher, Contributor, Language, ResourceType, RelatedIdentifier, GeoLocation — that round out a complete descriptive record without changing the basic function: helping something be found, identified, and correctly attributed.
The two standards that define these fields
Two standards do almost all of the practical work of defining descriptive metadata for datasets, and researchers depositing data will encounter both, usually without realizing it, because repository submission forms are built directly on top of them.
Dublin Core (the generic baseline)
The Dublin Core Metadata Element Set defines fifteen elements — Contributor, Coverage, Creator, Date, Description, Format, Identifier, Language, Publisher, Relation, Rights, Source, Subject, Title, Type — standardized as ISO 15836, ANSI/NISO Z39.85, and IETF RFC 5013. It is domain-agnostic by design: the Dublin Core Metadata Initiative describes the set as intentionally broad and generic so it can describe almost any kind of resource, not datasets specifically. Most descriptive metadata fields in domain-specific schemas trace back to one of these fifteen elements, even when the field is renamed or narrowed for a particular repository type.
DataCite Metadata Schema (the dataset-DOI baseline)
The DataCite Metadata Schema is narrower and dataset-specific: it is the schema behind every DataCite-minted dataset DOI, and it splits descriptive fields into a mandatory tier and a recommended tier. The four mandatory properties beyond Identifier and ResourceType are Creator, Title, Publisher, and PublicationYear — a repository cannot mint a DataCite DOI without supplying all of them, which makes this six-property set the practical floor for descriptive metadata on any dataset that will be formally cited. The recommended tier — Subject, Contributor, Date, RelatedIdentifier, Description, GeoLocation — is what turns a bare, citable record into a genuinely discoverable one. DataCite’s own citation format is built directly from the mandatory set: Creator (PublicationYear): Title. Publisher. ResourceType. Identifier. — a direct, visible demonstration that descriptive metadata is what makes a dataset citable at all, not an optional add-on to citation.
See core metadata for more on how a minimum required field set like this one is typically defined and enforced across different schemas, and Dublin Core Metadata Record: A Fully Worked Example for a complete, field-by-field worked record.
Why descriptive metadata is what drives discoverability
Descriptive metadata is not a formality attached to a dataset after the real work is done — it is the layer that determines whether the dataset can ever be found by anyone who doesn’t already know it exists. The FAIR Guiding Principles make this explicit in their second principle: F2, “Data are described with rich metadata (defined by R1 below),” with R1 elaborating that “(Meta)data are richly described with a plurality of accurate and relevant attributes.” A dataset can satisfy F1 (a persistent identifier) and still be functionally unfindable if its descriptive metadata is thin — a vague title, no keywords, no abstract — because repository search, DataCite Search, and general-purpose aggregators like OpenAIRE or Google Dataset Search all index on descriptive fields, not on the data files themselves.
In practice this means the fields covered in this guide do double duty: they are what a search engine indexes, what a landing page displays to a human deciding whether to download, and what a citation is built from. Weak descriptive metadata degrades all three at once, and unlike a missing checksum or an outdated file format (preservation concerns), it cannot usually be reconstructed after the fact without going back to the original researcher — which is often no longer possible by the time someone else wants to reuse the dataset.
Descriptive vs. structural, administrative, and preservation metadata
These four terms get confused constantly because all four attach to the same dataset, and a real deposit record contains all of them at once. The distinguishing question for each:
- Descriptive — what is this, and who made it? (title, creator, date, subject, description)
- Structural — how are its parts organized? (file relationships, table/column structure, version sequence within a multi-file dataset)
- Administrative — how was it created and managed, and what governs its use? (rights, licensing, funding source, access conditions, provenance)
- Preservation — what is needed to keep it usable long-term? (fixity checksums, format migration history)
Full definitions and examples of the other three types are in Types of Metadata: Descriptive, Structural, Administrative, and Preservation. One distinction worth calling out specifically because it is easy to conflate: descriptive metadata operates at the level of the whole dataset (its title, its creator), while a data dictionary operates at the level of individual variables within it (what column bp_sys_v1 means, what unit it’s in). A dataset needs both, and they are not interchangeable — a perfect title and abstract tell a reader nothing about what a specific column contains, and a complete variable-level data dictionary tells a search engine nothing about what the dataset as a whole is or who made it.
Writing descriptive metadata well: practical guidance
- Titles — make the title specific enough to distinguish this dataset from other outputs of the same project or grant. “Survey data, 2024” is technically a title but is not discoverable; “Household Food Security Survey, Rural Kenya, 2024 (Wave 2)” is.
- Creator — supply an ORCID iD alongside the name string wherever the repository allows it. A bare name string (‘J. Smith’) is ambiguous in a way a persistent identifier is not, and most modern repository and DOI-minting workflows are built to capture it.
- Date — use an unambiguous format (ISO 8601, YYYY-MM-DD) and be precise about which date is being recorded: collection date, creation date, and publication/deposit date are frequently different and each carries different meaning to a reuser.
- Keywords/Subject — combine free-text keywords with terms from a recognized controlled vocabulary or subject classification where the repository or discipline has one. Controlled terms are what let aggregators group your dataset with topically related ones; free text alone depends entirely on the searcher guessing your exact wording.
- Description/Abstract — write it so a reader can judge relevance without downloading the data: what was collected, from whom or what, over what period, and any major limitations or exclusions. A one-line restatement of the title is not a description.
Common mistakes
- Leaving descriptive metadata fields at their auto-populated defaults (e.g., a repository’s placeholder title) instead of writing dataset-specific values.
- Treating descriptive metadata as something to fill in at the last minute before deposit, rather than capturing title, creator identity, and subject terms as part of the research workflow, when they are easiest to get right.
- Confusing descriptive metadata with a data dictionary or with administrative fields like licensing and funding — all matter, but they are different documentation layers with different jobs, and a strong one does not substitute for a missing other.
- Supplying only the DataCite mandatory minimum (Identifier, Creator, Title, Publisher, PublicationYear, ResourceType) when the recommended tier — especially Subject and Description — is what actually drives discoverability rather than mere citability.
Frequently asked questions
What is the difference between descriptive metadata and a metadata schema?
A metadata schema is the specification — the list of field names, data types, and rules (e.g., Dublin Core or the DataCite Metadata Schema). Descriptive metadata is a functional category of fields within a schema. Most schemas define descriptive, structural, administrative, and rights fields together; descriptive metadata is only the subset of those fields concerned with discovery and identification. See How to Choose a Metadata Schema for a Dataset for guidance on picking a schema.
Is a dataset’s abstract part of descriptive metadata?
Yes. In both Dublin Core (as Description) and the DataCite Metadata Schema (as Description, recommended), the abstract/summary field is core descriptive metadata — it is one of the fields most directly responsible for a human reader or search engine correctly judging what the dataset contains.
Do I need to fill in every descriptive field, or just the mandatory ones?
The mandatory minimum (for a DataCite DOI: Identifier, Creator, Title, Publisher, PublicationYear, ResourceType) is enough to mint a citable identifier, but it is not enough to make a dataset genuinely discoverable. Subject/keywords and a real description are what most search and indexing relies on; skipping them produces a dataset that is technically citable but effectively invisible in a search interface.
Where does descriptive metadata live in a dataset’s repository record?
Typically in the structured deposit form fields a repository presents at submission — title, author/creator, keywords, abstract — rather than inside the data files themselves, though some file formats also carry embedded descriptive metadata (e.g., document or image file headers). Repository-level descriptive metadata is what gets indexed by search engines and DOI registration agencies regardless of what, if anything, is embedded in the files.
