Relevance-Level Tagging: A 'Backlinks Plus' Approach to Grouping Relevant Information

What should you do when you come across information that's not relevant to your current writing project but might be relevant in the future?

"Use backlinks!"

That’s the enthusiastic response you might expect from someone new to using one of the many notes apps that feature backlinks, such as Capacities, Logseq, Obsidian, Reflect, Roam, Tana, etc.

However, if someone uses backlinks when doing intellectual work over many months or even just a few weeks, the backlinks sections of their notes eventually become so cluttered that they feel overwhelmed each time they look at them.

It's just a matter of time before they stop looking at the backlinks sections altogether.

Some think the solution to the problem of too many backlinks is to be selective in their use. That way, the number of links in the backlinks section won’t grow too large, right?

But for me, that causes a new problem.

When I am reading a text and want to associate certain information with topics I might write about in the future, I frequently find myself thinking:

“Maybe right now, this material does not strike me as relevant enough to a particular topic, but later I might discover it is. It would be nice to have the material linked to the topic page so that I don't have to go hunting for it elsewhere.”

When I used to have this thought, I would either (a) backlink the material to a topic page but then worry I had just added yet more clutter to the backlinks section of that topic page or (b) not backlink the material but then worry that maybe I should have.

Is there a way to use backlinks without generating clutter and worry?

I believe there is. It's a "backlinks plus" approach—backlinks plus what I call "relevance-level tagging" (RLT).

RLT is a speedy way of using backlinks and queries to present information relevant to a topic, all in a way that sorts the information based on its “relevance level” to the topic. the level of its relevance to the topic.

Note: the app I will talk about the most is Obsidian, but much of what I lay out below could also be done in other apps such as Logseq, Roam, and Tana. They just need to have queries in addition to backlinking.

The "Backlinks-Only" Approach

Let's say you're looking at a page in your Obsidian vault containing your highlights from and notes about a book. You decide you want to keep track of passages related to the right-libertarian understanding of freedom and the social conditions required for people to be free.

Next to the passage, you could type two left square brackets ("[[") followed by the term "libertarian freedom." Click on that newly created link and it becomes a page in your vault. I'll be referring to such a page as a tag page (Bryan Jenks and Curtis McHale use the term "tag notes" for the same thing).

From that point on, whenever you come across material related to your [[libertarian freedom]] tag page, you could type "[[libertarian freedom]]" next to it. Doing this amounts to "tagging" the material as relevant to a certain topic.

The "tagging" I speak of (left, in the image above) should not be confused with what are normally called tags (right).

The link to the tag page—[[libertarian freedom]]—functions like a tag in that it collects links to a topic in a single place. That one place is the backlinks section of the topic page.

The only problem is that the backlinks section sucks.

Problems with the Backlinks Section

As already noted, one problem with the backlinks section is that it can become so cluttered with links that you become averse to looking at it.

Another problem is that even if you could overcome your aversion, you would (in most cases) have to click on the links and scroll through the linked-to pages to find the material relevant to the topic of that tag page. That's because, in Obsidian and plenty of similar apps, backlinks are links to entire pages rather than to just the most relevant parts of those pages, to the blocks containing the tag-page links you've added to them.

The main problem with having to click and then scroll through linked-to pages to find the relevant material is that it amounts to context-switching that can make deep, focused work difficult to maintain.

(Note: you could avoid the bulk of this sort of context switching by using apps like Roam, Logseq, and Tana, the backlinks sections of which contain links to blocks and thus to the most relevant parts of the pages you have tagged with tag pages, but there would still be reason to use RLT to sort those most relevant parts.)

As noted at the beginning of this piece, the solution to the problem of too many backlinks is not to use them very sparingly since doing that can generate anxiety about whether you are tagging too much or too little material. There is a better way.

The "Backlinks Plus" Approach (RLT)

Although there are problems with the backlinks sections in apps like Obsidian, backlinks themselves are useful—provided they are supplemented with relevance-level tags and the right kind of queries.

You can think of the backlinks section of each Obsidian note as a query—a search—plus the results of that query. The query in each backlinks section tells Obsidian to return results that match just a single search term: the title of the note that the backlinks section is a part of.

If we instead want Obsidian to not only (a) pull together in one spot all notes that contain a link to a block on a particular topic page but also (b) group the links to those blocks based on their level of relevance to the title of the topic page, then we need to create our own queries.

The image below shows what a section containing relevance-level queries looks like (you can see how to build this specific query here).

And here's what a "relevance - medium" section looks like on a tag page called [[🏷 amour propre]], where the "relevance - medium" query has returned a single search result:

The result returned by the query is (part of) a block tagged with both (a) a tag-page link ([[🏷 amour propre]]) and (b) a relevance-level tag—[[relevance - medium]].

Getting information from one page to show up as a search result in a relevance-level query on a tag page is simple: add (a) a tag-page link and (b) a relevance-level tag next to the piece of information, as shown below.

When you put a tag page next to a piece of information, you're indicating that the information is relevant to the topic of that tag page. When, in addition, you put a relevance-level tag next to that same piece of information, you are indicating how much relevance the material has to the topic of the tag page.

As you can see in Figure 3, the result of the query doesn't contain a whole lot of information: it's just the two search terms—the [[tag page]] and the [[relevance-level tag]]—preceded and followed by a couple lines of text. In almost all cases, you will want to see more information than that. Fortunately, that's easy to do.

There are several options when it comes to disclosing more information above and below the search terms, three of which I lay out in the detailed instructions on how to implement RLT.

The Advantages of RLT

One advantage of using RLT is that it speeds up the work of completing a project. Reviewing relevant material via queries that sort the material based on how relevant it is to a particular topic is faster (and less frustrating) than having to review material in the backlinks section.

When it is time to write something related to the topic of a particular tag page, I can start by focusing on the material I have tagged as being of high relevance, move on to the material tagged as being of medium relevance, and then probably just ignore material tagged as being of low relevance.

A second advantage is that you can view each query's search results without having to open the original page, thus reducing the sort of context-switching that erodes attention.

To explain two other advantages of using RLT, I need to say a little about my use of the [[relevance - medium]] and [[relevance - low]] tags.

The [[relevance - medium]] tag is the one I use the most. Yes, assigning that tag to too much material reintroduces the problem of clutter—this time where the "relevance - medium" query is on a tag page rather than in that page's backlinks section.

But I'm fine with that because using RLT has another advantage: when I tag material with not only a certain tag page but also a relevance-level tag, I rarely find myself feeling anxious about whether to tag material that's relevant to a topic page.

As for the [[relevance - low]] tag, I use it a bit more frequently than the "high relevance" one. You might be wondering: why use it at all?

One reason is that maybe, just maybe, low-relevance material will be useful for a future writing project. I know it is unlikely that I will use the material tagged as being of low relevance, but if it is even a tiny bit probable that I will use certain material, I usually put a [[relevance - low]] tag next to it.

Of course, what I have just said is what you could expect someone who has fallen victim to the Collector's Fallacy to say so as to justify collecting just about every bit of information they come across. But it's not the Collector's Fallacy that leads me to collect information of low relevance to a topic—I am not driven by the mistaken belief that the more information I collect, the more knowledgeable I will become.

Instead, the thought that certain low-relevance material might be useful for a future writing project amounts to an itch I haven't been able to get rid of. I have reduced the frequency with which I scratch that itch—I've been using the [[relevance - low]] tag a bit less than I did at first—but the itch remains.

Using the [[relevance - low]] tag scratches that itch without really adding to the clutter of search results (at least not to the ones returned by the queries for the other two levels of relevance). Put differently, scratching the itch adds "noise" to my notes without reducing the "signal."

I use the [[relevance - low]] tag to scratch that itch as much as I do to non-anxiously collect information that might be useful for a future writing project.

RLT isn't What You Should Be Doing Most of the Time

While RLT can be useful, it should be done in the service of—not as a substitute for—more important work, such as building a Luhmann-like Zettelkasten or working on a well-defined writing project.

Otherwise, you're doing something about as unimportant as merely collecting and tagging texts, videos, and podcast episodes (which happens to be yet another itch I too often scratch).

Detailed instructions on how to implement what I talk about in this piece can be found here.

ABOUT THE AUTHOR

Forrest Perry teaches philosophy and political economy at Saint Xavier University (Chicago, USA). His videos and posts about note-taking and writing can be found at www.fpnotes.io.