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.