Taxonomy, controlled vocabularies & thesauri for DAM: a practical guide

Why it matters

A DAM is only as findable as its metadata is consistent. Natural language works against consistency in two ways. Several words can name the same concept ("logo", "logotype", "brand mark"), and one word can name several concepts ("Mercury" the planet, the metal, the car). ANSI/NISO Z39.19 describes vocabulary control as the answer to both problems. It defines scope, links synonyms through equivalence relationships and separates homographs R3.

In practice, uncontrolled tagging shows up in a DAM as:

• Missed results. One uploader tags "SS26", another "Spring/Summer 2026". Faceted filters split the same campaign into two values.
• Facet sprawl. Free keyword fields gather near-duplicates, typos and one-off values. The filter panel becomes too long to use.
• Fragile automation. Permissions, workflows, portals and integrations that key on a value break silently when someone renames or re-spells it.
• Costly migrations. Every inconsistency has to be mapped or cleaned when you move platforms (see metadata schema & governance).
• Weak AI tagging. Auto-tagging produces generic labels unless it is mapped to, or constrained by, your own vocabulary.

Vendor guidance on DAM taxonomy repeats the same failure modes: uncontrolled terms growing without review, too many fields too early, and structures designed for administrators rather than searchers R15 R16 R17. None of these vendor articles gives sourced figures on the cost of poor taxonomy, and this guide does not quote any.

Core concepts

Two standards frame the field:

• ISO 25964-1:2011 (thesauri for information retrieval, monolingual or multilingual) and ISO 25964-2:2013 (interoperability and mapping with other vocabularies). The standard itself is paid, but NISO hosts a free XML schema and data model for it R4.
• SKOS, the W3C data model for publishing and linking such vocabularies on the web R1. NISO describes ISO 25964 and SKOS as close neighbours: ISO 25964 says how to build the vocabulary and SKOS says how to publish it. A published correspondence table maps one data model to the other R4.

The SKOS building blocks are a useful checklist of what a DAM vocabulary should be able to hold, even if your platform never exports RDF R1 R2:

• Concept (the idea) and ConceptScheme (the vocabulary it belongs to).
• prefLabel: at most one per language tag.
• altLabel for synonyms and hiddenLabel for strings that should match in search but never be shown, such as common misspellings.
• broader / narrower for hierarchy and related for associations. SKOS treats hierarchical and associative links as mutually exclusive.
• notation for codes such as SKUs or internal classification codes.
• definition, scopeNote, changeNote and historyNote for documentation and audit.
• exactMatch, closeMatch, broadMatch, narrowMatch and relatedMatch for mapping to other vocabularies.

Recommended practices

1. Decide the structure field by field

Do not pick one model for the whole DAM. Look at each field that needs vocabulary control and ask three questions:

Z39.19 presents these structures as steps of increasing complexity, from lists to synonym rings, taxonomies and thesauri. Choose the simplest one that solves the retrieval problem, because each step adds maintenance work R3. Platforms often encode the same trade-off. One distinguishes lightweight option lists from heavier taxonomy entities that can drive security and facets (see Sitecore Content Hub features). Another separates admin-controlled keywords from free tags (see Canto features).

2. Build facets, not one master tree

Facet analysis works bottom-up. You identify the independent characteristics of your assets and give each one its own small vocabulary. Z39.19 recommends it for interdisciplinary content and for cases where one hierarchy cannot draw clean boundaries R3. A common DAM facet set is:

• Asset type (photo, video, logo, template, document)
• Brand / sub-brand and product (often hierarchical)
• Campaign or project (time-bound and frequently added: give it its own lifecycle)
• Market / region / language
• Usage or channel (web, print, social, internal)
• Subject / depicted content (the best candidate for a thesaurus or a public vocabulary)
• Rights status (kept separate and machine-actionable)

Faceted navigation lets users narrow results on several dimensions at once. It also costs more to build and maintain, because every facet must be applied to all content. Check that people actually need a facet before adding it R14. Vendor guidance generally advises shallow trees of two to four levels within a facet R17. Treat that as a rule of thumb, not a standard. For how facets relate to folders and collections, see Folders vs metadata: organising a DAM; for which facets become mandatory fields, see metadata schema & governance.

3. Write terms to a house style

Z39.19 gives detailed rules on term form: when to use single-word or multiword terms, how to handle unique entities, which grammatical forms to use, and how to write scope notes R3. For a DAM, write down at least these points:

• One concept per term. Separate homographs with a qualifier, e.g. "Jaguar (vehicle)" vs "Jaguar (animal)" R3.
• Consistent form: singular or plural, capitalisation, abbreviations. Is it "USA", "United States" or a code?
• A scope note for any term whose meaning is not obvious, saying what it covers and what it excludes R1 R3.
• Users' language for labels. The GOV.UK taxonomy team made reflecting "users' language and mental models" a design principle R12. Put internal jargon or codes in altLabel or notation rather than in the label people see.

4. Separate identity from labels

Every term should have a stable identifier that never changes, even when its label is corrected, translated or reworded. The pattern appears throughout the standards:

• SKOS concepts are identified by URI, with labels attached R1.
• Dublin Core recommends referring to subjects by URI where possible and, failing that, using a value from a controlled vocabulary R8.
• The IPTC Photo Metadata standard (2025.1) stores controlled values as a "CV-Term" structure with a vocabulary identifier, a term identifier and a term name. Its plain Keywords field, by contrast, may be free text R5.

In a DAM, this means storing option IDs or external reference codes rather than display strings in integrations, CSV exchange files and embedded XMP. It also means keeping your filename convention free of taxonomy values that may change (see file naming conventions).

5. Model equivalence and multilingual labels on the concept

Search succeeds when any reasonable word finds the asset. Use:

• Alternative labels for synonyms, acronyms and former brand names.
• Hidden labels for misspellings and legacy codes you want to match but never show R2.
• Synonym rings when you cannot change the indexing and only want broader retrieval R3.

For multilingual DAMs, attach translations to the concept, with one preferred label per language R1 R2. Do not maintain separate lists per language: they drift apart and break cross-market filtering. Large multilingual vocabularies often keep one dominant language for notes and administrative data while translating the labels. The Getty's Art & Architecture Thesaurus, for example, keeps English as its dominant language R11. EuroVoc, the EU's multilingual thesaurus, shows the scale this model can reach: 27 languages in version 4.24 R10.

6. Reuse public vocabularies where they fit

Generic subject terms rarely need inventing:

• IPTC Media Topics: over 1,200 terms on five levels, 13 language variants, published as RDF and spreadsheet, updated at least yearly and mapped to Wikidata R7. Like other IPTC NewsCodes, it is free under CC BY 4.0 R6.
• Library of Congress vocabularies such as LCSH and the genre/form terms, maintained through a public proposal and approval process R9.
• Getty vocabularies (AAT, ULAN, TGN) for art, architecture, cultural heritage and places R11.
• EuroVoc for public-sector and policy subjects R10.

Keep your business vocabularies (brands, products, campaigns) local. Map local subject terms to the public ones with exactMatch or closeMatch where useful R1. ISO 25964-2 covers the mapping methodology R4.

7. Govern change on purpose

Vocabularies are living things. The GOV.UK team called its taxonomy "a living thing that will inevitably change over time" R12. A minimum governance setup:

1. Named owner per vocabulary, plus a documented change-request route. GOV.UK split the work: content support handles change requests, the navigation team handles structure and tagging quality, and the publishing-workflow team handles the tagging interface R13.
2. Evidence for additions. Check zero-result searches and frequent queries (user warrant) and recurring content (literary warrant) R3.
3. A periodic review of usage counts. Z39.19 flags both overused and rarely assigned terms as candidates for splitting, modification or deletion, since both retrieve poorly R3.
4. Rules for merge, split and retire. Z39.19 asks you to consider the effect on records already indexed whenever a term changes. One option is to keep a retired term "for retrieval purposes only" and record the date in a history note R3. In a DAM, decide whether a merge re-tags assets in bulk, keeps the old term as a non-preferred label, or both.
5. Change log. Record changes in changeNote/historyNote-style fields, or in an external log, so you can explain why a filter value disappeared R1.
6. Communicate downstream. Portals, PIM/CMS integrations, saved searches and subscriptions depend on term IDs. When GOV.UK retired a legacy taxonomy, it asked email subscribers to choose new topics rather than moving them automatically R13.
7. Versioned import/export (CSV, or SKOS where available), so the vocabulary can be reviewed outside the DAM and restored if needed.

Public vocabulary maintainers work this way at scale. The Library of Congress reviews LCSH proposals in regular editorial meetings and publishes the approved lists R9. IPTC issues dated releases of Media Topics R7.

8. Test with real users and real searches

Z39.19 includes testing and evaluation in the vocabulary lifecycle R3. Practical tests for a DAM:

• Findability tasks. Ask representative users to find specific assets using only facets. Note where they hesitate or choose the wrong branch.
• Indexing consistency. Have two people tag the same sample and compare their choices. Low agreement points to unclear terms or missing scope notes.
• Search-log review. Look at top queries with no results, and queries that match a label in another language or an unlisted synonym.
• Interface research. GOV.UK ran lab sessions with publishers and changed its tagging interface before and after rollout R13. How easy a vocabulary is to apply matters as much as its structure.

Common pitfalls

How DAM platforms support this

The wiki's solution pages document how each platform models vocabularies. Look for the Metadata & taxonomy and Search sections. Capabilities vary widely, so check the following points against your requirements rather than assuming a "taxonomy" feature covers all of them:

Questions to put to any platform, in demos or RFPs:

• Are option values stored and exposed through the API by ID?
• Can a term carry several labels per language, plus synonyms?
• What happens to tagged assets when a value is renamed, merged or deleted?
• Can the vocabulary be bulk-imported and exported, ideally in a standard format such as SKOS?
• Can facets be built on any controlled field?
• Can AI tagging be restricted to your own vocabulary?

Where a solution page says Unknown for thesaurus or synonym support, the vendor documentation did not cover it at the time of research. Ask the vendor directly.