Howdy, Stranger!
Categories
- 3K All Categories
- 153 Research & Reading
- 700 The Zettelkasten Method
- 11 Knowledge Work
- 101 Writing
- 471 Software & Gadgets
- 155 Workflows
- 732 The Archive
- 15 Plug-In Showcase
- 88 Resolved Issues
- 225 Projects Logs and Journals
- 86 Project: Zettelkasten.de
- 53 Critique my Zettel
- 177 Random
- 375 Introduce Yourselves!
Comments
I> @iylock said:
I have been working out a framework that covers some of these "categories", and it throws a different light on them. I will only mention "Concept" here. In my framework, a Concept is viewed this way:
A concept is a quasi- or meta-stable mental [1] model for some part of the world.
1. The world can be mental or fictional as well as physically-based.
2. A concept can be viewed as having a 2D space of attributes: (maturity X scope)
[1] "mental" can be expanded to include the entire nervous system.
Maturity is a measure of how fully developed a model is.
Scope is a measure of how large a part of the world is covered by the model.
"Idea", "notion", and similar words refer to concepts of different scope and maturity. A (Mental) Model is not a separate thing from a Concept but rather an inherent part of its definition.
Note that models can be (but do not have to be) recursive and hierarchical. This means that a model can be built up out of smaller sub-models.
The framework also covers Arguments and Beliefs but I'll leave them for another time.
This looks like a question for @Sascha. In comment 23960 he explicitly allows to "use any inventory of building blocks that you like", but also discourages "mixing two frameworks".
I think it would make sense to add a seventh category "solutions" for this purpose. It's compatible with the default inventory, because solutions don't overlap with the other categories and because each solution is an atomic idea.
Interesting.
There might not even be a direct mapping.
The solution to a complex problem could be an entire network of blocks.
In that sense, the six categories may describe the building blocks of knowledge, while a solution can be a configuration or application of those blocks to a particular problem.
I have actually "stopped" creating overly formal taxonomies of blocks a long time ago.
I see them mainly as a useful learning tool for understanding how to practice Zettelkasten. But after the learning phase in the day-to-day practice of my own system, I find it more useful to develop ideas according to what feels appropriate in the moment, rather than trying to fit always everything into a predefined taxonomy.
For my problems I have many cases (one note with the couple problem-solution, one problem with many solution notes, a structure note that represent the problem-solution interation), but every block remain a "zettel".
In 2023 @Sascha suggested the same in comment 18214: "But to be honest, those kinds of typologies are useful for teaching but not really for the actual work."
However The Guide was published after the 2025 threshold post. If I understand the threshold post and The Guide correctly, knowledge building blocks are now considered the foundation of knowledge work.
Comment 23960 mentions criteria for the inventory of knowledge building blocks:
Well, the inventory should be working. Meaning: It should not just be a bunch of definitions but a bundle of ideas, methods, thinking tools etc.
To create an inventory, you need to have a reasonable framework of completeness of what you are mapping. If we are talking about knowledge building block, the inventory should map the process of knowledge work.
Sure, I don't mean that the work of identify the required sub-elements, a model, an argument is not important.
A problem "calls" a solution in a very natural way, so a question an answer. A principle without some kind of support remains a belief or an opinion. You can often extract a concept or principle from an observation, so you have to have clear what these things are.
My point is, rather, if you meet in your everyday practice "a new kind of stuff", the problem in this case, once you've a bit of experience in other cases you can represent it as you feel it. It'not very important that you recognize that new kind as shapes already formalized.
It could be difficoult, indeed. In my practice, many (solved/unsolved) problems take place as examples, or observations. Other become models. Many of them are too complex to represent them with a simple building.
I've seen, anyway, that into my Zettelkasten I have a definition of "Problem Point" (Point is my often used term for Zettel/Evergreene/Main/Permanent), that reminds to another zettel:
" Problem-Solution Couple (Atomization Pattern)" that has a reference to this Sascha Writing:
"Treat the problem, solution pairing as the idea that you keep on this note, even if each solution might be worthy of its own note at some point. If you work on a solution, it is often wise to keep everything on one note. Your future self wants everything to be available with a single glance. It doesn’t want to be burdened by a lot of clicking and link-following".
Into the atomicity guide itself, as I see.
That is interesting. Why is "maturity" necessary? If we view this in terms of mathematical sets, couldn't a more concrete or developed concept simply be seen as a set containing more—or more precise—elements? In other words, my question is: can "maturity" be replaced by "scope"?
What are your thoughts on the possibility that the solution might lie outside the realm of knowledge? Alternatively, as @andang76 suggested, it could be a combination of knowledge building blocks. Or perhaps the solution could simply be treated as data that hasn't yet been processed into a model?
Maturity and scope are independent. Scope is about how wide the concept's coverage is. It could run from a "theory of everything" or an all-encompassing religious world view to, say, a mental model of how an incandescent light bulb or a door key works.
Maturity means that the model has been worked and reworked until it has more or less stabilized (at least for the time being). This doesn't have to entail any changes in scope or complexity. In fact, a more mature model could be leaner. For example, a "half-baked idea" (in English) indicates a very immature concept.
Being a member of a set does not require or imply that the member has only one dimension. If one allows for a space of several dimensions, in this case (maturity × scope), the space can be partially ordered on any or all of them. This allows one to rank different class members in a well-founded way.
As an example, the measurement of a physical quantity has at least three axes of importance: (mean × precision × bias) (even though the bias axis is often neglected). Each of them can vary without affecting the other two.
If it should turn out that the complexity of a model is an important attribute on its own, a third axis could be added. So far I haven't felt a need to do so but there is no reason it couldn't be done. This new axis could have a partial ordering of its own. In fact, a Complexity space might have more than one dimension, e.g.,
Complexity: (number_of_parts × hierarchical_levels).
"hierarchical_levels" could be viewed as sub-concept nesting, or as containment in the set-theoretic sense (A ⊂ B ⊂ C ...), or as composition. So far I haven't seen a need to invoke set theory, and I think it's a good idea not to overly complicate things unless forced to. But there is a principled way to proceed if more complexity should be needed.
I see. Thinking of it in terms of model versions makes the concept of maturity easier to grasp. It seems both intuitive and useful, largely because it allows individual concepts to be woven together systematically rather than remaining isolated ideas.
For context, here is why I initially asked about the necessity of maturity levels: even when the same term is used, a difference in definition implies a difference in the underlying concept. Examples include:
While one could view these as differences in maturity within the same scope, strictly speaking, they appear to delineate distinct boundaries. Visualized as a Venn diagram, they would likely appear as highly overlapping sets. That is why I was curious about the necessity of the maturity concept.
Beyond this "concept," I am also interested in other frameworks you have developed. Do you have any plans to share them publicly, perhaps online or through publications?
I have another question regarding the six building blocks of knowledge. Where do fables fit in? Are they considered models? Or do fables fall outside the categories of knowledge altogether?
Examples of fables include Aesop’s Fables or the story of Max Planck and his chauffeur, often cited by Charlie Munger.
That's the question. :-)
The context of our conversation is The Complete Guide to Atomic Note-Taking. If I understand Level 3 correctly, then a) knowledge is made of discrete pieces that come in a limited number of shapes and b) it is possible and desirable to have an inventory of those shapes (piece = knowledge building block; shape = types of knowledge buildings blocks).
Personally, I operate only at Level 2, because I think of knowledge differently. I don't believe that knowledge itself is atomic. But I find it useful to have some heuristics and rules for the scope of my notes.
I found it interesting to read the quoted paragraph in its original context.
First the author establishes the importance of knowledge building blocks:
"Purely atomic notes are notes that contain exactly one knowledge building block."
Second the author acknowledges practical difficulties, while emphasizing that the effort is worth it:
"(…) it is simple, yet often hard to move from atomicity level 2 to level 3: You identify the knowledge building block and make sure that you neither miss any part, nor put anything unrelated in the note. The formality often requires a significant amount of effort from you. Yet, it is more than worth it: The boon is complete mastery of the idea."
Third the author makes room for exceptions (emphasis added):
"There are supporting concepts that help to understand the principle of atomicity. These supporting concepts should help to soften the perspective."
Then the author mentions problem-solution pairing as an example of an idea that cannot be mapped on a knowledge building block.
So one answer to @iylock's initial question would be: don't worry to much about knowledge building blocks. ;-)
Bibliographical data is typically captured in the bibliographical section of your system. Some people use a tool like Zotero.
Some people add reading notes or source notes to their Zettelkasten, where they capture their thinking related to a source. (I find the practice very useful, others don't. This has been discussed previously in the forum. Search for "reading notes" or "literature notes" or "source notes".)
I think one could consider different definitions of probability to be different models. Depending on how you think of them, they also could all be (or become, in time), sub-concepts of one overall concept. I don't think it is worthwhile being too picky about these distinctions, but in the end it's all about how you regard them.
I have added some areas. It's still early days, and I've been feeling my way along. So far the framework includes Beliefs, Arguments, and Thought Trails. For example, a Belief is a Concept combined with a degree of attachment (that is, an emotional attachment). An argument consists of a series of steps with the purpose of justifying a thesis. Each step is a transformation that can be justified to some degree. The difference between logical proofs, arguments based on physical causes, and rhetorical arguments lie mostly in the soundness or kind of the justifications, which can range from logical to emotional. The justification of an argument as a whole can be estimated by combining the justifications of its individual transforms.
I would be interested, once I get the ideas worked out more fully. It's a puzzle where I could share them. Airing them here in the forum tends to present them in a fragmented way, with readership being spotty. I have a web site and could easily put a blog on it but I'm not prepared to set up and moderate comments.
My main interest is to cut through all the vague, handwavy, circular definitions that don't help with coming to grips with the subject. For example, here are some of the many definitions of Concept that I have found:
"Concepts are recombinable elements of deliberate conscious thoughts."
(Open Encyclopedia Of Cognitive Science - https://oecs.mit.edu/pub/j39m4jos/release/2)
"In philosophy, the notion of a concept designates an abstract idea or model that corresponds to something concrete in reality or in language. As used in this book in describing the evolution of projects, a concept is a mental construction intended to support the solution of a problem or the satisfaction of a need." (Samset, K. (2010). What is a Concept?. In: Early Project Appraisal. Palgrave Macmillan, London.)
I'm trying to distill ideas like these into clear forms that depend on as few primitives as possible, impute as few motives and conditions as possible, and align as well as possible with the ways the words seem to be be used in ordinary speech. For example, take this passage: "general, abstract idea that the human mind forms...". I eliminate the "human mind" part because that is basically an empirical matter or a human-oriented bias.
In "deliberate conscious thoughts" I get rid of "deliberate conscious" because it's apparent from experience that people have many concepts that have not become conscious or that only parts have made it to awareness.
In "an abstract idea or model that corresponds to something concrete in reality or in language", the word "concrete" is not helpful or actionable. The only part of the entire definition from Samset, K. (2010) that is actually helpful is "model".
My definition of a Concept as a mental model with maturity and scope depends on one primitive: "mental model", and that primitive seems like it could become understood in the future as depending on even more basic primitives. The definition is also something one can work with and reason about, unlike most of the above definitions.
I think it depends on how you use the fable in your process.
A fable could be an example (I could call it "an instance") of an idea that explains it better, or the source of a moral principle or a concept.
In this case, for me, the fable can be a "Source point", or it can become part of the higher-level idea or thought that emerges from processing it.
By reflecting on the fable, you can obtain something from it. I don't think the value necessarily lies in the fable itself, taken in isolation, but in what you develop from it.
So, let's take The Fox and the Grapes.
The fable itself could simply be a source point. From it, I might notice the idea that "when we cannot obtain something we want, we may start devaluing it".
I could then develop that into a concept, a more general model, or perhaps an argument about how this mechanism works.
I could also connect it to other examples and eventually develop a completely different thought.
Once the idea has been developed, the fable becomes part of its origin or context / can be used as an example, or explanation, or expression in the pop culture, while the idea can stand on its own.
If you then have a Zettelkasten specifically dedicated to popular culture, then why not? "Fable" could perfectly well be one of the blocks in your arsenal, with its own peculiarities, with its own structure and "typical parts", if you think it can be useful within the overall process by participating in connections with your other Zettels.
It could be the intended use (which can also be adjusted over time) that can define the required kind and shape of blocks.
To make my last point in the previous post clearer, instead of thinking about a fable, just think for a moment about a chef practicing the Zettelkasten method. Their arsenal of Zettel types could very well include a "recipe" type. It is something well-defined and frequently repeated throughout their Zettelkasten.
The idea of seeing a chef's Zettelkasten as a kind of "mental kitchen" creates a new perspective: knowledge is not just something to be stored, but something to be combined to create something new.
The same could apply to a fable Zettel for a novelist or a scholar of popular culture.
And that's actually something I find myself doing quite often.
The key point is, I think, that if there is a distinct subject you want to write or talk about, it is a prime candidate to become a z-card. Most subjects are somewhat hierarchical or composed of smaller pieces, and how far down you want to go can vary depending on what interests you at the moment. A general thinking about strategy may think about divisions and logistics capabilities as building blocks; a sergeant planning tactics may think about squads; a recruiter may think about individual people.
A chef may think about recipes, and also about ways to use leftovers the next day, meal planning, efficient kitchen organization, ingredient purchasing, and anticipated holiday specials. These all involve food products, staff, and kitchen equipment on different scales - physical and temporal.
My view is that a z-card should be about something specific that suits one's interest at the scale of that interest. The scale may change in the future.
Yes, I think this is close or similar to what I have in mind. It's a further dimension.
I agree the idea of the scale of one's interest. It makes it clear that there is no universally correct granularity at which something should become zettel; it depends on what is specific and meaningful to the person at that point in their process.
And it's something implicit in my idea of Zettelkasten.
And I think this also explains why I am reluctant to have a fixed taxonomy of Zettel types. The scale at which I find something interesting can change, and so can the kind of representation that is useful for it.
An example of my Zettelkasten, I develop into my system my observations, evaluations and reflections on my training sessions into "Running Session Points": a running session is an event, but it is also a recurring entity with a common structure, and it can be a source of further observations and ideas. So the same Point can have different roles depending on what I am doing with it.
All of these aspects (scale, role, purposes) can affect how something should be modeled, may change over time and outline the need for modeling that adapts over time
If I recall correctly, a few weeks ago @iylock raised a similar issue regarding how to handle songs within a Zettelkasten. After all, a listener, a musician, and a producer might require a completely different zettelkasten toolbox.
Strictly speaking, the problem-solution pairing is a model as it brings two entities (the problem and the solution) into a specific relationship.
However, the problem and the solution are complex entities that could contain a lot of building block.
An example, from my own work: I, once, wanted to solve a problem presented by Jablonka/Lamb (in Evolution in Four Dimensions) by introducing a concept that learned from Luhmann. The problem-solution pairing was fairly complex. The problem included:
The solution included:
I never wrote the essay (the teacher said to me, that this essay wouldn't allow her to evaluate the basic skills like placing a footnote and including standard literature, when I presented her this essay as I wanted to do actual work and not busy work). So, I can't remember any details.
The knowledge building blocks aim to be the atoms and I make the claim that they are the primary elements of knowledge. So, according to my theory the problem-solution pairing is of molecular nature.
Fables are stories for which I developed a different set of building blocks.
https://zettelkasten.de/posts/zettelkasten-fiction-writing-part-2-elements-of-story/
(I am not nearly confident in them as I am in the knowledge building blocks)
I don't discourage mixing two frameworks. I explicetely pointed out that you can't hold one framework to the the standards of the other. The concept of a concept make sense within one framework. (This is, btw., my objection to trying to define what a concept is in isolation of other epistemic objects like model or theory)
No, it doesn't make sense. This would only lead to bloat and poor rigor.
The answer is that it depends on how much rigor you expect from the knowledge that you produce.
Keep in mind that not reaching level 3 leads to less rigor and leaves a lot of room for self-sealing and errors. Analytical philosophy, for example, only works on level 3 with extensive work on level 4. Otherwise, it is just not possible. Math is perhaps the most extreme example which is the reason that you can have mathematical proof. And then you can look at the other extreme where scientific standards are just a facade.
No, I don't. I said to Nori that I wouldn't separate the problem-solution pairing into different notes, implying that the solution will develop into a separate idea worthy of its own note.
If you care about good arguments, you take care of one of the building blocks by extension. Not worrying about knowledge building blocks would include, for example, the quality of arguments. So, I wouldn't recommend that.
I am a Zettler
I see the problem-solution issue this way -
If we stay with Sasha's 6 building blocks (above) for the time being, then how to handle them in the Zettelkasten seems fairly clear:
It could happen that one notices a problem that doesn't seem to have come from a model; then it's probably related to a model one isn't aware of. E.g., Problem:
"I got a speeding ticket on this street. How can I avoid getting another one"?
Your mental model of the geography of the street and its surroundings didn't include a change in the speed limit there, and you didn't notice a speed limit sign.
Problem:
"There's something off about Sasha's six building blocks of knowledge"
Your understanding of Sasha's knowledge model is not developed enough, or your own model is not well-enough articulated to challenge it.
Problem:
"My car's engine keeps overheating. I need to have a solution."
Your model of how your car works is incomplete. Probably you should outsource this matter to a mechanic and his model. Alternatively, your model is up to the job of understanding but you need to devise a diagnostic approach so you can know what specifically to fix. You didn't realize that diagnostic procedures should be part of your model.
So far I haven't come up with a problem that doesn't fit this concept, but I won't swear there aren't any. If there are, what I have suggested above will still apply to most problems.
@tomp said:
I'm not sure that I'm understanding @tomp correctly, but this definition of problem doesn't seem to be general enough. Problems can also be about the real world instead of about models. Here's a definition of problem from David Straus (in his 2002 book How to Make Collaboration Work, although this is close to a typical dictionary definition, so he may have simply taken this from a dictionary):
Following Straus's definition, a problem is not, most generally, "in a model", but you have to (implicitly or explicitly) model a situation in order to determine what the situation is and that it should be changed. That modeling has variously been called: problem formulation, problem structuring, problem conceptualization, etc.
More specifically, it may be that the situation is that you have a model that you want to change, in which case @tomp's more specialized definition of problem applies: "a perceived deficiency in a model". Then problem formulation is modeling the deficiency of the model.
Nice definition
I gave three examples of problems, of which two were about the real world. I was a little surprised when I came to think about problems this way, and I'm still looking for exceptions. The thinking behind my suggestions is that if you had already modeled the situation adequately you wouldn't have a problem, or at least you would know of a solution. In this view, the problem doesn't arise from some occurrence per se but because the occurrence was unexpected or because you don't know how to handle it.
Perhaps there is a weakness here in the case where you do understand how to handle the situation but you don't have the ability. Suppose you fall down a well. I could say that the problem arose because you didn't include a well in your mental model. All right, but now even though your model of the situation has improved you still can't get out.
Hmm, this suggests to me that the desired outcome is pictured as a modified model and the solution is a plan to transform one's situation so that it fits the modified model.
The interesting issue is an understanding of what it means to judge that one's situation doesn't match up. What is one comparing with? It doesn't have to be the "real world". E.g., a novelist may have a problem working out the motivation of one of his characters.
It seems to me that there are at least two fundamental elements involved: which attributes are used to assess the goodness of fit, and what point of view (or criteria) are used to perform those assessments.
Good, I think this is leading me somewhere productive! In case it's not clear, I'm trying to come up with simple unifying abstractions rather than exploding the world into ever-greater complexity. In the context of this thread, Atomic Notes, I'm exploring basic aspects of mental operations.
Perhaps coincidentally, in his Zettelkasten, e.g., in I section "6.3 Equality and Identity", Luhmann got into this matter of judging. If I understand what he wrote in those zettels, it boils down to something similar to what I said above on attributes and their assessment.
@tomp: more thinking of mine if it is helpful:
I agree that you are focused on mental or intellectual parts of problem solving in your definition and examples. I would call these parts something like problem formulation and solution formulation. For purely intellectual or knowledge-related problems, those parts may be the whole of problem solving. Your examples are all intellectual problems, how (and perhaps what and why as well):
A Zettelkasten could be well suited to formulating some of those problems and solutions. But for problems 1, 3, and 4, there may be an additional part of problem solving, which is implementing the solution to change a (non-mental) situation: (1) changing how I drive, (3) fixing the car's engine, (4) doing the rescue operation. I haven't finished the problem solving until I have implemented the solution and changed a (non-mental) situation.
Those are simple examples, but for complex problems, implementing the solution would require some kind of task/project management. The distinction between a Zettelkasten and a task/project management system (previously discussed in this forum) becomes relevant. I may work on most of the intellectual parts of the problem in the Zettelkasten and plan most of the practical parts in the other system, and there may be interaction between the two, as I may need to plan my Zettelkasten work in the task/project management system.
Arnaud Chevallier, in his book Strategic Thinking in Complex Problem Solving (Oxford UP, 2016), elaborates on a basic four-step approach to problem solving:
Again, for some problems, all of these steps could be done in the Zettelkasten, but not for other problems.
This goes beyond the context of atomic notes but perhaps clarifies how a note system fits into problem solving more generally, where there may be a task/project management part, not typically done in the Zettelkasten, to guide the implementation of the solution.
I agree with what you say: Zettelkasten and task management are not the same; in fact, I usually think of them as orthogonal. So having different systems specialized for one or the other makes sense.
Just so.
My own framework for supporting execution-like projects is pretty conventional and goes like this:
Accomplishing the project proceeds by performing the tasks according to the task plan (which may include feedback and correction tasks). In terms of Chevallier's four steps, mission planning would kick in at his #3, I think.