The Hidden Problem with Note Titles as Links (And How to Fix It) • Zettelkasten Method
The Hidden Problem with Note Titles as Links (And How to Fix It) • Zettelkasten Method
Using note titles for links can be made to work, but it’s a kind of friction you could avoid.
Howdy, Stranger!
Comments
Does this mean that the next version of The Archive will render the specified text for a link as shown in the diagrams? Or at least better handle searches where link text is present?
Or is this more about how to link in other software perhaps?
From a technical point of view I find the links-as-search approach elegant. It implements links without implementing links. Search is a close enough simulation for many use cases. (You can use the same workaround with command line tools like find and grep.)
Unfortunately this method is less software agnostic than it might seem. It introduces incompatibilities at another level.
The notation
[[this-is-a-wikilink]]with double square brackets is also known as "wikilink" or "wiki link". According to MediaWiki history it was developed in 2001 by Clfford Adams as "free link". MediaWiki adopted the style in the same year. The syntax became popular with increasing popularity of Wikipedia. Many other Wiki implementations adopted that syntax, including DokuWiki.What happens, when you click on
[[345]]in The Archive? It starts a search and returns notes that contain the string "345" anywhere in the filename or note content.What happens, when you click on
[[345]]in an app, that recognizes wikilinks? It returns only notes, where the filename matches345, eg345.mdor345.txt. It would not return12345 This is a great note.md.For better compatibility with other software, a filename should contain just an ID, eg
202102180951.md. The ID is permanent by definition. Once created it is never supposed to change. So a filename that contains only the ID will never have to change either. This filename's sole purpose is to uniquely identify a file within your file system. This would also work for other naming schemes like Luhmann numbers, eg1-3a17.md, or bibliographical IDs, egAhrens-2022-Smart-Notes.mdorDoto-2024-System-for-Writing.txt.For maximum compatibility with other software, the links should also only contain that ID, eg
[[1-3a17]],[[Ahrens-2022-Smart-Notes]]or[[202102180951]]. When you navigate your notes with an app that recognizes wikilinks, this approach ensures that a click on the link opens the linked file directly.The safest bet would be something like this:
This should work with The Archive and many other apps.
I find The Archive's lightweight approach elegant, because it blends search and linking in one minimalistic mechanism. But if I wanted to optimize my notes for software-agnosticity, I'd also take other software's behavior into account, when choosing a file naming scheme and link syntax.
A solution for the "hidden problem" is to completely remove the title from the filename. This reduces the need to change filenames and removes a potentially misleading nudge. No title, no nudge. :-)
Aside: Most of Luhmann's zettels didn't have titles. He didn't need them, because he could identify zettels by their unique short ID. There's no need for titles in a digital Zettelkasten either. This is how Luhmann's Zettel ZK II 1/14b2 could be represented in The Archive:
Aside: The "hidden problem" is more a wiki problem than a Zettelkasten problem or a Hypertext problem. Luhmann solved the problem with his numbering scheme. HTML has the hyperlink tag
<a href="…">Text</a>. Wikis started out with titles as links. Free links emerged later, see https://wiki.c2.com/?FreeLink Wiki apps don't have that "hidden problem", because they automatically ensure consistency. The problem only appears, when we edit text files manually.If find the oxymoron above amusing, but also so true. Being agnostic you have to know what you are agnostic about
Personally, that is what I ended up with eventually. I've been juggling The Archive (which I like the most), Obsidian, Vim and command line tools as my toolkit to get everything from my Zettelkasten. There was always some extra friction if I wanted to make use of each one's best features. Then one night in desperation, a young man breaks away... and removed everything but UIDs from the filenames. At the time, I was struggling with tag searching challenges and pondering all the excessive clutter in my note-taking workflow anyway. So, I decided to conduct an experiment, backed up my vault, and did the cleanup.
At first, it was annoying to discern that the search bar had almost become useless. But then it finally started to become clear to me what link quality means. And why it is so important to have first-class structure notes from the beginning. This eagerness to rely on searching actually showed me that I had skipped some basic work stages. Even though my experiment is still young, and this file naming practise and its advantages are obvious to many of you, I can see how it might direct you to right direction as to how to use Zettelkasten more properly.
In addition, a step was taken towards more genuine(?) software agnosticism. At least there have been no issues so far with aforementioned tools.
@harr To be software-agnostic, you merely have to increase the probability that you can replicate the desired behavior in other and widely available apps.
It is not more software-agnostic if you alter the method, so you can click on the wikilink.
As long as you can perform a full text search, you can access your Zettelkasten with reasonable convenience.
The reasoning is wrong. [EDIT] He wouldn't identify notes by their ID (rather departments) and there is no need, since when he looks up a note, he will see the content. The use of the title arises from the act of asigning titles itself and that you want to represent the content without looking it up (for example: results).
EDIT: Corrected the pronoun.
I am a Zettler
Exactly my point. The desired behavior for wikilinks is to link to exactly one target. This is best achieved by an exact match of the text in the link and the filename.
The Archive behaves differently. It doesn't know links. It only knows a very basic form of full-text search.
It does, if the goal is increased compatibility with other and widely available apps.
That's the lowest level of software agnosticity. Storing your notes in plain text files, so that you can read and search them without knowing the syntax.
The next level is about compatibility of syntax, for example:
Ignorance and agnocity are not the same thing. Ignoring common standards doesn't make your files more software agnostic. It only makes them, shall we say, different?
Sorry, I don't understand. What do you mean by "department"?
It is not about knowing or not knowing links. This is feature-thinking. The goal is to refer from one file to another. If you insist making it happen by clicking on a string between brackets or by utilising the full-text search, your thinking is software-contingent.
This is not software-agnostic thinking.
See above.
Common standards are often not that common and there are many application that don't respect those standards.
The system search for example.
Luhmann talks about departments in his ZK. I am referring to this term. (I cleaned up the pronouns, since I referred sometimes to me instead of consistently to Luhmann)
I am a Zettler
Still doesn't make sense.
Yes.
Circular reasoning: we use titles, because we use titles.
That's a limitation of a particular software.
There are other UX patterns. One of the learnings of my Logseq experiment was, that you can navigate Luhmann's zettels digitally without titles.
Some apps display not only titles in the search results, but some part of the content.
In the following screenshot I opened The Archive's Demo Notes in Obsidian and searched for open standards:
This is a screenshot from Zettlr
By the way, neither of these apps can resolve wikilinks in the demo, because there is no file that matches that link. The same also applies to iA Writer.
I agree with sample note 201705120916:
One could argue, that wikilinks qualify as an open standard by now.
My solution to the "hidden problem" is to adhere to such standards.
Having titles is different from the act of assigning titles. The benefits of assigning titles can persist even if you delete the title afterwards.
Result and Process are different entities.
I am a Zettler
Filenames and note titles are different entities.
Digital notes need filenames to identify notes in the file system (if we use one of the common file systems and if we create one text file for each note).
But why assign titles to notes?
We're discussing this question in the comment section of an article, that talks negatively about titles:
Is the title a problem, because it appears in the filename? If yes, we have a simple solution. Remove the title from the filename and only use short content-agnostic IDs for idea notes, eg a timestamp. (That's what I suggest in an earlier comment.)
Is the title itself a problem? Possibly. We don't need the title as filename. We don't need the title for links. And not everybody needs titles for their note-making either, eg Niklas Luhmann.
What are those benefits?
EDIT: Just to make sure that we talk about the same thing. Here's an image from The Introduction to the Zettelkasten Method with the title highlighted. I mean by title the content of the first heading without the timestamp:
I think we should distinguish more clearly between:
Luhmann's paper Zettelkasten had only #1, but not #2 to #4. Other paper-based index card systems might also have #2, but I don't have an example at hand.
In text-file based digital hypertext systems, that are modeled after early wikis or Andy Matuschak's Evergreen Notes, #1 to #3 are the same, without having the option #4.
Digital hypertext environments that properly support standards like HTML, plain Markdown or wikilinks can easily differentiate between #1 to #4. So another simple solution for the "hidden problem" is to use a standard markup language and render it with a standard compliant app. For example you could write your notes in HTML and navigate them with any web browser, that can read local files.