Importance of naming with zettelkasten IDs?

What’s the consensus on this? I have a few dozen notes at this point (yep, I’m a noob) and have not used a unique identifier anywhere, but should I be doing that?

Thanks for any and all viewpoints.

1 Like

Some people like to add them so that it’s impossible to have two files with the same name. Personally, I avoid zettelkasten IDs because I think notes look cleaner without them and I don’t feel the need to have the date of the creation of a note in the title.

Others use them for things like meeting notes where all notes for that type of note would have the same name if there was no unique identifier, but I just append the date (YYYY-MM-DD) to the note title instead.


I don’t use them and I have quite a few notes. I use the PARA method as my main organizing structure and my notes cover a wide variety of different types of projects and references. I link back to daily notes from my notes so my backlinks provide a timeline if I need it.

Others use them for things like meeting notes where all notes for that type of note would have the same name if there was no unique identifier, but I just append the date (YYYY-MM-DD) to the note title instead.

I do this too.

If I were focusing on one major area of interest in my notes (like a huge research or study), I would consider the zettlekasten approach to be a little more useful to me. I’d worry less about structure and more about capturing ideas and following threads.

But for my purposes where my vault is more of an organized, broad-based productivity tool, zettlekasten doesn’t really connect for me.


I like doing this because each meeting will be listed in their order of occurrence (Meeting 2021-04-06, Meeting 2021-04-07, Meeting 2021-04-08).


I think you should read this: Asking for suggestion to get started with PKM using Obsidian

In my opinion, for long term, Unique Identifiers are crucial for your sanity while handling thousands of notes.


I use them in my zettelkasten but in a nonstandard way. My note titles tend to be phrases (see Andy Matuschak for more on this) and I need the unique ID capability since I use tools like Alfred to create notes sometimes and am concerned about accidentally overwriting a note, but I hate the visual “speed bump” of the ID prefix in the notes and I can’t stand the noise that comes from creating a non-ID alias for every. single. note.

My solution is to place them at the end of the title. This solves all of the problems: collision resistant :white_check_mark: no visual speed bump :white_check_mark: no link noise from aliases :white_check_mark:.



Conversely in my PKM (for project tracking, meeting notes, etc) I don’t use IDs at all but I use tags quite a bit, which I barely use in my ZK. My PKM also has very structured folders while my ZK has a loose set of mostly 3 broad folders for the workflow. (inbox → lit notes → permanent notes)


Something that works well for me: all notes from meetings start with qmtg YYYY-MM-DD (as in qmtg 2021-04-10). That makes it super-fast to search. I actually have a TextExpander snippet that expands xmtg to qmtg YYYY-MM-DD.

I also use: qrun (for running notes, Standard Operating Procedures), qlog (for logs of activities on projects, journal entries), qtalk (for lectures), qbug (for bugs, things to fix or tweak, etc.),… You get the idea. Adapted this from Merlin Mann’s “runx” convention, but moved the odd character to the front to take advantage of autocompletion.)


In general, Zettelkasten IDs are useful if the primary concern is to avoid duplication. But usually I’m more focused on resurfacing ideas I’ve been developing already. This means that I want to take advantage of autocompletion, and for that it’s key to have distinctive phrases that I can use and reuse in various contexts. For example, if I write up this idea in a note, entitled “Zettelkasten IDs thwart autocompletion”, then I’m more likely to return to the thought, use it elsewhere, refine it, etc.


This is exactly why I use phrases.

Plus they make outlines of links ridiculously useful because the outlines become collections of principles which combine to make larger strategies, theories, etc.

Here’s a snippet showing how they combine together into outlines.

Note Prefer abstractions built on trustworthy components is in both this and the above outline because it is applicable in both contexts.


Excellent. My question to you, then, would be – why not lose the Zettelkasten-ID altogether? Perhaps for your use case, where most notes seem to carry a sentence-like title, this is fine.

But suppose I use the phrase “abstractions leak” (love it!) more often, e.g.: “Because [[abstractions leak]], especially in [[early stages of model-building]], it is important to adopt an agreed upon a [[terminological ontology]] at the outset.” My practice is to establish nodes in the graph both for longer notes (as you do, with long titles, closer to a statement) but also for distinctive phrases or key concepts (some of which turn out to be the basis for long notes, while others simply serve to bridge notes, much like tags, but in a more fluid way).

These key concepts get integrated into my writing. Say I’m writing a sentence about abstract reasoning, and I have the hunch that I already have an apt phrase that I’ve developed in this domain, so I type [[abstractions and the nice phrase “abstractions leak” is presented to me via autocompletion. In this way, a phrase that I might not have thought to use, but which I’ve already done some thinking about, gets integrated into my connected thinking. Note that this is not a matter of just recycling clipping for others, but a matter of cultivating a set of my own thoughts, which involves using some distinctive phrases consistently.

Aliases provide another help here. If I include, the note on “abstractions leak” aliases like “abstractions bleed into each other”, “abstractions tend to be leaky”, etc., then there are even more options. So, if I just type [[bleed I get prompted for the phrase I was looking for (or I can decided to revise it; you’re never locked in on this).

For this purpose, I don’t want to have to be presented via autocompletion with [[abstractions leak (202104101809)]] and [[abstractions leak (202103101209)]] and [[abstractions bleed into each other (202104101809)]].

Thanks for forcing me to articulate this. I hope it’s clear!

1 Like

Thanks for this tip. I might adopt this and it’ll take me mostly there. The one lingering issue I have is keeping the ID at the end would not allow sorting by date using the filename. Have you found a workaround for that?

(this ended up longer than expected but hopefully its useful…)

I don’t use aliases simply because I prefer to think in terms of the specific concepts as I put them into the zettelkasten. This reinforces the ideas as a cohesive interlinked framework that is etched a bit deeper into my mind each time and which begins shaping how I see and interact with new information, finding ways to incorporate it into my existing mental models. This is how we build up our mental models which we use as lenses through which we understand the world around us. Learning something new then becomes an extension of an existing branch of knowledge, so my ZK evolution is directional in that it expands in particular directions (as opposed to being a place where information is thrown in haphazardly without intentional links to it), similar to an amoeba moving through space to find food. Though I don’t agree with him on much, Jordan Peterson describes much the same thing in this short video on note taking: Jordan Peterson: Don't Take Notes During Lecture! - YouTube

For this purpose, I don’t want to have to be presented via autocompletion with [[abstractions leak (202104101809)]] and [[abstractions leak (202103101209)]] and [[abstractions bleed into each other (202104101809)]] .

What is the difference between that and seeing exactly the same things as aliases without the suffixes?

What I’ve found in my own archive is that not only is there no issue with having notes with slightly divergent titles but in fact they help tease out potentially subtle nuances between them that I had not considered before. Sometimes this happens intentionally and sometimes accidentally. (ex: I am in a hurry and forget that I wrote about X and make a link to X' to get my thoughts/learning/whatever into the note) What happens is eventually I realize this and then can analyze them to see if they truly represent separate ideas or not. If so then perhaps one or both should get slightly reworded titles. Or they should be merged into a single note.

When I find notes that need to be reworked or merged I simply tag them with #refactor and a statement of what/why, and eventually I will get around to updating them. Out of about 800+ notes in my ZK 29 are tagged for refactoring to some degree, several of which are tagged to consider merging two notes together. Ex: I have two notes named Generic topic-based note tagging is an anti-pattern and Create a personal idea ontology instead of adopting the terms of others that are tagged with a note that they may well need to be merged at some point. Even though I don’t have “refactoring days” where I spend time cleaning up, I do occasionally work on one when I come across the tag during regular use of the ZK. And even when I don’t make any changes (which is often) the tag acts as a signal that this note is “a bit messy” so I take that into account when I read it.

In other cases there is no need to rework or merge them because even though they are closely related they are distinct enough that it’s worth keeping them separate. For example I have a note titled Discard information to gain clarity which is closely related to (but slightly different from) Bound a problem to gain control. They are both applicable to thinking and decision making, but the first is also applicable to things signal processing, networking, statistics (binning), and other domains while the second is not applicable to those but is applicable to certain types of computational decision algorithms. If I follow a link to one I can follow its link to the related note (in either direction) if desired.

If I were to find “Abstractions bleed into each other” a more appropriate title I would simply rename the note so as to update my mental model. (I don’t happen to agree with that particular statement because there are other specific aspects of leaky abstractions that I’m focused on, but that’s beside the point and reflects my views, while yours are equally valid and work for you)

The ID suffix was added because I use external tools to add notes to my vault so I needed a means to ensure there would never be a collision. For example, Alfred. If I accidentally typed the name of a note that already exists into it I didn’t want it to accidentally overwrite an existing note, since this is supposed to be my prized collection of lifelong knowledge.

Now that I’ve split my vaults I suspect there will be less automated insertion into the ZK vault, as it should be, so the IDs may eventually become unnecessary.


@kard32 I have no need or interest in sorting my ZK files by date using the filename. The ideas (either my own or those I take from others) have no inherent temporal context. I don’t use daily notes in my ZK or anything like that. (I tried for a bit, but it never felt pleasant to me at all.)

As a practical matter I can still search for anything by approximate date by simply adding for example file:(2104) to any search to get all files created in (or at least labeled as created in…) April 2021. Doing that and sorting by file name seems more intuitive to me.

If I really needed to sort like that I would probably just write a python script to collect all the filenames into a dict with the ID suffix as the key and sort on that key then display the results. I’m no longer a code ninja so it would take me more than two minutes to write that but its fairly straightforward as a problem to solve.

By comparison, in my PKM work project type vault I use the daily note and a lot of automation, and my daily notes and things like meeting notes are all prefixed like 21.04.Apr.10.Sat specifically so they can be sorted. Because in that context days matter a lot.

I suspect that now that I have a functional reason to use daily notes in my PKM vault that it will become where I take “fleeting notes” which can then be gradually considered for inclusion into the ZK. This further insulates the ZK from pollution, which feels like a move in the right direction.

1 Like

Great points. I also wonder often whether any utility sorting by filename would have is greatly exaggerated (at least in my use cases). And you’ve brought out a great workaround: searching for the suffixed date in part, then sorting the search results. Thank you!

Very useful, thanks! There is much to mull over here. I’ll limit myself to three points in response:

  • I agree that renaming and refactoring are important practices, a matter of maintenance of one’s knowledge garden (especially pruning). My point is about using autocompletion to make connections to other notes as you go. If I keep coming up with new phrases for the same think, I worry that I’ll miss the connections more easily.
  • I suspect that there is a fork in the road that comes early in setting up an approach to a connected system of note-making: whether primarily to (1) writing note titles into the sentences of other notes or (2) referencing related notes separately (at the bottom/top of a note or block, or in an outline - as your example above illustrates).
  • Regarding ZK IDs: the point is well taken about the risk of overwriting files while using file explorer outside Obsidian. In collaborative settings this is also a particularly relevant point.
1 Like

Certainly, if you find value in aliases then by all means use them. I’m not prescribing this, merely describing my own approach. :slight_smile: But you do give me something to think about regarding the possible utility of aliases as I continue working in my notes.

To your second point, I don’t only place links in notes like that; links go where they want to go. Most (non-outline/MOC style) notes have a # References section at the end that will contain one or more of:

  • link to a source note
  • link to a lit note
  • link to an external web resource

Not all notes have that section, mostly those from earlier in my note taking, so I usually add such a section when I find one that doesn’t have it.

As an example I have a note titled Fatigue is an emotion created by the brain based on the level of perceived threat of injury that has no links in the note (just several quotes from two sources) and the following section at the end:


Another one titled A product's North Star metric is the key measure of the team's success in value delivery has a few links inside the note and a references section at the end like this:


I’ve also begun adopting a style loosely based on the approach to introductory signals used in legal writing, where things like See: [[something]] and See also: [[something]] and But see: [[something]] each have slightly different meanings. This gives me a set of supporting, comparison, and contradictory signals I can use when placing links as well.


We have to always remember: [[All models are wrong but some are useful (2012221141)]] so we should use them to gain understanding. But see: [[Abstractions leak (2012292024)]].

Also, on a note titled Reasoning through models yields greater insight this is currently the entire note verbatim:


See: [[Multi-model thinking increases decision making power (2012261259)]]

Contra: Use of abstraction is “a form of mental laziness” per Yudkowsky: [[Create triggerable mental responses that lead us towards rational thinking through concrete examples (L.210206)]]

Clearly I still have work to do on this note! :laughing:

I think that, in many ways, your approach is closer to Luhmann’s, whereas mine feels a bit more like Wikipedia. I think I’d like to incorporate elements from you approach into my note-making practice.

Regarding the last point: there are some people exploring the idea of having different modes of relationship between notes: links of support, of challenge, of elaboration, of illustration, etc. Seems very much worth developing.

Note that one definite negative effect of using IDs in this manner is that it essentially destroys the “unlinked mentions” feature. For example, I just typed the phrase transitive trust into a note I’m writing on the harms that isolated groups pose to democracy (drawing from Paxton’s 2002 paper) because I recognize that transitive trust plays into this based on prior readings. I have not incorporated those readings into my notes yet but I want this phrase to act as a signal. When I do incorporate them I will probably create a note named Transitive trust that will store the core concept. But the current note won’t show up as an unlinked mention because that new note will actually be named something like Transitive trust (2107041341).

What I could do is check the unlinked mentions before I add the ID to the end. I haven’t done that yet because I haven’t used unlinked mentions before, but I can see why it would be very useful. (Though arguably it would be less useful anyway since I may just as well title it def. Transitive trust or Transitive trust (author name) or something, which would break it anyway. Which leads to the general strategy of “write a generic name and check unlinked mentions, then rename” which perhaps I should try to start. ¯\_(́ ◡◝ )_/¯)

1 Like

Really enjoying the conversation and like @AutonomyGaps , I also perked up at the note “Abstractions leak”.

  • Autocomplete is powerful to resurface notes and ideas. Thanks @AutonomyGaps
  • I personally prefer to not use aliases very often. For me, I’d rather have a single statement to articulate a note, rather than several. Having several seems to introduce fuzzier results in my own mind. Thanks for articulating that @davecan

I’ve been using See: and See also: but not as deliberately as you’ve just presented. This is great.

Interesting expansions; they are making me think.

With notes where the date seems to matter (like meeting notes), I’ll usually take notes in a YYYY-MM-DD daily note, then just refactor meeting notes into a new note titled YYYY-MM-DD Meeting description; and all of those timestamped notes stay in a Timestamps folder. It’s been nice to retrieve time-related notes like this and see some chronological context.

But with ZK styled / evergreen notes, those don’t have timestamps for all the reasons everyone has mentioned. Sometimes I’ll put a timestamp in the front matter text of the note, but only if there is some extra reason.


I like this idea of a key phrase as a “signal”. The metaphor that comes to mind is like tossing a floating beacon buoy into the ocean, so that you’re likely to come back to it.

This raises the issue of how best to use backlinks and unlinked mentions. Short distinctive phrases or even keywords (as distinct from tags!) are useful for revealing connections later, since these notes show up in the lists of backlinks. (The “Dangling links” plug-in is also useful for this.)

This is a strategy that is recommended by @EleanorKonik:

Part of Eleanor’s cautionary point, as I understand it, is that tossing out too many of these beacons reduces the clarity of the signal. But she also has a more technical point: she leverages the fact that aliases also show up in unlinked mentions to find variations on a key term. For example, I have an author note about [[Niklas Luhmann]], which has “Luhmann” as an alias. If I go into the “unlinked mentions” part of the backlinks pane, I can see all the references to Luhmann, even if I didn’t use his first name (which is used in the title of the author note). If I click on “Link” for an unlinked mention, then the text is changed in the linked note, but in a way that still hides the first name in the preview mode (via the pipe): [[Niklas Luhmann|Luhmann]].

It also comes up in @nickmilo’s YouTube video with her (which I think you’ve commented on elsewhere).

On the power of aliases, one further point:

They are sometimes useful for phrases that are used regularly, as a sort of “snippet”. For the Luhmann note, I could also have an alias like “the originator of the idea of Zettelkasten (Niklas Luhmann)”. Then, when I type [[Luhmann…., one of the autocompletion options is this: [[Niklas Luhmann|the originator of the idea of Zettelkasten (Niklas Luhmann)]]. It’s a bit of a fanciful point, but I find it very handy for book titles, since for publishing or sharing, I don’t always want to use the abbreviated version that I use for the titles of my literature notes: [[AuthorYYYYShortTitle|Firstname Lastname, Full Title of the Book (YYYY)]].