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.

These two documents were in agreement exactly once, on the day the second one was written. Since then, the operational schema has gained eleven fields, renamed two, and made email required. The ontology knows about none of this. It is still correct in the way a portrait is correct: a faithful likeness of how things looked some time ago.

This is the gap our OWL support exists to close.

The bottleneck is translation, and translation is manual

Formal semantics and operational schemas attract different people. The team that can write owl:Restriction axioms is rarely the team shipping the API, and the ontology usually lives in a different repository, a different tool, and a different review culture from everything else. So keeping the two in sync means a human transliterating between them — reading YAML and writing Turtle, or reading Turtle and writing SQL — and manual transliteration has two reliable properties: it happens late, and it happens lossily.

The losses are not random. They cluster around exactly the facts that matter most. Is this field required? Can it repeat? Which class does this property belong to? An ontology that answers those questions imprecisely is decoration; a database schema that answers them without any recorded meaning is a liability. And when a knowledge-graph project, a compliance mandate, or a data-sharing agreement suddenly requires a real ontology, teams discover that producing one by hand from a live schema is weeks of specialist work — and that it starts going stale the day it is finished.

The reverse journey is just as painful. Plenty of teams inherit an ontology: a domain vocabulary from a standards effort, a legacy knowledge model, a partner's Turtle file. Turning that into something an application team can build against — tables, records, validation — is another round of hand transliteration, this time performed by people guessing at what the open-world semantics were supposed to imply.

Cardinality is where naive converters give up

There is a specific technical trap here worth naming. In RDF's open-world reading, a property with no stated restriction is not "required" and not "single-valued" — it is optional and may occur any number of times. Most casual OWL-to-schema converters either ignore this (and silently invent required fields that the ontology never asserted) or throw the information away entirely (and hand you a schema where everything is an optional array).

OWL does have a native carrier for these facts: cardinality restriction axioms on the owning class. They are just tedious to write and easy to skip. We treat them as first-class in both directions. When CoreModels exports a governed model to OWL, a required element becomes a minimum-cardinality restriction and a single-valued element a maximum-cardinality restriction — real axioms that a real reasoner sees, not comments or naming conventions. When we import an ontology, those same restrictions are read back as required/collection facts, and a property with no restrictions decodes as what the open world actually says it is: optional and multi-valued. The required/repeatable truth — the truth applications most need — survives the round trip.

What the bridge looks like

CoreModels treats OWL in its Turtle serialization as one schema format among many, under the format key owl, and it works in both directions. Export a governed project and you get an ontology that loads as-is into GraphDB or Protégé: a class per type with subclass axioms for inheritance, a datatype or object property per element with its domain and range, and your controlled vocabularies expressed as SKOS concept schemes with broader/narrower hierarchy. Import a Turtle document — including hand-written ones that look nothing like our own output — and classes become types, properties become elements attached to the right types, and SKOS vocabularies become taxonomies.

Because every OWL entity is an IRI, identity comes along for free. Equivalence assertions — owl:equivalentClass, owl:equivalentProperty, skos:exactMatch — are captured as cross-standard mappings on the imported nodes, and mappings recorded in the governed model flow back out as equivalences on export. The ontology's connections to schema.org, Dublin Core, or a domain vocabulary are not lost in translation; they are the translation.

And where the two worlds genuinely cannot express each other — OWL has no construct for a curated view; our model holds one label where an ontology may carry many language-tagged ones — nothing disappears silently. Every such gap is written into a lossiness ledger that travels with the result, so the person reviewing the translation knows exactly what it could not carry.

One definition, two audiences

The point is not that everyone should learn OWL, or that ontologists should give up their tools. It is that "the ontology" and "the schema" were never two different things — they are two renderings of one set of definitions, and the rendering should be mechanical. When it is, the semantics team and the application team stop maintaining rival truths about Person, and the ontology stops being a portrait and becomes a live view.

If you have a governed model that needs to become an ontology, or an ontology that needs to become an operational schema, the transform documentation at https://coremodels.example.com walks through both directions.