I’ve half-heartedly used tags in markdown tools for years, most notably in Typora and Obsidian. However, my dislike for them has hardened in recent months, and I am transitioning to using links, instead.
What’s Wrong With Tags
Tags are a form of annotation, created by affixing a hash (‘#’) to a series of characters. So, for example, I might write — or copy and paste — a block of text like this:
A study published in *Environmental Science and Technology*, a journal, suggests that a five-day heatwave in Phoenix, with a blackout, could kill more than 13,000 people and send more than half of the city’s residents to hospital.
This is Phoenix’s worst-case scenario. But heatwaves do not not need to cause catastrophic power loss to threaten people’s lives. The urban heat-island effect means that city centres can be much hotter than surrounding areas because roads and buildings absorb and trap heat.
Imagine I would like to be able to find this fragment of text in the future because of its definition of the ‘urban heat-island effect’. I could simply search for the string ‘urban heat-island effect’, but in other fragments, the term might be slightly different, like lacking a hyphen, so searching is not the optimal approach.
A tag approach might work, except where do you put the tag? Do you stick it in the fragment? If you do, how do you indicate that it wasn’t in the original text — in this case an Economist article by Aryn Braun — so you aren’t putting annotations in the author’s work? I have often resorted to putting tags at the bottom of the fragment but that moves the tag away from the term, and in this case, away from the definition I wanted to be able to find. Alternatively, I could put it in a footnote near the definition, like this —
A study published in *Environmental Science and Technology*, a journal, suggests that a five-day heatwave in Phoenix, with a blackout, could kill more than 13,000 people and send more than half of the city’s residents to hospital.
This is Phoenix’s worst-case scenario. But heatwaves do not not need to cause catastrophic power loss to threaten people’s lives. The urban heat-island effect^[#urban-heat-island-effect] means that city centres can be much hotter than surrounding areas because roads and buildings absorb and trap heat.
— which at least pins the tag close to the definition (since the footnote is immediately next to the term in edit mode in Obsidian, and in read mode I rely on Tufte-style Sidenotes, so they appear in the right margin). But because tags do not have spaces in them, I had to name the tag something different from the term, which is ‘urban heat-island effect’ in this case. This means I’d have to remember the exact tag at some point in the future: they lack fuzziness.
The Alternative: Links
I have dropped tags for several months and replaced them with links (or WikiLinks, specifically). So, the fragment of text in raw markdown would be replaced with this:
A study published in *Environmental Science and Technology*, a journal, suggests that a five-day heatwave in Phoenix, with a blackout, could kill more than 13,000 people and send more than half of the city’s residents to hospital.
This is Phoenix’s worst-case scenario. But heatwaves do not not need to cause catastrophic power loss to threaten people’s lives. The [[urban heat-island effect]] means that city centres can be much hotter than surrounding areas because roads and buildings absorb and trap heat.
Note that the only change to the author’s words is encircling the term in wiklinks’ brackets. In Obsidian, that references a file that is created the first time the link is clicked, and after that point backlinks are created to all the Obsidian files with such links in them. Note that I can optionally create an alias to exactly match the author’s words, and refer to a more generic filename, for example, ‘heat island effect’:
A study published in *Environmental Science and Technology*, a journal, suggests that a five-day heatwave in Phoenix, with a blackout, could kill more than 13,000 people and send more than half of the city’s residents to hospital.
This is Phoenix’s worst-case scenario. But heatwaves do not not need to cause catastrophic power loss to threaten people’s lives. The [[heat island effect|urban heat-island effect]] means that city centres can be much hotter than surrounding areas because roads and buildings absorb and trap heat.
This leads to a secondary benefit of the link approach: the file that is being referred to automatically serves up backlinks to the various files with the linked term, and I also used the definition from Aryn Braun in the ‘[[heat island effect]’ file.
The list of files with the link is automatically created. I don’t have to create a search query, or use tags-related plugins.
Going a Bit Further: My Knowledge Base
I confess that I have used a simplified version of how I use these links in the example above.
I actually have a more sophisticated approach, which I think of as a knowledge base, where I apply either an asterisk, a plus sign, or a degree symbol as the first character of the knowledge base file names. An asterisk indicates a person file, like
[[@John Maynard Keynes]]
Because of aliases, this could also be rendered like this:
[[@John Maynard Keynes|Keynes]]
A plus sign indicates a concept, like
[[+heat island effect]]
And a degree symbol indicates an organization, like
[[ºApple]]
This allows for distinguishing between ‘[[ºApple]]’ and ‘[[+apple]]’, and in both cases they could be aliased, like ‘[[ºApple|Apple]].
I have set up rules for the Obsidian Auto Note Mover plugin so that files with those three characters in their titles are automatically moved to folders for people, concepts, and organization all located in a top-most folder in my vault called ‘00 knowledge’.
I am greatly helped by the way Obsidian offers up possible matches for links, as in this case:
I find the list of backlinked references in these knowledge files more useful than Obsidian Graph view alone, but I often use them at the same time when navigating around a group of topics, like Holacracy and writings about it:
Looking Ahead
I expect it will take a few months to get a sense of how the knowledge base will grow, and its utility in my work, which is mostly writing. I recently wrote an article for Reworked that included — in an early draft — material from Paul Graham’s Makers Schedule, Managers Schedule, and I came upon Virginia Heffernan’s piece shown in the image immediately above. I instrumented the piece with various knowledge base links. While I did not use anything from her piece in the article I wrote, It’s now wired so that when I search in the future for Slack, Tony Hsieh, or Paul Graham, her article will swim back onto my radar screen.
But, as I said, it will take a few months to know how it works, since I am not going to open all 10,000 notes in my Obsidian Vault and create knowledge base links all at once.
I expect that I will be experimenting with the relationships between concepts, so the ‘[[+macroeconomics]]’ concept file could be linked to ‘[[economics]]’, and vice versa.
I am adding links everyday, as I clip and write, so it’s a little bit at a time.
And I am also replacing — deleting — tags, as I go.
Probably the only useful way to use tags is to replace folders with them, is to use nested tags. #area/productivity, #status/processes
I still put tags in the frontmatter/properties so
I can use Dataview to make a dashboard of certain themes (mostly related to a project) but over years of using Pinboard as my bookmarking tool I’ve realised tags usually end up as a mess of taxonomy. I also still use folders to divide stuff just in case I ever have to look for things in the files or change systems.