Appearance
A controlled vocabulary is a curated list of terms with simple relationships, a thesaurus; an ontology is a formal model of classes, properties and logical constraints that software can reason over. The quick test: if you only need agreed labels and broader/narrower links, you want a vocabulary; if you need to model relationships and let a machine infer new facts or enforce rules, you want an ontology. Every ontology is technically a vocabulary, but the reverse is not true, and conflating them leads people to over-engineer simple term lists or under-power genuine modelling problems.
Step 1: Diagnose what you are actually trying to do
Before choosing, write down your goal in one sentence and match it:
- "I need everyone to use the same word for etching versus engraving." -> vocabulary.
- "I need to say a production event involved an actor who used a material, and infer the object's date from the event." -> ontology.
The first is terminology control; the second is knowledge modelling. Most heritage projects need both, but for different parts of the data.
Step 2: Recognise the families
| Aspect | Controlled vocabulary | Ontology |
|---|---|---|
| Purpose | Consistent terms | Formal model of a domain |
| Typical tech | SKOS thesaurus | OWL / RDFS classes |
| Relationships | broader, narrower, related | domain, range, sub-class, constraints |
| Reasoning | None or minimal | Inference and consistency checking |
| Heritage example | Getty AAT, LCSH | CIDOC CRM, Dublin Core terms |
Notice SKOS appears as the tech for vocabularies, yet SKOS itself is an ontology. That is the detail people trip on: SKOS is an ontology you use to publish vocabularies.
Why is "every ontology is a vocabulary" true?
A vocabulary is any agreed set of terms with defined meanings. An ontology supplies exactly that, plus axioms. So an ontology satisfies the definition of a vocabulary and adds logic on top. The asymmetry, that not every vocabulary is an ontology, is what matters in practice: the Art and Architecture Thesaurus is not an ontology because it does not define logical classes and constraints, only terms and their hierarchy.
Step 3: See the difference in code
A vocabulary entry in SKOS just asserts a concept and its place in a hierarchy:
turtle
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
<https://vocab.example.org/aat/etching>
a skos:Concept ;
skos:prefLabel "etching"@en ;
skos:broader <https://vocab.example.org/aat/printmaking> .An ontology defines structure a reasoner can use:
turtle
@prefix crm: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
crm:E12_Production
a rdfs:Class ;
rdfs:subClassOf crm:E7_Activity .
crm:P108_has_produced
rdfs:domain crm:E12_Production ;
rdfs:range crm:E24_Physical_Human-Made_Thing .The vocabulary names things; the ontology says what kinds of things can relate and how.
Step 4: Combine them, the practical default
Real heritage data uses an ontology for structure and vocabularies for values. CIDOC CRM (or Dublin Core) gives you the framework; SKOS vocabularies fill the slots with controlled subject terms, materials and object types.
turtle
<https://data.example.org/object/00041523>
a crm:E22_Human-Made_Object ;
crm:P45_consists_of <https://vocab.example.org/aat/oil-paint> .crm:P45_consists_of comes from the ontology; the oil-paint URI comes from a vocabulary. This separation lets you swap vocabularies without redesigning your model.
When do I genuinely need reasoning?
You need a reasoner only when you want to derive implicit facts or check consistency, for example inferring that anything produced in a E12_Production event is a human-made thing, or catching that an object asserted as both a person and an object violates disjointness. If you only need a shared schema, use the ontology as a vocabulary and skip inference entirely.
What pitfalls bite beginners?
- Building a heavyweight OWL ontology when a SKOS thesaurus would do.
- Treating SKOS as "just a list" and ignoring that it is itself an ontology.
- Putting subject terms as free text instead of vocabulary URIs, losing interoperability.
- Assuming an ontology forces you to run a reasoner; it does not.
Key Takeaways
- A vocabulary curates terms; an ontology formally models classes, properties and constraints.
- Every ontology is a vocabulary, but most vocabularies are not ontologies.
- SKOS is an ontology you use to publish controlled vocabularies.
- CIDOC CRM and Dublin Core terms are ontologies; Getty AAT and LCSH are vocabularies.
- The common pattern is an ontology for structure plus vocabularies for values.
- Reasoning is optional; use an ontology as a schema without inference if that is all you need.
- Match the tool to the goal to avoid over- or under-engineering.
Frequently Asked Questions
What is the core difference between an ontology and a vocabulary?
A controlled vocabulary is a curated list of terms and their relationships, like a thesaurus; an ontology adds formal logic, classes, properties and constraints that a reasoner can act on. Every ontology is a vocabulary, but not every vocabulary is an ontology.
Is SKOS a vocabulary or an ontology?
SKOS is an ontology used to publish vocabularies. The SKOS model itself is an RDF ontology, but you typically use it to express thesauri and term lists, which are controlled vocabularies, not heavyweight domain ontologies.
When do I need a full ontology instead of a vocabulary?
When you need to model relationships and infer new facts, for example that a sub-event implies a parent event, or enforce that an object must have a creator. If you only need consistent labels and broader/narrower terms, a vocabulary is enough.
Is CIDOC CRM an ontology or a vocabulary?
CIDOC CRM is an ontology. It defines classes like Event and Actor and properties with domains and ranges to model how cultural heritage information relates, going well beyond a flat list of terms.
Can I mix a vocabulary and an ontology in one dataset?
Yes, and you usually should. Use an ontology such as CIDOC CRM or Dublin Core for structure, and reference SKOS controlled vocabularies for the actual subject terms, materials or types as values.
Does using an ontology require a reasoner?
Not always. You can use an ontology purely as a shared schema without running inference. A reasoner only matters when you want to derive implicit facts or check logical consistency against the ontology's axioms.