Why hierarchy > tags for PKM

Tags can't compete with deep hierarchy for PKM, due to the unmaintainability of the former. The Textmind algorithm causes constant hierarchical evolution to meet one's changing needs. Achieving the same effect with tags is impossible without causing a giant mess. And without continual schema adjustment, detailed quality thought simply isn't possible. Rectification of names is fundamental to thought.

To understand how bad tags are for refactoring, consider a bit of my Textmind's hierarchy selected at random:


How do I express the above with tags? The intersection of Emacs and Linux includes a huge range of topics, but the subject of Emacs->Linux is much narrower. Hierarchy is what narrows it. It means something different than Linux->Emacs.

The above path actually expresses a pretty simple concept. Converting it into tags would only take a few: reference, tech, Emacs, Linux. Some info is lost due to flatness, but it's not too bad. That's because this category is general knowledge; it's nothing personal or specific to me.

Even here, one can see potential problems. Will I remember to include "reference" and "tech" on each note? Otherwise I can't exclude unwanted info about license, personnel, etc. What if I sometimes use "ref" instead of "reference"? What if "ref" sometimes also means "referee"?

In a hierarchy, every item is in one place. If it's misfiled, it can be found and moved, and then the problem is fixed. But with tags, one never knows what's broken or fixed. Items belong to many tags, and it's unclear when some are missing or wrong.

Therefore tags should be sparse, stable, precious and non-critical. If some of these adjectives are weak, the others should be strong to compensate. For example, org-mode uses GTD tags successfully, even though executive function is critical, because GTD tags are very sparse, stable and precious.

Publish At: Author:Cyberthal

Read more posts by this author

comments powered by Disqus