Zettelkasten note-taking with Logseq - Tagging, processing and structuring your notes (Part 2)
Based on CombiningMinds's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Categorization in Zettelkasten is broader than context tagging: it includes scaffolding for bottom-up development and growth.
Briefing
Zettelkasten note-taking isn’t just about tagging finished ideas—it’s about turning raw, half-formed notes into a structured “knowledge garden” you can reliably retrieve and build on. The core push here is bottom-up development: start with small, imperfect inputs, then add just enough scaffolding—through tagging, processing stages, and levels of abstraction—to make those notes usable across different contexts without forcing rigid folders that slow thinking.
The discussion builds from earlier design principles into categorization as a broader discipline than context tagging. Categorization becomes a way to manage digital workspaces so a person’s attention stops being chaotic, while also creating growth surfaces for knowledge to “climb.” The guiding mindset is iterative and personal: systems are flexible, so there’s no one-size-fits-all setup. Instead, the aim is to borrow patterns from other methods and adapt them to how a person actually writes, searches, and revises.
Three recurring commonalities tie the methods together. First is context tagging—using subject or keyword tags to resurface relevant notes later—but with discipline. Keywords should be chosen carefully and sparsely, not as a dumping ground of 15 overlapping labels. Tags should reflect the topics being worked on, and they should be assigned with long-term questions in mind (what someone wants to answer in 10–15 years) rather than short-term memory. To avoid “keyword world” tunnel vision, the approach emphasizes contextual congruence: tags should align with the higher-level point of a note, not just the words inside it.
Second is incremental progress, framed as “thinking in stacks” and “virtual workshops.” Notes move through development stages such as empty → develop → raw → medium-baked, or a steak-style progression (blue/rare/medium/well). Separately, working areas manage where attention goes: inbox for unprocessed items, ideas for investigation, fleeting for quick captures, graveyard for discarded-but-retained notes, and junk/straight junk for cleanup. The point is to keep the system flexible while making the next action obvious.
Third is levels of abstraction and emergence. A single note is only the atomic unit; value appears when notes aggregate into higher-order structures. The analogy uses playing cards: one card can belong to multiple groupings (runs, sets, flushes, straights), and those groupings can be recombined without locking the system in place. In Zettelkasten terms, linking notes is one level, but map notes (MOCs) and content pyramids add further layers—chapters, books, and areas—so the same underlying notes can feed multiple structures.
To bring it together, the workflow described funnels daily inputs through queries into a “raw” development note, then advances it through stacks, finally tagging it with an areas → books → chapters scheme (and using namespace-like prefixes such as z-a for outputs). The later portion connects these ideas to other frameworks—Linking Your Thinking (MOCs), Luhmann-style levels (fleeting/literature/permanent), Robert Pirsig’s card categories, the Eisenhower matrix, and GTD/kanban-style inbox-to-done workflows—while emphasizing that the real power comes from database querying and repeatable organization. The takeaway is practical: build scaffolding that supports growth, keep it adaptable, and use queries to turn scattered notes into an evolving body of work.
Cornell Notes
The central idea is that Zettelkasten systems succeed when they treat notes as raw materials that get processed into usable knowledge. Categorization goes beyond context tags: it includes (1) disciplined context tagging tied to long-term questions, (2) “thinking in stacks” with development stages and separate working areas like inbox/ideas/graveyard, and (3) levels of abstraction where linked notes aggregate into higher-order structures such as chapters and books. The approach uses an areas → books → chapters tagging scheme (with namespace-like prefixes for outputs) to keep retrieval precise and to build scaffolding for a knowledge garden. The payoff is smoother retrieval and writing because queries and structured scaffolds turn chaos into an evolving workflow.
Why does “context tagging” need more than adding keywords to notes?
What does “thinking in stacks” mean in practice for note development?
How does the “areas → books → chapters” tagging scheme help with retrieval and structure?
What does “levels of abstraction or emergence” add beyond linking notes directly?
How do other frameworks map onto the same categorization ideas?
Why does querying matter so much in this workflow?
Review Questions
- How would you design a minimal set of tags so you avoid “keyword world” while still supporting long-term retrieval?
- What criteria would you use to decide whether a note belongs in inbox, ideas, fleeting, or graveyard?
- Give an example of how one note could participate in multiple “emergent” groupings (e.g., different chapters or books) without duplicating the note itself.
Key Points
- 1
Categorization in Zettelkasten is broader than context tagging: it includes scaffolding for bottom-up development and growth.
- 2
Choose keywords sparsely and with long-term intent; tags should act as durable breadcrumbs tied to questions you want answered years later.
- 3
Separate development maturity (e.g., empty → raw → medium-baked) from working areas (e.g., inbox, ideas, fleeting, graveyard) to make next actions obvious.
- 4
Use an areas → books → chapters hierarchy to keep tags at the right level of abstraction and to mirror real writing projects.
- 5
Build higher-order structure through levels of abstraction (e.g., map notes/MOCs) so linked notes can aggregate into chapters and books without locking the system in place.
- 6
Use namespace-like tagging (such as z-a vs areas) and linking conventions (like forward slashes) to connect inputs to outputs and improve search precision.
- 7
Database querying can turn scattered daily captures into a funnel that selects what to develop next, then advances it through stacks.