SKOS or OWL: Choosing the Weakest Thing That Works
The most valuable judgement in this field is knowing the weakest language that answers your questions, and stopping there. Lesson 2 named the failure mode from a distance: eighteen months of OWL axioms about the metaphysics of “agreement” when the business wanted faceted product search. Now that you have both languages in your hands, the decision becomes concrete and answerable, and it turns out to have a procedure. This lesson gives you the procedure, the three legitimate ways SKOS and OWL coexist, and the one test that settles the argument faster than any amount of discussion.
What SKOS structurally cannot do
The limits are not deficiencies to be worked around; they are the specification working as designed. Knowing them precisely is what turns the choice from taste into engineering.
SKOS has no properties of its own beyond the vocabulary ones. You can say a concept is broader than another, has a label, has a notation and has a note. You cannot say a pump has a rated power of 18.5 kW, because SKOS is about the vocabulary, not about the things the vocabulary is used to talk about. The moment your question mentions an attribute of a real object, SKOS is not the layer that will answer it.
SKOS has no consistency to check. There are integrity conditions, and a validator can tell you that you violated S27 by relating two concepts that are also hierarchically linked. There is nothing that can tell you your model contradicts itself, because a vocabulary makes no claims strong enough to contradict anything. Lesson 6’s disjointness axiom, the one that catches a pump filed as a pipeline, has no SKOS equivalent and cannot have one.
SKOS has no cardinality, no domain and range inference, no defined classes. You cannot say every pump has exactly one rated power, cannot derive that something is a pump because of the properties it has, and cannot define a class by a condition. Every one of those is a thing OWL exists to do.
SKOS carries no instance data. A concept scheme knows about the type “centrifugal pump”. It knows nothing about ex:P101, and putting ex:P101 in it as a narrower concept is the universals-and-particulars error from lesson 1 wearing SKOS syntax, which lesson 2 already dissected.
Against that, the things SKOS gives you that OWL does not, and which are systematically undervalued by engineers: labels in many languages with a disciplined preferred-versus-alternative distinction, hidden labels that improve retrieval without polluting display, a notation system that carries several code schemes at once, documentation properties with editorial standing, and above all a model that a subject expert can maintain without you. That last one is not a technical property and it decides more projects than any technical property does.
The specification’s deliberate silence
People argue about whether a SKOS concept is “really” an OWL class. The specification declines to settle it, in as many words: it “does not make any additional statement about the formal relationship between the class of SKOS concepts and the class of OWL classes”. That silence is a design decision, and it means both readings are permitted and you must choose deliberately rather than inherit a choice from whichever tutorial you read first.
The consequence in practice is that there are three legitimate architectures, and one of them is right for you.
| Architecture | How it works | Use when | What it costs |
|---|---|---|---|
| Separate layers, linked | Scheme and ontology are different resources; a documented predicate relates a concept to the class that formalises it | Default. Different editors, different cadences, different purposes | Two artefacts to keep aligned; a join in some queries |
| Punning, one URI both ways | The same URI is typed skos:Concept and owl:Class; OWL 2 punning permits it | The vocabulary genuinely is the class hierarchy and one team owns both | Every editorial change is now an ontology change; reasoner sees editorial noise |
| Full promotion to OWL | The scheme is discarded and rebuilt as a class hierarchy with axioms | Rarely. Only when every broader link is provably generic and inference is required | A modelling project, not a migration; usually loses the editors |
On linking, one warning that catches experienced people. It is tempting to write skos:exactMatch between your concept and an ontology class, because exactMatch is the strongest mapping predicate and this feels like the strongest link. Resist it. SKOS mapping properties were designed to relate concepts in different concept schemes, and lesson 29 works through the mapping vocabulary properly. A concept and a class are different kinds of thing, so what you want is an explicit predicate of your own, documented, meaning “this vocabulary term is formalised by that class”. Inventing a clear predicate is cheaper than borrowing an unclear one, and it survives the reviewer who asks what exactly you meant.
The procedure: sort your questions, not your preferences
Write the questions the system must answer, then sort them. The layer is determined by the question type, and the answer is usually mixed, which is the point.
| The question sounds like | Weakest layer that answers it | Why nothing weaker works |
|---|---|---|
| “Find documents about this topic, and its subtopics” | SKOS | A flat keyword list cannot expand the query |
| “The French team calls it something else” | SKOS | Labels per language is exactly the SKOS design centre |
| “Which of our terms mean the same as the regulator’s?” | SKOS mapping properties | Needs graded match strength, not identity |
| “Reject any record missing a rated power” | SHACL | A validation question, and SKOS makes no claims about data |
| “Flag anything filed as both a pump and a pipeline” | OWL | Detecting contradiction requires a language that can be contradicted |
| “Which pumps share a model with a failed pump?” | OWL plus instance data | Needs individuals, relations between them, and a model level |
| “How many pumps do we have?” | Depends entirely on what you mean by pump | Lesson 1’s question, and no layer answers it until the ambiguity is resolved |
Worked example · the Aberdeen-2 asset register
Where we left it: a governed concept scheme, an ontology with disjointness, and no statement anywhere about how the two relate.
The boundary gets drawn once, in writing, and it holds for the rest of the course. The scheme owns naming: what the three source systems call things, in which languages, with which codes and misspellings, maintained monthly by the maintenance superintendent. The ontology owns meaning: that a pump is not a pipeline, that a rated power is a quantity with a unit, that maintenance events have participants. The register owns fact: that ex:P101 exists, was installed in 2019, and had its motor changed from 15 to 18.5 kW in 2023.
Between scheme and ontology we write one predicate of our own, ex:formalisedBy, from the concept ex:CentrifugalPump to the class ex:CentrifugalPump in the ontology namespace, documented as “the vocabulary term is formalised by this class”. Not skos:exactMatch, which is for concept to concept; not owl:equivalentClass, which would require the concept to be a class and drag the whole editorial layer into the reasoner. Roughly a third of the scheme’s concepts have no class at all, because the ontology only formalises what the questions need, and that asymmetry is healthy rather than an omission to be tidied away.
Then the test that settles it. Ask the register the question that reliability engineering has wanted since lesson 1: which pumps share a model with a pump that failed within twelve months of an impeller swap. Work through what each layer contributes. The scheme knows “impeller” has an alternative label and a code, which is how the work orders were found at all. The ontology knows a swap is a maintenance event with a participant and a date. The register knows ex:IMP77 came out and ex:IMP12 went into ex:P101 under WO-2022-114 in April 2022. And the question still cannot be answered, because nothing anywhere represents the fact that ex:P101 is an instance of model ex:HX300 and that other pumps are too. That is not a SKOS failure and not an OWL failure. It is a missing model level, and no amount of choosing between the two languages supplies it.
State of the register: three layers with a written boundary, and one question that defeats all three. It becomes a formal competency question in lesson 18, fails there on purpose, and is finally unblocked by the power type pattern in lesson 25. Next lesson we start querying what we have with SPARQL.
Migration is downhill only
Converting an OWL or RDFS vocabulary into SKOS is largely automatable, which is exactly what Skosify was built to do: it takes RDFS and OWL vocabularies and produces SKOS, then validates and corrects the result. That direction works because you are discarding claims, and discarding claims is always safe.
The reverse is not a conversion and no tool will do it for you honestly. Lesson 7’s block showed why: skos:broader deliberately collapses generic, partitive and instance relations, so the information needed to emit the right axiom is not in the source. Promoting a thesaurus to an ontology means deciding, link by link, what each link meant, and that is a modelling project scoped in months. Anyone who offers you a script for it is selling you the false axioms.
What breaks · promoting the whole vocabulary to OWL
A new architect arrives and finds the arrangement untidy: two artefacts, a hand-rolled predicate between them, and a scheme full of concepts with no logical content. The proposal is clean and sounds unarguable. One model. Every concept becomes an owl:Class, every broader link becomes rdfs:subClassOf, the scheme is retired. Three things then happen, in this order.
First, the reasoner slows down and then stops being run. The scheme carried around nine hundred concepts, most of them fine-grained naming distinctions that existed to improve search recall and nothing else. As classes in a hierarchy with the existing disjointness axioms, they multiply the classification work for no answered question, and classification moves from seconds to minutes. A reasoner that takes minutes is a reasoner that is removed from CI, which quietly deletes the only check that ever caught a real modelling error.
Second, the editors leave. The maintenance superintendent could add a synonym in a web form. Adding a synonym now means editing an ontology, which means a pull request, which means a review by someone who understands description logic, which means a two-week turnaround for a spelling variant. Within a quarter the vocabulary stops being updated, the fourth dialect appears in the field, and the register drifts back to the state lesson 7 fixed.
Third, and worst because it is invisible, the false axioms arrive. Some of those nine hundred broader links were partitive and some were instance links, so the promotion silently asserts that every pump casing is a pump and that a named platform is a class of things. Nothing detects it until an inference somewhere is confidently wrong. The remedy is not to argue about tidiness but to ask the question this lesson opened with: which of the system’s questions was unanswerable before, and is now answerable? On the register, the honest answer is none. Two artefacts with a documented predicate between them is not untidiness; it is two different jobs, done by two different people, at two different rates.
Check yourself
A retailer needs product pages in seven languages, synonym-aware search, and a rule that rejects any product record lacking a supplier. A consultant proposes a full OWL ontology of the product domain. What is the strongest objection?
- None of the three requirements needs inference; two are vocabulary problems and one is a validation problem
- OWL cannot represent multilingual labels, so it cannot meet the first requirement
- OWL reasoning would be too slow at retail catalogue scale
- SKOS should be used because it is a W3C Recommendation and OWL is not
Show the answer, and why each wrong option is wrong
A is correct. Run the procedure. Multilingual labels and synonym-aware search are naming problems, which is the SKOS design centre. “Reject a record lacking a supplier” is a constraint on data at a boundary, which is SHACL, and lesson 4’s open world argument explains why OWL is the wrong tool for it: the absence of a supplier entails nothing, so an OWL cardinality axiom will not reject anything. Nothing in the brief asks for a contradiction to be detected or a classification to be derived, so nothing in the brief pays for an ontology. That is the objection, and it is an objection about the requirements rather than about OWL.
B is simply false and worth killing off. OWL classes take rdfs:label in any language you like; what OWL lacks is the preferred-versus-alternative-versus-hidden distinction and the editorial machinery around it, which is a difference of discipline, not of capability. C is the answer that sounds most expert and is the weakest, because it argues from a performance guess rather than from requirements, and it is the sort of claim that collapses when the consultant produces a benchmark. Even if reasoning were fast, the ontology would still be unpaid-for. Argue from the questions, never from the runtime. D is factually wrong on its own terms, since OWL 2 is equally a W3C Recommendation, and it is the worst kind of argument regardless: choosing a technology by its credentials rather than by what the system has to do.
Further reading
- Baker, T. et al. (2013). Key Choices in the Design of Simple Knowledge Organization System (SKOS). The section on the relationship to OWL is the authoritative treatment of the silence discussed above. https://arxiv.org/abs/1302.1224
- Alexopoulos, P. (2020). Semantic Modeling for Data. O’Reilly. The pitfalls chapters are the best practitioner account of choosing expressivity deliberately. https://www.oreilly.com/library/view/semantic-modeling-for/9781492054269/
- Suominen, O. and Hyvonen, E. (2012). Improving the Quality of SKOS Vocabularies with Skosify. The downhill direction, automated. https://doi.org/10.1007/978-3-642-33876-2_34
- Bechhofer, S. and Miles, A. (2009). Using OWL and SKOS. W3C Note on the interaction between the two languages and what punning does and does not buy you. https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html
- A worked regulated-domain example of SKOS and SHACL used together rather than one replacing the other: SHACL-SKOS Based Knowledge Representation of Material Safety Data Sheets for the Pharmaceutical Industry. arXiv:2502.07944. https://arxiv.org/abs/2502.07944