# Ontology In philosophy, ontology is the study of what exists. In information science, Tom Gruber defined an ontology in 1993 as "an explicit specification of a conceptualization": the kinds of things a system recognizes, what each of them carries, and how they relate to each other. In [[Personal Knowledge Management (PKM)]], the second meaning is the one that matters: which kinds of notes exist in your system, which metadata each one has, and how they connect. Every vault has one, whether you wrote it down or not. Your folders, note types, properties and links all declare what exists in your world. If your system has no type for something, you won't capture it reliably, and you can't query it either. ## Taxonomy or ontology? I often describe the [[IPCRA Method]] as a simple ontology for knowledge and context management. Strictly speaking, it's a taxonomy: a classification where each note sits in exactly one category (Inbox, Projects, Caps, Resources or Archives). A taxonomy is a tree. It tells you where a note goes, but it says nothing about what the note is or how it relates to other notes. The same goes for the [[PARA method]] and the [[Johnny Decimal system]]. In my [[Types of tags|tag system]], topic tags play that role too: I call them taxonomy tags. An ontology adds three things on top of a classification: 1. **Types**: distinct kinds of things (a project, a task, a goal, a person, a book) 2. **Properties**: what each type carries (a task has a status, a due date and a priority; a book has an author and a rating) 3. **Relations**: how things connect (a task belongs to a project, a project serves a goal, a book has an author) With relations, the structure becomes a graph instead of a tree (cfr [[Knowledge Graph (KG)]] and [[Personal Knowledge Graph (PKG)]]). ## The Obsidian Starter Kit as an ontology The note types of the [[Obsidian Starter Kit]] are much closer to a real ontology. My vault has 96 of them (November 2026). Each one has [[One home per note|one home]], its own metadata, template, rules and workflows. And they're related: a task points to its project (`related_projects`), a project points to its goals (`related_goals`) and to its areas (`areas`), an activity carries a cadence instead of a deadline. The folders are still there as the taxonomic backbone (cfr [[Organize information by type, not by topic]]); the types, properties, tags and links form the ontology on top. An ontology only helps if the notes respect it. A convention that nothing checks drifts as the vault grows. That's why the [[Obsidian Starter Kit plugin for Obsidian|OSK plugin]] defines each type with its properties, tags, icons, folder and template, recognizes a note's type by tag, folder or name pattern, and validates notes against their type. It also exports the type definitions (md-base files), and exposes them through `osk-cli` and an MCP server. [[TypedMark]] is where I'm taking this next: an open specification for typed Markdown note systems. Note types are defined by schemas, with fields, reusable property sets, inheritance and validation. Every managed note conforms to exactly one concrete type, and tools infer structure from those artifacts alone, never by guessing at prose. The structure lives in the files themselves (YAML frontmatter), so the notes stay plain Markdown (cfr [[File over app principle]]). With the plugin and TypedMark, I'm trying to build taxonomies and ontologies that are SOLID, that scale, and that the AI system on top understands and uses correctly. ## Why it matters for AI This is what lets automation and AI agents work on my vault. An agent doesn't have to guess what a note is or where the tasks of a project live: the type definitions tell it. In my vault, agents ask the OSK plugin for a type's folder, template, required fields and statuses instead of hardcoding them (cfr [[Obsidian Starter Kit - System - AI Assistant System]]). The ontology is part of the context you give to AI (see [[Context Engineering]] and [[AI-Ready Second Brain]]). Declared types replace guesses, and less guessing means more predictable output (cfr [[Context Reduces AI Entropy]]). Typed metadata is also one of the dimensions of [[PKM-to-AI Readiness]]. Companies hit the same problem with their databases. A schema says that a column exists, not what it means, so an agent writing SQL has to guess. [[NVIDIA Auto Ontology]] (November 2026) drafts a business ontology (terms, reviewed SQL expressions, joins) from database metadata, has people certify it, and only then lets agents answer questions against it. ## References - Tom Gruber, "A Translation Approach to Portable Ontology Specifications" (1993) - W. V. O. Quine, "On What There Is" (1948) ## Related - [[Organize information by type, not by topic]] - [[One home per note]] - [[TypedMark]] - [[Obsidian Starter Kit plugin for Obsidian]] - [[Obsidian Starter Kit - Reference - Note Types]] - [[Types of notes in a Personal Knowledge Management System]] - [[Information Architecture (IA)]] - [[Knowledge Graph (KG)]] - [[Personal Knowledge Graph (PKG)]] - [[Web of knowledge]] - [[Types of tags]] - [[Templates make notes easier to find]] - [[File over app principle]] - [[IPCRA Method]] - [[PARA method]] - [[Johnny Decimal system]] - [[AI-Ready Second Brain]] - [[Context Engineering]] - [[Context Reduces AI Entropy]] - [[PKM-to-AI Readiness]] - [[NVIDIA Auto Ontology]] - [[Obsidian Starter Kit - Theory]] - [[AI Wiki - PKM - Ontology]] - [[AI Wiki - PKM - Taxonomies vs Ontologies]] - [[AI Wiki - PKM - Ontological Commitment]]