Metadata Schema

A metadata schema is a defined, published set of fields (elements or properties) — each with a name, a definition, an expected data type or controlled vocabulary, and rules about whether it is required, repeatable, or how it relates to other fields — used to describe a resource consistently enough that people and machines can find, cite, exchange, and reuse it. A schema is the specification; a metadata record is one specific instance of data filled into that specification for one actual resource. Any given resource is typically described by more than one schema at once, layered for different purposes: a generic schema for baseline discoverability, plus a discipline-specific one for domain detail, plus sometimes a web-indexing schema aimed at search engines rather than repositories.

What a schema actually specifies

A real metadata schema is more than a list of column headers. At minimum it defines, for each element:

• Name and definition — an unambiguous label and description, so “creator” means the same thing in every record that uses the schema.
• Obligation — mandatory, recommended, or optional. DataCite’s schema, for example, has a small mandatory core (Identifier, Creator, Title, Publisher, PublicationYear, ResourceType) plus a much larger set of optional and recommended properties.
• Cardinality — whether the element can repeat (a dataset can have multiple creators; it typically has one publication year).
• Data type or controlled vocabulary — free text, a date in a specified format, or a value drawn from a fixed list (a resource-type vocabulary, a language code list, a rights/license identifier).
• Relationships — how elements can point to other resources or identifiers (a “relatedIdentifier” property linking a dataset to the paper that uses it, for instance).

This is what separates a genuine schema from an ad hoc set of spreadsheet column headers a single research group invents for its own use: a schema is published, versioned, and maintained by a body other than the person filling it in, which is precisely what lets an unrelated system consume the record correctly.

Generic schemas vs. domain-specific schemas

Metadata schemas split broadly into two families, and most real-world records combine both:

Generic, cross-domain schemas describe the baseline facts true of almost any resource — who made it, what it’s called, when, who published it, what rights apply. The Dublin Core Metadata Element Set (fifteen elements: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights; standardized as ISO 15836, ANSI/NISO Z39.85, and IETF RFC 5013) is the reference point most later schemas were built against or crosswalked to. The DataCite Metadata Schema plays the equivalent role specifically for citable research outputs: it is the schema a repository must populate to mint a DataCite DOI, and its mandatory-property set functions as a practical baseline — see core metadata for how that baseline is defined and enforced. schema.org/Dataset is a third generic option, aimed less at repository interoperability and more at making a dataset understandable to search engines and tools like Google Dataset Search.

Discipline-specific schemas add the fields a domain actually needs and a generic schema has no vocabulary for. The Data Documentation Initiative (DDI), maintained by the DDI Alliance, describes survey and observational data in the social, behavioral, economic, and health sciences — questionnaire structure, variable-level codebooks, sampling frames — in a level of detail Dublin Core has no fields for at all. Ecological Metadata Language (EML) plays the same role for ecological and environmental data, and Darwin Core for biodiversity occurrence records. None of these replace a generic schema; they typically sit alongside one, describing what the data actually contains rather than the discovery-level facts about it.

Why the distinction matters in practice

Choosing or combining schemas isn’t an abstract exercise — it determines whether a dataset can actually be found, cited, and machine-processed outside the system that created it. A repository that only generates its own proprietary field set produces records nothing else can reliably parse. A repository built around DataCite’s schema produces a record that any DataCite-aware tool, aggregator, or citation manager can consume without custom integration work. Crosswalks — documented field-to-field mappings between schemas — let systems translate a record from one schema into another, which is how a discipline repository’s DDI or EML record still ends up exposed as Dublin Core or DataCite metadata to a general-purpose harvester. For a worked, decision-oriented walkthrough of picking or combining schemas for a specific dataset, see How to Choose a Metadata Schema for a Dataset.

Related concepts

See also core metadata for the minimal field set a record needs regardless of schema, and data management plan (DMP), which typically specifies which metadata schema a project commits to using before data collection even begins.