Questioning some Original Zettelkasten Practices

mlevison

Like many, I'm attempting to build my personal Zettelkasten using a computer and software tools. As my tiny practice starts to evolve, I starting to question some of the practices that are central to the paper version.

The core value in any form seems to be small atomic notes that are interlinked allowing for discovering relationships, chains, and threads that hadn't previously been noticed. Additionally, I've been reminded as I spending time thinking to write my notes the very act of reframing in your own words makes an idea your own.

Practices in question:

• Dates as IDs instead of names
• IDs can't be changed
• Links must be bidirectional

IDs are derived from dates - In the original paper/index card version unique IDs were key because you needed a way of avoiding collisions. I.e. one ID pointing to two different things. In addition, unique IDs helped organize the cards for faster retrieval. In the world of computers and filesystems collisions are avoided because we can only have one file of a given name per directory. Lookup/retrieval is instantaneous on a computer. Date IDs are really annoying because they don't tell you anything about the content, names give you a hint as to the content. I give you: 202001191122 vs KingmanFormula,

IDs can't be changed - yet in the world of software development renaming things is a key habit we discover the name doesn't quite fit the purpose - we rename it. Often called: Rename Method (https://en.wikipedia.org/wiki/Rename_method) and Rename Class - in most development environments these are implemented with automated tools. In text/markdown files this is called search and replace.

Links are bidirectional - Does this make sense? If I'm looking at the KingmanFormula and I wonder what links to it - I search all files in Zettelkasten that have the text KingmanFormula.md.

The Talking Head's were right - Zettel users: Names make all the difference.

What paper practices have you found that deserve a rework in the digital world?

Sascha

Is your point that unchangable IDs are problematic because you want to change the title to keep it connected to the content of a Zettel? If so, there is no problem in the first place because a Zettel has an ID and a title. It is not "202001191122" or "KingmanFormula", but "202001191122 KingmanFormula". You can change the title as you please and should change it.

MartinBB

Personally, I regard IDs as absolutely essential. Indeed, it would be nice if The Archive used UUIDs in my view, but that is another question. Part of my reasoning for IDs is that I don't only want to find notes from inside a directory -- I want to find them from anywhere. With an ID I can stick that in any file anywhere, and use it as a search term, or even a link. It will still work even if I change the name part of the file. Try having six or seven pieces of writing that all link to a particular note through its name, which you then change, then remember that you also have to change it in six or seven other files, and you can't remember what they were or where they are. Maybe you don't use file linking in that way in your work, but I do, hence my opinion of IDs is different.

Will

@mlevison said:
What paper practices have you found that deserve a rework in the digital world?

We're so lucky not to be limited but the 'card' size for a note and our sloppy handwriting.

@Sascha is right on by suggesting using both, not either, a UID and a name. Why limit yourself. Not like this takes up CPU time or disk space.

Sure, for link integrity, it would be necessary for the software to do an automated search and replace every time you changed a title when not using a note UID for linking. But as @MartinBB hints at, would you be comfortable with the software doing a comprehensive hard drive search and replace for links embedded in other documents outside your zettelkasten? Oh, you have a collaborator or editor and have shared notes, do you have the search and replace scan his machine too? Soon we'll be scanning the whole internet to be sure we've got every use case, every deviant use of Zettelkästning covered. Maybe this is hyperbole and edge-case, but we may get there one day. There may be technical issues we're not considering. We need to be watching to be sure our software stack doesn't bloat and become fragile.

@mlevison said:
Date IDs are annoying because they don't tell you anything about the content, names give you a hint as to the content.

This may be true for you so far, but I have used the Dates IDs to place them in the context of the history of my life. A grand way of saying seeing the date sets the note in time. Granted, putting the note in time is less than super helpful but sometimes adds a smidgen of context. I'd downvote the switch to a UUID as these are human unreadable.

@mlevison you are on to something here. You are thinking outside the box, differently.

mlevison

A little more background on my first few months of this game. I've been building growing my Zettelkasten by writing notes in Markdown and interlinking manually. My current tools of choice - Visual Studio Code with two extensions: Markdown Preview Enhanced and Markdown All In One - because it supports intellisense for filenames/linking.

If you're not familiar with Intellisense - basically you type a few characters of name and the tool starts to offer options that match. Colleagues have joked that they never see me type more 4 characters of a class/method name before I've got match. (More details: https://en.wikipedia.org/wiki/Intelligent_code_completion#IntelliSense). Key point for any intellisense approach - type only a few characters and the unique item is picked.

As recovering software developer this feels like a fairly minimalist/lightweight approach. Its also what made me reflect on the limits on IDs.

In a markdown world atoms or zettels seem best as files.

@Sascha the challenge with: 202001191122 KingmanFormula is that its not an easy name to type or remember. When I want the first characters that will appear in an intellisense will the same 2019 or 2020. Second they won't tell me what I'm looking at. With the first windows tool I tried it didn't display enough of the name for me to see even the whole id. If the name is the ID then even if it the tool only displays a few characters I still have a good idea. I'm sure I could add date ids at the end, I'm just not sure the benefit.

@MartinBB Perhaps this is one of the key differences - my system lives inside one set of folders all of which checked into Github in a private repo. The structure will undoubtedly grow over time with more and more subfolders but search and replace will be limited. As to the question do I trust it? Up until about 2003 if I wanted to rename a method/class in my source I did a find and replace. Around that time the "rename" refactor became a standard tool in all Development tools. When I have spare time I will take a lot at what it would take to implement that as an extension Visual Studio Code and Markdown documents.

@Will If you collaborate with me we will use Github, all changes are synced through there. If you're working with me and you edit a file where I've done a rename both preserved. Really worried - scan the differences everytime your partner makes changes in the repository. Really really concerned - eventually you write a markdown link checker and run it after every change - use it to find broken links.

As the value of dates for reminding of us of history - Windows/MacOS already store date created as metadata. I suspect git does too - I've never looked.

My challenge to all of us - how can we make the approach, faster and easier to use.
Mark

MartinBB

I have often observed that when people make recommendations of software, they are usually telling us as much, if not more, about the kind of work they are doing as they are about the software. Working methods, and requirements, vary wildly with the field of study (if it is study) not to mention with the individual concerned. (I tend to regard individual+work+method+software as a system.) I work in psychology and the humanities (mainly history) so there is probably very little in common with what a software developer needs to do. There is a well known phenomenon in psychology, called the False Consensus Effect, which crops up all over the Internet. Basically, we all (without realising it) assume that other people have opinions that are more like ours than they actually are. Because I am very different, and my needs are very different, the challenge of making the approach "faster and easier to use" has almost no resonance for me. The main block on my productivity is how long it takes me to understand something, not how long it takes me to find things or type things. I habitually create Zettels with just an ID and no name, because I cannot think of an appropriate one at the time. I may leave such a Zettel for months until my developing understanding of what I am doing provides me with the insight to come up with a name element that adequately summarises what the Zettel is about. Naming is part of the process of understanding, for me, not merely about finding things. But then I'm a bit of a Social Constructionist on the quiet. And when it comes to searching for things, I might add, I am almost never looking for the name. I am much more likely to be looking for content or tags. I usually want a collection of Zettels relating to a theme, not a single one. As I follow academic practices, I may also find the Zettels I want through the fact that they have a temporary citation marker showing that they have come from a particular book or article -- and that will be in the body of the Zettel, not in the name. That is how I link much of my work together -- through temporary citation markers and tags. But I realise that other people will work very differently. One of the good things about this method is that it is flexible, and can be used in many different ways.

Just to go back to the question of UUIDs, I would not want them instead of date/time IDs. Reflecting, I think the date/time IDs are good enough, but I sometimes wonder if it might be useful to put a UUID in the metadata. Perhaps not.

ctietze

Since the term "refactoring" was mentioned: there's good news for all yer lazy fellas. Zettel refactorings are going to come to The Archive eventually, when the v2 set of features is tackled.

@mlevison: When you already do have an IDE that works for your wiki links and want to rely on it (!) you can consider adding the ID at the end of the file name: 202001191122 KingmanFormula becomes KingmanFormula 202001191122.

• This will prevent The Archive, nvALT and apps of similar behavior to identify the best match by looking for the search term at the beginning of the file name, so you have to select the note manually.
• You'll also lose the capability to tab-to-complete file names in Terminal based on the ID, so a [[202001191122]] link will end up producing a bit more inconsistent behavior in daily work. Then again, how often do you do that And ls -l | grep 202001191122 to find the file name isn't that much more work, can be extracted into a findzettel alias or function, etc.

I have never tried not linking to Ids, because of the problem of stability of links and to keep my setup software agnostic. I want it to work with the most basic form of computer system, a Terminal, or a web interface directory listing, if I have to.

A git clone will actually create the files at the current point in time, so that metadata is lost. That's probably because Git really is an object-based file system on its own. Dropbox preserves metadata, until it accidentally doesn't. Files copied between macOS and Windows will lose the info, too. You're only safe while you're on the inside of BSD/UNIX environments In that case I'd rather go back to adding a 2020-02-01 07:45 time stamp to my note headers and probably use a YAML Frontmatter, because that's trivial to strip out with the currently available tools if I need to process the notes automatically.

Sascha

@mlevison wrote:
@Sascha the challenge with: 202001191122 KingmanFormula is that its not an easy name to type or remember. When I want the first characters that will appear in an intellisense will the same 2019 or 2020. Second they won't tell me what I'm looking at. With the first windows tool I tried it didn't display enough of the name for me to see even the whole id. If the name is the ID then even if it the tool only displays a few characters I still have a good idea. I'm sure I could add date ids at the end, I'm just not sure the benefit.

You got this backwards. You try to adapt the method to the software you are using. This is the first step into the trap of software dependency. Not only this. You are holding to software related features that seem to increase your efficiency as you are working right now. But saving a quarter second per string is not worth the cost of becoming dependend on the software and losing functionality of the method.

Because of your fixed outcome-related conclusion you need to make many assumptions that are not well-justified but rather claims. See this example:

In a markdown world atoms or zettels seem best as files.

This is wrong as you identify a Zettel with a file. There are one-file-solutions like TiddlyWiki which can be used as a Zettelkasten. This is not a recommendation in general. But for some people it works fine and can be used as the software solution to the underlying (Zettelkasten) Method.

Even in Markdown this is wrong. I use a one-file-approach for a software independent introduction into the method.

By making assumptions based on the validity of an already chosen software solution you create learning barriers to method-related problems. The practice of unchanging date-based IDs is not a solution to the paper version but the result of the generalisation process to make the Zettelkasten Method independent from its manifestation (being paper or specific software).

Atoms are entities that are the smallest adressable units. The distinction between files is arbitrary and there is no principle problem having multiple Zettel in one file even if this practice is flawed in most but not all use cases.

You can adapt the principles, alter them or even ignore them for your personal solution. You should as all of us are different. But in my opinion, you need to make yourself more familiar with the older material because quite a few of your assumptions are based on you being very experienced and probably skilled in one domain and importing claims that become invalid once you switch to the similar looking field.

NiranS

Software dependency. I would rather have fewer features than be dependent on the specific features of a particular program. I should be able to create, and access my system from any text editor on any platform. Linking should be human readable, easily searchable and prominent. I want a “link” that is clearly visible and I understand what it refers to on any system.

I like the Archive because it adds some nifty tools to find, link and tag Zettels, but I am not dependent on it. As for UUIDs - use them on indexed files in Devonthink and get the best of both worlds. But, using them as a way to reference files directly in a Zettelkasten, limits portability.

I think the OP original issue stemmed from not seeing enough of the title to make linking easier. This is a limitation of the software and not the method.

Will

I want to add my voice to @MartinBB's comment.

@MartinBB said:
I have often observed that when people make recommendations of software, they are usually telling us as much, if not more, about the kind of work they are doing as they are about the software.

I'm certainly guilty of confabulating workflow with tools and thinking I have "everything dialed in perfectly". I'm at my best when I relax, am open to change, am open to suggestions, and steal ideas from anybody and anywhere if it helps.

Working methods, and requirements, vary wildly with the field of study (if it is study) not to mention with the individual concerned. (I tend to regard individual+work+method+software as a system.) I work in psychology and the humanities (mainly history) so there is probably very little in common with what a software developer needs to do.

Thanks for the reminder that I am an n=1 when it comes to fields of study and prefered knowledge building stack (individual+work+method+software).

There is a well known phenomenon in psychology, called the False Consensus Effect, which crops up all over the Internet. Basically, we all (without realising it) assume that other people have opinions that are more like ours than they actually are. Because I am very different, and my needs are very different, the challenge of making the approach "faster and easier to use" has almost no resonance for me.

Reminds me of the Curse of Knowledge. The phenomenon where I think because I know something, it is common knowledge and everyone is in agreement with me or clearly stupid.

The main block on my productivity is how long it takes me to understand something, not how long it takes me to find things or type things.

Beautifully said. I want to focus on growing my understanding of science, technology, art, humanities, literature and have my stack be in the background and support not dominate that goal.

I habitually create Zettels with just an ID and no name, because I cannot think of an appropriate one at the time. I may leave such a Zettel for months until my developing understanding of what I am doing provides me with the insight to come up with a name element that adequately summarises what the Zettel is about. Naming is part of the process of understanding, for me, not merely about finding things. But then I'm a bit of a Social Constructionist on the quiet. And when it comes to searching for things, I might add, I am almost never looking for the name. I am much more likely to be looking for content or tags.

I do something similar I don't tag my notes when I create them. I experience the tagging as part of my "process of understanding". Hadn't considered using the naming of the note as part of the "process of understanding". I'm stealing this idea!

I usually want a collection of Zettels relating to a theme, not a single one. As I follow academic practices, I may also find the Zettels I want through the fact that they have a temporary citation marker showing that they have come from a particular book or article -- and that will be in the body of the Zettel, not in the name. That is how I link much of my work together -- through temporary citation markers and tags. But I realise that other people will work very differently. One of the good things about this method is that it is flexible, and can be used in many different ways.

Just to go back to the question of UUIDs, I would not want them instead of date/time IDs. Reflecting, I think the date/time IDs are good enough, but I sometimes wonder if it might be useful to put a UUID in the metadata. Perhaps not.

As soon as you start down the path of storing metadata, you sauntering towards proprietary, lock-in, export failures, and other disasters.

Thanks, great post.

mlevison

@MartinBB thank your thoughtful note, it gave a perspective I didn't have and I appreciate it. Thank you for reminding of False Consensus Effect - it was nice play on your part.

All several people have suggested that my questioning is tied to the software/implementation. It is not, I'm attempting to make whatever I approach I use independent of the tooling. Since I only use Markdown and links - I've managed to try about 10 different tools to edit. If it helps think of Intellisense as a small benefit from using names not the key function.

First all systems we build are tied to their implementation. In Luhmann's case the implementation was the index card and metal filing cabinets. The date/time IDs are a function of that system.

Since I've had decided not to use index cards for my knowledge system (although most of my initial note taking does happen on index cards), then do build it with software. Since I'm doing that I simple tried to start from first principles:

• Atomic notes
• Links to denote relationships

Coming from a world of software development, we normally ask the question "what is the simplest thing that could possibly work".

When it came to DateTimeID I got stuck is this really a core principle? Why? What benefit does it provide? This is all I'm really questioning. It doesn't feel simple.

Cheers
Mark

MartinBB

Thank you to both.

"what is the simplest thing that could possibly work" -- Occam's Razor (as it is known in philosophy) basically. Not always easy to implement!

henrikenggaard

@mlevison I've thought many of the same thoughts recently as I have been learning about Zettelkasten. I asked a question in a similar vein on Reddit at r/Zettelkasten "Time stamps, why? What is the big advantage?".

Of course, I can only speak for myself and I am not experienced in using a Zettelkasten, but I decided against having numeric/date IDs for my notes. I can't say that my reasons are fully informed, but I've done my best to understand why numeric/date IDs are useful, but I just done see the benefit for my system. Issues like renaming and avoiding metadata about dates are, in my eyes, not big issues.

If it turns out to be useful with numeric/date IDs, then adding them is extremely easy if you know any programming language. I don't see why it wouldn't be worth trying to see if it works.

Sascha

@mlevison
First all systems we build are tied to their implementation. In Luhmann's case the implementation was the index card and metal filing cabinets. The date/time IDs are a function of that system.

No. As already stated:

@Sascha wrote:
The practice of unchanging date-based IDs is not a solution to the paper version but the result of the generalisation process to make the Zettelkasten Method independent from its manifestation (being paper or specific software).

Luhmann did not use date/time IDs. He used a hierarchical ID-System to provide his Zettelkasten with physical order. (for example: Having most of topics nearby and not too spread out)

You can read his translated article here: Communicating with Slip Boxes

He didn't use metal filing cabinets by the way but wooden ones.

donblanco

@mlevison said:
A little more background on my first few months of this game. I've been building growing my Zettelkasten by writing notes in Markdown and interlinking manually. My current tools of choice - Visual Studio Code with two extensions: Markdown Preview Enhanced and Markdown All In One - because it supports intellisense for filenames/linking.

If you're not familiar with Intellisense - basically you type a few characters of name and the tool starts to offer options that match. Colleagues have joked that they never see me type more 4 characters of a class/method name before I've got match. (More details: https://en.wikipedia.org/wiki/Intelligent_code_completion#IntelliSense). Key point for any intellisense approach - type only a few characters and the unique item is picked.

As recovering software developer this feels like a fairly minimalist/lightweight approach. Its also what made me reflect on the limits on IDs.

This is why I love keeping things plain-text. I can use any text editor to insert a link manually with brackets and parentheses. But I can also use more 'fancy' editors to automate. Right now in VS Code if I have already copied a link, I can highlight a word or words and just Ctrl/Cmd+V and it automatically creates a markdown link with brackets and parentheses in place. Or I can highlight a word or words and hit the bracket key. Brackets are inserted. I then move the cursor to the right, hit the opening parenthesis key, and the closing parenthesis is added, and I also have an Intellisense pop-up list of all possible documents I can link to! I love this approach.

Eurobubba

@NiranS said:
As for UUIDs - use them on indexed files in Devonthink and get the best of both worlds. But, using them as a way to reference files directly in a Zettelkasten, limits portability.

I'm probably missing your point, but it seems to me it should be just the opposite. Any modern computer system should be able to search for a UUID within a text file or more or less anywhere that can be externally accessed at all. Using a UUID as "primary key" is about as portable as it gets.

Eurobubba

@Sascha said:
He didn't use metal filing cabinets by the way but wooden ones.

And thin paper slips, not index cards, while we're at it! :-)

Glade

Gathering all this together it looks like a good link tag should be:

• Short: 720af740-b5d7-4c12-bfb6-2a4a3c8c19e3 is just unwieldy.
• Unique: Collisions break the system
• Permanent: links shouldn't change so that files that point at them don't need constant updating
• Searchable: easy for programs to look for and identify
• Visible: not buried in invisible metadata somewhere
• Not ugly: note linking should be fun not hideous to look at

I'm growing my system from a bunch of unlinked notes and I settled on a format that looks like ^k4P^ or in a markdown-friendly hyperlink [Some descriptive text](k4p). Software can generate a sequential non-colliding series of these kinds of tags, they're easy to search for and copy/paste.

If you really wanted to you could date-index these but I'm not yet sure how much value there is in knowing when the note was created.

What do you all think?

Cristiano

@ctietze I’m totally new to Zettelkasten, so this has possibly been talked about before.

Would it be helpful / practical to define that the first line in a Zettel contains its ID and the second line its title / short description? So the new anatomy of the Zettel would be:

1. A unique identifier (can be just an identifier, like the suggested date+time number, or this identifier plus text, if the user prefers it that way)
2. Title of the Zettel (changeable and can be used to search/list and automatically order multiple Zettel(s) with the same or similar titles.)
3. The body of the Zettel.
4. References

This would maybe make it set up more like a data set in a database table. The first column contains the unique ID and all other columns contain data related to a specific subject.

If all Zettelkasten users agree on this extended anatomy then all software used to work with the Zettelkasten method can take this into account. I also have only very rudimentary programming knowledge, but it seems to me that it’s probably a trivial thing to write a command that searches in the first or the second line of a text document, depending on the what the user is looking for.

ctietze

@Cristiano I don't have high hopes for such conventions because the result looks weird to humans I do have higher hopes for conventions like "use first line of the note as the file name", for example, and then make the app be clever enough to ignore e.g. leading Markdown heading # characters.