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.

graph TD cs["Concept scheme"] -. "skos:hasTopConcept" .-> c1["Transport"] c1 --> c2["Road transport"] c2 --> c3["Bicycles"] c2 --> c4["Buses"]

Displayed, that is a tree. The concept hierarchy below comes from a real scheme:

A hierarchy of SKOS concepts, shown as a tree

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:broader points from a concept to its parent. Bicycles skos:broader Road transport.
  • skos:narrower points 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:prefLabel as 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