How to set up DAM metadata and taxonomy people actually use

Every DAM implementation that fails, fails here. Not at the software. Not at the migration. Here. The platform gets bought, the assets get uploaded, and eighteen months later search returns nothing useful, because half the library has three tags and the other half has none. The software was never the problem.

DAM metadata is the description attached to each asset: what it shows, where it came from, what you're allowed to do with it. Taxonomy is the agreed structure those descriptions follow: the fields you use and the values allowed inside them. Get the taxonomy right and the metadata stays maintainable. Get it wrong and every upload becomes a small negotiation with yourself about what to call things.

The good news: getting it right has far more to do with restraint than with effort. Let's walk through it.

Taxonomy, metadata and tags are three different things

Vendor marketing uses all three interchangeably, which is why workshops about them go sideways so reliably.

• Taxonomy is the framework: the set of dimensions you classify by and the approved values inside each. It's a decision, not a feature.
• Metadata is the structured data on a specific asset: fields with defined types and, ideally, defined value lists.
• Tags are free keywords. Flexible, great for the long tail, and the first thing to go inconsistent the moment nobody's watching.

A working library uses all three. Taxonomy sets the shape, metadata fills the reliable filters, and tags catch whatever nobody anticipated.

The six types of metadata

Six sounds like a lot of theory, but the split matters for one practical reason: each type has a different owner and a different lifespan.

Only two of these should ever cost a human any effort: descriptive and rights. Everything else should be handled for you. If your DAM asks a photographer to type in the file dimensions, buy a different DAM.

Design the taxonomy around questions, not around your org chart

The single most useful exercise happens before you touch any software: collect the last thirty real asset requests your team received. Actual sentences, in the words people used.

"Do we have photos of the new production line?" "I need a landscape shot of the venue with people in it." "Anything from the 2025 open day that we can use publicly?" "The logo, white, on transparent, for print." "Recent portraits of the management team."

Now group them. Those groupings are your dimensions, and in almost every marcom library they land close to:

• What it shows: subject matter, product, location, people
• Where it came from: campaign, event, shoot, photographer, agency
• What it is: asset type, orientation, format, language
• What you may do with it: approval state, usage rights, expiry, internal or public
• When: date created, date published, season

Design for the questions you actually get. A taxonomy built from the marketing department's structure describes the department, not the content, and it'll be obsolete the next time you reorganise. Which, statistically speaking, is soon.

Rules that keep a taxonomy alive

Keep it shallow

Three to five levels of hierarchy is the practical ceiling. Beyond that, nobody can hold the structure in their head, so people default to searching anyway. Which is fine, but then all that careful depth was wasted effort. Breadth beats depth: more dimensions with fewer levels each is far easier to maintain than one deep tree.

Use a controlled vocabulary

This is the highest-leverage decision in the whole exercise. Skip it and you'll collect, for one and the same place:

Antwerp · antwerpen · ANTWERP · Antwerp HQ · Antwerp office · ANT

Six values. One city. No filter that returns all of it. A controlled vocabulary means the field offers a list, and typing something new is either impossible or requires approval. It feels restrictive in month one. It saves the library in year three.

Where a platform supports it, tag recycling (suggesting the existing term as you type instead of letting you invent a near-duplicate) does most of this work invisibly.

Make very few fields mandatory

Every required field is a tax on uploading, and taxed uploads get avoided. Pick the minimum set that makes an asset findable and safe to use. For most teams that's four:

1. Subject or description (AI can propose this)
2. Campaign, event or project
3. Usage rights or approval state
4. Date, if it's not reliably in the file

Everything else is optional enrichment. A library where 100% of assets have four good fields beats one where 20% have twelve.

Write the definitions down

"Approved" means what, exactly? Approved by whom, for which channels, until when? If two people can read a value differently, they will. A one-page document mapping each field to a plain-English definition prevents most of the drift, and it's the thing you hand to a new colleague on day one.

Give it an owner

Taxonomies decay. New products launch, brands merge, terms fall out of use. One named person should own the vocabulary and review it; quarterly is enough for most teams. Without an owner, everyone adds terms and nobody removes them, and you're back to six spellings of Antwerp.

Where AI fits, and where it doesn't

AI tagging is properly good now. Vision models describe what's visually present in an image with high accuracy, read text inside images, recognise recurring faces, and produce usable captions in dozens of languages. It removes the most tedious part of metadata work. (The part everyone secretly skipped anyway.)

What it can't do is know your business. A model can tell you an image contains two people, hard hats, steel structure, overcast. It can't tell you this is the Borssele II project, shot by the agency you contracted in March, cleared for public use until the client's embargo lifts.

So the practical split looks like this:

• AI handles descriptive metadata: subject, objects, scene, colours, text-in-image, faces, similarity
• Humans handle business metadata: campaign, rights, approval, project codes, internal vocabulary

The reliable pattern is two-pass. Let AI generate generic descriptors on ingest, then map or supplement them with your controlled vocabulary, with review on anything the model was unsure about. Structured upload forms do that second pass at the moment of upload, which is the only moment the uploader still knows the context.

One warning. AI tagging isn't a substitute for a taxonomy. It's an accelerant for one. Point auto-tagging at an ungoverned library and you'll produce a very large number of inconsistent, ungoverned tags very quickly.

Retrofitting metadata onto an existing library

Nobody starts clean. Here's the realistic approach:

Don't enrich everything. Most libraries follow a steep usage curve: a small fraction of assets accounts for nearly all retrievals. Enrich that fraction properly and let the rest be findable through AI search and technical metadata alone.

Mine what you already have. Folder names, filenames and EXIF carry real information. 2024-09_OpenDay_Hasselt/ is a campaign, a date and a location. Bulk-apply it during migration rather than re-deriving it later by hand.

Enrich on use. When someone retrieves an under-described asset, prompt for the missing field. The people using an asset know the most about it, and the effort lands exactly where the value is.

Set a cut line. Assets older than a defined date go to an archive that stays searchable but sits outside the default view. Old material stops diluting everyday search results, and you dodge a cleanup project that was never going to finish anyway.

How to migrate to a DAM puts all of this into a full sequence.

Standards worth knowing

You don't need to implement these. But you should know they exist, so you don't spend a workshop reinventing them.

• IPTC Photo Metadata: the standard fields for photography (creator, credit line, copyright, description, keywords). Widely supported by cameras, Lightroom and DAMs, and it travels inside the file.
• XMP: Adobe's container for embedded metadata; it's how IPTC and custom fields survive a trip through Photoshop.
• EXIF: camera-written technical data: device, lens, exposure, GPS, timestamp.
• Dublin Core: a small, generic descriptive set; useful vocabulary when you're designing your own schema.
• C2PA Content Credentials: cryptographically signed provenance describing how an asset was created and edited, including whether AI was involved. Increasingly relevant for compliance; see GDPR, EU data residency and the AI Act.

Prefer embedded metadata where you can. Metadata that lives only in a database is lost the moment a file leaves the system.

A starter schema

If you want somewhere to begin, this one holds up for most marketing and communication teams:

Ten fields, four required. Start smaller than feels right. Adding a field later is trivial; removing one after two years of use is not.

Frequently asked questions

How many metadata fields should a DAM have?

Fewer than you think. Aim for four or five required fields and a handful of optional ones. Completeness of a small schema beats the theoretical richness of a large one, because required fields are only useful if people actually fill them in.

What is a controlled vocabulary in a DAM?

A fixed list of approved values for a field, so the same concept is always recorded the same way. It prevents near-duplicate tags like "Antwerp", "antwerpen" and "Antwerp office" from fragmenting your search results.

Can AI replace manual tagging?

For descriptive metadata (what an image shows, text inside it, who's in it), largely yes. For business context such as campaign, rights status and project codes, no. AI doesn't know your organisation. The effective pattern is AI for description plus a short structured form for context.

How deep should a DAM taxonomy be?

Three to five levels at most. Deeper structures are harder to maintain and rarely used, because people search rather than browse once a library passes a few thousand assets.

How often should we review our taxonomy?

Quarterly is enough for most teams: merge duplicate terms, retire unused ones, add vocabulary for new products or brands. Assign it to one named owner, otherwise it won't happen.