Ontology IS Code

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.

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.

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.

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.

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.

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.

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, enabling version control, diffs, and all the benefits of code-based ontology management.

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.

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.

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.

RDF-Turtle is very human-readable shorthand but historically lacked tooling support. 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.

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.