Connect OWL ontologies
Keep the ontology and the application schema from becoming two portraits of Person.
How CoreModels works with OWL
OWL is the right language for description logic. It is the wrong runtime for APIs and warehouses. Teams export once, then the running schema evolves in git while the ontology evolves in Protégé.
CoreModels imports OWL as types and properties, then lets you generate and audit the schemas applications actually compile. Equivalences and subclass axioms inform mapping; the lossiness ledger shows what OWL expressivity the target format cannot hold.
The goal is not to make engineers open Turtle. It is to make the next field added to the API a governed change against the same Person the ontology already named.
Recipes
No recipes yet for OWL. The articles below still describe the problem this connector is built to close.
Uses
Problems this connector fixes
Articles that explain the gap, then point at the recipe that closes it.
Two Truths About "Person": Why Ontologies and Application Schemas Drift Apart
Somewhere in your organization there are two documents that both claim to define a person. One is an OWL ontology, lovingly curated in Protégé by someone who understands description logic: `Person` is a class, `name` is a datatype property, there are equivalences to schema.org and careful subclass axioms. The other is the schema your applications actually run on — a JSON Schema, a set of `CREATE TABLE` statements, an Avro record — written by engineers who have never opened a Turtle file and never will.
OutcomesThe 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.
GovernanceThe Confession at the Top of the File: Governance Through the OWL Round Trip
Open an ontology exported from CoreModels and, before any prefix declaration, you may find something unusual: a block of comment lines beginning `# lossiness:`. Each one names a kind of change, the exact path in the model where it happened, and a plain-English explanation of what the export could not carry. Comments are valid Turtle, so the file still loads cleanly into GraphDB or Protégé — but anyone who opens it reads the confession first.
EcosystemA Field Guide to the Stack Beneath OWL — and Why We Keep Our Turtle Vanilla
OWL is not one standard; it is the top floor of a building. At the foundation sits RDF, the data model in which everything is a triple — subject, predicate, object — and every named thing is an IRI. Above it, RDFS adds the basic schema vocabulary: classes, properties, domains, ranges, subclass relations. OWL adds the expressive machinery on top — equivalences, restrictions, unions, the constructs a reasoner can actually reason over. Beside the tower stands SKOS, the W3C vocabulary for thesauri and controlled vocabularies: concepts, schemes, broader/narrower hierarchy, preferred labels. And Turtle is none of these — it is simply the friendliest syntax for writing any of them down, the serialization humans actually read.
AgentsAxioms Beat Sample Data: What OWL Support Means for AI Agents
Ask an AI agent to integrate with a system it has never seen, and watch what it does: it requests a few sample records and starts inferring. Three JSON documents in, it has decided that `email` is always present (it appeared in all three), that `tags` is a scalar (each sample happened to have one), and that `status` takes two values (it saw two). Every one of those conclusions is a guess dressed as knowledge, and every one can be wrong in ways that surface weeks later as a production incident.
QuickstartTurtle In, JSON Schema Out: Your First OWL Transform
There is a `.ttl` file somewhere in your repository. Someone modeled the domain properly once — classes, subclass axioms, cardinality restrictions, a SKOS scheme for the controlled list — and then everyone else carried on hand-writing JSON Schema and DDL, because nothing bridged the two.
APIOWL Over HTTP: Export, Import, Map, Replay
Two questions decide whether a format is really supported: can the system read it, and can the system write it? For the `owl` format key in CoreModels the answer is yes to both, and this article is the proof — four routes, real request bodies, real responses, and the direction rules stated without hedging.
MCPOntology Alignment You Can Delegate: `transform_schema` and OWL Over MCP
A partner sends you their vocabulary as a Turtle file. You need your catalog expressed in their terms so the two sides can exchange data, and you need a record of which of your concepts had no counterpart on their side. That used to be an afternoon in an ontology editor plus a spreadsheet nobody trusts.
AutomationInfer Once, Gate Always, Replay Forever: OWL in a Build Pipeline
Commit an exported ontology, re-run the export tomorrow, and look at the diff. If it shows reordered prefixes and reshuffled blocks, the export is not a build artifact — it is a rumor, and no reviewer will read it twice. If it shows exactly the statements your model changed, you have something CI can gate on.
Deep diveWhat the OWL Coder Knows: The IR Map, the Extras, the Ledger
Ask a schema converter what it does with `owl:Restriction` and you learn most of what you need to know about it. Many treat OWL as a serialization problem — emit classes and properties, drop the axioms — so "required" and "single-valued" evaporate at the border. CoreModels treats it as a semantics problem: required and cardinality ride as `owl:Restriction` subclass axioms, OWL's own carrier, in **both** directions. That decision propagates through everything below.