parents: My Systems, My PKM Practice


Problem

  • My previous pyramid system was too rigid.
    • Notes didn’t fit neatly into one place.
  • I need a system that is more robust without sacrificing fluidity.

Principles

  • Use a matrix instead of a pyramid.
    • A note’s position is defined by two primary axes:
      • Domain Axis (parents): What the note is about.
      • Form Axis (type): What kind of note it is.
  • Embrace tags.
    • They add a flexible third dimension for context and status.
    • This avoids polluting the main structure with temporary pages (e.g., [[Finish This Week]]).

The System

  • A note has four key components: parents, type/subtype, tags, and other properties.
  • parents (Domain Axis)
    • Purpose: Defines belonging, context, and aggregates notes into Maps of Content (MOCs).
    • Rules:
      • A list of direct parent notes.
      • A note can have multiple parents.
      • Defines the direct parent only. Deep hierarchy emerges from links within MOCs.
  • type & subtype (Form Axis)
    • Purpose: Defines identity, making notes machine-readable for queries and automation.
    • Rules:
      • type is required, subtype is optional.
      • Core types:
        • concept: An abstract principle, theory, or mental model.
        • entity: A concrete thing, like a person, book, or game.
        • process: A how-to guide, framework, or system.
        • narration: My personal thoughts, analyses, or stories.
        • source: Raw material from elsewhere (clippings, meeting notes).
        • meta: A note about this knowledge system itself.
      • subtype should be generic.
        • Example: An app idea and a game idea both get subtype: idea.
  • tags (Context Axis)
    • Purpose: The flexible, cross-domain glue for association.
    • Rules:
      • Use for anything that doesn’t fit the other pillars.
    • Use Cases:
      • Connecting Themes: #creativity, #mental-model
      • Marking Action: #to-discuss, #project/alpha
  • Properties (State Axis)
    • Purpose: An evolution of tags for systematic data, like status.
    • Rules:
      • Create a dedicated property when a tag’s usage becomes systematic.
      • This separates a note’s lifecycle state from its topical associations.
    • Use Cases:
      • status: "idea"
      • status: "in-progress"

Examples

A Process Note: The MDA Framework. It belongs to my collection of gameplay design methods. Its identity is a process, a framework. It’s associated with the broader theme of game design.

---
parents:
	- "[[Gameplay Design Methods]]"
type: process
subtype: framework
tags:
	- game-design
	- analysis
---

An Entity Note: Slay the Spire. It belongs to two MOCs at once. Its identity is an entity, a game. My personal context is that it’s a favorite.

---
parents:
	- "[[Deck Building Game]]"
	- "[[Roguelike]]"
type: entity
subtype: game
tags:
	- favorite,
	- high-replayability
---

A Narration Note: A Game Idea. It belongs to my general pool of ideas and a specific project. Its identity is a narration, an idea. Its state is ready for a demo, and it’s associated with pvp and mobile.

---
parents:
	- "[[Game Ideas]]"
type: narration
subtype: idea
status: "ready-for-demo"
tags:
	- pvp
	- mobile
---