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. The two aren't mutually exclusive, and most DAM setups work best combining both: folders provide a broad organizational skeleton -- by project, year, or client -- that keeps ingestion and browsing predictable, while taxonomy tags layer flexible, multi-facet description on top, letting each team filter by its own criteria. Folders alone just can't substitute for that metadata layer.
What's a concrete example of taxonomy tags applied to one file?
A single product photo can carry several independent tag dimensions at once -- for example product: chair, color: blue, campaign: spring 2026, and usage rights: web-only -- each describing a different facet of the same file. A folder can't do this: the file lives in only one folder at a time, so this kind of simultaneous, multi-facet classification is only possible through metadata tags, not physical location.
What's the risk of forcing a single "correct" folder path for shared assets?
When an asset is needed by several teams or projects at once, forcing it into a single folder path creates real friction. Teams often end up duplicating the file into multiple folders, which then drift out of sync as one copy gets updated and the others don't. Others argue over which location is "correct," or simply never find the asset because it isn't filed under the path their team expects.