LinkedIn Post · Tony Seale · 2026
An ontology is not a database artefact — it is logic. Formal, expressive, versioned. Your ontology is source code for your meaning.
Tony Seale argues that every ontology should satisfy three non-negotiable engineering criteria.
Syntax must be valid, all classes satisfiable, and all entailments exactly as expected. An absent entailment is a test failure. Shipping an ontology that contradicts itself is equivalent to shipping application code that crashes on import.
Plain text files give you diffs, branches, blame, pull requests, and review in context. Critical now that LLMs are in the loop: you want the LLM to read, navigate, and edit ontology source directly — not only through an API or MCP server.
Branches, pull requests, reviews, automated checks, releases. Engineering organisations already do all of this. The artefact deciding what the organisation means by a customer, an order, or a risk should not be governed less rigorously than the CSS on the marketing site.
Each ontology-as-code principle maps directly to an established software engineering practice.
| Ontology Practice | SE Parallel | Equivalent Tooling |
|---|---|---|
| Satisfiability + Entailment Checks | Build System | HermiT / ELK reasoner as compiler; failed satisfiability = build error; missing entailment = failing unit test |
| Plain-Text RDF Turtle Files | Version Control (Git) | diff, branch, blame, pull request, review — exactly as for application code; LLMs read/edit directly |
| Branch / PR / Release Workflow | DevOps / CI-CD | GitHub Actions / GitLab CI with reasoner validation, semantic versioning (MAJOR.MINOR.PATCH) |
Practitioners from the knowledge graph and semantic web community responded with complementary insights, caveats, and extensions.
LLMs and RDF Files as a Natural Ecosystem — LLMs and the Semantic Web stack gel naturally. You can ask an AI Agent to express conceptualisations in any RDF notation and save to a file; with the right platform (Virtuoso + DAV), files copied to a designated folder transparently update a backend quad store. LLM-powered Agents with appropriate Skills make this a "zillion times easier." The DAV demos folder at linkeddata.uriburner.com/DAV/demos/daas/ is a live example.
Caution About New Ontology Tool Vendors — Everyone should be very careful with new tools and vendors reframing themselves as ontology tools. Vendor claims should be scrutinised against the compile-branch-govern standard.
Highly Regular Ontologies May Tolerate Table-Driven Curation — For large (>10K entity) highly regular ontologies such as anatomy or chemistry, it is sometimes acceptable to curate in a table and map each row to a design pattern — provided the mapping generates compilable Turtle.
Vocabulary vs Ontology Distinction Matters — Raises whether vocabularies and taxonomies should also be treated as code, noting that large regular knowledge bases may be closer to vocabularies than full ontologies.
Four Lines of Python to Migrate from Table to Turtle — Migrating an ontology from an EAV table to RDF Turtle can require as few as four lines of Python. Shares the RDF Vendor Landscape resource for tooling overview.
Ontology as Typed Python Objects — Executable Ubiquitous Language — Proposes projecting ontology as typed Python objects using @kgbo decorators so engineers interact with familiar programming models. Ontology remains governed logic; developer experience feels like engineering with types, diffs, and PRs.
Interactive D3.js force-directed graph derived from the companion RDF/Turtle artifact. Click nodes to resolve via URIBurner. Click into graph area to activate zoom.
All queries target the named graph at the URIBurner DAV path. No Sponger pragma required — data must be pre-loaded.
PREFIX schema: <http://schema.org/>
PREFIX : <https://www.linkedin.com/posts/tonyseale_did-you-start-building-your-ontology-as-a-share-7463353332565356545-jY54/#>
SELECT ?principle ?name ?description
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-ontology-is-code-claude_sonnet4.ttl>
WHERE {
?principle a :OntologyPrinciple ;
schema:name ?name ;
schema:description ?description .
}
ORDER BY ?name
▶ Run live query
PREFIX schema: <http://schema.org/>
SELECT ?person ?name ?title ?org
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-ontology-is-code-claude_sonnet4.ttl>
WHERE {
?person a schema:Person ;
schema:name ?name .
OPTIONAL { ?person schema:jobTitle ?title . }
OPTIONAL { ?person schema:worksFor ?orgNode . ?orgNode schema:name ?org . }
}
ORDER BY ?name
▶ Run live query
PREFIX schema: <http://schema.org/>
PREFIX : <https://www.linkedin.com/posts/tonyseale_did-you-start-building-your-ontology-as-a-share-7463353332565356545-jY54/#>
SELECT ?insight ?name ?authorName
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-ontology-is-code-claude_sonnet4.ttl>
WHERE {
?insight a :CommentatorInsight ;
schema:name ?name ;
schema:author ?author .
?author schema:name ?authorName .
}
ORDER BY ?authorName
▶ Run live query
PREFIX schema: <http://schema.org/>
PREFIX : <https://www.linkedin.com/posts/tonyseale_did-you-start-building-your-ontology-as-a-share-7463353332565356545-jY54/#>
SELECT ?parallel ?name ?description
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-ontology-is-code-claude_sonnet4.ttl>
WHERE {
?parallel a :EngineeringParallel ;
schema:name ?name ;
schema:description ?description .
}
ORDER BY ?name
▶ Run live query
12 common questions about ontology-as-code practice.
10 key terms defined in the knowledge graph.
A formal specification of concepts within a domain, the relationships among them, and the constraints that cannot simultaneously hold — expressed as axioms amenable to automated reasoning.
A formal logical statement that asserts a fact or constraint about the domain model, e.g. that every Person has exactly one birthdate.
A conclusion that logically follows from a set of axioms. An absent expected entailment is treated as a test failure in ontology-as-code practice.
A class is satisfiable if it could have at least one instance. An unsatisfiable class indicates contradictory axioms and should break the ontology build.
A system (typically Git) for tracking changes to files over time, enabling branches, diffs, blame, and pull requests — the foundation ontologies should adopt.
The W3C standard language for authoring ontologies, built on Description Logic. Supports rich axiom expressivity and decidable automated reasoning.
A compact, human-readable plain-text serialisation of RDF triples. Diff-friendly, well-supported by LLMs, and compatible with standard SDLC tooling.
Software (e.g., HermiT, Pellet, ELK) that applies Description Logic rules to derive implicit facts and check satisfiability. Acts as the "compiler" in ontology-as-code pipelines.
A mechanism in Git-based workflows for proposing, reviewing, discussing, and merging changes — bringing peer review to ontology development exactly as for application code.
A precise system of rules for deriving valid conclusions. OWL ontologies are grounded in Description Logic, a decidable fragment of first-order logic.
Seven steps to adopting ontology-as-code practice within an engineering organisation.
Select RDF Turtle (.ttl) or OWL/Manchester Syntax as your canonical format. Both are human-readable, diff-friendly, and well-supported by LLMs.
Create a dedicated Git repository containing only ontology source files. Commit the initial TTL, add a .gitignore for reasoner cache artefacts, and push to a shared remote.
Configure a CI workflow that runs on every commit: validate Turtle syntax, run a reasoner to check satisfiability, and assert all expected entailments are present. Fail the build on any violation.
Adopt a branching convention: main for released versions, feature branches for new terms or axioms. Protect main with required CI passes and at least one reviewer approval.
Require pull requests for all changes. Reviewers check logical correctness, naming conventions, documentation completeness, and test coverage.
Give your LLM direct read/write access to ontology source files — not just an API or MCP wrapper. The LLM can propose new terms, spot duplicate concepts, and draft axioms within the same file-edit workflow.
Tag releases using semantic versioning (MAJOR.MINOR.PATCH). Publish a CHANGELOG with each release. A MAJOR bump signals breaking changes; MINOR adds terms backwards-compatibly.