Three Tags, One Idea: Pick One, Keep All Three

When one idea carries three tags, the fix is not to delete two of them. Choose one as the tag you assign from now on, then record the other two in a plain-text file as pointers to it. The choice is the small step. The record is what makes the choice safe.

That is not a preference. It is the mechanism specified by ANSI/NISO Z39.19-2005 (R2010) — an American National Standard, approved on July 25, 2005 and reaffirmed on May 13, 2010. Twenty named people wrote it, drawn from the Library of Congress, the National Library of Medicine, OCLC, the Getty Research Institute and ProQuest¹.

The standard states the fix in two consecutive sentences. The first: "A controlled vocabulary must compensate for the problems caused by synonymy by ensuring that each concept is represented by a single preferred term." The second: "The vocabulary should list the other synonyms and variants as non-preferred terms with USE references to the preferred term"².

Most tag-cleanup advice stops after the first sentence. In 1987 four researchers measured what happens when you do — and their number is the reason the second sentence is the load-bearing one.

The single habit: pick one tag, keep every other name

The habit has two halves and they ship together. Pick one tag as the label you assign to a concept — the preferred term. Then write every other name you have used for that concept into one file, each pointing at the preferred term. Assign one. Keep all three findable.

Z39.19 gives both halves a name, and the names are worth borrowing because they are precise. A preferred term is "One of two or more synonyms or lexical variants selected as a term for inclusion in a controlled vocabulary"³. Its rejected siblings are entry terms — "The non-preferred term in a cross reference that leads to a term in a controlled vocabulary." The standard adds the notation: "the relationship indicator for this type of term is U (USE); its reciprocal is UF (USED FOR)"⁴.

So #mtg does not get deleted. It gets a job. It becomes the line that says: whoever typed this meant #meeting-notes.

Three tags, one idea: pick one, keep all three. The picking takes ten seconds — the keeping is the part that pays.

The same rule exists in machine-readable form — a useful second opinion. The W3C's SKOS Simple Knowledge Organization System Reference is a Recommendation of 18 August 2009, edited by Alistair Miles and Sean Bechhofer. Its integrity condition S14 reads: "A resource has no more than one value of skos:prefLabel per language tag"⁵.

The specification then ships a worked counter-example — this post's problem, in four tokens. A concept given both skos:prefLabel "love"@en and skos:prefLabel "adoration"@en is "not consistent with the SKOS data model, because two different preferred lexical labels have been given with the same language tag"⁶.

One label, assigned. Every alternative, recorded. Two different standards bodies, two decades apart, same shape.

Why "pick one and delete the rest" is the documented failure mode

Deleting the losing names throws away the half that carries the retrieval. Furnas, Landauer, Gomez and Dumais measured spontaneous word choice across five domains in 1987 and found that access through one chosen word fails most of the time. Their optimal strategy was not a better single word. It was keeping many of them.

The paper is The Vocabulary Problem in Human-System Communication, published in Communications of the ACM, Volume 30, Issue 11, pages 964–971, on 1 November 1987⁷. Its abstract reports the measurement plainly: "We studied spontaneous word choice for objects in five application-related domains, and found the variability to be surprisingly large. In every case two people favored the same term with probability <0.20"⁷.

Then the consequence, in the authors' own words: "the popular approach in which access is via one designer's favorite single word will result in 80-90 percent failure rates in many common situations"⁸.

And then the fix, which is the opposite of a purge: "An optimal strategy, unlimited aliasing, is derived and shown to be capable of several-fold improvements"⁹.

Read the scope honestly, because it matters. Furnas and colleagues studied people naming objects and commands in application domains — not one person naming their own notes across six years. The transfer is an argument, not a measurement.

But the direction of that argument is hard to escape. If two people agree on a word less than one time in five, the odds that you at 2020 and you at 2026 reached for the same word are not obviously better. Your past self is — for retrieval purposes — a different person.

That is the whole case for the second sentence. A single preferred term is how you stop the sprawl. The recorded variants are how you still find the thing when the word you reach for is the one you retired.

Count your own variants before you change anything

No published number tells you what fraction of a vault's tags are variants of one another. Yours is the only honest figure, and one command gets it. List every tag by frequency, read the list from the top, and mark the pairs that mean the same thing. Count the pairs. That number is your brief.

The standard describes vocabulary control as three separate jobs: "defining the scope, or meaning, of terms; using the equivalence relationship to link synonymous and nearly synonymous terms; and distinguishing among homographs"¹⁰. The census is how you find out which of the three you actually have. A list of names is a hypothesis; a list of names with counts beside them is evidence.

Run this in your notes folder. It lists every inline hashtag by how often it appears:

grep -rhoE '(^|[[:space:]])#[A-Za-z0-9][A-Za-z0-9/_-]*' . \
  | tr -d ' \t' | sort | uniq -c | sort -rn

If your tags live in YAML frontmatter instead, this reads only the tags: field of every file's frontmatter — inline [a, b] lists and indented - a lists both — and counts what it finds there:

find . -name '*.md' -exec awk '
  FNR==1 && /^---$/            {fm=1; next}
  fm && /^---$/                {fm=0; t=0; next}
  fm && /^tags:/               {t=1; sub(/^tags:/,""); print; next}
  fm && t && /^[[:space:]]*-/  {print; next}
  fm && /^[^[:space:]]/        {t=0}
' {} \; | grep -oE '[A-Za-z0-9][A-Za-z0-9/_-]*' | sort | uniq -c | sort -rn

Variants cluster where you cannot see them, so it helps to have the list find its own collisions. This one strips a trailing s from every tag and prints only the stems that now appear twice — the singular/plural pairs:

grep -rhoE '(^|[[:space:]])#[A-Za-z0-9][A-Za-z0-9/_-]*' . \
  | tr -d ' \t#' | sort -u | sed 's/s$//' | sort | uniq -d

All three are plain shell. No plugin, no import, nothing written to your files. If you prefer rg, mind the flags — rg is already recursive, and its short -E means encoding, not extended-regex. Write rg --no-filename --only-matching '…' . where the commands above say grep -rhoE '…' .; the output has the same shape.

Write down the count — it is the only number in this post that is about you.

The five-minute version

Five minutes buys the decision and the record — not the rename. Run the census, take the top thirty tags, and find the clusters where two or more names carry one idea. For each cluster, write one line naming the winner and listing the losers. Stop there. Change nothing in your notes yet.

1. Run the census. One command, thirty seconds, no writes.
2. Read the top thirty. Frequency ordering puts the real workhorses first and the accidents right below them.
3. Circle the clusters. #meeting-notes / #meetings / #mtg is a cluster. #read / #reading / #to-read is probably two clusters — reading you did and reading you intend, which is a distinction worth keeping.
4. Pick the preferred term per cluster. The standard's definition is permissive: a preferred term is any one of the synonyms or lexical variants you select for inclusion³, and the standard stops short of telling you which. The tie-break that ages best: choose the one you would type, not the one that is prettiest. You are optimizing for the hand, not the eye.
5. Write one line per cluster into a new file. Preferred term first, then every other name after it. That file is now the thing you grep when you cannot remember which one you settled on.

Notice what step five is not. It is not a rename, not a mass edit, not a plugin run. Nothing about your notes has changed, which means nothing about this is irreversible.

The thirty-minute version: one file called vocabulary.md

Thirty minutes turns five lines into a file with four fields per entry, each one lifted from the standard's glossary. Preferred term, its used-for variants, a scope note that says what the term covers, and — if you nest tags — a node label saying what axis the group divides on. Four definitions, four fields, one file.

Here is the whole artifact. Copy it, replace the terms with yours:

# vocabulary.md — the tags I assign, and every other name I have used for them

## [by activity]
NL  Node label. The tags in this group divide notes by what I was DOING,
    not by subject. A note can also carry a subject tag from the group below.

#meeting-notes   UF  #meetings · #mtg · #standup · #call-notes
    SN  A note taken during or right after a scheduled conversation with
        another person. Solo thinking sessions are #planning, not this.

#reading         UF  #read · #article-notes · #book-notes
    SN  Something I read that I did not write: books, papers, long articles.
        Notes on my own drafts are #writing. Things I intend to read but
        have not are #to-read — that is a queue, not an activity.

## [by subject]
NL  Node label. These divide the same notes by what they are ABOUT.

#typography      UF  #type · #fonts · #typesetting
    SN  Letterforms, spacing, and the craft of setting text. Page layout
        and colour are #design.

The fields are not decoration. Each one catches a specific failure.

UF (used for) is the retrieval half. Z39.19 defines the equivalence relationship as one "that leads to one or more terms that are to be used instead of the term from which the cross-reference is made"¹¹. Written on the same line as the preferred term, it means a search for mtg returns the line that answers and names the winner. That single-line layout is a deliberate choice — a nested list would hide the answer one line above the match.

SN (scope note) is the boundary half. The standard defines it as "A note following a term explaining its coverage, specialized usage, or rules for assigning it"¹². It settles the argument you will have with yourself in four months. A cluster without a scope note splits back apart — nothing recorded where its edge was.

NL (node label) is the honesty half. A node label is a dummy term that "is not assigned to documents when indexing, but which is inserted into the hierarchical section of some controlled vocabularies to indicate the logical basis on which a class has been divided"¹³. You never assign it. It is there to make you notice a mixed axis — some notes tagged by activity, others by subject.

The standard is explicit that this machinery aims at recall, listing "Preferred terms and equivalence relationships for synonym control" first among the methods by which "Recall can be improved"¹⁴. Borrow the mechanism — do not claim the outcome.

Z39.19 was written for indexing teams building institutional vocabularies, and a personal notes folder is not one of those. Nothing published measures what this does for a personal vault. What it demonstrably does is make your own past decisions legible to you.

Only now is the rename safe. With the variants on record, retiring #mtg across your notes loses nothing you need to remember — the name still exists in vocabulary.md, pointing at where it went. The file does not record which notes carried it, so the rename itself is one-way: check it before you run it. The mechanics of that edit are a separate job with their own hazards, covered in Find and Replace Across All Your Markdown Notes. Decide here; execute there.

Indexing time is not retrieval time

Two things that look contradictory are actually two different jobs. Writing synonyms into the body of a note helps you find it later. Choosing one tag per concept governs what you assign when you file it. Z39.19 draws the line itself, and once you see it the tension disappears.

The standard names the retrieval-side device a synonym ring: "a set of terms that are considered equivalent for the purposes of retrieval." And it is unambiguous about where the device does not apply — "Synonym rings cannot be used during the indexing process. Rather, they are used only during retrieval"¹⁵.

That is precisely the practice described in Don't Build a RAG Over Your Vault. Grep It., which argues that writing vacation and PTO into the source is a one-line write that pays out forever, and in Shape the Note Before You Send It, which adds the parenthetical next to the first occurrence so a regex catches both. Both are retrieval-time moves on note bodies. Keep doing them.

A tag is different. A tag is a label you choose and attach — an indexing act, one slot, one decision. There is nowhere for a ring to live inside #mtg. So the ring moves out of the tag and into vocabulary.md, where it can hold as many aliases as you like without forcing your future self to guess which one you used.

Write synonyms in your notes. Assign one tag. The file holds the ring.

Common mistakes

Four failures show up again and again in abandoned tag cleanups, and two of them are ordering errors rather than errors of judgment. The costliest is building the vocabulary before running the census — designing a taxonomy you then have to enforce, instead of recording the equivalences you already created by accident.

• Building it up front. A career librarian on Hacker News put the case against this better than any argument here could: "I've been a librarian for more than 15 years and I can only speak from personal experience when I say that I am the apex predator of nothing. Every once and a while I will get it in my head to systematize my personal knowledge base with a controlled vocabulary and ontology and I just fall on my face"¹⁶.

  He is right about the thing he is describing — and the method here is its inverse. You are not designing an ontology; you are transcribing collisions you already made by accident. If a cluster is not already in your census, it does not go in the file.

• Renaming before recording. This is the one that actively makes things worse. An Obsidian forum user described the sequence exactly: "I found many tags that were either unnecessary or had very few hits. Although there were many I found it easy, using Tag Wrangler, to rid my documents of these tags by simply renaming them to an existing meaningful tag. Unfortunately, in so doing I created another situation. I now have many documents with duplicate tags"¹⁷.

  The post goes on: "That is the same tag written twice"¹⁷. The rename erased the old names from every note and doubled the winner wherever a note already had it — so the cleanup left a second cleanup behind, and with no record kept, nothing anywhere says which names were retired or where they went.

• Picking the prettiest name. #correspondence loses to #email every time — the tag you actually type at 11pm is the tag that gets assigned. Optimize the preferred term for typing speed, not for how it looks in a graph view.

• Skipping the scope note. A cluster with no recorded boundary comes apart again within a season. Thirty seconds of writing stops the same merge decision from being litigated four times.

One more limit, stated plainly: Furnas and colleagues' optimal strategy was unlimited aliasing, which is closer to "keep every name" than to "pick a winner." This method picks a winner only because a tag field forces a single choice at assignment time. If nothing forced that choice, the honest answer would be to keep them all.

How this works in MNMNOTE

vocabulary.md is a Markdown file, which means it belongs in the same folder as the notes it governs. Nothing about it is app-specific — no plugin reads it, no index consumes it, and the only tool required is whatever you already use to search text. It is a note about your notes.

MNMNOTE keeps notes as plain Markdown on your own device and works offline, so the vocabulary file and the notes it governs are the same kind of object: text in a folder you can point a command at. The census commands above run against that folder unchanged.

There is a sibling habit worth pairing this with. Keep a Glossary File Your AI Can Read describes the same one-file discipline pointed at a different target — a glossary tells a model what your terms mean; vocabulary.md tells you which of your terms wins. Definition on one side, equivalence on the other. They sit well in the same folder.

And if your problem is too many tag axes rather than too many names for one idea, that is a different fix entirely — a budget on how many dimensions you are allowed to invent, not a merge of two names that already collided.

Frequently asked questions

Short answers to the questions people actually type when three tags turn out to mean one thing. The through-line in most of them is order — measure, then record, then rename. Run those three steps out of sequence and the cleanup creates work instead of removing it; run them in sequence and every decision stays on record.

What do I do when I have two tags for the same thing? Pick one as the tag you will assign from now on, and record the other on the same line as a used-for variant. Do not delete the second name — it is the pointer that finds the notes you filed before you decided. Rename the old tag only after the record exists.

How do I clean up duplicate tags? Census first, record second, rename last. List every tag by frequency, mark the clusters that mean one thing, write one line per cluster naming the winner and its variants, and only then edit your notes. Reversing that order erases the old names before anything records them, so nothing remembers which names were retired or where they went.

Is there a de facto tag naming convention? No standard governs personal tags, and the request for one is old. The most-viewed thread on the subject in the Obsidian forum — a request to rename and delete tags in bulk — had drawn 46,628 views and 190 posts as of September 2026, having opened on 27 May 2020 and still taken a new reply in April 2026¹⁸. Absent a convention, write your own down.

Should I use singular or plural tags? Pick either and record the other. The choice matters far less than the record — #book versus #books is a coin flip that costs nothing until both exist and neither is documented. The near-miss command above exists specifically to surface pairs you created without noticing.

Do I need a plugin to do this? No. The census is grep, sort and uniq; the vocabulary is one Markdown file you write by hand. A bulk-rename tool is useful for the final step, but it is the last step and the smallest one — and running it before the record exists is the single most common way this goes wrong.

Doesn't this contradict writing synonyms into the note itself? No, and Z39.19 draws the line explicitly: a synonym ring works only during retrieval, never during indexing¹⁵. Synonyms in the body are a retrieval-time aid and remain good practice. Choosing one tag is an indexing-time commitment, because a tag is a label you assign rather than a word you happened to type.

What is a controlled vocabulary? In the standard's terms, it is a list in which "each concept is represented by a single preferred term," with the other synonyms and variants listed as non-preferred terms pointing at it². Your vocabulary.md borrows that mechanism. It is not a controlled vocabulary in the institutional sense, and it does not need to be.

The tag you assign is a decision. The names you keep are the insurance on it — and a decision without insurance is the one you reverse at 11pm, badly, six months from now.

MNMNOTE keeps notes as plain Markdown files on your own device, which means vocabulary.md lives in the same folder as everything it governs — mnmnote.com.