Rethinking PKM Part 4: Gardening in my Obsidian Vault with ExcaliBrain and Dataview

A key shift in personal knowledge management is treating link structure as an explicit “ontology”—a defined set of relationship types—then using Excalibrain to visualize those relationships consistently inside an Obsidian vault. The payoff is practical: once relationships like “friend,” “parent,” and “child” are encoded as fields, Excalibrain can render a graph where related documents and concepts appear in predictable positions, making exploration faster and meaning clearer.

The workflow centers on separating two mental tasks that often get mixed together: (1) deciding what relationship a link represents and (2) deciding how that relationship should be visualized in Excalibrain. Instead of designing visualization on the fly, the user adds a DataView field (the “example” field in the “Building a Second Brain” page) that acts as the ontology for that link. Excalibrain then uses the field to show how “Building a Second Brain” relates to “Gardening in my world” and to other surrounding documents. Crucially, the relationship definition isn’t locked in—changing the ontology mapping later can immediately alter the graph layout. For instance, moving items from “friend” to “child” is done by editing the ontology field in Excalibrain settings, after which the graph updates so “Building a Second Brain” becomes a child of “Gardening in my world.”

To keep the system clean, the transcript describes a cleanup step for Excalibrain’s “unassigned fields” list. Many DataView fields exist in the vault but haven’t yet been categorized as parent/child/friend. Some fields are intentionally excluded from the ontology because they’re not meant to become links—examples include “twitter” (a username/address) and “email” (never a navigable node). By moving such fields into an “excluded” category, they disappear from the unassigned list and avoid cluttering the ontology choices.

The same categorization logic extends to fields that represent roles or membership. “Architect,” for example, is treated as a member of a project, so it’s added in a way that places related people on the left side of the graph when viewing project relationships. The end result is a consistent visual grammar: when someone is sought in relation to a project, the graph layout signals where that person should appear.

Excalibrain enhancements also support the workflow. A suggester lists all DataView fields that are valid ontology candidates, with triggers to filter by parent, child, friend, or the full set. DataView “mid-sentence fields” let the user embed ontology-driven links inside running text using bracket syntax, so concepts can be linked naturally within sentences.

The transcript then argues that ontology should be built while writing, not retrofitted later. A retrospective cleanup attempt is described as “super hard slash impossible,” requiring significant time and mental effort. The practical conclusion: adding ontology upfront reduces uncertainty about what to write as a connector and adds context immediately, which later enables Excalibrain graphs to reveal connections that would otherwise remain hidden.

Finally, the workflow includes quick corrections: when a new relationship like “contradicts” appears as unassigned, it can be promoted into the ontology via a comment palette action (e.g., setting it as a “friend”). A display toggle controls whether suggested field names appear in bold, improving readability when inserting DataView fields into text.