Did you start building your ontology as a set of rows in a custom database table?
Tony Seale argues that ontologies should be treated as source code — compiled, versioned, reviewed, and shipped — rather than stored in database tables. An ontology is source code for your meaning.
Tony Seale
Knowledge Graph & Ontology Expert
Kingsley Uyi Idehen
Founder & CEO, OpenLink Software
Veronika Heimsbakk
Knowledge Graph Specialist, Author of SHACL for the Practitioner
Gabor Csepregi
Joseph Macdonald
Harish Iyer
Robert Sanderson
Mark O'Donovan
Honorio J. Padrón III
Olivier REY
Stepan Karandin
Tony Seale LinkedIn Post Image
Ontology IS Code — Analysis
Analysis of Tony Seale's argument that ontologies should be treated as source code: compiled, versioned, reviewed, and shipped — not stored in database tables.
ontology, knowledge graph, software engineering, version control, Git, RDF, Turtle, JSON-LD, LLM, AI agents, semantic web
Ontology as Code
The principle that ontologies should be treated as source code artifacts — compiled, versioned, reviewed, and shipped — rather than stored in database tables.
Knowledge Graphs
Graph-based representations of knowledge using RDF, OWL, and related semantic web technologies.
Software Engineering Practices
Engineering practices including version control, code review, automated testing, CI/CD, and branching strategies applied to ontology development.
Ontology IS Code
Tony Seale's core argument: ontologies are logic and formal logic expressed as rigorous axioms. They should compile, live in plain text, and be governed like code.
Ontology Should Compile
An ontology should compile — not just parse. The syntax should be valid, classes satisfiable, and entailments expected. An absent entailment is a test failure.
Ontology Should Live in Plain Text
Ontologies should live in plain text files — enabling diffs, branches, blame, pull requests, and review in context. LLMs should read, navigate, and edit the source directly.
Ontology Should Be Governed Like Code
Ontologies should use branches, pull requests, reviews, automated checks, releases, and builds — governed more rigorously than CSS on a marketing site.
Ontology Governance
The argument that the artefact deciding what an organisation means by a customer, order, risk, or product should not be governed less rigorously than application code.
Comments on Ontology IS Code
41 comments from knowledge graph practitioners, engineers, and industry leaders responding to Tony Seale's post.
Kingsley Idehen on Files-and-Filesystem Pattern for Ontologies
The creation and management of ontologies — and even instance data — is a classic files-and-filesystem interaction pattern. Prior to LLMs, this was difficult due to RDF notation issues: Turtle is human-readable but lacked tooling; JSON-LD had tooling but wasn't human-readable; RDF/XML was challenged on both. Today, the Semantic Web stack gels naturally with LLMs and AI Agents. You can ask an AI Agent to express your conceptualization in whatever notation you prefer and save the result to a file. You can copy those files to a folder transparently bound to a backend RDF DBMS for updating the underlying quad/triple store. LLM-powered Agents loosely coupled with appropriate Skills make this process a zillion times easier.
Gabor Csepregi on Ontology Explanation
I don't know how you ended up in my feed, but also can't remember the last time I had ontology and knowledge graph related content properly explained.
Joseph Macdonald on Logic as Data and TODAGs
Not only is Ontology code, Logic as data is important. We should be mostly using WhenTTT, not only IFTTT. Ontologies used in Temporal Objective-Directed Acyclic Graphs (TODAG) — a form of hypergraph designed to treat Ontologies and other data as revenue generating assets. Ontologies are great for many to many relationships on the client as opposed to server based computation.
Harish Iyer on Ontology as Company Language
In today's time when the gap between engineering, design and product is narrowing — the ontology layer should no longer be a layer — but more about the language of the company. It will eventually be the catalyst that enables product building, shipping and maintaining become seamless. The concept of context switching within product teams will be replaced with context expansion. However, it comes with shedding a lot of dead know-how, myths, and misinterpretation of terms, terminology and internal mis-definitions. Curious how you see the ontology guardian sitting in the product stack. As AI systems increasingly consume organizational context as a direct input, the ontology stops being documentation and starts being an active dependency. Which makes who owns it, and how well they guard it, one of the more consequential product decisions a company will make.
Robert Sanderson on Linked Art Transpiling Ontology to Code
For Linked Art, part of our compile pipeline is to process the ontology from RDFS+OWL into a python class library, so instead of graph.add(T triple) engineers can do the much more familiar: r = Person(id='Rob'); r.name = 'Rob'. Ontology is code ... and transpiles to other code that makes it more developer friendly.
Veronika Heimsbakk on Getting Ontology from Tables to Code
Hear, hear! And if you have your 'ontology' in tables, it's super-easy getting it into code and work iteratively from that, just four lines of Python.
Mark O'Donovan on His Ontology Journey
I started my business ontology as an idea in my head. Then a note in a notebook. Then an excel table. Then a sql Table (well set of them). Now looking at graphDB.
Honorio J. Padrón III on Decision Ontology vs Operational Ontology
Most enterprises are building operational ontologies. Objects, attributes, relationships. What exists. That problem is real and your point about treating it as code rather than a database table is exactly right. But there is a second ontology that almost nobody is building. The decision ontology. Not what exists, but what the enterprise does about it. Who owns each decision. What triggers it. What action it generates. How the loop closes and feeds back. An operational ontology makes your data legible. A decision ontology makes your enterprise executable. You can have a perfect vocabulary and still fail to act, because no one has defined the decision. That is the gap I built CLEARED to close. The platform sits above the semantic layer and above the operational ontology. It is the layer that governs the grammar of enterprise action, not just the vocabulary of enterprise data. And like you said about the ontology itself, that layer needs to compile. It needs to be versioned. It needs to break the build when authority is undefined or when a trigger has no owner. Your ontology is source code for your meaning. The decision ontology is source code for your will to act.
Olivier REY on Ontology as Graph Not Code
I would rather say: 'an ontology is an (hyper-) graph'. Code is not a graph but a tree.
Stepan Karandin on Ontology as Information
From my point, ontology is information. Database or any code/signature is just data (format) describes information. Your example of relation database is the worst kind of normalization for ontology. In maths ontology could described as graph.
FAQ: Ontology IS Code
Frequently asked questions about treating ontologies as source code.
Why should ontologies be treated as code rather than database tables?
Answer: Ontologies are logic, not data storage
Ontologies declare what kinds of things exist, how they relate, and what cannot both be true. They are formal logic expressed as rigorous axioms. Treating them as code enables compilation, validation, versioning, and review — capabilities that database tables cannot provide for logical artifacts.
What does it mean for an ontology to 'compile'?
Answer: Syntax validation, satisfiability, and entailment checking
An ontology should compile meaning its syntax should be valid, classes should be satisfiable, and entailments should be the ones expected. An absent entailment is a test failure, not a curiosity discovered months later in production. If the model says two things that cannot both be true, the build should break.
Why should ontologies live in plain text files?
Answer: Diffs, branches, blame, and pull requests
Plain text files enable diffs, branches, blame line by line, pull requests, and review in context. This is especially important now that LLMs are in the loop — you want the LLM reading, navigating, and editing the source directly, exactly the way it works with a codebase.
How should ontologies be governed?
Answer: Branches, pull requests, reviews, automated checks, releases, builds
Ontologies should use branches, pull requests, reviews, automated checks, releases, and builds. The artefact that decides what an organisation means by a customer, an order, a risk, or a product should not be governed less rigorously than the CSS on a marketing site.
What role do LLMs play in ontology development?
Answer: LLM-powered agents make ontology creation dramatically easier
LLMs can express conceptualizations in any RDF notation (Turtle, JSON-LD, RDF/XML) and save the result to a file. LLM-powered agents loosely coupled with appropriate skills make the process dramatically easier. You can copy files to a folder transparently bound to a backend RDF DBMS for updating the quad/triple store.
What is the difference between operational and decision ontologies?
Answer: Operational describes what exists; decision describes what to do about it
An operational ontology describes objects, attributes, and relationships — what exists. A decision ontology describes who owns each decision, what triggers it, what action it generates, and how the loop closes. An operational ontology makes data legible; a decision ontology makes the enterprise executable.
How can you migrate an ontology from database tables to code?
Answer: Four lines of Python can extract and convert
If your ontology is in tables, it is super-easy to get it into code and work iteratively from that. Just four lines of Python can extract the table data and convert it to RDF format, enabling version control, diffs, and all the benefits of code-based ontology management.
What is the Linked Art approach to ontology compilation?
Answer: Transpile ontology from RDFS+OWL into Python class libraries
For Linked Art, part of the compile pipeline processes the ontology from RDFS+OWL into a Python class library. Instead of manually adding triples to a graph, engineers can use familiar object-oriented patterns: r = Person(id='Rob'); r.name = 'Rob'. The ontology transpiles to developer-friendly code.
Is an ontology a graph or code?
Answer: Both — it is a hypergraph that should be managed like code
An ontology is fundamentally a (hyper-)graph of interrelated concepts. Code is typically a tree structure. The argument for treating ontology as code is about the management practices — versioning, review, compilation — not about the underlying data structure being a tree.
What is the 'ontology guardian' role in product stacks?
Answer: The ontology becomes an active dependency, not documentation
As AI systems increasingly consume organizational context as a direct input, the ontology stops being documentation and starts being an active dependency. Who owns it and how well they guard it becomes one of the more consequential product decisions a company will make.
What are the challenges of RDF notations for ontology development?
Answer: Trade-offs between human-readability and tooling support
RDF-Turtle is very human-readable shorthand but historically lacked comprehensive tooling support compared to other formats. JSON-LD had more tooling support but wasn't as human-readable. RDF/XML was challenged on both fronts. Today, LLMs bridge this gap by generating any notation on demand.
What is the typical journey of building an ontology?
Answer: From idea to notebook to spreadsheet to SQL to graph database
A common journey: start with an idea in your head, then a note in a notebook, then an Excel table, then a SQL table (or set of them), and finally a graph database. Each step represents increasing sophistication in modeling relationships and semantics.
Glossary: Ontology as Code Terms
Key terms from the Ontology IS Code discussion.
Ontology
A formal representation of knowledge as a set of concepts within a domain and the relationships between those concepts. In software engineering, an ontology is source code for organizational meaning.
Knowledge Graph
A graph-based data structure that represents entities and their relationships, typically using RDF and semantic web technologies to enable reasoning and inference.
RDF (Resource Description Framework)
A standard model for data interchange on the web, representing information as subject-predicate-object triples. Supports multiple serializations including Turtle, JSON-LD, and RDF/XML.
Turtle (Terse RDF Triple Language)
A human-readable RDF serialization format using prefixes and shorthand notation. Very readable but historically lacked comprehensive tooling support compared to other formats.
JSON-LD (JSON for Linking Data)
A JSON-based serialization for linked data that combines JSON's developer familiarity with RDF's semantic capabilities. More tooling support than Turtle but less human-readable.
Version Control
A system that records changes to files over time, enabling diffs, branches, blame, pull requests, and review. Essential for managing ontologies as code artifacts.
Entailment
A logical consequence that follows from the axioms in an ontology. An absent entailment is a test failure — if the model should derive something but doesn't, the build should break.
Satisfiability
A property of a class in an ontology meaning that there exists at least one possible instance that satisfies all its constraints. Unsatisfiable classes indicate logical contradictions.
Operational Ontology
An ontology that describes what exists in an organization — objects, attributes, and relationships. It makes data legible but does not define what actions to take.
Decision Ontology
An ontology that describes what an enterprise does about what exists — who owns each decision, what triggers it, what action it generates, and how the loop closes. It makes the enterprise executable.
How to Treat Your Ontology as Code
Step-by-step guide for transitioning from database-table ontologies to code-managed ontologies.
Step 1: Extract Your Ontology from Tables
If your ontology currently lives in database tables or spreadsheets, extract it using a simple script. Four lines of Python can convert table rows to RDF triples in Turtle or JSON-LD format.
Step 2: Save to Plain Text Files
Save your ontology as plain text files in a version control system (Git). Use Turtle for human readability or JSON-LD for tooling compatibility. Organize by domain or module.
Step 3: Set Up Compilation Pipeline
Configure a build pipeline that validates syntax, checks class satisfiability, and verifies expected entailments. Use tools like PySHACL, Jena, or Protégé for validation. The build should break on contradictions.
Step 4: Establish Code Review Process
Require pull requests for all ontology changes. Review in context with diffs. Ensure new terms don't silently duplicate existing concepts. Treat ontology review with the same rigor as application code review.
Step 5: Integrate LLM Agents
Configure LLM-powered agents to read, navigate, and edit your ontology source files directly. Use skills to express conceptualizations in any RDF notation on demand. Connect to a backend RDF DBMS for quad store updates.
Step 6: Define Decision Ontology
Beyond operational ontology (what exists), define a decision ontology: who owns each decision, what triggers it, what action it generates, and how the loop closes. This makes your enterprise executable.
Step 7: Ship Releases
Version your ontology releases like software releases. Tag versions, maintain changelogs, and ensure downstream systems consume specific versions. The ontology that defines organizational meaning should be shipped with the same rigor as application code.
Large Language Models (LLMs)
AI models that can generate, read, navigate, and edit ontology source files in any RDF notation, dramatically simplifying ontology development workflows.
An ontology describing what an enterprise does about what exists — decision ownership, triggers, actions, and feedback loops. Source code for organizational will to act.
Ontology Migration from Tables to Code
The process of extracting ontology data from database tables or spreadsheets into plain text RDF files for version control and code-based management.
Linked Art
A community and ontology for cultural heritage data that transpiles RDFS+OWL ontologies into Python class libraries for developer-friendly usage.
Ontology as Graph
The perspective that an ontology is fundamentally a (hyper-)graph of interrelated concepts, distinct from code which is typically a tree structure.
Ontology Guardian
The role responsible for owning and guarding an organization's ontology as an active dependency for AI systems, not just documentation.
RDF Notations
Different serialization formats for RDF data including Turtle (human-readable), JSON-LD (tooling-friendly), and RDF/XML (legacy). LLMs bridge the gap between readability and tooling.
Ontology Development Journey
The typical progression from idea to notebook to spreadsheet to SQL tables to graph database, representing increasing sophistication in modeling relationships.
kg-generator skill
Knowledge Graph Generator skill for transforming web content into RDF knowledge graphs using schema.org terms.
rdf-infographic-skill
RDF-based HTML and Markdown Infographic Generation Skill.
qwen3.6-plus
Large language model by Alibaba Cloud (Qwen series) used for RDF generation and infographic creation.
opencode
AI-powered coding agent that orchestrates skill execution, file generation, and validation workflows.