The Atlas, modeled as an ontology
The Atlas catalogs ontologies — so what happens if we describe how it does that as an ontology itself? It turns out the filter system you use to search is already a lightweight ontology. Here it is made explicit, and written three ways so you can feel what each ontology language is actually for.
Same model, three languages, one notation (Turtle). The only thing that changes between the tabs below is how much the language lets you say.
Three layers people conflate
Before the model — the distinction that trips everyone up. "What kind of ontology" is really three independent choices:
| Layer | What it decides | Examples | On this site it's… |
|---|---|---|---|
| Notation | how the text is written | Turtle, RDF/XML, JSON-LD | just the file format |
| Language | its modeling power & logic | SKOS, RDFS, OWL | the Format facet |
| Type | the role the ontology plays | taxonomy, domain, upper, thesaurus | the Type facet |
They cross freely: the SKOS tab below is a taxonomy (type) written in SKOS (language) as Turtle (notation).
The Type axis — kinds of ontology
This is the layer you were probably expecting: the role an ontology plays. The same subject can be modeled as any of these — they differ in scope and rigor, not topic. Each is a value of the Type filter on the search page, so every card links straight to a real example and to that slice of the Atlas.
The abstract top layer — continuants vs occurrents, parts and wholes — that domain ontologies build on. Broad and reusable; rarely used on its own.
Models one subject in depth — its own classes, properties and rules. The workhorse, and most of the Atlas.
A hierarchy of terms (broader / narrower), often with synonyms and related-term links — but no logic. Perfect for tagging and browsing. Usually written in SKOS.
A ratified specification from a standards body — stable, versioned, governed. May or may not carry heavy logic; the point is authority.
Not an ontology itself — a directory that catalogs many ontologies. (The Atlas is one of these.)
The model
Every catalog entry is a Resource. Each facet on the search page is a relationship from that Resource to a value — and the Topic → Domain hierarchy is a narrows link. This picture is generated automatically from atlas-rdfs.ttl with Graphviz — the same class-and-relationship graph Protégé's OntoGraf draws:
The same model, three languages
Read them top-to-bottom — SKOS → RDFS → OWL — and watch the model gain power and cost at each step. Load any file into Protégé to poke at it.
Loading…
Each picture is auto-generated from its Turtle file with Graphviz (scripts/gen-diagrams.py) — no hand-drawing. Notice how SKOS is a tree, RDFS adds the entry + fields, and OWL adds the red ≠ disjoint constraint and the (≤1) on hasTopic.
So which should the Atlas use?
You don't pick one — you layer them, using each where it's strongest. They compose (a SKOS concept can be an OWL individual; OWL builds on RDFS).
SKOS for the vocabularies
Topic → Domain, Type, Format, License are controlled vocabularies with a broader/narrower hierarchy. That's exactly what SKOS is for.
RDFS for the entry
A thin schema: what a catalog row is and what fields it has. No logic, nothing to enforce — just shape.
OWL for guardrails
"Exactly one topic," disjoint types, auto-classification, inconsistency detection. Worth it only if a reasoner is in the loop.