Reference Glossary
Folder structure vs taxonomy
Folder structure files each asset in one fixed physical location; taxonomy is a metadata-driven classification that lets the same asset appear under multiple categories at once.
Why it matters in a DAM
Real DAM libraries need the same asset findable through different paths by different teams — a product photo a regional team looks for by country/language folder and an e-commerce team looks for by product category. Folder-only organization forces a single "correct" location and either duplicate copies or dead-end searches for whoever doesn't know that path, while taxonomy applied as metadata lets one master file be discoverable multiple ways without duplication.
A worked example
Common mistake
Teams replicate their old shared-drive folder tree one-to-one inside the DAM instead of rebuilding around metadata taxonomy, so the migration ends up as the same slow, siloed folder browsing with none of the cross-cutting search benefit that justified moving off the shared drive in the first place.
A folder structure files each asset in exactly one place, the way a shared drive does — an image lives at one path, and finding it means knowing or guessing that path. Taxonomy instead classifies assets through metadata fields and controlled categories that sit independently of file location, so an asset can belong to several categories simultaneously without existing in several places.
The practical difference shows up the moment more than one team needs the same asset for different reasons. A product photo a regional marketing team looks for by country and language, and that an e-commerce team looks for by product SKU, is the same file — but a folder tree can only nest it one way. Taxonomy lets both teams filter to it through their own lens, from tags applied once at ingestion.
This is also why DAM migrations from shared drives fail to deliver on their promise so often: the team imports the files and preserves the existing folder hierarchy exactly, because it’s familiar and fast, then wonders why search still feels like browsing a file server. The folder tree isn’t wrong to keep as a coarse container, but it can’t substitute for the metadata layer that makes cross-team discovery possible.
Frequently asked
What's the core difference between folder structure and taxonomy?
A folder structure files each asset in exactly one physical location, like a shared drive. Taxonomy classifies assets through metadata fields and controlled categories that sit independently of file location, letting an asset belong to several categories simultaneously without existing in several places.
Why does this distinction matter for teams with different needs?
The same product photo might be looked for by a regional team via country/language folder and by an e-commerce team via product category. Folder-only organization forces one "correct" location, while taxonomy lets both teams filter to the same file through their own lens.
Why do DAM migrations from shared drives often fail to deliver expected benefits?
Teams import files and preserve the existing folder hierarchy exactly because it's familiar and fast, then wonder why search still feels like browsing a file server -- the folder tree can't substitute for the metadata layer that makes cross-team discovery possible.
Should a DAM abandon folders entirely in favor of taxonomy?
Not necessarily -- folders aren't wrong to keep as a coarse container, but they can't substitute for the metadata layer taxonomy provides for cross-cutting discovery.
What's a concrete example of taxonomy tags applied to one file?
A single hero-shot file might carry Product: Sunscreen, Region: EU, Campaign: Summer 2026, and Usage: Web as independent tags, letting different teams filter to it through different criteria.
What's the risk of forcing a single "correct" folder path for shared assets?
It creates duplicate copies or dead-end searches for whoever doesn't know that specific path, since folder organization can only nest a file one way.