Short answer
A metadata schema is the set of fields, data types and controlled vocabularies that describe every asset in a DAM. The schema decides how assets are found, filtered, governed and passed to other systems. A metadata schema must exist before migration starts, because every search filter, rights rule and integration mapping reads from its fields.
How a metadata schema works in a DAM
A metadata schema works as the contract between the people who add assets and the people and systems that use them. Each field in the schema carries four properties.
| Property | What it defines | Example |
|---|---|---|
| Field name | The label users see and the API key systems read | Rights expiry |
| Data type | Text, number, date, list, link to another record | Date |
| Vocabulary | The allowed values for list fields | Web, App, Print, Marketplace, Social |
| Rule | Required, optional, inherited or calculated | Required before approval |
Schemas usually differ per asset type, because product images, lifestyle photos, video and documents need different fields. Embedded standards such as XMP and IPTC carry part of the metadata inside the file. The DAM maps those embedded fields to its own schema on ingest and back again on download.
Example of a metadata schema
Worked example: an image schema for a consumer goods brand holds brand, product SKU, channel, rights expiry and alt text. Brand and channel use controlled vocabularies, SKU links to the PIM record, rights expiry is a date, and alt text is required free text.
That schema answers three daily needs. Users filter by brand and channel, the DAM blocks downloads after the rights expiry date, and the webshop receives alt text with each image.
Metadata schema in a DAM selection
A metadata schema belongs in Checkpoint 2: Define, before any vendor demo. DAMSelection assessment: the metadata model decides DAM success, so design it before the first demo and send it to every shortlisted vendor.
Vendors then configure your schema at Checkpoint 5: Test, and you see the real effort. Ask each vendor to show these points:
- Configure 10 of your fields, including one controlled list and one date field.
- Make one field required for one asset type and show an upload being blocked without it.
- Map one field to XMP on download and one to the PIM through the API.
- Rename a list value and show what happens to assets already tagged with it.
The metadata model builder produces a first schema to hand to vendors. The metadata schema guide covers field design in depth.
Common metadata schema mistakes
The most frequent metadata schema mistake is copying the old folder structure into fields. Four other errors recur in PIMvendors practice:
- Too many free-text fields, which fill with synonyms and typos.
- No named owner per field, so values drift after go-live.
- One schema for all asset types, which forces irrelevant required fields on users.
- Rights fields added after migration, which leaves migrated assets without expiry dates.
Related terms: Controlled vocabulary, Taxonomy, XMP.
Frequently asked
How many fields should a DAM metadata schema have?
A DAM metadata schema should hold only the fields that a named use case needs, grouped per asset type. DAMSelection rule of thumb: start with the fields that drive search filters, rights rules and channel delivery. Add a field only when a user group asks for it and someone agrees to own it.
What is the difference between a metadata schema and a taxonomy?
A metadata schema defines every field that describes an asset, including dates, text, links and lists. A taxonomy is a hierarchical classification that supplies values to one or more of those list fields. The schema is the full structure, and the taxonomy is one input to it.