OWL

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.

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.

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.

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.

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.