Zettelkasten vs. org-mode

Meta
1

I’m an absolute beginner with org-roam and still in the “haze” of your typical vertical Emacs learning curve. I started reading about Zettelkasten, but when they talk about the “Principles of Atomicity” I had to pause.

That means that each Zettel only contains one unit of knowledge and one only.

or

In the words of us “Zettlers”: Create one Zettel per thought.

Basic org-mode really does not follow the Principles of Atomicity at all. Each “thought” in standard org-mode simply gets a new heading or sub-heading. Typically, the hierarchical nature of org-mode outline means many “thoughts” and their expoundings are on a continuum from general to specific as you go from Heading 1 on down into sub-headings. However, the diagram in the ZK intro shows a tree structure, branching off at each slight change of thought, while, again, standard org-mode typically keeps many “units of knowledge” together and linear – at least in the sense of reading an org-mode file from top to bottom. Question: Am I to understand that org-roam wants us to be more ZK-like, i.e., don’t make org files with multiple headings and sub-headings? Seems so. It seems ZK/org-roam wants to have an individual file for each “atom,” and that each atom is, theoretically at least, a graph vertex with links as its edges. OTOH, basic org-mode is just an outlining tool not too dissimilar to MS Word.

Before I found org-roam I was creating links between one main org file’s headings and many separate “supporter” files. Here is my default drawer under a heading 1 in …/SolToProbs.org

* Solution to Problem 4
:PROPERTIES:
:TIME: 2021-01-17T15:37:58
:ID: 9f04133e-301a-4c66-bd7e-de2e06d5afee
:EDGES: [[id:9ece8434-ce9e-40e6-8c68-8cced3b2d7e3][Solution to Problem 4 Aux]]  
:END:

…/SolToProgAux.org is a separate file where I have added details and thought excursions I didn’t want to have bloating up the main file, and in it "Solution to Problem 4 Aux " was a main heading with its own PROPERTIES drawer, and its EDGES had a link pointing back …/SolToProbs.org. So I’m treating the headings in both files as vertices and creating back-and-forth link edges between them. …/SolToProg.org and …/SolToProgAux.org are in parallel, again, each heading in the main file mirrored in the aux file.

Another question: How close does org-roam want to get to the greater “Semantic Web” efforts – or to the graph database/graph query efforts? For the longest time I’ve wanted to break out of the org-mode outline jail and the Roam idea seemed like a good step. To me, a graph version of org-mode freed of the outline would be very good.

2

Maybe you are giving yourself too much stress on the perfect definition of
atomicity. Checking the history of particle physics might give you
some ideas.

Humans used to think that atoms are not able to be cut. When [electron],
[proton], [neutron], and [photon] were discovered, human changed their
perspectives. Later, with quantum theory, humans proposed that proton
and neutron are consistent of quarks; electron can be divided into
[holon], [spinon], and [orbiton]. Unfortunately, the Standard Model, the most
successful theory judging by experimental measurement, discarded
previous thoughts.

The idea is that the definition of atomicity highly depends on your
goal. Just as what Seneca said: “If a man knows not which port he
sails, no wind is favorable.”

Back to the idea of atomicity in the context of notes taking.

The idea of packing a thought is just a part of the story. To unlock
the full potential, one has to think from packaging to delivery, from
design the ship, harbor, truck, etc. Even in the academic world, the
landscape is quite different. Some domains require publications
explaining ideas that are highly interactive with literature.

However, if you are doing the best science, reading “experts” ideas
could have negative impacts on your own thoughts. Feynman learned a
lesson from the problem that was to find the right laws of beta decay.
From then on, Feynman never makes that mistake again, reading the
experts’ opinions.

If you want to see how to break a chunk of information into small piece,
here’s a trivial example of how to do that.

After I read the post, I immediately broke his notes into
three separate ideas as the content of Table of Content. If I want to
study more about characteristics of solitude, I would just start new
note from the 1st note; if I want to see differences between how
people define solitude, I will go from the 2nd note; if I want to
write an article about why we need solitude, I will extend the 3rd
note.

[Characteristics of solitude](20201115183813-characteristics_of_solitude.md)

[Definition of solitude](20201125183916-definition_of_solitude.md)

[Benifit of solitude](20191125183820-benifit_of_solitude.md)

I can also write a demonstration about how I break ideas into atomic
notes just using this post as an example.

1 Like
3

I can assume nobody here knows about the whole semantic web effort – especially how it seems to have bogged down – mainly due to the maze-like complexity of trying to create self-referential meta-information ontologies. XML pretty much died because of this too. JSON replaced XML, but didn’t really have metainfo aspirations. So yes, all of these efforts were trying to go beyond hierarchies and ad-hoc, untracked linkings that were, in effect, subjective, one-off mazes, i.e., you know what you’re mazing on about, but there’s no perceivable method beyond your subjective maze spinnings, i.e., no formalizing your method for others to understand, and, most importantly, tap/plug into.

Also, my OP was a question of whether a long org-mode outline document with lots of headings and lots of subheadings under headings was antithetical to Zettelkasten – and obviously it is. And no, it doesn’t seem like what I was describing with my two big, long, mirrored org files bidirectionally linking their headings is the ZK/Roam way, either . . . although I believe it could be viable. In relational database language, this might be called a many-to-many situation where the “left many” is all in File 1 and the “right many” is in File 2. org-marginalia would be a one-to-many. ZK/Roam is obviously a many-to-many where the many are all individual notes – very much a maze. BTW, I haven’t looked at the code, but I assume the database is DAG-to-relational and not a real graph database, right?

4

Yes. Org-roam manual (excerpt below) makes it explict that it is designed with the Zettelkasten method in mind. One unit of thought per note is encouraged, organised in a flat structure (as opposed to a hierarchical structure) with links to other related notes. And yet, this is by no means forced. You can use it in the way you see fit.

Org-roam is the slip-box, digitalized in Org-mode. Every zettel (card) is a plain-text, Org-mode file. In the same way one would maintain a paper slip-box, Org-roam makes it easy to create new zettels, pre-filling boilerplate content using a powerful templating system.

I do not understand the mathematical precise definition of DAG (directed acyclic graph), but Org-roam data is probably not acyclic. You can do this to make a closed loop (do I understand it correctly?):

  • Note A links to Note B
  • Note B links to Note A

Org-roam uses SQLite, which is probably not a “real” graph database (I do not know if a choice of database management system is relevant for the definition you have in mind; apologies if I am talking nonsense).

You can see the database schema by inspecting the variable org-roam-db--table-schemata.

In addition, there have been some related discussion threads that you might find interesting:

5

@borgauf The “trick” here is to not identify ‘Zettel’ with ‘file’. You can have a whole Zettelkasten in a single text file and use headings to mark where one Zettel ends and another begins. That obviously fits the bill or huge org files, too. So no problem there :slight_smile:

6

It also comes down to how the user writes and links their notes. I personally write many smaller notes, each given its own file and aimed at being conceptually atomic. The content of each note is written in a way that it can be interpreted as a set, which means it is similar to a database table or programming language type. Then when I link between notes, I only do so if it has a functional relationship. In other words my ZK is basically a DB schema where every note(table) is only allowed one to many or one to one relationships. I got this idea from something called Ologs. It is a way to more formally represent knowledge but in a way that is still natural for humans

IMG_20210731_003251
IMG_20210731_0032511027×400 103 KB

In the end though I chose to create my ZK that way, others have their own strategies and heuristics and you can too