Class, Relation, Instance: Turn Your Content Inventory Into a Graph (No Plugins)

Every content inventory starts as a list: URL, title, type, owner, last updated. And every content strategy question that matters is about relationships: which articles support this service page? Which guide replaced that one? Which topics have only one piece holding them up? A list can’t answer those questions. A list is a graph with all its edges deleted.

You don’t need a knowledge-graph platform, a plugin, or a database to fix that. You need three ideas borrowed from ontology design (classes, relations, and instances) and the discipline to write them down consistently. This guide gives you a minimal content ontology you can run in plain Markdown or a spreadsheet, five diagnostics that only a graph can perform, and a direct path from the graph to better internal linking and briefs.

Three ideas, borrowed precisely

The W3C’s OWL 2 Primer organizes knowledge around three kinds of things, and they map cleanly onto a content inventory:

• Classes: kinds of things. Service Page, Article, Topic, Audience, Proof.
• Properties (relations): typed connections between things. supports, about, for, supersedes.
• Individuals (instances): the actual things. “/services/furnace-repair/” is an instance of Service Page.

The power is in the typing. “These pages are related” is a vague tag. “This article supports that service page” is a claim with a direction and a meaning, and you can query it, check it, and act on it.

You don’t need to write OWL to use the idea. You need to stop using one undifferentiated “related” field and start naming your relations.

A minimal content ontology: 5 classes, 4 relations

Start small. This covers most service-business and small-publisher sites:

Classes

Relations

Four relations is deliberate. Every relation you add is a field someone has to fill in correctly on every page. Add a fifth only when a real question can’t be answered without it.

Design rules that keep it usable

1. Every relation has a direction and a definition. Write the one-line meaning down. If two people would fill the field differently, it isn’t defined yet.
2. One primary about per page. Secondary topics are fine, but a page that is “about” six topics is about none of them, and that is a finding in itself.
3. Relations point at instances, not strings. “Furnace lifespan” must be spelled the same way everywhere, ideally as a link to a Topic note or a row ID. Free-text values quietly fork your graph.
4. Classes don’t overlap. A thing is a Page or a Service, never both. If your service page is confused with the service itself, you’ll never be able to ask “which services have no supporting page?”

Implementation: plain Markdown, no plugins

If your inventory lives in a Markdown-based notes tool, each instance is a note, and its relations live in the frontmatter:

---
class: Page
url: /blog/repair-vs-replace/
supports: "[[Furnace repair]]"
about: "[[Furnace lifespan]]"
for: "[[First-time homeowners]]"
supersedes: "[[Old furnace guide]]"
updated: 2026-11-01
---

Topics, services, and audiences each get a note of their own, whose class is in their frontmatter. Because the relation values are links, every Service note’s backlinks show the pages that support it, with no query language required. In Obsidian, you can also search frontmatter directly: per the Obsidian search documentation, [supports] finds notes that have the property at all, and [about:null] finds notes where it exists but is empty.

In a spreadsheet, it’s two tabs: Instances (ID, class, name, URL) and Relations (from ID, relation, to ID). The Relations tab is the graph. Pivot it, filter it, count it.

Build it in one afternoon

The fastest path from list to graph is a fixed sequence:

1. Export the inventory. URL, title, and type for every page. That’s your Page instances.
2. List services from the business, not the site. Use the price list, the proposal template, or the invoice line items. Services that exist only in invoices are your most important findings.
3. Name topics from what you want to be known for. Five to twelve is plenty for a small site. Resist importing a keyword tool’s cluster list wholesale: topics are strategic choices, not search-volume artifacts.
4. Define audiences by buying situation, not demographics. “Landlord with an emergency” models behavior better than “adults 35–54.”
5. Fill relations in one pass per relation. Do every supports first, then every about, and so on. Filling page by page invites inconsistency, while filling relation by relation keeps each definition fresh in your head.
6. Run the five diagnostics and write the findings as a dated note.

The sequence matters because steps 2–4 force decisions the inventory never asked for. Most teams discover at step 2 that their site and their offer have drifted apart, and that discovery alone is worth the afternoon.

Five diagnostics only a graph can run

This is where the structure pays for itself. Each diagnostic is a simple count or filter, and each one surfaces a problem a flat list hides:

Run them quarterly. The first run usually produces a backlog more useful than any keyword tool’s, because it’s grounded in your own business model rather than in search volume alone.

From graph to internal links and briefs

The relations become instructions:

• Internal linking: every page with supports → Service X should link to Service X’s page, and Service X’s page should link back to its strongest supporters. Pages sharing an about should link to each other. You no longer decide links page by page. The graph tells you which links are missing.
• Briefs: a new brief inherits its relations before a word is written. It supports this service, is about this topic, is for this audience, and supersedes that page. The writer starts with the context the whole strategy depends on.
• Refresh queues: export the Relations tab to CSV and join it to your refresh scoring. A decayed page that supports a top service outranks a decayed page that supports nothing.

There’s also a search-facing benefit. Google’s SEO starter guide calls links “a great way to connect your users and search engines to other parts of your site.” Typed relations make that linking systematic rather than incidental.

Worked example: a plumbing contractor

Illustrative example. A plumbing contractor’s 60-page inventory, mapped into the ontology in an afternoon, gives these first diagnostic results:

• Unsupported services: water-heater installation, the highest-margin service, has zero supporting articles. Every water-heater article on the site is about repair.
• Orphan pages: seven pages, mostly old event announcements and a duplicated “about our team” page.
• Thin topics: “Water pressure” is held up by one 2022 post.
• Supersedes chains: a 2021 drain-cleaning guide is still live alongside its 2024 replacement, and both rank weakly.
• Audience gaps: property managers, a meaningful customer segment, appear on no page at all.

None of these needed traffic data to find. Each one is a structural fact about the site, and each produces a concrete action: two briefs, one merge with a redirect, one retirement batch, and one audience-specific landing page.

The ontology test

A good content ontology passes one test: can a new team member answer “what is this page for?” from the inventory alone? If the answer requires asking the person who wrote it, the relations are missing. If it’s in the row, your inventory has stopped being a list and become a working model of the business.

Start with a working model, not a blank vault

Organa Obscura’s Ontology & Knowledge-System Starter Kit gives you this structure ready to use. It’s an Obsidian vault organized into Core, Domain, and Applied layers with hub notes, plus eight templates (Concept/Class, Relation, Instance, Hub, Decision, Digest, Project Workbench, and Daily) so every new note starts with the right fields. A complete worked example (a Home Library with Book, Author, Shelf, and Genre classes and the relations writtenBy, locatedOn, and hasGenre) shows classes, relations, and instances working together as notes, as a CSV, and as a Turtle (.ttl) OWL file you can open in RDF/OWL tools such as Protégé. A “Catalog My Library” project with a CSV workbench walks you through modeling your own domain. No plugins required.

Swap the library for your content inventory, and you have the graph this article describes.