My Personal Knowledge Management System Design

I use a personal-hacked variation of Zettelkasten. I read about it mainly from (Ahrens 2017).

Generally, a note is an org-mode file. All its headlines are only for locating. That is, references to its headings should be counted as references to the file node itself.

I have several link types as inspired by (Hubmann 2020; alan 2020):

id

Plain-old id links. They are forward links to the corresponding target note files, or maybe subheadings to be more specific.

related

This is basically a linked version of tags. A note with this kind of links is related to the corresponding topics.

follow

A note with this kind of links means that it is a follow-up of the target note in the original Zettelkasten sense. That is, if the source note is indexed abc, the target note is probably indexed ab. Usually that means a is-next-post-of relation. This is meaningful when reviewing, because I can recover the context of taking down the note.

under

A note with this kind of links means that it is a sub-topic of the target note. In normal structural organizations, that usually means the source note is a subheading of the target note.

translate

This type of link is mainly used for blogging. If I have a translated version of a previous note, the new note should point to it with this link type.

Tags are notes themselves, and notes tag themselves using Link Tag related pointing to those tags.

I use a personal variation of P A R A method for tagging. My understanding of it and my implementation is as follows:

Projects

Active tasks showing in the front of agenda, tagged with under:Project in PARA. Belongs to areas, using related:SOME_AREA

Areas

Responsibility or standard maintained, tagged with under:Area in PARA. Things marked with Areas are hidden from publishing by default.

Resources

a topic of ongoing interest, tagged with under:Resource in PARA. Things marked with resources are publishable (even if they are related:SOME_AREA).

Archives

the things hidden from my agenda. The whole points of archives in PARA is marking things non-actionable, so my implementation of it is different from that of the original method: Projects, Areas, Resources themselves can be marked under:Archive in PARA, and anything related to them are hidden from the views. The reason using a link tag instead of the built-in ARCHIVE is that, sometimes I want to actually make these archived information found-able.

By following PARA, my workflow is basically

daily

list all non-archived Projects. To-dos are those related:SOME_PROJECT.

weekly review

list all non-archived Projects and Areas. To-dos are those related:SOME_PROJECT, plus related:SOME_AREA

monthly review

list all non-archived Projects, Areas and Resources. To-dos are those related:SOME_PROJECT, related:SOME_AREA, related:SOME_RESOURCE.

To-do items can be thrown everywhere. They are tagged ((Therning 2021)) as TODOs. Daily journals are:

• fleeting notes
• log on To-dos. More specifically, these are like "fleeting to-dos", each a headline marking a pomodoro clock time that contributes to the solution of Projects.

I use my own static site generator, which uses slick and its underlying dependencies shake, pandoc and mustache. It also uses sqlite-simple to read Org-Roam database.

The core building process is as follows:

1. read the database to find file paths to all publishable notes.
2. For each note:
   1. generate the Pandoc AST from the file content
   2. replace links in the AST (they are IDs at this phase) with the data from the database:
      • a link to a publishable note is replaced with the correct file link.
      • a link to a literature note is replaced with citations, if it is not already a citation.
      • a link to a non-publishable note is replaced with text.
   3. Render the AST into HTML DOM, with the help of bib file for citations.
   4. In addition to rendering the post content, the template system also renders backlinks into the final HTML file.
3. Put only those under:Blog into the index file.