Every organization has two classification schemes. One is written down somewhere — a taxonomy, a records schedule, a governance policy. The other is the folder tree. The folder tree is the one people actually search against, and it was never designed. It accreted.
This article is about reading that accreted structure as evidence. Not as a standard-compliant artifact, not as a records schedule, and not as something to migrate. The folder tree is a concept scheme in the descriptive sense: it has labels, near-synonyms, code-like segments, and links (or missing links) to the formal schemes it is supposed to serve. Reading it with the vocabulary of controlled-vocabulary practice is a diagnostic method. It is not a claim that the tree conforms to any standard.
Why the folder tree deserves a careful read
The Simple Knowledge Organization System (SKOS) is a W3C Recommendation that defines a common data model for sharing and linking knowledge organization systems via the Web. Its specification notes that thesauri, taxonomies, classification schemes, and subject heading systems share a similar structure and are used in similar applications, and that SKOS captures much of this similarity and makes it explicit (W3C SKOS Reference). The SKOS home page describes the work as developing specifications and standards to support the use of knowledge organization systems such as thesauri, classification schemes, subject heading lists, and taxonomies within the framework of the Semantic Web (W3C SKOS home).
None of that says a folder tree is a thesaurus. What it says is that the structural vocabulary exists, is well documented, and is useful for describing what a folder tree actually does. A folder tree has preferred labels (the names people use), alternate labels (near-synonym folders for the same concept), hidden labels (folders whose names no longer match their contents), notations (code-like segments such as dates, case numbers, or agency codes), and mapping relations (links, or missing links, to schedules and published taxonomies). Borrowing that vocabulary is the first move.
The second move is to be honest about what the tree can and cannot answer. It can tell you how people group work. It cannot tell you what must be retained. Those are different questions, and conflating them is the most common category error in this space.
Step 1: Harvest the artifact
Everything in this analysis hangs on one exportable artifact: a folder-path inventory. Depending on the platform, this may come from a site collection report, a PowerShell listing, a Confluence space export, or a crawl of the content repository. What matters is that it is a flat list of paths, ideally with item counts and last-modified dates.
If you cannot export the folder paths, stop here. The rest of this method depends on having the list in hand, not on reading it through a UI.
Two cautions. First, the export is a snapshot; folder trees change. Second, the export is a list of labels, not a list of contents. A folder named Contracts 2019 may contain executed agreements, drafts, and correspondence about the agreements. Those are three different concepts with three different retention profiles. The folder name does not tell you which is which. Only a sample read will.
Step 2: Separate labels from notations
In controlled-vocabulary practice, a label is a human-readable string; a notation is a lexical code. SKOS describes concepts as being identified using URIs, labeled with lexical strings in one or more natural languages, and assigned notations (lexical codes) (W3C SKOS Reference). The distinction matters because the two carry different kinds of meaning.
In a folder tree, a segment like FY2024, Case-2021-0447, or Region-04 is a notation. It is a code. It may be meaningful to a system, a schedule, or a filing convention, but it is not a concept label in the ordinary sense. A segment like Procurement or Onboarding is a label. It names a concept.
When you sort the inventory, keep the two apart. Notations are usually stable and machine-generated; labels are where drift accumulates. A folder tree that is mostly notations is a filing system. A folder tree that is mostly labels is a folk taxonomy. Most real trees are a mix, and the mix is itself diagnostic.
Step 3: Find the alternate labels
An alternate label is a near-synonym for a preferred label. In a managed thesaurus, alternate labels are recorded explicitly. In a folder tree, they show up as sibling folders that split the same concept.
Two sibling folders named HR and Personnel may be alternate labels for the same concept, or may be genuinely distinct concepts. The diagnostic move is to sample both and compare contents, not to assume either from the names. If the contents overlap substantially, you have a candidate merge or mapping pair. If they do not, you have two concepts that happen to have similar names.
Record candidate pairs in a simple table: folder A, folder B, sample size, overlap assessment, proposed action. This table is the beginning of the label-coverage report. It is also the artifact that makes the next conversation concrete rather than rhetorical.
Step 4: Find the hidden labels
A hidden label is a label that exists but is not used for search or display. In a folder tree, the hidden labels are the folders whose names no longer match their contents. The folder was named for a project that ended; the contents have drifted into something else. The name persists because renaming is disruptive.
These are the findability gaps that no search query will surface, because the query returns the folder and the searcher assumes the name is accurate. The only way to find them is to sample contents against names. A small sample — five to ten items per folder, chosen at random — is usually enough to flag the worst offenders.
This is also where the folder tree stops being a naming problem and starts being a metadata problem. Dublin Core metadata terms are described as intended to be used in combination with metadata terms from other compatible vocabularies in the context of application profiles, and as expressed in RDF vocabularies for use in Linked Data (DCMI Metadata Terms). The relevant point here is not that you should adopt Dublin Core for your folders. It is that the metadata layer — title, description, subject, access rights — is where the folder name stops being the only signal. A folder with a stale name and a current description is a smaller problem than a folder with a stale name and no description at all.
Step 5: Read the hierarchy honestly
SKOS describes concepts as being linked to other concepts and organized into informal hierarchies and association networks (W3C SKOS Reference). The word informal is doing real work. A folder tree is an informal hierarchy. It is not a formal ontology, and it does not need to be.
Three things to note when reading the hierarchy:
- Depth. Where does the tree exceed what a person will click? Depth is a findability cost, and it is usually invisible to the people who built the tree because they navigate by search, not by clicking.
- Sibling overlap. Where do sibling folders cover overlapping content? This is the same diagnostic as alternate labels, applied one level down.
- Collections versus concepts. Some folders are not concepts at all; they are collections — ordered sets of items that belong together for a reason other than shared meaning. A folder named Board Packets 2024 is a collection. A folder named Governance is a concept. Treating a collection as a concept produces a hierarchy that looks wrong because it is answering a different question.
None of this requires a standard. It requires a careful read of the export you already have.
Step 6: Check the mapping layer
Where the folder tree is supposed to connect to a records schedule, a retention label, or a published taxonomy, verify the mapping exists and is current. Do not assume the folder name implies the authority.
This is where the distinction between the two classification schemes becomes operational. The National Archives and Records Administration (NARA) issues General Records Schedules (GRS) that provide disposition authority for common federal records, and states that use of the GRS is mandatory unless an agency can justify the use of an agency-specific schedule (NARA GRS). The GRS covers records documenting administrative or support functions and typically does not cover records documenting the mission of an agency. That is a disposition authority. A folder name is not.
NARA also advises that agencies should maintain administrative records separately from program records in their agency recordkeeping systems, and that if administrative records are mixed with program records and cannot be economically segregated, the entire file must be kept for the period approved for the program records (NARA GRS Introduction). This is a concrete example of why folder names cannot carry retention force: a folder that mixes administrative and program records inherits the longer retention, and the folder name will not tell you that.
On the platform side, Microsoft Purview records management documentation describes a records management system as a solution for organizations to manage regulatory, legal, and business-critical records, and states that when an item is declared a record by using a retention label, restrictions are placed on the item in terms of what actions are allowed or blocked, additional activities about the item are logged, and there is proof of disposition when the item is deleted at the end of its retention period (Microsoft Purview records management). The same documentation notes that the most important difference for a regulatory record is that after it is applied to content, nobody, not even a global administrator, can remove the label. That is a one-way door. It is not a folder-naming decision.
Where a folder tree is supposed to map to a records schedule or a retention label, the mapping should be recorded as an explicit relation with a review date, not inferred from naming similarity. Naming similarity is a hypothesis to test, not a mapping to rely on. NARA’s own Records Control Schedules page notes that its process for determining which schedules are currently valid is an ongoing work in progress, and advises verifying that you are using the most recent and current disposition authority before implementing disposition (NARA Records Control Schedules). If the authority itself requires verification, a folder name certainly does.
Step 7: Produce the two deliverables
Two artifacts are sufficient for a first pass. Both are exportable. Both are reversible. Neither requires a migration, a new platform, or a governance committee.
The folder-path inventory. A flat list of paths, with item counts and last-modified dates where available. This is the raw evidence. It is also the artifact you will re-export in six months to see what changed.
The label-coverage report. A table with one row per folder, and columns for: path, label type (concept or notation), sample size, content-name match assessment, candidate alternate labels, candidate hidden labels, and proposed action. The proposed action column should be conservative: leave, rename, merge, map, or investigate. Most rows will be leave.
If the analysis is to say anything about retention, a third artifact is needed: the current disposition authority or retention label mapping for the records in scope. Without that, the analysis should stop at findability and naming. That is not a limitation of the method; it is a boundary of the evidence.
Step 8: Propose the lightweight fix
The lightweight fix is a naming convention plus a small set of mapping notes plus a label-coverage target, reviewed on a schedule. Anything heavier should be justified by a specific failure the lightweight fix cannot address.
A naming convention is not a taxonomy. It is a short set of rules — for example, that folder names use the preferred term from the published taxonomy where one exists, that notations are kept in a separate segment, and that collection folders are marked as such. The convention should be short enough to remember and specific enough to test.
Mapping notes are the explicit relations between folder paths and the authorities they are supposed to serve. Each note should have a review date. Where no mapping exists, the note should say so. A missing mapping is information.
A label-coverage target is a simple statement of what proportion of folders should have a current description or a mapped authority. The target is a local decision; the point is to make the gap visible and to track it over time.
Keep the fix reversible. A naming convention can be revised. A mapping note can be corrected. A label-coverage target can be adjusted. None of these require the kind of commitment that a regulatory record label does.
What the folder tree can and cannot tell you
The folder tree can tell you how people actually group work. It can show you where near-synonyms have split a concept, where names have drifted from contents, where the hierarchy has grown deeper than anyone will click, and where collections have been mistaken for concepts. All of that is answerable from an export and a sample read.
The folder tree cannot tell you what must be retained. That is answerable only from a disposition authority. The GRS is one such authority, and NARA states that its disposition instructions are to be implemented without further approval from NARA, with the exception that most records created before January 1, 1921, must first be offered to NARA for appraisal (NARA GRS Introduction). That is a specific, dated rule. A folder name is not a rule.
The folder tree also cannot tell you what a standard requires. ISO 25964 is the international standard for thesauri, published in two parts: Part 1 on thesauri for information retrieval (August 2011) and Part 2 on interoperability with other vocabularies (March 2013) (ISO 25964 overview). The SKOS home page records an announcement of alignment between SKOS and ISO 25964, noting that ISO 25964-1 replaced ISO 2788 and ISO 5964, and that a correspondence document between the ISO 25964 data model and SKOS, SKOS-XL, and MADS/RDF was developed (W3C SKOS home). None of that prescribes a folder-naming convention. The standards describe how to build and map vocabularies; they do not describe how to name a folder.
Where the folder tree is supposed to feed a data catalog, DCAT is the relevant vocabulary. DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web, enabling a publisher to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs (W3C DCAT 3). The same specification notes that aggregated DCAT metadata can serve as a manifest file as part of the digital preservation process. That is a useful framing for the folder-path inventory: it is a manifest, not a taxonomy.
Frequently asked questions
Is the folder tree a taxonomy? No. It is an informal hierarchy that functions as one in practice. SKOS describes concepts as being organized into informal hierarchies and association networks (W3C SKOS Reference). The word informal is the operative one. Treating the tree as a formal taxonomy overstates what it is and understates what it can tell you.
Do I need to adopt SKOS to do this analysis? No. SKOS provides a vocabulary for describing what you find. The analysis itself is an export and a sample read. The vocabulary is useful because it gives you precise terms — preferred label, alternate label, hidden label, notation, mapping — for distinctions you are already making informally.
Can I use the folder tree to determine retention? No. Retention is determined by a disposition authority. NARA states that the GRS covers records documenting administrative or support functions and typically does not cover records documenting the mission of an agency, and that use of the GRS is mandatory unless an agency can justify the use of an agency-specific schedule (NARA GRS). A folder name is not a disposition authority.
What if the folder tree is supposed to map to a records schedule? Verify the mapping exists and is current. Do not infer it from naming similarity. NARA’s Records Control Schedules page notes that its process for determining which schedules are currently valid is an ongoing work in progress, and advises verifying that you are using the most recent and current disposition authority before implementing disposition (NARA Records Control Schedules).
How much sampling is enough? There is no universal number. The purpose of sampling is to distinguish alternate labels from genuinely distinct concepts, and to find folders whose names no longer match their contents. A small sample per folder — enough to see what kind of content is there — is usually sufficient for a first pass. The sample size should be recorded in the label-coverage report so that the basis for each assessment is visible.
What if I cannot export the folder paths? Then the analysis cannot proceed in this form. The method depends on having the list in hand. A UI walkthrough produces impressions, not an inventory.
Is this a governance project? No. It is a diagnostic pass that produces two exportable artifacts and a lightweight, reversible fix. If it grows into a governance project, that should be a separate decision with its own justification.
Closing note
The folder tree is evidence. It is evidence about how the organization actually classifies its work, and it is the classification scheme most people use. Reading it carefully — with the vocabulary of controlled-vocabulary practice, against an exportable artifact, and with a clear boundary between findability and retention — is a small, reversible, and useful thing to do. The alternative is to keep asking the folder tree to answer questions it was never designed to answer, and to keep being surprised when it does not.
