16-5 Zettelkasten & Ontology 🗂️

The agent already knows the conventions of Zettelkasten & Ontology, so if you say "organize this using that method," it'll build folders, frontmatter, and links to match. It's the most powerful combo for growing scattered notes into connected knowledge.

← Home: ObsiKO 101 · Parent: 16 AI Agent

📖 For the concepts themselves (the why and what), see 17 Structuring Knowledge — here we focus on how to direct the agent.

🧩 Zettelkasten (letting notes mature)

Say "organize this vault using the Zettelkasten method," and it'll sort things into four folders by maturity.

• Each note automatically gets frontmatter (id, type, created, tags).
• Permanent note principles: one idea only (atomic) · understandable on its own (self-contained) · rewritten in your own words · related notes linked with a wiki link + one-line reason.

Prompts to try

• "Promote this fleeting note to a permanent note — keep it to one idea only, rewrite it in my own words, and add wiki links + a one-line reason to related notes."
• "Turn this PDF into a literature note — keep the source and page, and flag anything not in the original with [[Needs check: …]] instead of making it up."
• "Make an MOC (table-of-contents note) for topic ○○ — organize the wiki links from intro → core → advanced."
• "Split this long note into individual ideas (atomize) and link them to each other."
• Dedicated commands: /permanent /litnote /connect /moc (and the overall /zettel)
• 🛡️ Fleeting and source notes are never deleted casually (it will ask first).

🕸️ Ontology (linking with types and relations)

Say "add ontology relations to these notes," and it'll fill in the frontmatter with a class (type:) and relation predicates. Where Zettel's [[link]] only says "related," ontology spells out the kind of relation.

---
type: Concept                  # what this note "is" (its class)
is-a: "[[Knowledge Management Methodology]]"      # parent category
part-of: "[[PKM]]"             # part of
causes: "[[Knowledge Compounding]]"         # causes
---

• Example classes: Concept · Person · Place · Event · Work · Method · Claim (adapt to your domain).
• Core predicates: is-a (parent category) · part-of/has-part · related, plus causes, precedes, opposes, depends-on, example-of, etc. as needed.
• Wiki links inside frontmatter must always be wrapped in quotes like "[[ ]]" (a YAML rule). Use a list for multiple values.
• "First build the kind & relation dictionary (definition notes)" → a single source of truth that keeps you using only registered kinds and predicates. See the dictionary section below!
• Set this up and it'll shine clearly in 10 Graph View with colors and arrows per predicate! ✨
• Dedicated commands: /ontologize (a whole folder/topic — check dictionary → approve plan → apply → report) · /classify (class) /relate (predicate) (plus /ontology for design and /ontolint for review)
• 🛡️ Only frontmatter is changed; unknown values are marked with ? or [[Needs check: …]] — never invented.

📖 Kind & relation dictionary — the app reads it

The ontology "dictionary" isn't a config file — it's made of ordinary vault notes. Create them and ObsiKO picks them up everywhere (in Obsidian they degrade to plain notes, no loss).

# author.md — a relation definition note (note name = predicate name)
---
type: relation
label: wrote this work
inverse: works          # inverse name — shown in the Connections panel ("← i.e. this note's works")
color: "#c79a3c"        # graph edge color
targets: person         # the kind this relation usually points to
---

# book.md — a kind definition note (note name = kind name)
---
type: kind
extends: source         # parent kind — kindof("source") also matches books
fields: author, publisher, rating   # fields this kind usually uses
---

With a dictionary in place: - Connections panel: incoming relations get inverse names (author ↔ works), and the ＋ button adds relations without touching YAML (predicate suggestions + note autocomplete — names of not-yet-created notes are fine too). The relation check at the bottom gently flags missing targets, unregistered predicates (one-click register), and kind mismatches. - Graph view: predicate colors follow the dictionary\'s color:, and the relation chips at the bottom toggle individual relations on/off. - Bases: use kindof("source") in filters (includes sub-kinds) and ancestors("parent_area").count() in formulas (ancestor-chain rollups). - Any language for predicates: Korean keys like 저자: work as relations too.

Three quick starts: 1. Command palette → "Build kind/relation dictionary from notes" — scans the type: values and predicates you already use and offers to register them (only after you confirm; existing notes stay untouched). 2. Command palette → "View kind & relation dictionary" — the kind tree and relation list at a glance (click a row to open its definition note). 3. To take your data elsewhere, "Export vault relations (JSON-LD)" writes one standard-format file (your notes stay as they are).

📱 Mobile & web chat follow the same rules ("organize this as an ontology" — dictionary first, frontmatter only, plan approval before bulk edits). For big folders the desktop agent is sturdier.

💡 The two are a pair: Zettelkasten links say "these two are related (for this reason)," while ontology links say "this is a kind of/part of/cause of" something. It's fine to use both in one vault. See the results at a glance in the Connections panel on the right and in 10 Graph View. → Details: 17 Structuring Knowledge

← Previous: Building an LLM Wiki · Home · Next: Recommended Prompts →