Reference Glossary
Metadata schema
A defined set of metadata fields — their names, data types, and allowed values — that a standard or DAM system requires an asset's record to conform to, such as Dublin Core's 15 elements or IPTC's photo field set.
Why it matters in a DAM
A schema is the contract that makes metadata exchange between systems possible — a DAM's configured schema determines what's mandatory before an asset can be published, and what a connected PIM, CMS, or syndication feed can reliably expect to receive through an API or export. Two DAMs with incompatible schemas can hold functionally identical metadata and still fail to exchange it cleanly, because one expects a field the other doesn't have or names it differently.
A worked example
Common mistake
Teams import a standard schema like Dublin Core into the DAM's field configuration but leave every field optional, so ingestion pipelines happily create records with empty title or rights fields — the schema exists on paper but enforces nothing, and downstream syndication feeds that expect non-null values break when they hit the gaps.
Dublin Core is the most widely referenced general-purpose metadata schema, originating from an invitational 1995 workshop in Dublin, Ohio, aimed at improving discovery of electronic resources. Its 15 core elements — Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, and Rights — were standardized as IETF RFC 2413, then as ANSI/NISO Z39.85, and later as the international standard ISO 15836. Because it’s deliberately generic, Dublin Core is often used as a baseline or mapping target rather than a complete schema on its own.
Domain-specific schemas layer on top of or alongside that baseline: IPTC’s Photo Metadata Standard for editorial and stock photography, PBCore for broadcast and public media, VRA Core for visual art and architecture images, and any number of proprietary schemas a DAM vendor or enterprise defines for its own workflow. A DAM’s actual field configuration is usually a custom blend — a handful of Dublin Core-equivalent fields for basic interoperability, an industry schema like IPTC for domain-specific needs, and organization-specific custom fields for internal workflow (approval status, project code, internal usage restrictions) that no public standard covers.
It’s worth distinguishing schema from controlled vocabulary: a schema defines the structure — which fields exist and what type of data they hold — while a controlled vocabulary constrains the actual values allowed inside one of those fields. A schema can require a “Rights Status” field without saying anything about which specific values (“Cleared,” “Pending,” “Expired”) are valid within it.
Frequently asked
What is a metadata schema in a DAM context?
A defined set of metadata fields — their names, data types, and allowed values — that a standard or DAM system requires an asset's record to conform to, such as Dublin Core's 15 elements or IPTC's photo field set.
Why does a schema matter for exchanging data between systems?
It's the contract that makes metadata exchange possible — a DAM's configured schema determines what's mandatory before an asset can be published and what a connected PIM, CMS, or syndication feed can reliably expect through an API or export.
Can two DAMs with the same metadata still fail to exchange it?
Yes — two DAMs with incompatible schemas can hold functionally identical metadata and still fail to exchange it cleanly, because one expects a field the other doesn't have, or names it differently.
What happens when a schema exists but isn't actually enforced?
Teams sometimes import a standard schema like Dublin Core but leave every field optional, so ingestion pipelines happily create records with empty title or rights fields. The schema exists on paper but enforces nothing, and downstream syndication feeds that expect non-null values break when they hit the gaps.
What role do mandatory fields play in a metadata schema?
They determine what must be filled in before an asset can be published or exported, which is what lets connected systems trust that certain fields will always be present rather than checking for gaps every time.
Does adopting a standard schema like Dublin Core guarantee clean data?
No — adopting the field list alone doesn't enforce anything. Without marking fields mandatory and validating what's entered, a DAM can technically use Dublin Core while still producing records with empty required fields.
Sources
- Dublin Core originated from a 1995 workshop in Dublin, Ohio, and its 15-element set was standardized as ISO 15836 checked 2026-08-07 — Wikipedia / DCMI, Dublin Core Metadata Element Set