Wiki Gardening Rules

I put together the organizing rules I apply while organizing notes in Obsidian. A wiki is like a garden, so what matters is not perfect design but steady maintenance.

The wiki’s current state

This is what the state of this wiki looked like when captured on July 18, 2025. Each dot is a single document, and links between documents are represented as lines connecting the dots. Red dots indicate dates, and blue dots indicate books or papers, and so on. Following the principles explained below, I use neither folders nor tags, and manage information solely through links.

I do not use folders

Folder structures have the problem of distorting or fragmenting information by forcing mutually exclusive classification based on a single perspective. For example, a book on “computational biology” feels wrong if you put it under the “biology” category, and also feels wrong if you put it under the “computer science” category. See also: The Tyranny of the Dominant Decomposition, It Is Not a Tree.

If you make folders by topic and isolate information, there is also the side effect of reducing the chance of accidentally discovering connections between different topics.

If you really need to organize certain information in a tree structure, you can just make a document and organize the links within that document in a tree structure (e.g. Things I’ve Written). If you use this method, you can naturally achieve separation of multidimensional concerns and minimize the side effects of folders.

For these reasons, I currently do not use folders in this wiki. However, when necessary, I assign each document a type using Obsidian’s properties feature. The names of the properties follow the type names of schema.org. For example, a person is Person, a book is Book, a paper is ScholarlyArticle, and so on.

Folders are not only inappropriate for use in a knowledge management system, but also tend to make the problem more complicated. You end up devising methods like attaching numbers in front in order to arrange things in the order you want (001, 002, …), or imitating the Dewey Decimal Classification while inheriting its disadvantages intact, and then knowledge management is obstructed by having to solve not inherent complexity but manufactured complexity (self-inflicted complexity; you asked for this) instead.

I do not use tags

Tags, or folksonomy are better than folders in that they do not force exclusive membership, but as the amount of material being managed increases, the advantages of tags steadily diminish. That is because the advantages of tags only come into play if the following two conditions hold.

• There must not be too many tags: if there are too many tags, management cost increases and the memory burden grows when assigning tags or searching by tag.
• There must not be too much material under a single tag: if the results returned by searching a particular tag are too numerous, the usefulness of the search drops. This is especially true because it is hard to rank the results (to prioritize which materials are important).

But as materials increase, those two conditions necessarily conflict. In order for there not to be too much material under a single tag, the number of tags must increase linearly as the amount of material increases. But if tags increase linearly, then there become too many tags. Therefore, once there is a lot of material, those two conditions cannot both be satisfied at the same time.

The reason tags feel tidy and useful when you first introduce them is usually just that there is not much material yet, and once material accumulates to a certain extent, their usefulness drops sharply. But even after that usefulness has declined, people often fail to notice for quite a long time and keep tagging out of habit. Because when they first started, it really was useful.

Applying faceted classification to tags can improve some of these problems, but it makes management and use more complicated. Besides, everything you can do with tags you can also do with links. In this wiki, instead of using Obsidian’s tag feature, I use wiki tags.

I use links aggressively

If you use neither folders nor tags, then how do you classify information?

You use links. One of the fundamental differences between links and folders is that folders are a tree structure whereas links are a graph structure. A tree is a kind of graph, but it has major constraints (“every node except the root has exactly one parent”), and the problems that come from this constraint are enormous. (See: It Is Not a Tree)

Some rules for using links:

• Eliminate orphans: a document with no links at all to other documents (including backlinks) is called an orphan. If you structure only through links, orphan documents cannot be reached by any means other than search, so there must not be any orphans. The best method is: when creating a new page, first go somewhere in an existing page and add a link to it before you begin.
• Preserve context: rather than gathering only “related links” separately, I preserve the context of links by placing them as naturally as possible within the body text. If they are collected under “related links” without context, it is not good because you then have to explain separately in what sense they are related.
• Allow “See also” only exceptionally: if it is hard to place a link within context, I temporarily put it in a “See also” section. It is good to manage things steadily so links do not pile up too much in that section. Gradually, the body text should be revised appropriately so they can be moved into the main text.
• Link to nonexistent documents: in most wiki engines, you can create links in advance to documents that have not been created yet, and it is good to use this feature actively.
• Link major entities: always add links to people’s names, place names, dates, and book titles.

Consistently adding links requires ongoing effort, but this is closer to an advantage than a disadvantage. That is because the conscious effort involved in finding existing knowledge that connects to newly acquired knowledge helps bring memories back up and encourages knowledge to become interconnected in my head.

You could probably use things like LLMs or embedding models to add links automatically, but this kind of overautomation is not good. You can lose the value embedded in the process.

I give things good names

For documents to be richly interlinked, and for those links to fit naturally within the context of writing, it is important to give documents good names. Similar to naming variables or functions when doing programming, it is best if they are sufficiently specific while also being as concise as possible.

To name things well, it is better if each document contains, as much as possible, a single piece of content. If it is hard to give something a good name, it is better to split the document into appropriately sized units.

This way of linking by means of names is one of the most essential characteristics of a wiki. Thanks to that, it becomes possible to create links in advance to documents that have not yet been made.

It is also good to make good use of Obsidian’s alias feature.

Retrieval matters more than recording

The goal should be retrieval, not recording itself.

Depending on the person, some may prefer the reassuring feeling that “everything has been preserved,” but I value active retrieval more than preservation. From this perspective, having a lot of information that has been recorded but is not being retrieved is a bad sign.

It should be usable as externalized belief

A personal wiki should not merely be a lump of information. If what you need is a vast lump of information, it is better to use Wikipedia. A personal wiki should be externalized belief. The reason some piece of information is in my wiki should be that I consciously reviewed it and decided to include it.

For example, I should not take content generated by an LLM, copy-paste it in, and store it without close review. When I do include generated content, I always attach the GeneratedContentWarning wiki tag.

I eliminate duplication

I do not write the same content repeatedly here and there. It is bad for the same reasons as code duplication:

• Whenever you fix copy 1, you always have to fix copy 2 as well, so duplication of content leads to duplication of action.
• You can make mistakes like fixing only copy 1 and not fixing copy 2, which can reduce consistency.
• Links pointing to copy 1 and links pointing to copy 2 become dispersed. (This is similar to how code duplication disperses hotspots and interferes with performance optimization.)

I improve it gradually and consistently

A strategy of designing a perfect structure from the beginning and only then starting to gather information does not work well (see: perfect as a verb). Likewise, doing a huge “design change” all at once once a year like some annual event is also not good.

The design of an information structure should be done steadily and incrementally. For example:

• Add links to documents that were hard to find: if a certain document was hard to find and I finally managed to locate it after struggling, then instead of just reading it and stopping there, it is good to add links connecting it with relevant related documents so it will be easy to find next time. Not making it perfectly organized all at once, but tending it continuously.
• Split long documents: if it often happens that I want to refer to only part of a document’s contents, then I split out just that part and make it into a separate document.

It is like refactoring in programming. Do it steadily and incrementally. Do not try to do it perfectly all at once. Do not let it pile up for a long time and then do it in a batch.

Quantify it

It is good to set quantitative goals and improve things gradually.

Goals I have set now:

• Lower the graph’s diameter. The diameter of a graph means the distance between the two farthest nodes. The diameter was 10 as of January 2026, and the average shortest path is 4.79 as of September 5, 2026.

Examples of quantitative goals:

• At first, the goal was to reduce orphan documents. Managing things so every document would be connected somewhere.
• After orphan documents completely disappeared, the goal was to reduce disconnected graph clusters. That is, there were no unconnected individual documents, but there were several clusters in a state where not every document was connected to every other document, and the goal was to completely merge them into one big cluster.
• After disconnected graphs disappeared completely, the current goal has been to reduce the length of the shortest path connecting any two arbitrary documents. (Current situation)

Make and improve rules about the rules

Think not only about the organized result but also about the value embedded in the process of organizing. Be wary of overautomation and use LLMs in ways that augment the value embedded in the process:

• In the direction of giving hints about what is a mess and how, and helping me improve it gradually (so that in that process my own thoughts become better organized too).
• For example: finding duplicated content across different documents, or suggesting to me links for documents whose meanings are similar but are not linked (instead of doing the linking automatically).

The rules, too, are improved steadily and incrementally.

TODO

• A way to periodically review the document that has gone the longest without being modified
• Find a good way to manage quotations (it would be nice if it were compatible with Bases, but that is not very important. Compatibility is good, but dependency is bad)
• It would be nice if something similar to Semantic Link could be supported