Metadata is usually sorted into a small number of functional types, not by subject matter but by what job it does: helping someone find and identify a resource, describing how a complex resource is put together, or recording the facts needed to manage, use, and preserve it over time. The most widely cited version of this taxonomy comes from NISO’s Understanding Metadata: What is Metadata, and What is it For? primer (2017, authored by Jenn Riley), which distinguishes three core types — descriptive, structural, and administrative — with preservation metadata and rights metadata treated as specialized subtypes of administrative metadata. Because preservation metadata has its own mature standard (PREMIS) and its own dedicated workflows in research data management, many practical guides — this one included — break it out as a fourth type in its own right rather than leaving it nested. Either framing is defensible; what matters is recognizing the same four functional jobs underneath, however they’re grouped.
This guide explains each type, how they relate to metadata schemas (the specifications that define which fields exist) versus metadata records (the filled-in data), and where each type shows up in a real research data workflow.
Descriptive metadata
Descriptive metadata is what supports discovery and identification — it answers “what is this, who made it, and how do I find it again.” It’s the type most people picture when they hear “metadata”: title, creator/author, subject keywords, abstract or description, publication date, and identifiers.
In research data management, descriptive metadata is what a repository search interface or a catalog like DataCite Search actually indexes. The DataCite Metadata Schema‘s small mandatory core — Identifier, Creator, Title, Publisher, PublicationYear, ResourceType — is a working example of a minimum descriptive record: enough to cite and locate a dataset, even before anything else about it is known. See core metadata for how that minimum baseline is typically defined and enforced across schemas, and Dublin Core for the generic, cross-domain descriptive element set (Title, Creator, Subject, Description, Publisher, Date, and eleven others) that many repository systems build their descriptive fields against.
Example: a dataset record’s title, author list, keywords, and abstract in a repository landing page are all descriptive metadata — none of them says anything about the file’s internal structure or how it should be preserved.
Structural metadata
Structural metadata describes how the parts of a resource relate to one another — the internal organization, sequence, or hierarchy that lets a system (or a person) navigate a complex object correctly. It answers “how do the pieces fit together,” not “what is this” or “who made it.”
A single dataset file rarely needs structural metadata of its own, but multi-part or multi-file research objects do. A digitized multi-volume archival collection needs structural metadata recording which page images belong to which volume and in what order; a compound dataset made up of raw files, a codebook, and derived tables needs structural metadata recording how those parts relate. METS (Metadata Encoding and Transmission Standard) is a schema built specifically to carry this kind of structural information, typically packaged alongside descriptive metadata (often encoded in MODS) and administrative metadata for the same object.
Example: a table of contents recording that “Chapter 3” consists of page images 45 through 62, in that order, is structural metadata. Counter-example: the same chapter’s title and author are descriptive metadata, not structural — the distinction is sequence/composition versus identification.
Administrative metadata
Administrative metadata supports the management of a resource: information a repository, archive, or institution needs to run its own processes, rather than information a searcher needs to find or cite the resource. It typically includes:
- Technical metadata — file format, file size, software/hardware dependencies, encoding, checksums generated at ingest.
- Rights metadata — copyright status, license terms, access restrictions, embargo dates.
- Provenance metadata — who created, modified, or processed the object and when, and what process produced it. See CASRAI’s guide to data provenance for how this is documented in practice, and PROV-O for the W3C ontology commonly used to express it formally.
- Preservation metadata — covered separately below, given how substantial and standardized this subtype has become.
Administrative metadata is usually not shown to an end user browsing a catalog; it’s consumed by the systems and staff responsible for keeping the object accessible, secure, and correctly licensed. Project metadata and PID metadata are both examples that lean administrative — recording funding source, grant number, or the registration details behind a persistent identifier, rather than describing the resource’s subject matter.
Example: a checksum value and the software version required to open a file are administrative (technical) metadata. Counter-example: the file’s title and keywords are descriptive, even though both live in the same metadata record.
Preservation metadata
Preservation metadata is the information a repository needs to keep a digital object usable and verifiably intact over the long term — well past the point where the people or systems that originally created it are still available to answer questions about it. The reference standard is PREMIS (Preservation Metadata: Implementation Strategies), a data dictionary developed and maintained under the Library of Congress that specifies a standard structure for recording exactly this kind of information: fixity events (the algorithm, timestamp, and checksum value used to verify a file hasn’t been altered or corrupted), provenance of preservation actions (format migrations, integrity checks), rights relevant to preservation actions, and the technical environment needed to render the object.
In research data management, preservation metadata is what a certified repository is actually being audited on. CoreTrustSeal’s certification requirements, for example, include fixity and data-integrity practices scored across progressive maturity levels — from a checksum generated once at ingest, up to periodic, proactive re-verification. See CASRAI’s guide to checksum verification and fixity checking for how this is implemented operationally, and PREMIS’s own documentation (Library of Congress, loc.gov/premis) for the full data dictionary.
Example: a record showing that a dataset’s SHA-256 checksum was verified against its original value on a recurring schedule, with the verification dates logged, is preservation metadata.
Discipline-specific schemas layer on top of, not instead of, these types
The four functional types above describe what job a metadata field does; a metadata schema is the concrete specification that defines which fields exist for a given domain, and any real schema mixes types. Darwin Core (biodiversity occurrence records) and Ecological Metadata Language (EML) both carry descriptive fields (what species, where, when) alongside administrative and provenance fields (who collected it, under what protocol). See CASRAI’s guide on how to choose a metadata schema for a dataset and the metadata schema term for how generic and discipline-specific schemas are typically combined in practice.
Frequently asked questions
Are there really only four types of metadata?
No single count is universally fixed. NISO’s own primer names three core types (descriptive, structural, administrative) and treats preservation and rights metadata as administrative subtypes; many practitioner guides, archives, and digital-preservation programs list preservation as a fourth type in its own right because it has its own dominant standard (PREMIS) and its own dedicated workflows. Both framings describe the same underlying functions — the count differs by how finely administrative metadata gets subdivided, not by disagreement about what the metadata actually does.
Can one metadata field belong to more than one type?
Not usually within a single, well-designed schema — a given field is defined for one purpose (find/identify, structure, manage, or preserve). But a complete metadata record for one resource typically combines fields from all four types at once, often drawn from more than one schema layered together (for example, Dublin Core for descriptive elements plus PREMIS for preservation events on the same object).
Where does rights/licensing metadata fit?
Rights metadata (license terms, access restrictions, embargo dates) is conventionally treated as a subtype of administrative metadata, since it governs how the resource may be managed and used rather than how it is found or structured.
Do I need all four types for a research dataset?
At minimum, funders and repositories require descriptive metadata (to make the dataset findable and citable) and enough administrative/technical metadata (format, checksum) to manage it responsibly. Structural metadata only becomes necessary once a dataset is a multi-part or multi-file object with an internal organization worth recording. Preservation metadata becomes load-bearing once long-term retention, not just initial deposit, is the goal — which is precisely why repository certification frameworks like CoreTrustSeal evaluate it directly.
