The Day the Ontology Became a Build Artifact

Tuesday, 9:40 a.m. A message arrives from the knowledge-graph team: "We're loading the reference data into GraphDB this sprint. Can you send us an ontology for the content model?" Six months ago that message would have started a two-week side project. Today the modeler it lands on opens the CoreModels project that already governs the content model, makes one export call with format: "owl", and posts the resulting Turtle file back before her coffee is cold. It loads into GraphDB without edits. It loads into Protégé without edits. The reasoner accepts the cardinality axioms as axioms.

That is the after-state in one scene: the ontology stopped being a document someone maintains and became an artifact the governed model produces.

What actually comes out

The export is not a sketch of the model; it is the model, re-expressed in the W3C stack. Every type becomes an owl:Class, with rdfs:subClassOf carrying the inheritance the project already knows about. Every element becomes a property — a datatype property when it holds a value, an object property when it points at another type or a vocabulary — with its owning type as rdfs:domain and its value type as rdfs:range. An element reused across several types gets a union-class domain rather than being duplicated or flattened.

The facts that make a schema operational survive as OWL's own constructs. A required element is exported as a minimum-cardinality restriction on the owning class; a single-valued element as a maximum-cardinality restriction; a bounded collection keeps its upper bound. That means the required/repeatable structure of your model is visible to any reasoner and any downstream tool that reads standard OWL — the fidelity does not depend on our library being at the other end.

Controlled vocabularies come out as SKOS: a concept scheme per taxonomy, each term an individual with its preferred label, hierarchy carried by skos:broader, and any cross-standard mappings on the terms emitted as skos:exactMatch. Documentation travels too, and from further back than you might expect: a description that entered the governed model as a SQL column comment or a JSON Schema description surfaces in the ontology as rdfs:comment. Provenance an ontologist would write by hand is simply carried through.

The reverse morning

The same team has the mirror-image day. A partner sends a hand-written vocabulary — Turtle formatted by a human, SPARQL-style prefix declarations, labels in two languages, a few FOAF and Dublin Core terms mixed in. Before, this meant somebody reading the file line by line and re-typing it as an application schema, guessing at intent.

Now the file is imported under the same owl format key. Classes arrive as types with their subclass links intact. Properties arrive attached to the right types, with restriction axioms read back as required/single-valued facts — and properties with no restrictions arrive as the open world defines them, optional and multi-valued, rather than as somebody's guess. Equivalence assertions like owl:equivalentClass schema:Person are captured as cross-standard mappings on the imported nodes, so the vocabulary's links into schema.org and FOAF become queryable facts in the project. A plain SKOS concept scheme becomes a taxonomy with its hierarchy. And everything the importer could not carry — a French label where the model keeps one, triples outside the schema vocabulary — is recorded in a lossiness ledger instead of vanishing, so the review takes minutes and is about decisions, not archaeology.

Before and after, honestly

Before: the ontology and the application schema were separate deliverables with separate owners. Syncing them was a calendar event. Every schema change created invisible debt in the Turtle file; every ontology improvement stayed trapped in Protégé because nobody would hand-port it to the JSON Schema. When someone asked "is the ontology current?", the honest answer was a date.

After: there is one governed model, and the ontology is one of its renderings — alongside JSON Schema, SQL DDL, Avro, LinkML, and the rest of the formats the same project exports to. When the model changes, the next export reflects it. When the export cannot express something, it says so in the ledger rather than shipping a silent approximation. The prefix map and original datatypes from imported ontologies are preserved, so a vocabulary that arrived under its own namespaces exports back under those same namespaces — the round trip is engineered, and covered by tests, not hoped for.

The quality-of-life changes are small but constant. The knowledge-graph team pulls a fresh ontology whenever they want one, over the API or through the export_owl tool on our MCP endpoint, without filing a request. The modeling team edits definitions in one place and stops answering "which file is right?". The ontologist spends her time on actual ontology work — equivalences, hierarchy, meaning — instead of transliterating field lists, because the field lists now transliterate themselves.

What it costs

One thing, mostly: accepting that the governed model is the source of truth and the Turtle file is output. Teams with a hand-tended ontology sometimes hesitate at that — until the first time they diff a hand-maintained file against reality. The import path softens the transition: bring the existing ontology in, review the ledger of what needed adapting, and continue from a model that now renders back out to OWL and eleven other formats on demand.

To try it against your own model, the schema transform section of the CoreModels docs at https://coremodels.example.com covers the export call, the import call, and what to expect in the lossiness ledger for each.