A taxonomy is the agreed set of terms your organization uses to describe its assets, and the structure those terms live in. It sounds abstract until you watch it fail: one person tags a photo "sneaker", another "trainer", a third "footwear", and a fourth files it under the campaign name and tags nothing. All four photos exist; none of them are findable together.

Taxonomy work is the unglamorous middle of every DAM rollout. This guide keeps it practical: what the options are, how to choose, who gets to change things, and a worked example you can adapt.

Taxonomy and folksonomy: two ways to tag

There are two fundamentally different approaches to describing assets, and understanding the trade-off matters more than picking a side.

A taxonomy is a controlled, pre-agreed set of terms. Someone decides that the term is Sneakers — not Trainers, not Athletic footwear — and taggers pick from a list rather than typing. The payoff is consistency: every sneaker photo carries the same term, so a filter for Sneakers returns all of them, every time. The cost is upkeep: someone has to maintain the list, and taggers occasionally can't find a term that fits.

A folksonomy is the opposite: free tagging. Anyone types whatever words seem right. The payoff is zero friction and vocabulary that evolves as fast as your content does — when a new product category appears, the tags appear the same day, no committee required. The cost is drift: synonyms, plurals, typos, and personal idiosyncrasies accumulate, and search precision decays as the library grows.

This is a design distinction, not a contest with a winner. Small libraries and exploratory content lean folksonomy; large libraries with structured retrieval needs lean taxonomy. Most healthy DAM setups use both, deliberately:

• Controlled vocabularies for the dimensions your business depends on: product family, asset type, region, brand. These power filters, automation rules, and reporting, so they must be consistent.
• Free tags for everything ad hoc: moods, one-off themes, working labels. Cheap to add, harmless when messy.

A useful rule of thumb: if you'd ever want to build a filter, a workflow rule, or a report on a field, control it. If it only helps discovery, let it be free — especially since semantic search now finds "team celebrating outdoors" without anyone having tagged those words at all. AI-generated tags soften the trade-off further: they behave like a folksonomy written by a consistent tagger, giving you broad free-text findability while your controlled vocabularies stay small and load-bearing.

Controlled vocabularies: the building blocks

In freedam, taxonomy is built from vocabularies: named lists of terms that administrators manage centrally and users select from when tagging. A vocabulary might be Asset Type (Packshot, Lifestyle, Logo, Video, Document), Region (EMEA, Americas, APAC), or a full product hierarchy.

What makes a vocabulary more useful than a text field:

• One spelling, everywhere. Users pick; they don't type. "Sneaker vs. trainer" stops being a problem.
• Multilingual labels. A term can carry translations — freedam can auto-translate term labels — so a French colleague filters by Baskets and finds the same assets an English colleague finds under Sneakers. One concept, many labels.
• Safe evolution. Renaming a term updates every asset that carries it. Deleting a term in freedam prompts you to replace it with another or clear it — no orphaned tags, no broken filters.
• Reliable filters. Vocabulary fields become gallery filters, and in freedam a vocabulary field can be promoted to a quick filter that sits beside the search bar — a one-click cut of the whole library.

Vocabularies plug into your metadata schema as fields: an asset class can have a Product Category field backed by the product vocabulary, an Asset Type field backed by another, and so on. (If you haven't designed your schema yet, start with the metadata guide — schema and taxonomy are two halves of one decision.)

Hierarchical or flat?

Every vocabulary is either a flat list or a tree, and choosing wrongly creates friction for years.

Flat lists suit short, independent value sets: asset types, regions, channels, statuses. If the list fits on one screen and no term is "inside" another, keep it flat. Flat lists are faster to pick from, easier to govern, and never suffer the "which branch does this go in?" argument.

Hierarchical trees suit categories with genuine parent–child structure: Footwear → Running → Trail running. The hierarchy earns its complexity in one specific way: broadening and narrowing. A user filtering on Footwear should find assets tagged three levels deeper, and drilling from a big bucket into a precise one should feel natural. If you never need that roll-up behavior, the tree is decoration — flatten it.

Practical guidance:

• Three levels is usually enough. Beyond that, taggers can't decide where things go and browsers get lost. Deep trees are a sign you're modeling the org chart or the ERP, not how people search.
• A term should have one home. If an item plausibly belongs in two branches ("is a running sandal footwear/running or footwear/sandals?"), your tree is encoding two independent dimensions. Split them into two vocabularies instead — which brings us to facets.
• You can grow into a tree. freedam lets you convert a flat vocabulary to a hierarchical one later, so start flat when in doubt.

Think in facets, not folders

The deepest habit to unlearn from shared drives is the single-hierarchy mindset — the idea that every asset has one right place. Folder trees force an ordering decision (year → campaign → product? or product → year → campaign?) that is wrong for half your users on day one.

A faceted taxonomy abandons the ordering entirely. Each independent dimension becomes its own vocabulary — its own facet:

• Product category (hierarchical)
• Asset type (flat)
• Region (flat)
• Season / collection (flat)
• Usage channel (flat)

An asset carries one or more values per facet, and users combine facets at search time: Lifestyle + Footwear → Running + EMEA + Spring 2026. Nobody had to predict that combination; the intersection just works. Facets also keep each vocabulary small — five lists of ten terms cover more ground than one tree of a thousand nodes, and are far easier to maintain.

The test for a good facet: it applies to most of your assets, its values are mutually understood, and it's independent of the other facets. If two "facets" always move together, merge them.

Governance: who may add terms

Taxonomies die two deaths: neglect (the vocabulary no longer matches the business, so people stop using it) and sprawl (everyone adds terms, so it becomes a folksonomy with extra steps). Governance is how you avoid both, and it needs to be lightweight enough to actually happen.

A minimal governance model:

• One owner per vocabulary. Not a committee — a person. The product vocabulary probably belongs to someone near product marketing; asset types to the DAM admin.
• Anyone may propose; the owner disposes. Make requesting a term trivial (a message, not a form). The owner's job is mostly to catch synonyms — "we already have Sneakers; you don't need Trainers."
• Admin rights match the model. In freedam, vocabulary management is an administrator function, so casual taggers physically can't add terms mid-upload. Critical vocabularies can be protected against accidental deletion.
• Review on a calendar, not a crisis. Twice a year, each owner spends thirty minutes: merge synonyms that slipped through, retire terms with no assets, check that AI-suggested tags aren't drifting away from vocabulary terms that mean the same thing.
• Change with a migration, never in place. When a term must change meaning, use replace-on-delete (freedam prompts for a replacement term) so history stays consistent.

Free-tag areas need almost no governance — that's their point. Just watch for free tags that keep recurring; a tag that hundreds of assets share organically is a vocabulary term telling you it wants to be promoted.

Start small, evolve deliberately

The strongest predictor of taxonomy failure is launching with the complete, final, twelve-vocabulary model on day one. You don't yet know how people search; you're guessing, and every wrong guess is a field full of stale data later.

Instead:

1. Launch with two or three facets you're certain about — almost always Asset type plus your primary business dimension (product, client, or department).
2. Watch real behavior for a month. Failed searches, recurring free tags, and "where do I find…" questions in chat are your requirements document.
3. Add one facet at a time, backfilling values on existing assets as you go (bulk editing plus AI suggestions make this tractable).
4. Promote, split, and prune based on use: promote hot facets to quick filters, split any vocabulary where taggers keep hesitating between branches, and delete what nobody filters on.

A taxonomy is a product, not a document. Version it, iterate on it, and measure it by one number: how often people find what they're looking for on the first try.

Worked example: a consumer brand media library

Say you run the media library for a footwear and apparel brand — product shots, campaign imagery, video, logos, and documents, growing by a few thousand assets a season. A reasonable starting taxonomy:

Facet 1 — Asset type (flat, required at upload): Packshot · Lifestyle · Campaign key visual · Logo & brand mark · Video · Document. Six terms. This single field powers the most common filter in the library.

Facet 2 — Product category (hierarchical, 2–3 levels): Footwear → Running / Lifestyle / Kids; Apparel → Tops / Bottoms / Outerwear; Accessories. Maybe thirty terms total. Product identifiers (SKUs) do not go in the tree — they're a metadata field, machine-matched, because a vocabulary with ten thousand leaf nodes is a database table wearing a costume.

Facet 3 — Season (flat): SS25, FW25, SS26… plus Evergreen. One term per asset, mostly set in bulk at import time.

Facet 4 — Region rights (flat): Global · EMEA · Americas · APAC. Note this facet earns its keep twice — as a filter and as an input to access and usage rules.

Free tags + AI handle everything else: moods ("urban", "sunrise"), depicted activities, colorways. AI auto-tagging populates most of these on ingestion; nobody maintains them, and semantic search covers the gaps.

Governance: brand ops owns Asset type and Region rights; product marketing owns the category tree; Season is append-only. Total maintained terms: roughly fifty. A library of a hundred thousand assets can run on that — and when a new business line launches, you add a branch, not a rebuild.

---

Want to poke at vocabularies, facets, and quick filters on a seeded library? Try the demo — it's a working freedam instance.