Diligent Dilettante

ZettelKasten part 1

Building a system for knowledge management

I recently began reading about a knowledge management technique called ZettelKasten. It works well with my current system of bullet journaling which I use to keep track of things to do, log my activity, and keep a pattern of overall mindfulness.

Like most things I develop an interest in, it's a result of a confluence of interests intersecting. In this case, archiving information, owning my own data, journaling, and graphs (in the mathematical sense).

This series of posts is an exploration into system design as I build a system for ZettelKasten which I can run according to my own requirements. And I'll be open-sourcing it.

ZettelKasten

ZettelKasten (literally "notebox" or "slipbox") is a meta-textual knowlege-cataloging method. The method encourages frequent logging of knowledge and organizing it in a way that promotes discovery of related knowledge.

If you're familiar with "Getting Things Done" as a method for task management, it will seem immediately familiar, but with an orientation around knowledge rather than task management.

The method

The classical method of ZettelKasten as performed in a physical way consists of storage of notes ("zettel"), normally on index cards. It was described by prolific sociologist Niklas Luhman in his essay Communicating with Slipboxes and expanded by ardent practitioners of the method. A fantastic guide is this one by Tomas Vik. These notes are written quickly when notable information is encountered ("fleeting notes") or written while researching ("literature notes"). These notes then go into an inbox to be categorized. When reviewed, they are connected to form "permanent notes" - one's own thoughts as a result of digesting information. "index notes" reference notes on a topic to help build connections.

Characteristics of the method

The ZettelKasten method has several important aspects.

What I want

I've reviewed a lot of systems for ZettelKasten, but they all fall short in one way or another:

My system will:

Stretch goals (I'll update as I have more ideas):

Building a system to accomplish these goals

Our first goal is to define our data models. This isn't necessarily the first step of any system design, but I've opted to start here because the systems purpose is to store and relate data. ZettelKasten is largely based around particular methods of describing notes, and this is a good place for us to start.

Let's begin with a single note, or "Zettel"

The anatomy of a Zettel

A basic Zettel

The simplest Zettel is a fleeting note, an inspiration with no reference to other content.

First an foremost a Zettel contains information. The body or text of a zettel is a small note about a subject. Ideally the content of a Zettel:

Zettel also need a "stellordnung" - an ordered position. They need a place in a hierarchy, though it need not be a tree. People choose to make this a number, a guid, a title, a timestamp. It needs an unchanging id so it can be indexed and referred to by other notes.

A research Zettel

A research Zettel contains a bibliography or reference to a text being described. Historically, this would usually be a book, but we may want to consider any arbitrary resource. A book, a webpage, a movie, a video file, a recipe. Anything which has information we could study and which we can reference. Ideally, we would store an archive of that information at the time of study in order to avoid link rot, though this might not always be possible. And of course we would want to store the canonical location of any archived data.

An index Zettel

Index Zettel contain references to other Zettels by their stellordnung. In a modern computing system an Index Zettel need not exist, tags themselves can "self organize" as a queryable source. However, it does make sense to make Zettel that describe an index and our thoughts on it.

Defining a Zettel in code

Let's fire up typescript and get started. Why typescript? It's fast and easy and I have it on hand. I try not to let the perfect be the enemy of the good. This series is all about building this system as rapidly as possible while fulfilling my goals. It's an experiment. Let's go wild.

export interface Tag {
uuid: string,
name: string
}

export interface Resource {
uuid: string,
canonicalURI: string,
archiveURI: string
}

export interface Zettel {
content: string,
uuid: string,
title?: string,
tags: Tag[],
timestamp: Date,
reference: Resource
}

Well, that'll do. You might say "but Dilly, that's certainly not going to cover all the use cases." First of all, don't call me "Dilly." That's far too familiar. Second of all, of course this isn't final. Why would it be? All that matters is that it is a start.

In the next step, let's find the optimal way to store this type of data.

The adventure continues in
ZettelKasten Part 2