Every organisation already has knowledge models. They're in spreadsheets of product categories, SharePoint term stores, code lists in the data warehouse and the folder structure of the document system. When an ontology or knowledge graph programme starts, one of the first decisions is how to represent these formally. Two W3C standards dominate the conversation, and choosing the wrong one for a given job is a common reason programmes lose a year.
Two standards, two purposes
SKOS, the Simple Knowledge Organization System, became a W3C Recommendation in 2009. It is a common data model for sharing and linking knowledge organisation systems, such as thesauri, taxonomies and classification schemes, on the web1. Its world is concepts, labels and loose relations between them.
OWL 2, the Web Ontology Language, defines classes, properties and logical axioms that reasoners can use to infer new facts and detect contradictions. Its profiles, finalised in their second edition in 2012, trade expressiveness for tractable reasoning3.
The SKOS designers were explicit that SKOS was not meant to compete with OWL but to complement it, offering a path to bring existing knowledge that doesn't map easily into an OWL ontology onto the semantic web5.
Side by side
| SKOS | OWL 2 | |
|---|---|---|
| Core unit | Concept with labels | Class, property, individual |
| Hierarchy | skos:broader: "is filed under", for navigation and retrieval | rdfs:subClassOf: "every X is a Y", logical subsumption |
| Labels | First-class: preferred, alternative and hidden labels, with at most one preferred label per language1 | Annotations, not part of the logic |
| Reasoning | Light; little to infer | Rich, with profiles tuned for scale3 |
| Cross-scheme links | Mapping properties such as exact, close and broader matches1 | Equivalence and subclass axioms with logical consequences |
| Who maintains it | Taxonomists, subject experts, business owners | Ontologists and data architects |
| Best for | Product categories, subject tags, code lists, synonyms for search | Domain models, constraints, integration semantics |
The mistake that matters most
The most expensive error is treating a taxonomy hierarchy as a class hierarchy. In a product catalogue, "Garden furniture" sits under "Outdoor" and also under "Furniture". That is a filing decision, not a claim that every garden chair is, logically, an instance of "Outdoor".
SKOS is careful here. skos:broader is used only for direct hierarchical links and is not declared transitive; skos:broaderTransitive is a separate superproperty for inferring indirect links12. Converting the same hierarchy into rdfs:subClassOf makes every relation logically binding, and a reasoner will happily draw conclusions nobody intended.
If the business owner would say "it's filed under", use SKOS. If they would say "it is always a kind of", consider OWL. Most enterprise hierarchies are the first.
Choosing OWL profiles when you do need logic
Where OWL is the right tool, its profiles help match reasoning to scale34:
- OWL 2 EL suits ontologies with very large numbers of classes and properties, with polynomial-time reasoning for core tasks. Large biomedical terminologies are the classic fit.
- OWL 2 QL targets large volumes of instance data queried through relational databases, which suits virtual knowledge graphs over existing warehouses.
- OWL 2 RL supports rule-based reasoning that works directly on RDF triples, practical inside many triple stores.
Choosing a profile early prevents a common failure: a model that is logically elegant and unusable at production volume.
The combined pattern I use
- A small OWL core for the domain: customer, product, contract, patient, asset, and the relations between them. Keep it in a tractable profile.
- SKOS vocabularies for classification: product categories, risk types, diagnosis groupings, document subjects. Instances in the core point to concepts through ordinary properties, such as "has category".
- Mappings between vocabularies using SKOS mapping properties, so a local code list can align with an industry standard without pretending they are identical.
- SHACL for data quality, as described in SHACL validation, because closed-world checks belong outside the open-world logic of OWL.
- Labels feed search and AI. SKOS alternative and hidden labels give retrieval and GraphRAG the synonyms and misspellings users actually type.
This also clarifies ownership. Business teams can maintain vocabularies in a taxonomy tool without touching the ontology, while architects govern the core. How these pieces relate to a semantic layer is covered in ontology vs knowledge graph vs semantic layer, and how clinical vocabularies are handled in practice in clinical terminologies in OMOP.
How I can help
I design ontology and knowledge graph programmes that start with the models an organisation already has, and choose the lightest formalism that does the job. See ontology and knowledge graphs, or analyse your challenge and bring the result to a call.
- 1SKOS Simple Knowledge Organization System ReferenceW3C Recommendation · 18 Aug 2009
- 2
- 3OWL 2 Web Ontology Language Profiles (Second Edition)W3C Recommendation · 11 Dec 2012
- 4OWL 2 profiles (working group wiki)W3C OWL Working Group
- 5Post on SKOS and its relationship to OWLW3C public-esw-thes mailing list (A. Miles) · Mar 2004