Every metadata workshop follows the same arc. Someone asks what we should capture, everyone answers honestly, and ninety minutes later there is a whiteboard with forty-three fields on it. All of them are genuinely useful. The schema ships. Eighteen months later, five fields are populated and the rest are empty columns in an export nobody reads.
Short answer: design the schema around what will actually get filled in, not around what would be nice to know. That means a small required core, a conditional layer that only appears when it applies, and everything else either inferred by the system or left out. A schema with twelve real fields beats one with forty aspirational ones, every time, because search quality depends on completeness rather than richness.
Why big schemas fail
Three mechanisms, and they compound.
Every required field is a tax on contribution. A twenty-field upload form does not produce twenty fields of data. It produces fewer uploads, and it produces n/a, TBC, and the same value copy-pasted down the column. You have converted a data quality problem into a data quality problem with more rows.
Fields designed for one department are noise to everyone else. The photographer’s release number matters enormously to legal and not at all to the person looking for a header image. Put both on the same flat form and you have made the form worse for both.
Unpopulated fields poison search. This is the part that surprises people. If a field is filled in thirty percent of the time, filtering on it hides seventy percent of the matching material. Users learn quickly that the filters lie, and they stop using them. A field that is inconsistently populated is worse than no field, because it actively produces wrong answers with confidence.
The three-tier model
Structure the schema in tiers rather than as one flat list.
Tier one: required, always, no exceptions. Five to eight fields, every one of which someone will genuinely use to find something. Typically: asset type, owning business unit, subject or product, approval state, and rights status. If you cannot explain in one sentence which query a required field serves, it is not tier one.
Tier two: conditional. Fields that appear only when a tier one value makes them relevant. If rights status is “licensed”, then licensor, licence expiry and permitted territories become required. If the asset type is “product photography”, then SKU becomes required. The form stays short for everyone and gets long only for the cases that warrant it.
Tier three: inferred or optional. Dimensions, format, colour profile, dominant colours, detected objects, extracted text. Nobody should type any of this. It is either read from the file or produced by analysis, and modern platforms will do it on ingest. Cloudinary exposes this through its asset analysis capabilities, which populate descriptive attributes automatically rather than asking a human to.
The rule of thumb that has held up for me: if a field can be derived, deriving it is always better than asking, even when asking would be more accurate. Accuracy at thirty percent coverage loses to approximation at ninety-eight.
Do not invent your vocabulary from scratch
There are standards for this, they are free, and reusing them buys you interoperability you will need later.
Dublin Core gives you the fifteen-element descriptive base that most systems already understand, with the full property set published as DCMI Terms. IPTC Photo Metadata is the standard the photography and publishing supply chain actually uses, so if you receive material from agencies it is already arriving in that shape. For controlled vocabularies covering subject, materials and geography, the Getty vocabularies are the reference set, and ANSI/NISO Z39.19 is the guidance on constructing your own controlled lists if you have to.
Map your fields to these rather than parallel to them. It costs a day and it means that when you export, migrate, or feed a partner, the mapping already exists.
The place to depart from the standards is your own operational vocabulary: business unit, brand, campaign, approval state, product code. Those are yours and no standard covers them. Everything descriptive should sit on a standard.
Free text, controlled lists, and where to draw the line
The single highest-leverage schema decision is which fields are typed and which are chosen.
Controlled list anything you will ever filter, group, or report on. Brand, market, asset type, approval state, rights status, channel. If two people can spell it differently, it must be a list. US, USA, United States, us and U.S. are five values and one country, and no amount of search cleverness recovers from that.
Free text the description and the title, and nothing else. These exist for human reading and full-text search, not for filtering.
Tags are the tempting middle ground and they are a trap at enterprise scale unless governed. Open tagging produces product, products, product-shot, productshot and prod within a quarter. If you want tags, run them from a managed vocabulary with an approval path for additions, and accept that this needs an owner. The mechanics of keeping that vocabulary usable are in designing a taxonomy people actually use.
How do you know if the schema is working?
Measure three things quarterly. They are cheap to collect and they tell you everything.
- Completeness per field. Percentage of assets with a non-null, non-junk value. Anything under eighty percent on a tier one field is a broken field, not lazy users. Either it is unclear, or it is not actually required, or the form is asking at the wrong moment.
- Filter usage. Which facets people actually click. A field with high completeness and zero filter usage is dead weight and should be demoted to tier three. This is the metric that gives you permission to delete fields, which is the hardest political act in metadata work.
- Zero-result rate. Proportion of searches returning nothing. High zero-result rates usually mean the vocabulary in the schema does not match the vocabulary in people’s heads, which is a naming problem rather than a coverage problem.
Publish these. A schema that nobody reviews becomes a schema nobody trusts, and this is the whole reason governance needs a standing owner rather than a launch project.
Where the schema has to live
One point that gets missed in the design and then costs a migration later: the schema needs to be a first-class, queryable structure in the platform, not a bag of key-value pairs stapled to the side.
The practical test is whether you can define a field once, with a type and a controlled list, and have it enforced at the API as well as in the interface. If validation only exists in the upload form, every integration becomes a hole in your data quality, and integrations are how most assets arrive at enterprise scale. Cloudinary handles this through structured metadata fields with defined types and validation, which is the shape to look for regardless of vendor: typed, centrally defined, enforced everywhere the asset can enter.
Ask that question in every demo. “Show me the field definition, then show me the API rejecting a bad value.” Most platforms pass. The ones that do not will cost you a data cleanup project in year two.
Start smaller than feels right
If you are building this now, my advice is to ship six required fields and be ruthless about it. You will be told this is not enough. It will be enough, because six fields at ninety-five percent completeness supports better search than thirty fields at twenty percent.
Add fields when a specific failed search justifies one, and make the justification write it down. That keeps the schema tied to real retrieval need rather than to what a workshop imagined, and it makes the asset lifecycle tractable, because a small schema is one you can actually maintain across a state change.
The broader case for why the fields matter more than the storage is in what enterprise DAM actually is, and if your fields include anything about permissions or expiry, read access control, SSO and audit trails before you finalise the model.