Zettelkasten Options

Dear community, I'm looking for a comparison of the various note-taking-packages implementing the Zettelkasten-method. I don't want to build *a second brain* or create a personal wiki, instead I want to capture and link ideas for researching and writing. Using `org`, I'm naturally drawn to [`org-roam`](https://github.com/org-roam/org-roam), however, I dislike the bulk of dependencies and its complexity stemming. Furthermore, I dislike, that I can't get a textual overview of a subset of notes belonging together (using a webserver-solution like `org-roam-ui` is not what I want here). Looking at the new [`zk`](https://github.com/localauthor/zk)-package, I want to note that I like its simple and clean approach, but I dislike, certain design decisions, like using spaces in file names and the fact, that it doesn't integrate deeply in the `org`-ecosystem, e.g. not utilizizing org-IDs. The last point is the biggest downside imho. While one could hack on the codebase to change this, another drawback seems to be that it is not really mature and doesn't seem to have a large userbase. Currently, I'm try out both of these very different options, but I can't really decide for on or the other, since both have different strengths and downsides. Therefore, I want ask for your opinions and experience with implementing the Zettelkasten-method (or a personalized derivation of it). Which horse should I put? Thanks in advance!

>While one could hack on the codebase to change this, another drawback seems to be that it is not really mature and doesn't seem to have a large userbase. Well, it is brand new code. You could open an issue on that tracker and see if he's open to such changes?

Already contributed a few things which were more or less welcome. However, the maintainer works (mainly?) with markdown and does that most probably in his leisure time, so I'm not certain whether we will see improvements regarding the things I previously brought up. Are you using `zk` yourself, /u/bdarcus?

No; I've haven't tried it. But it's author contributes to my citar package, so was intrigued.

[I don't think that most people actually need the complexity of Zettelkästen](https://karl-voit.at/2020/06/14/Zettelkasten-concerns/). So [I personally settled for simple bi-directional links with human-readable IDs](https://karl-voit.at/2020/07/22/org-super-links/). YMMV.

>not certain whether we will see improvements Only way to find out is by opening issues! ;) The no-spaces-in-file-names thing should be fairly simple, depending on your expectations for how inserted titles should be handled. And I don't use org IDs, so I'd need to hear a bit more about how they might be integrated. The package originally had a `zk-org.el` extension, but it wasn't substantial enough to warrant a separate file. So maybe it could come back with org ID implementation? UPDATE: opened a PR for no-spaces-in-file-names here [https://github.com/localauthor/zk/pull/5](https://github.com/localauthor/zk/pull/5) ; ready for some testing

Honestly I've been in the same boat as you for ages and have even tried writing my own zettelkasten packages here and there on top of things like [deft](https://github.com/jrblevin/deft) (I started with [zetteldeft](https://github.com/EFLS/zetteldeft), which shows). In my opinion all necessary zettelkasten functionality can be built upon one thing: A robust searchable index of all notes in your zettelkasten. I tried to do this on top of deft, but unfortunately deft is designed as a user-focused package and can't be reasonably used as a library. I [tried](https://github.com/lambdadog/zettelkasten-mode), mind you (warning: this package is very broken and hacky), but even if I had gotten that to work I think I would end up wanting a richer index and pre-processing of input data (when entered into the zettelkasten index, I should be able to parse out all forward-links for example, and store them separately so they're searchable without a regex over full-text).

Sounds like you might want to give [zk](https://github.com/localauthor/zk) a try and let me know what you think! (I'm the author, full disclosure.)

Orgmode is by itself a zettelkasten tool. I just use superlinks and custom settings, and no specialized package is needed for my zettelkasten.

What complexity would be that? I find it's a simple system.

Have you considered adding a custom org link type? You wouldn't be able to use your current link format I don't think, but instead of, say, `[[202012091130]]`, you would be able to use `[[zk:202012091130]]` and it would have the full support of the Org ecosystem without having to advise any functions, including things like `#'org-store-link`. As an example, see [`zettelkasten-org.el`](https://github.com/lambdadog/zettelkasten-mode/blob/master/zettelkasten-org.el) in my unmaintained zettelkasten-mode. That said I will definitely check it out, it seems interesting.

My understanding of Luhhman's method is that you arrange related notes proximally. This then encourages discoverability. Is this what you're looking for from Zettelkasten? In any case, I use org-roam. Retrieval is the vast majority of what I do with notes (other than writing them). org-roam does it extremely well. I tried org-brain and found it interesting, I can't recall now why I didn't stick with it. I also tried a zettel package integrated with deft, but searching my notes was too slow (3 megs, 400 files), so I stopped. I'm sticking with roam: - external index is the killer for me, it's so fast. - it uses basic org primitives, so with out org-roam you don't lose your structure. - org-roam-ui is the "proximal arrangement" I was talking about initially. Or at least a visual representation. > I dislike, that I can't get a textual overview of a subset of notes belonging together I think you might be looking for [delve](https://github.com/publicimageltd/delve). It allows to create collections of notes and operate on them.

>Only way to find out is by opening issues! ;) That's right. Thanks for being active and responsive -- here and on Github. >The no-spaces-in-file-names thing should be fairly simple, depending on your expectations for how inserted titles should be handled. > >And I don't use org IDs, so I'd need to hear a bit more about how they might be integrated. The package originally had a zk-org.el extension, but it wasn't substantial enough to warrant a separate file. So maybe it could come back with org ID implementation? > I think the biggest downside is, that the ID is not placed in the file name anymore. While it is easy to add `org-id-get-create` in `zk--generate-id`, all the functions operating with the ID, like `zk--parse-file` and `zk--parse-id`, would need to operate on the `:PROPERTIES:`-block within the file instead of a list of file names. So, this might be not as efficient and a notable downside. I'm also not sure, if org-IDs are that much beneficial. IMHO, the main advantage would be, that one could follow links using plain `org-mode`. But maybe this would be just a step in a direction of overengineering, which I actually don't like that much in solutions like `org-roam`. >UPDATE: opened a PR for no-spaces-in-file-names here https://github.com/localauthor/zk/pull/5 ; ready for some testing It works great. A minor addition to `zk-index.el` has been submitted, however. It would be great, if you could have a look at it.

Thank you very much for your thoughts. Your reasons for staying with roam sound very reasonable. The hint on `delve` is great! Thanks for that. That is basically what I was missing when using roam.

Interesting link on `zettelkasten-mode`. I totally agree on the point that "a robust searchable index" is the central aspect of a zettelkasten. Nevertheless, I would prefer, if it integrates nicely with the ecosystem and some other packages for convenience. Which tool are you using now?

Would you elaborate that, please?

Thanks for the links. A lot of ideas are very relatable and I agree, that the Zettelkasten might not fit the general note taking needs. As I pointed out, I am specifically interested in utilizing the zettelkasten-method in a research-workflow aiming to assist (and track) a structured cognition process. However, tools like `org-roam` and `delve` (which I recently checked out) introduce a certain degree of complexity to the system -- especially if you want to understand the technicalities of the utilized solution. Therefore, I'm very much intrigued by `zk`, developed by /u/oldjawbone recently. Asking you as the die hard PIM-enthusiast who you certainly are: What is your opinion on [`zk`'s](https://github.com/localauthor/zk) general design decisions? Do you think it is reasonably future-proof,/u/publicvoit?

First, being a researcher is one of the few situations where I do understand that Zettelkästen are something with a benefit. zk does seem to be a consistent approach with clever design decisions. Future proofness depends on two factors here I guess: the data collected and the tools support for making use of those links. In [Orgdown](https://gitlab.com/publicvoit/orgdown/-/blob/master/README.org), access to data and being able to read it is never the issue. Tool-wise, zk uses standard Org-mode features as much as it can. So I'd say you're good to go with that approach.

I do see additional complexity and effort on many levels. The use of an external database (some implementations; at least it is just an ephemeral one), the use of an independent tool for graphical navigation (although web browsers are common and probably the most sane choice for this but it is still a media break), the need for splitting up every (small) note, the theoretically exponential(?) effort to link new nodes to existing ones if you take the method serious (AFAIR Luhmann spent large amounts of time just maintaining his Zettel), the sometimes non-standard Org-mode way of linking headings and so forth. Compared to other systems it is a simpler system. Compared to my method with standard Org-mode extended by bi-directional links it isn't IMHO. Again: I can think of using a Zettelkasten method if I personally would profit from the 2D-navigation. At the moment with my use-cases I just don't think that this offers me personally any benefit but would cost me much more maintenance effort. YMMV.

I'm currently not using any tool, although I am playing around with binding [Milli](https://github.com/meilisearch/milli) and [the most up-to-date Mentat fork](https://github.com/mwatts/mentat) to emacs with [emacs-module-rs](https://github.com/ubolonton/emacs-module-rs). The first promises to be an easier binding but I think the second could be incredibly robust once I decide on/find a DSL to represent datalog in elisp well* (it does include full data search as well, although it won't do it as well as milli I imagine). I'm liable to use either or both to implement a simple zettlekasten package once they're bound. *So far I've found [this](https://github.com/clojure-emacs/parseedn) but it'll likely take a little more investigation until I find something I'm entirely happy with

You can run deft on top of org roam to handle searching via text interface. I've had good results with org roam so far. I used zetteldeft before switching over for the bells and whistles.

In the zettelkasten notes are one behind another, just like sequential headlines in orgmode. Notes take ramifications for different matters, just like headlines levels in org-mode. In the zettelkasten, notes that are related but not sequential are "linked", just as you can do in org-mode. You can have too in different places headlines for references (external books, etc) and link to your notes as needed, as in the zettelkasten.

I think the fancy software implementations and their fireworks could have blinded you. Zettelkasten is not that: https://www.reddit.com/r/emacs/comments/swg4bx/comment/hxrhbmi/

If you interpret the Zettelkasten method in this simple "no hierarchy form" way, I agree. However, I don't see much difference between "one file with many linked headings on the same level" and your interpretation of Zettelkasten. For this, I would not need any complex framework, I totally agree. [The Zettelkasten method](https://en.wikipedia.org/wiki/Zettelkasten) according [to Luhmann](https://zettelkasten.de/) is so much more than this. Even org-roam and other implementations do implement a (more sane) sub-set of the original paper-based workflows. And this involves navigational workflows, a clever indexing method, periodic re-linking and partly re-ordering of some sorts, ... I was referring to the non-trivial Zettelkasten usage.

I can't be much of help but for the "see notes grouped together", while not perfect can be done in various (a bit long/mechanic) ways with org-ql and/org org-transclude. It's not as easy as a paper based ZK with a set of card on a desk, but you get all the benefit of a computer-based system witch are much more powerful in general than paper... org-ql unfortunately does not output an org-mode buffer, but still offer a dedicated major mode that list all results, enter/click on a note brings you in the relevant place. With two buffer side by side that's "almost" re-create the ability to have dynamically grouped notes in a single place. Perhaps (never tried) something similar can be done with consult+embark at a less fine level but with similar results and less mechanics. For such "card-like" usage perhaps TiddlyWiki do a better job in it's WebUI, it's limited, enormously limited, compared to Emacs, but offer a really effective and deadly simple transclusion that let the user easily compose notes in an instance and have many of them individually shown in the UI. I do not know nothing already implemented in Emacs that do the same, while formally all the ingredient are already there to bake one. In the past was announced a "simplified org-roam" package, actually a totally different one in code terms, that puts the backlinks in the note itself, unfortunately I can't recall the name... I just rememeber a demo with some kanji + ascii chars, with a light theme... Other classic options (like NotDeft witch use lucene as backend) or org-brain, org-wiki etc do not seems to meet your criteria...

The ZK links are actually "complex" in the human readability sense, they are like that just because on paper there aren't many options, but re-create that on a computer IMVHO it's ridiculous... It's like buying a Pagani (the most expensive sport car on the market I AFAIK) than body-lift it an putting some extreme mud tires just because 4x4 body-lifted vehicle with such tires exists and works well in certain natural environments... ZK index/catalog is made to work on paper, yes if force a bit of regular upkeep, but without giving back something valuable. Instead features common on computer based systems like queries, full-text search, tagging etc gives back much, much, much more... The sole downside I've seen so far is in information cleanliness terms: if I have to write on paper, store paper properly, I keep a better attention, I write better in clearness and synthesis, expressiveness terms. But while it's hard to mitigate that on digital systems the better tools you get compensate many times IME... In the end that "polemics" happen in the recent past where most UIs ditch classic menus for search&narrow UIs: many said that's menus gives discoverability, better grip of what's available etc, but in the end almost all have ditched menus simply because it's more valuable a computer-mediated immediate access then a hierarchical discoverability in most cases. Traversing the ZK index might let you discover new things while looking for something, but just trying a full-text search on your ZK likely made *many more* new things and connections emerge...

Do not limit yourself to tags :-) with org-ql you can create as much complex metadata and queries on them as you wish. Certainly it's long, you need a catalog note, perhaps some snippets/org-roam-capture templates etc to ensure consistence and a regular a bit tedious update, around an order of magnitude more work than mere tagging, but also the outcome might be an order of magnitude better!

I don't think Luhman's ZK is "more" than my implementation. But anyway, I'm happy, you're happy, and if I can help, let me know. Hug!

`Hi u/oldjawbone, allow me to pose a quick question: How does the performance of `ripgrep` for identifying backlinks scale? What was the biggest zettelkasten you operated with `zk`?

I've done stress testing on a zk-directory containing 20,000 notes and found that things scale fairly well. It never took more than a few seconds to list backlinks, even when there were \~1000 backlinks to list. Seemed good enough that I didn't do extensive benchmarking/profiling. BTW: in the interest of keeping things in one place, in case others have similar questions, I've set up a 'discussions' section on the repo, for questions like this