SKOS¶
Every organisation has lists of agreed terms: subject headings, product categories, document types, place names. They are maintained by people who know the domain, they change slowly, and everything else refers to them.
SKOS — the Simple Knowledge Organization System — is the W3C standard for publishing exactly those lists as linked data. If you work with libraries, archives, museums or government information, it is probably the standard you will meet first.
It assumes Linked data.
Concepts, not classes¶
The first question is why SKOS exists at all, when OWL already describes classes and hierarchies.
A class is a set of things. Building as an OWL class means every building
in the world, and saying something is a CentrifugalPump licenses a machine to
conclude it is also a Pump.
A concept is an idea people agreed to name. Building as a SKOS concept is an entry in a terminology — something you can tag a record with, translate, deprecate, or place under a broader heading, without asserting anything logical about the world.
That difference is deliberate. SKOS is designed to be light on logic, because real vocabularies are full of relationships that are useful without being strictly true. A thesaurus can put Bicycles under Transport without committing to the claim that every bicycle is a transport. SKOS lets you say that; OWL would draw conclusions from it.
The practical rule: use OWL when a machine should reason, SKOS when people need to agree on words.
Schemes hold concepts¶
A concept scheme is one vocabulary: one thesaurus, one classification, one controlled list. Concepts belong to a scheme, and a scheme has one or more top concepts where the hierarchy starts.
Displayed, that is a tree. The concept hierarchy below comes from a real scheme:

A > in front of a concept means it has narrower concepts and can be expanded. A
dot means it is a leaf.
The direction that trips everyone up¶
Two properties carry the hierarchy, and their direction is the opposite of what most people expect the first time:
skos:broaderpoints from a concept to its parent. Bicyclesskos:broaderRoad transport.skos:narrowerpoints from a concept to its children.
So a query for "everything under Transport" follows skos:broader backwards,
or follows skos:narrower forwards. Getting this wrong returns an empty result
rather than an error, which is why it costs people an afternoon.
Alongside these sit skos:broaderTransitive and skos:narrowerTransitive, which
express the full chain rather than a single step. Whether those chained triples
actually exist depends on whether anyone generated them — which is why hierarchy
queries usually use a property path instead. See
querying real-world data.
skos:related connects concepts that are associated without one being above the
other.
Labels¶
A concept is identified by its IRI, not by its name, which is what makes SKOS multilingual without effort. Names are attached as labels:
skos:prefLabel— the preferred name. At most one per language.skos:altLabel— synonyms, abbreviations, older names, spelling variants.skos:hiddenLabel— names you want search to match but never display, such as common misspellings.skos:notation— a code from a classification system, where one exists.
Alternative labels are worth more effort than they usually get. They are what makes a search for "bike" find the concept called Bicycles, and they cost one triple each.
Linking one vocabulary to another¶
Vocabularies rarely stand alone. Your subject headings may need to line up with a national standard, or a partner's list. SKOS has a separate set of properties for crossing that boundary:
| Property | Says |
|---|---|
skos:exactMatch |
These two concepts are interchangeable |
skos:closeMatch |
Close enough for most purposes, but not identical |
skos:broadMatch |
The other concept is broader than this one |
skos:narrowMatch |
The other concept is narrower than this one |
skos:relatedMatch |
Associated, without a hierarchy between them |
Two schemes chained with skos:broadMatch and skos:narrowMatch behave as one
hierarchy for browsing, while each remains separately maintained and separately
owned. That is usually the point: nobody has to give up control of their own
vocabulary to connect it to someone else's.
Retiring a concept¶
Concepts should not simply disappear. Anything already tagged with a concept would be left pointing at nothing, and in a published vocabulary those references are outside your control.
The convention is to mark the concept with owl:deprecated set to true. It
stays resolvable and stays visible, flagged as deprecated, so existing references
survive while nobody uses it for anything new.
Where this appears in Triply products¶
- The Editor has a SKOS view for creating and editing concept schemes, including chained schemes and deprecated terms. See Edit SKOS data.
- TriplyDB's linked data browser uses
skos:prefLabelas one of the properties it reads to give a resource a readable name. See Data views. - SKOS is the backbone of Triply's work with libraries, archives, museums and government terminology.
Where to next¶
- OWL and ontologies — for when a machine should reason
- Querying real-world data — walking a concept hierarchy in SPARQL
- SHACL — checking that a vocabulary is well formed
- Linked data — the triples underneath
- Glossary — every term on this page, in one place