A 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.

Knowing which floor you are on matters, because when CoreModels reads or writes "OWL," it is really conversing with the whole building. Here is the map.

The subset we speak, precisely

Our OWL support works with the parts of the stack that carry schema meaning. A governed Type is an owl:Class, and inheritance is rdfs:subClassOf. An Element is an owl:DatatypeProperty when it holds a value and an owl:ObjectProperty when it points at another type or a vocabulary; its owners are carried as rdfs:domain — as a union class when several types share the element — and its value type as rdfs:range, using the standard xsd datatypes. Required-ness and single-versus-collection travel as owl:Restriction cardinality axioms on the owning class, because that is OWL's own carrier for those facts and it is the one a conformant reasoner respects.

Taxonomies live on the SKOS floor: a concept scheme per vocabulary, each term a concept with its skos:prefLabel, hierarchy as skos:broader, and cross-vocabulary links as skos:exactMatch. A plain SKOS file with no OWL classes at all imports as a taxonomy in its own right — the floors are independent, and we treat them that way.

Cross-standard identity uses the stack's native idiom too: owl:equivalentClass and owl:equivalentProperty on classes and properties. Because every entity in this world is an IRI, identity is not a naming convention bolted on afterward — it is the substrate.

What it composes with

The payoff of speaking the standard stack is the company it keeps. An ontology exported from CoreModels loads as-is into Protégé, the editor most ontologists live in, and into GraphDB, a mainstream triple store — no preprocessing, no dialect shims. Property-graph shops can carry it into Neo4j through the neosemantics tooling. Any SPARQL endpoint, any OWL reasoner, any SKOS-aware vocabulary manager is a potential consumer, because there is nothing in the file but the recommendations those tools already implement.

The same is true of the public vocabulary ecosystem. Turtle files in the wild are woven through with schema.org terms, FOAF, Dublin Core, and domain vocabularies, connected by equivalence assertions. When we import an ontology, those equivalences are not discarded as decoration — they land as cross-standard mappings on the imported nodes, and they flow back out as equivalences on export. A model whose Person is declared equivalent to the schema.org and FOAF notions of a person keeps saying so, in every direction, in the vocabulary the rest of the world uses to say it.

Where it sits inside CoreModels

Within our own transformation surface, owl is deliberately unprivileged: one format key among many, alongside jsonschema, shex, avro, jsonld, sql, linkml, protobuf, odcs, and the rest. Every format converses with the same governed model at the center, which means OWL composes with formats that have never heard of a triple. A vocabulary imported from Turtle can be exported as SQL DDL for a warehouse team, as Avro for a streaming team, as LinkML for a data-modeling team — and the identities and equivalences that arrived as IRIs travel with it.

Its closest sibling is JSON-LD, the other RDF-family format we support. The kinship is practical, not just taxonomic: namespace prefixes preserved from a JSON-LD import are honored when the same model is exported as OWL, so a schema that arrived under its own prefixes leaves an OWL export under them too, whichever RDF door it arrived through. The stack is one family, and we treat its serializations as views of one thing — which is, after all, exactly what the W3C designed them to be.

Why vanilla matters

There is a strong temptation, when implementing a standard, to "improve" it — a custom annotation property here, a proprietary construct there, a dialect that only your own tools read back. We refuse it, for a governance reason rather than an aesthetic one.

The value of an ontology is portability of meaning. The moment an export contains vendor-specific constructs, every downstream consumer either depends on the vendor or silently drops the nonstandard parts — and silent dropping is precisely the failure mode a semantic stack exists to eliminate. So our Turtle is vanilla: W3C recommendations as published, owl, rdfs, skos, and xsd namespaces doing their standard jobs. Where our model holds something OWL genuinely cannot express, we do not smuggle it into the file under a private predicate; we leave it out and record the omission in the lossiness ledger that accompanies every conversion.

Neutrality also runs in the import direction. We do not require ontologies shaped like our own output — hand-written files, tool exports, unfamiliar formatting, vocabularies we have never seen all decode, with anything outside our schema vocabulary counted and reported rather than refused. Your ontology was never ours; it should not have to become ours to be useful.

That is the ecosystem position in one sentence: CoreModels is a hub that speaks the semantic-web stack as published, connects it to a dozen formats that never will, and keeps the exit door open — because an ontology you cannot take elsewhere is not an ontology, it is a hostage.

For the full list of supported formats and the OWL specifics, see the schema transform section of the CoreModels docs.