This idea came from using Obsidian. Some of it may carry over to other note-taking tools, but I am assuming features specific to Obsidian: aliases, unlinked mentions, and custom link text that fits the surrounding sentence.

For a while, I treated tags as the default tool for organizing notes. I added #nodejs to articles about Node.js and #kubernetes to articles about Kubernetes. Tags were short, visible, and convenient: clicking one gathered related notes immediately.

As my vault grew, however, so did the number of questions that tags could not answer.

  • What exactly does this tag mean?
  • Why did I apply it to this note?
  • How is it related to another idea?

Tags are good at gathering notes, but they do not explain why those notes belong together. Now, before I add a tag, I first ask whether a wikilink can express what I mean.

Another post on this blog Properties and Tags: Two Layers of Note InformationThe rules I use in Obsidian to keep Properties as minimal machine-readable structure and tags as cross-cutting topics. #pkm

A tag has nowhere to hold an explanation

Clicking #kubernetes gathers my Kubernetes-related notes. The tag itself, though, cannot explain what I mean by Kubernetes or how I define it.

A wikilink is different. I can create a note called [[kubernetes]] and keep revising its definition and criteria.

# Kubernetes

Kubernetes is an open-source container orchestration system.

- [[pod|Pod]] is the smallest deployable unit that can contain one or more containers.
- [[node|Node]] is the physical or virtual worker machine where [[pod|Pod]] runs.

Kubernetes is no longer just a label that opens a list. It becomes a note I can keep revising. Other notes can point to [[kubernetes]] and follow its definition, while backlinks show the contexts in which I have used the idea.

More tags create more choices

Ten tags rarely cause trouble. With a hundred, I have to remember the existing vocabulary every time I write a note. Did I use #infrastructure or #kubernetes, #observable or #observability, or #monitoring? Retrieval has the same problem: I have to check several similar tags.

This is not a flaw unique to tags. If I turn every word into a wikilink, the same disorder returns in another form. Replacing a hundred tags with a hundred empty notes does not make the system simpler.

The useful difference is that a linked note can accumulate content. I create one only for an idea I expect to explain repeatedly, call by several names, or use as a reference point for other thoughts. If a term is not worth that much attention, I may need neither a link nor a tag.

I need relationships, not only hierarchies

Obsidian supports hierarchical tags such as #infrastructure/kubernetes, so saying that tags cannot connect at all would be inaccurate. Nested tags can express a parent-child classification. The relationships I want to preserve are often more varied than that.

When I use [[kubernetes|Kubernetes]], I first need to think about how to approach [[infra|infrastructure]].

A [[pod|Pod]] is smaller than a [[node|Node]] and runs on it, so resource allocation matters.

The first sentence expresses a condition and a priority. The second sentence distinguishes the two concepts. A hierarchy such as #infrastructure/kubernetes cannot preserve either relationship naturally. A wikilink does not explain the relationship by itself, but it gives the surrounding sentence a place to do so.

One subject can have several names

The same idea can have different names across contexts or languages. If I create separate tags for kubernetes, k8s, and 쿠버네티스, I split one subject into three paths.

In Obsidian, I can add those names as aliases to one canonical note.

---
aliases:
  - k8s
  - 쿠버네티스
  - 쿠버
---

When I select the alias 쿠버, Obsidian creates a link such as [[kubernetes|쿠버]], which still points to the same note. The Unlinked mentions section in Backlinks can also find occurrences of a note name and its aliases. I can discover places where I already wrote “kubernetes” and convert only the meaningful ones into links. In other words, even if I forget to add a link, I can still discover the relationship later.

If I need different wording in only one sentence, I do not need another alias.

I have started reconsidering [[kubernetes|how to orchestrate containers with an open-source system]].

The destination remains kubernetes, while the sentence reads naturally in its local context.

Sometimes a tag is still the simpler tool

At this point, removing tags altogether can sound tempting. In practice, that has not worked for me.

Tags remain a simple way to gather and filter notes under the same topic. If I want one view of security notes across software development, investing, and daily life, a tag is convenient. Creating a nearly empty [[Security]] note and linking every relevant file merely to reproduce that filter would be a detour.

My current rule is:

  • Use a wikilink for a concept or subject that deserves its own explanation, especially a proper name.
  • Use a wikilink when I can state the relationship between two thoughts in a sentence.
  • Use a tag only when I repeatedly filter for the same topic across different contexts.
  • Use neither when I have no concrete reason to retrieve it again.

For me, then, a wikilink is not a complete replacement for tags. It is the default I consider first. A tag makes a list; a wikilink creates a place for explanation and a path for relationships. When I return to a note, I need more than a list of similar things. I need enough context to understand why I connected them.