Unlinked mentions and Zettelkasten prefixer

Hi!
I began working with Obsidian at the beginning of the week and so far I am very pleased with the results. Being a beginner with the Zettelkasten method of note-taking, I activated the Zettelkasten prefixer plugin, so that I have unique IDs generated with every new note. I was unsure of these IDs’ utility, but I thought that it wouldn’t be a bad thing to have.
However, after a few tests today, I realized that this might be taking away a key feature of Obsidian - the un-linked mentions. Is this true for everyone, or just for me? When I wrote the title of a note in another note, without the ID, it didn’t find it, but when I added the ID, it found it and showed it in the ‘un-linked mentions’ tab.
Would it be possible for the un-linked mentions finder to “ignore”, so to say, the IDs? Otherwise, I think the addition of the prefixers takes away a major feature of the digitized Zettelkasten method - a great disadvantage for users.

Cheers.

3 Likes

Many posts on the web that describe “how to take notes in the Zettelkasten method” seem to assume that a time-based stamp in the note title is needed, or at least ‘standard’. This might stem from the fact that that when Zettelkästen were made using pen&paper index cards, there had to be an easy way for people to reference the link between notes. Using ID numbers was easier than having to use a note’s full title.

Even in the digital age, the recommendation to use ID numbers in notes persisted, because these IDs are seen as ‘immutable’ and ‘reliable’ - for example, if you link to an ID number, you can (supposedly) change the title of the note without affecting your links. As a consequence, even modern Zettelkasteners still recommend using ID numbers in titles and links - and sometimes go through the whole trouble of building Zettelkasten software that explicitly supports this convention. But is it still necessary?

Ensuring Title Uniqueness

One of the arguments of the proponents of using an ID in the note title, is that it ensures ‘uniqueness’ - that is, it ensures that no 2 notes will have the same title. In a Zettelkasten, however, all your notes should be kept in one big folder - i.e., there should be no hierarchy of sub-folders separating the notes. In most computer systems, this means that if you try to create 2 files with the same name, you’ll get a warning anyway.

Now, if your filename is different to your note title, you could still end up with 2 notes that have the same title (but different filenames). But a clever app like Obsidian makes it very easy for you to avoid that: just look at your ‘backlinks’ and ‘unlinked mentions’, and you will see the other note staring back at you.

Flexibility to Change Note Title

In Zettelkasten apps that use the ID format in note titles, you can make links between the notes using only the ID. So, instead of linking to [my note](Zettelkasten), you’d link to [my note](202005171231). This means, that in these apps you can change the title of your note, without affecting your links to it.

In smart apps like Obsidian, however, if you decide to change the title of your note - our even its filename - the app will automagically update all links for you anyway. That means, that if you change your note title from ‘Zettelkasten’ to ‘Zettelkastening’, your links will be changed to [my note](Zettelkastening). This has the advantage of keeping your links more readable, and of being more compatible with other standard markdown programs - who won’t understand those ID links anyway.

Conclusion

IMHO, the use of IDs in note titles - whether based on time stamps, UUIDs or any other arbitrary notation - is an antiquated an unnecessary procedure, left over from the days of building Zettelkästen with paper index cards. The perceived advantages of a visible ID in the note title can all be provided by sufficiently smart apps, like Obsidian, without using them - and much more.

By using standard titles, and standard links, your notes will be more portable, and readable by a wider variety of markdown apps.

Many practitioners have more than one zettelkasten devoted to different subject areas or work/academic/home.

But if you are combining two sets, whether two of your own or adding from someone else, this potentially creates multiple clashes.

One of the touted advantages of plaintext is that files can function without apps but will always be readable by the file system.

The advantage of UIDs is that it allows the system to function whether or not apps are available.

Good point about merging folders/vaults - I haven’t tried doing that in Obsidian, so honestly don’t know whether or how the program handles it.

The point about portability, however, is arguable. Even if we’re planning on manually managing our text files, we’ll be likely using a markdown-compatible editor. Therefore, the closer we adhere to the standard markdown syntax, the more portable our notes will be.

With that in mind, If portability is the goal, then it’s certainly best to use standard markdown notation than wikilinks for our images and links - as the standard notation will be understood by all markdown apps, while wikilinks will only be understood by some.

Similarly, links to an “ID” which is part of the text file’s title is not standard markdiwn - and understood by an even smaller number of apps (not even Obsidian understands that, and requires conversion of those links on import). So, that’s not very portable at all.

On Aliases

I’ll first speak on the software problem itself, so those that aren’t interested in the conversation of why one might want to use IDs in titles can skip my prolixity on the matter.

I think that this capability could be easily solved by the use of a more generic tool which could prove beneficial to anyone, not just those looking to very specifically use a string pattern prefixed to their titles as a link target elsewhere: that is the use of an alias or a handle by which an entry or document can be referred to in addition to its formal address, whether that be title, filename, URL or whatever.

This is really isn’t a new or novel capability, because we can think of the role of overriding a literal link target with visible text as being a form of ad hoc aliasing: [[Here is the Target|Here is the Alias]]. The desire to refer to a thing not by its formal address, but by a more contextually relevant or shorter handle is undeniable. We just do not often see that desire mapped into software level interlinking for some reason.

DEVONthink Pro, a database tool for the Mac, has this concept, where each document in the database can be given an alias, which as a string is then scanned for automatically in every other document. When encountered, the text becomes an active hyperlink automatically, and otherwise operates as a real link unless you change the text.

We also see this capability in MediaWiki, where I can refer to the octothorp symbol by an unusual name, and be redirected to what most people know it by.

There are several ways in which this could be implemented. In a GUI fashion, there could be some sort of button up near the title that displays a fly-out that you can view or provide an alias into. Perhaps the alias could even be displayed in the title area optionally, using a smaller font and some kind of grey “pill” formatting. Also along GUI lines, something in the sidebar or off the ellipses button might be better, as that might better allow for multiple aliases to be defined.

Another approach would be more aligned with the spirit of extended Markdown, and that would be to allow for some sort of pattern recognition in the content area itself. This would couple nicely with @icouto’s comment on the use of YAML preamble metadata, such as used in MultiMarkdown (this is the standard I use in all of my entries as well). For example:

Title: This populates the Obsidian note entry automatically
Date: 2020-11-15
Alias: alias-idea

And there you go, now you can verbosely refer to the document by its title, but alternatively you can just use [[alias-idea]] where brevity is valuable. Of course a ZK user could put their ID there, but one might use it for any variety of reasons. It could even be used to make external links less clunky and more long-term resilient, like obsidian://open?vault=something&alias=alias-idea.

Of course that is a bit more operationally clunky than a plugin that looks for a title pattern and just uses that as the alias—but perhaps that could be the plugin, and the alias itself be more of a core feature that the plugin automates—and such an approach would allow for a far greater variety of people to benefit.

On The Virtue of IDs

All right, on to theory. :slight_smile: I don’t use Zettelkasten, rather a system of my own devising that is based more upon the theories of Noguchi, but it does bear a number of resemblances to the system as I understand it, in particular with regards to the use of an ID per note. While I can understand why most people out there would be perfectly fine working on text titles alone, I don’t think that alone is reason enough to suggest that the use of IDs for entries is obsolete or that it lacks any compelling merit, even in a purely digital environment where software augmentation is depended upon.

The page that you linked to had some good arguments for why you might want to use an ID, but they don’t seem to be addressed here, rather it was only used to illustrate that in general, it is advocated for. Here are some of the reasons given, along with my commentary on how I independently arrived to the same ideological point:

Pre-processing

Completely does away with the compatibility argument you raise. This is the approach I’ve taken since 2005 or so, where all of my bespoke syntax, including cross-referencing via IDs, has been handled seamlessly for so long that I forget it even happens. This can be an asset, rather than a work-around, which I’ll illustrate below.

Link resilience & flexibility

One of the first points raised in the linked article is that one should think very carefully before adopting any software’s hyperlinking system, and this is a point I strongly agree with. They make the point in the framework of resilience: you don’t lose the link if you have to leave the system (more true for non-markup users), but there are good arguments for extending the usefulness of links in ways most hyperlink systems completely ignore.

This is where post-processing can become an asset. One area where my approach differs from ZK is that my linking syntax is capable of (a) declaring intention and (b) annotation. While some link formats can do this (HTML clutter comes to mind), Markdown and Wiki style links typically do not. They at most allow you to change the visible text when the document is rendered, but that is not a very flexible tool for adding additional information to a link, and adds clutter while writing and editing.

Granularity

The notion that each entry is in itself a link target is only one small part of the idea. In fact in my earliest prototypes I did not ID each entry, but rather put all of the IDs into the content. This was because, at the time, I tended to write daily aggregate entries with multiple topics. Links, for how I worked back in '05, were purely point-to-point. When I changed my methods to add an ID to the entry title a couple of years later, it only gave me another link target to point at. The key thing here is that the link remains predictably succinct no matter the depth of the target.

Succinctness

Yes, something that I am not very good at. :laughing:

This concept leads to a digression on brevity and legibility in a prose context. Here is an example of what I mean by avoiding mechanical clutter; visualise these different examples embedded in the middle of a paragraph:

[See also](re20319867>)

Versus

[[This is the verbose name of a note#Here is the topic heading I want to point at|See Also]]

Or worse, the Markdown approach:

[See Also](This%20is%20the%20verbose%20name%20of%20a%20note#here-is-the-topic-heading-i-want-to-point-at)

The latter two require a fair amount of squinting—neither provides a very readable result in terms of being able to allow the eye to skip over the technical baggage and get to the “See also”, or the prose amidst the technological apparatus.

Where granularity comes back into the picture is that the inverse of my outbound link syntax looks like this: 20319867<. That, as a piece of text, can be inserted anywhere I want… like right there. If I were to put a link to that ID in another document then I would arrive at this paragraph. I don’t need a heading, or a figure caption, or any other typical ID generating element around it. So succinctness and granularity go hand in hand, when devising legible systems for networking data.

In my interpretation, this is what the author of the article is getting at when they ask, “Think outside of the box for a moment: when note identity and file system representation are decoupled like this, how could we use information identity elsewhere?”.

With a system that does not depend upon formal titles or interior structural elements in order to create a link, we do not need to even think in such terms while building our network of ideas. We have freedom to embed networking as deeply or as broadly as we like.

Inherent Double-Endedness

A cross-ref syntax where the outbound link is essentially identical to the inbound anchor makes for a naturally double-ended system. Consider the previous example, where I link to the paragraph above from another document, and instead of using that data as a cross-reference, I plug it into a search tool. The result gives me both documents, and indeed any other places in the network where I chose to refer to that spot. It doesn’t require any alteration to what I do to get that ability. The Wiki or Markdown link approach, on the other hand, creates a link that looks nothing like the target (and may well be cluttered by encoding and other apparatus to make the link HTML-valid). You have to select individual components out from it and perhaps even use multiple searches to get to the spot you really wanted to get to.

Now you might say, that’s just what back-links in a tool like Obsidian do for you, and you’d be right, so long as we constrain ourselves to the use of software that has that capability (rare). The key point here is you get this capability using ID-based links with nothing more than ls and grep on the command line. Pretty much any software that is capable of storing entries and searching their contents is thus a fully capable back-referencing system thanks to the data being organised for that approach.

And if that clicks, perhaps it better clarifies the concept of portability, as being something that goes beyond whether you use strict Markdown syntax or not. If I can lift twenty years of archived data, millions of words at this point, and dump it into a completely new piece of software in a lossless fashion, with 100% capability without really learning much of anything about it… that is portability.

Accessibility

Closely related to this concept is how easy it is to extract what amounts to a link from any source material. If it is easy to double-click or select the important part of the text out of a link and use that to paste into another program, then our links remain functional across contexts. We wouldn’t expect our coding editor to understand a cross-reference to a document in our archive, so being able to easily extract the target no matter its specificity increases its usefulness. It also means we don’t have to depend upon software to provide an external link feature, though such is always nice, having data that doesn’t need it is nicer.

Avoiding Constraints

In Writing Methods

@icouto: The point about portability, however, is arguable. Even if we’re planning on manually managing our text files, we’ll be likely using a markdown-compatible editor. Therefore, the closer we adhere to the standard markdown syntax, the more portable our notes will be.

So then we have added a constraint to the archive, that it must be comprised of Markdown files. You will seldom find a more outspoken advocate of Markdown, but my system straddles all manner of file types. I use org-mode, YAML, .taskpaper and other various plain-text formats for information management. My system extends into code itself, embedded in comments pointing back to tickets and to do list entries. It even extends into the realm of paper, for my system was based off of how I was already marking dates down in handwritten journals.

With my ID system I can refer to an entry right here in this forum, with a compact link code like xr05273912> that would enable me to, within no more than five minutes, stand up and pull a book off of my shelf and be reading the desired entry from a journal, penned in early Autumn of 2005. I can do that because my ID is a date, and that gives me everything I need to know to pluck the right thing off the shelf and flip through pages until I reach the right spot. If all I had was a title, there would not even be a point in bothering to try and find it, it would take months!

While not everyone might need such a capability or that degree of specificity, the fact that I can do that again means my ability to find data outside of “The Archive”, across my computer, across old backups, FTP servers and so forth and diverse file formats, remains unhampered.

A title all by itself is never going to provide that level of inter-connectivity across a broad spectrum knowledge network.

I came up with my bespoke link syntax before lightweight markup hit the scene, but when it became a thing, my system slotted right into it without any hassles—portability. If I want to refer to something in such a way that it has a clickable hyperlink in prose, then [this is all I need to do](re20319744>). It’s perfectly Markdown compatible, as you put. You might argue it doesn’t work, but it does if you have built a system around that approach already. For me when a Markdown file gets typeset or output, my link gets turned into a valid file:// URI prior to getting to the Markdown processor. That can be useful with Markdown, but also becomes useful in Org, or whatever.

In Software

Now, if your filename is different to your note title, you could still end up with 2 notes that have the same title (but different filenames). But a clever app like Obsidian makes it very easy for you to avoid that: just look at your ‘backlinks’ and ‘unlinked mentions’, and you will see the other note staring back at you.

This is another constraint, but now we aren’t merely constrained by the methodology with which we type in data, but by the software we use. Now our archive is hampered if you take it out of Obsidian, or any program that can shore up its weaknesses.

The original argument you made was that the digital age itself has made the ID obsolete (which I take to be a purely humanist statement, obviously IDs are bread and butter in the digital realm), but unless the digital age is all about getting your work stuck in one program because it falls apart outside of it, then I guess that’s just not what I’m about. It’s certainly not what I designed my system for—mine was rather designed out of a frustration with how data becomes constrained and limited by the software we put it into. I wanted data to become liberated from software design, to remain fully functional no matter where you put it, even as loose files, even as a stack of printed documents.

The Freedom to be Lazy

One of the arguments of the proponents of using an ID in the note title, is that it ensures ‘uniqueness’ - that is, it ensures that no 2 notes will have the same title. In a Zettelkasten, however, all your notes should be kept in one big folder - i.e., there should be no hierarchy of sub-folders separating the notes. In most computer systems, this means that if you try to create 2 files with the same name, you’ll get a warning anyway.

I think in stating it that way you are dwelling on the technical aspect more than the human aspect. Sure, the OS won’t let you have two files named “The importance of IDs in names.md” the same folder, so if I were to immortalise this conversation as a sequence of separate entries, I would then have to contrive some serialisation technique to handle that problem. Or I would have to creatively label your post for you in my system, and my posts, and at what point does that necessity hamper the more useful attribute of the title here: as a binding agent in a list that declares these entries as being related to a chain of conversation? If each entry has a seemingly unrelated title it depends upon other agents for that binding (it does, to be clear, but we should have a human-friendly front end to that).

So in my system, I have this:

20182056 m2.1.Obsidian  The importance of IDs in names
20319752 M2.4.Obsidian  The importance of IDs in names
20319852 M2.1.Obsidian  The importance of IDs in names

Here we have, in order, your post IDed by when it was posted, a first draft response and the one you are actually reading right now.

Do I need more for the title than how I think of the conversation thread? Not really! I could put your name into the title, but I don’t really need it because the lowercase ‘m’ already signifies to me that I didn’t write that particular entry. Could I put ‘draft’ into the second title? Again, sure, but I don’t need to because I know in my system the minor number ‘4’ indicates an unfinished work, which in the context of ‘M’ (communication that I wrote), ‘2’ (publicly) tells me it’s a rough draft for a post to the Obsidian forum (‘1’).

So when you’ve got chronological/identifier and taxonomy information already in the title, you don’t really have to be as creative or force variation into your titling to please the gods of the file system (or your ability to link properly).

This archived conversation example is only one case where using the same title for multiple different notes is simply more convenient and even to a degree more informative, than having to come up with verbosely unique titles.

IMHO, the use of IDs in note titles - whether based on time stamps, UUIDs or any other arbitrary notation - is an antiquated an unnecessary procedure, left over from the days of building Zettelkästen with paper index cards.

Again I think that is a limited way of looking at it, since in my case I knew nothing of ZK until fairly recently, but yet I came up with a very similar approach independently, and specifically to circumvent weaknesses in digital information management. It wasn’t that I had been using IDs in paper journals all along and just kept doing that when I started digitising, but rather the other way around. Perhaps I’m being a bit pedantic on this point, however, but it seems to me the crux of your argument is that it is a vestigial tool without digital merit, or that perhaps software should circumvent the need for data that can fully represent systemic qualities on merit of its content alone.

3 Likes

I really dig your approach, and I think you might have solved problems I was unconsciously aware of but hadn’t formulated.

Would you be so kind and explain it a bit in detail?

1 Like

I’d be happy to share! But maybe this isn’t the best place to do so? Maybe shoot me a PM with any questions you may have, and if I end up writing enough I’ll post it publicly as a new thread.

1 Like

Why yes, of course! Will send you a DM in a few. Thank you!