JT's Weblog

Plain Text for Personal Knowledge Management, Part 3

published: November 2, 2025 estimate: 7 min read view-cnt: 56 views

In the previous article, we discussed major categorization approaches in PKM systems. Now let’s see how to blend them in practice.

Note: If you’re not familiar with Zettelkasten, PARA, MOC, or tag-based systems, read Part 2 first.

After trying most of these methods, I’ve developed a syncretic system that combines their strengths. I’ll quickly review each method from my perspective, then show you my actual category structure and design principles.

Overview

Hierarchical based approaches:

This type of method has two obvious drawbacks:

  1. you cannot put an item in two different places at the same time (i.e. the categories are mutually exclusive)
  2. cross-cutting items are hard to categorize (i.e. the cost of disambiguation grows inevitably)

Links, graph based approaches:

This type of method addresses the limitations of hierarchical based approaches. However, maintaining all the links and tags is not a trivial task. It should be managed by an experienced user within a PKM system.

Chronological (Time-Based)

In LogSeq, the official docs recommend beginners to use journal as their entry point for taking notes, then, create dedicated pages or tags whenever needed.

The journal is a series of files named after dates, LogSeq simply creates files on a daily basis.

I keep the entry point concept, and I generalize the idea of a journal to “untitled prose”. On the other hand, a named prose is like a “permanent note” from Zettelksten method where you have recognized a pattern from your journal, and decided to extract the concept to a dedicated place.
In other words, you give names and build your domain of knowledge from these named proses.

With this generalization, I could have multiple journals in my PKM system. The first journal is the entry point; the second would be logs for a specific project to take arbitrary notes.

PARA Method (Projects, Areas, Resources, Archive)

Let’s review this method bit by bit.

Projects

I kept the concept of projects. It is something like defining a “function” in programming. You know the boundary and the goal (i.e. expected output) you want to achieve from this function.
In practice, I treat every git repository as a project, which makes it straightforward to categorize.

Areas

For me, Areas are very similar to Projects. By definition, the only difference is that Areas are long-term projects whereas Projects have a deadline. I have a similar concept in my system, but the name “Area” by itself is very confusing, so I try to avoid using this word in my system.

Resources

At its core, resource is a piece of data with an attribute of “external”. Again, I do have a similar concept in my system, but I try to avoid using the word “Resource.”

Archive

At its core, archive is a piece of data with an attribute of “inactive”. I believe that data attributes should not be categories on their own. Instead, they should be attributes or metadata recognized and operated by the PKM system.

Verdict

Project is a good category primitive. The other three should be treated as a data attribute, and handled at the application-level, instead of being a standalone category.

Topical/Domain-Based

I use this one as the advanced version of named prose.

I extract standalone categories for the domain that I am strongly interested in.

The dataflow looks like this: journals (untitled prose) > named prose > standalone category

The cross-cutting issue still persists, but it is fine if I don’t expand my interests too much.

Zettelkasten

From what I know, these are the components of Zettelkasten method:

In my design, I map fleeting note to journals; permanent note to named prose.

I don’t use a separate category for reference notes due to the “data attribute” reason aforementioned. Instead, I incorporate external references within the material and virtual categories.

I would like to implement bi-directional links in my system. For now, I just occasionally refer to an existing file in my writing if I can recall it, which is simply a unidirectional link. I will implement this feature once I need it.

Map of Content (MOC)

This is a transitional method I use to build a similar network before I fully implement bi-directional links.

I create an index file whenever I feel the need to disambiguate something in my system or to group similar concepts together.

Tag-Based System

In my previous LogSeq experience, tags are the most powerful categorization approach and the easiest method to be abused.

The reason it is powerful is that tags allow non-exclusive categorization, yet can still represent hierarchical structures when needed (i.e. it is a superset of hierarchical approaches).

Tags are often abused by spamming them as if we’re stuffing keywords for better SEO.

At its core, tags are just a piece of metadata. My heuristic to prevent abuse is to treat them with the same care as systematic decluttering. Adding a tag to an item should require the same energy you spend on decluttering an item from your personal collection.

That’s the spirit. However, I have not yet implemented the tag system in my PKMs. I will implement it once I need it.

Additional Concepts

Now, we know how these methods inspired my design. I have two more concepts to share before introducing my actual design.

Orthogonality

It is the secret sauce to minimize the disambiguation cost generated by cross-cutting items.

I found that “media type” is a strong orthogonal concept that is rarely ambiguous.

Just to name a few:

One could expand it further:

It is a small trick I found in my ~10-year note-taking journey.

Content Type (Prose and Fact)

Prose is non-structured data (i.e. freeform writing)

Facts, on the other hand, are structured data

P.S. I use “facts” and “data” interchangeably; calling them differently is just a way to reduce readers’ cognitive load.

The Design

General Principle

Meta-Categories

I introduce meta-categories in order to better organize and reason about categories. The first, second, and third entries (‘general’, ‘devotion’, ‘project’) are marked as “internal” because the information comes from my own experience and activities. The fourth and fifth entries (‘material’ and ‘virtual’) are marked as “external”, which means the information comes from external sources.

  1. general, personal, interpersonal stuff
    • you may refer to this one as “Areas” from PARA
    • possible content format: all types
  2. devoted domain
    • evolved from accumulated knowledge in journals, similar to how fleeting notes become permanent notes
    • represents domains where you’ve developed deep interest and substantial content
    • possible content format: all types
  3. personal project
    • is a direct map to “Project” from PARA
  4. material or objective stuff
    • you may refer to this one as “Reference” from PARA and Zettelkasten
    • possible content format: data, quest
    • contains various media types (refer to the Orthogonality section)
  5. virtual or subjective stuff
    • a spin-off version of “material or objective…”, except it stores conceptual things
    • possible content format: data, prose

Category

Voila!

This is my current category setup in my PKM system. The setup borrows a few concepts from a few popular PKM category approaches
such as:

I also introduce the prose/fact concept to benefit from both sides of structured and non-structured data.

Hope you find something interesting from this article! See you in the next one 😎

2 Comments

#2 | Jeff |
Cool
#1 | Jeff |
Nice