Textmind permits mapping of the whole text-expressible contents of one's mind. This is not possible, for example, with a wiki. A wiki is limited by its flat namespace. Every article has a human-readable name, and no name is the child of another name. Thus the depth of detail about a name is limited by the practical limits of a single-page outline.
Attempts to circumvent this limit typically use concatenated article names, such as "tech->apple" and "fruit->apple". This is awkward and scales poorly.
By contrast, Textmind uses an infinitely-deep meta-outline composed of the directory tree and outlines within files. The same file name has different meanings depending on its path.
Much contextual meaning is determined by the top-level directories of the Textmind template. For example,
7-Background/Education/Motivation/ is about motivating students, whereas
3-Names/2-Flat/1-Me/Motivation is about what motivates me specifically.
Even disambiguating highly-specific words such as people's names becomes a thorny problem when trying to use a wiki as a comprehensive knowledge manager. Textmind easily supports multiple directories about the same person in different contexts, whereas a wiki cannot.
Wikis are suitable when uniform shallowness is desired. For example, Wikipedia is an encyclopedia of general knowledge. Encyclopedias cover the breadth of subject by observing a strict depth cutoff. They call this cutoff "noteworthiness".
Many PIMs use database backends. This is reasonable for genuinely relational data, such as a time series of one's weight, for example. However, the vast majority of one's personal information is not structured data, but freeform prose. Therefore the overhead of a database isn't justified for one's primary PIM.
Databases are harder to version control than plain text files. They are more fragile and less future proof. A huge ecosystem of tools is compatible with plain text files. It is the computing standard.
Much has been written about why plain text is the correct foundation of a PIM system.
Tags are a part of Textmind, via Org mode. The Org agenda runs on tags. However, Textmind relies on the meta-outline, not tags, for knowledge management.
Why? Because tags are inherently messy. It's difficult to keep tag nomenclature consistent as one's exomind evolves. It's difficult to keep tags applied to the correct atoms. There's no good starting or stopping place for tag maintenance. They're fire-and-forget.
GTD is a workable system for tag maintenance, because its scope is limited to the executive. Even then, tag management should focus on the immediate horizon, leaving long-range planning to datestamps, tickler directories, and freeform prose.
Similar limited uses for tags can work, e.g. tagging headings with people's names. However, one can't be sure to do this perfectly every time. And even if one could, unexpected changes would still result in missing tags.
Unlike tags, an outline can handle unlimited information. In Textmind:
Each heading goes in only one place, where it fits best. (If another location needs to refer to it, use a link.)
The current task gives a clear starting and stopping point for sorting the tree
Info can usually be found manually by navigating the tree
Important interstitial info tends to propagate redundantly
Once an exomind stores hundreds of megabytes, a tagger could find himself doing nothing but managing tags all day. By contrast, Textmind's outline usually costs no more maintenance than is productive for personal review.
Sometimes a major conceptual shift requires reorganization of a section of the Textmind outline. This is a good opportunity to remove lots of obsolete info that has been shoved down out of sight. In the process, one will likely come across provocative forgotten fragments.
When one is full of clarity and motivation, the meta-outline is a silently helpful filing cabinet. When one is filled with doubt, the outline is a trove of one's every inspiration, awaiting recombination. Even when one is exhausted, the outline offers insight on demand, in exchange for mostly mechanical labor.
Search-based knowledge management fails to scale, no matter how powerful the search engine, due to absence of strong Artificial Intelligence.
Emacs offers many search tools. I grep often. Tree and search synergize.
I'm able to search effectively at a 1/3 gb scale due to my Textmind's deeply-nested directory structure. I can intelligently narrow search scope by path before grepping. Machine intelligence works best when augmented by human, and vice versa.
I adjust search scope easily by "stepping" up and down the directory hierarchy in Dired.