Simple Knowledge Organization System

Simple Knowledge Organization System for Health Economics Vocabularies

The Simple Knowledge Organization System (SKOS) is a data model that the World Wide Web Consortium (W3C) published as a Recommendation on 18 August 2009 for writing thesauri, classification schemes and taxonomies as machine-readable web data. Each term in such a vocabulary becomes a concept with its own web identifier, a preferred name, synonyms, notes such as a definition, links to broader, narrower and related concepts, and mapping links to concepts in other vocabularies. Health economists rely on vocabularies of this kind in the code lists behind a costing study, the subject terms used to search for evidence and the glossaries that fix what a model input such as a QALY means. SKOS gives those vocabularies stable identifiers and a shared structure that software can search and join. It is lighter than a formal ontology language, since it records how a vocabulary is organised and makes no logical claims about the world.

Concepts, labels and notes for a single term

The SKOS Reference describes a concept as a unit of thought, identified by a URI and named by labels in a given language. The preferred label (prefLabel) is the main name, and a concept may have no more than one per language tag. Alternative labels (altLabel) hold synonyms, abbreviations and acronyms, and hidden labels (hiddenLabel) hold strings that a text search should match but a display should not show, such as misspellings. The three label properties are pairwise disjoint, so the same string cannot be both the preferred and an alternative label in one language.

The Reference treats "en", "en-GB" and "en-US" as different language tags, so British and American spellings of a term can both be preferred labels without a clash. The SKOS Primer recommends that no two concepts in one vocabulary share a preferred label in the same language, though the model does not enforce it. A notation (notation) is a code, such as a classification number, that identifies a concept within one scheme and is not normally a word in any natural language. Notes come in seven properties, a general note and six specialisations of it such as the definition and the scope note, so every note on a concept can be retrieved through the general property.

HealthEconomics.wiki's own Health Economics Ontology (HEO) shows these parts on a real record. In HEO version 1.3.1 the QALY concept has the preferred label "Quality-Adjusted Life Year (QALY)", the alternative labels "QALY" and "Quality-Adjusted Life-Year", a written definition, the notation HE-EE-QALY-005 and links to two broader concepts, Health-Adjusted Life Year and Outcome Measure. A search tool reading the file can find the QALY page from either the acronym or the full name.

Broader, narrower and related links

SKOS has two kinds of semantic relation between concepts. A hierarchical link says one concept is more general than the other, and an associative link (related) says the two are connected without either being more general. The Primer notes that, for historic reasons, the name broader does not show its direction. The subject of the statement is the narrower concept, so "cost-utility analysis broader cost-effectiveness analysis" places cost-utility analysis underneath.

By convention broader and narrower record only direct parent and child links, and they are deliberately not transitive. Two further properties, broaderTransitive and narrowerTransitive, are transitive super-properties that by convention are inferred and never asserted. The Reference gives query expansion to improve search recall as an example of their use, since a reasoner can then reach every ancestor or descendant of a concept while the direct links stay available for drawing the hierarchy.

The associative link related is symmetric and not transitive. It is disjoint with broaderTransitive, so two concepts joined by a chain of broader links cannot also be declared related. Several parents are allowed, as in the QALY record above, because the Reference treats alternative paths through a hierarchy as normal.

The Primer notes that a broader link can stand for a kind and its subkind or, on some readings, a whole and its parts, and basic SKOS does not separate these. A publisher who needs the difference can define sub-properties of broader, for example one for generic and one for partitive links, and a reasoner will still read each as an ordinary broader link.

Concept schemes, top concepts and collections

A concept scheme (ConceptScheme) is the resource that stands for a whole vocabulary, such as one thesaurus or one classification. Concepts are placed in it with inScheme, and its entry points are listed with hasTopConcept. A concept can belong to no scheme, one scheme or several, which lets a new scheme reuse concepts already published elsewhere. There is no way to close the boundary of a scheme, so a file can say that three concepts are in a scheme but cannot say that only those three are.

Collections (Collection and OrderedCollection) group concepts under a label, or in a set order, without making the group a concept. They suit the node labels of a printed thesaurus, for instance a heading such as "costs by perspective" that gathers several cost concepts. Pointing a broader, narrower or related link at a collection makes the data inconsistent with SKOS.

Mapping links between vocabularies

Health data rarely arrives in a single vocabulary, and a costing or real-world data study has to reconcile diagnosis, procedure and outcome codes from different systems. SKOS provides five mapping properties for links between concepts in different schemes. These are exactMatch and closeMatch for similar meaning, and broadMatch, narrowMatch and relatedMatch, which mirror the hierarchical and associative links.

A close match says two concepts are similar enough to be used interchangeably in some information retrieval applications, and it is not transitive, so that small differences do not compound when mappings across several schemes are chained. An exact match signals high confidence that the concepts can be used interchangeably across a wide range of applications, and it is transitive and a sub-property of close match. An exact match is disjoint with broad and related matches, so a pair of concepts cannot be both. Each of the three mirroring properties is a sub-property of its semantic relation, so a broad match implies an ordinary broader link.

The OMOP Common Data Model used by OHDSI shows why the distinction matters for costing. Its "Maps to" relationship links a source code to an equivalent standard concept where one exists, and otherwise to a slightly broader concept, which OHDSI calls an up-hill mapping. Its example is ICD-10-CM W61.51, bitten by goose, which has no SNOMED equivalent and is mapped to SNOMED 217716004, peck by bird, losing the fact that the bird was a goose. In SKOS terms the first kind of link would be an exact match and the second a broad match, so a mapping table written in SKOS keeps the loss of detail visible to the analyst who later sums the costs. The SKOS Reference adds that mapping properties are no substitute for careful management of the data and its provenance.

The OWL property sameAs is the wrong tool for this job. The Reference explains that declaring two concepts the same resource merges everything said about them, and in its example the merged concept ends up with two preferred labels in English, which is inconsistent with SKOS. HEO uses exactMatch to link concepts such as the QALY to the matching Wikidata item, which keeps each record intact.

SKOS beside OWL and formal ontologies

The SKOS Reference is explicit that SKOS is not a formal knowledge representation language. A formal ontology asserts axioms and facts about a domain, whereas a thesaurus or classification identifies ideas through natural language and arranges them in structures that carry no formal meaning. SKOS therefore models the concepts of a vocabulary as individuals and its links as facts about the vocabulary, never as statements about how the world is arranged. The Reference describes turning a thesaurus into a formal ontology as intellectually demanding, time consuming and costly, and warns that the result may no longer serve its original purpose.

The two standards are built to sit together. SKOS is itself defined as an OWL Full ontology, and SKOS data are written as triples in the Resource Description Framework (RDF). The Reference gives a resource that is both a concept scheme and an OWL ontology as a consistent example, and HEO takes exactly that form, with its concepts arranged by broader links and a few relationships defined as OWL object properties. Its companion, the Real Health Economics Ontology (RHEO), describes the real world, and HEO's rule that a concept and an RHEO type never share an identifier matches the Primer's advice that users of OWL DL keep SKOS concepts and OWL classes as separate resources.

SKOS has few integrity conditions and follows the open world assumption. The Reference states that no conclusions can be drawn from missing data, and that removing something never makes the remaining data inconsistent. A concept with alternative labels and no preferred label is therefore consistent, even though many applications need one for display. House rules such as "every concept has one preferred label and one definition" need a separate check, and HEO's release package includes record rules in the Shapes Constraint Language (SHACL) that the release was checked against.

Worked example with query expansion in an HTA document library

All figures here are illustrative. An analyst keeps a library of 100 health technology assessment reports and indexes each with the single most specific concept it covers, taken from a small in-house SKOS scheme for types of economic evaluation. SKOS has no property for linking a document to its subject, and the Primer points to the Dublin Core subject property.

All 100 reports concern some form of economic evaluation, so a complete search should return all 100.

Step 1. Matching the query "economic evaluation" to the preferred label and returning only reports indexed to that concept finds 12 reports, or 12% of the relevant set.

Step 2. Adding concepts whose direct broader link points to economic evaluation brings in cost-effectiveness, cost-benefit and cost-minimisation analysis, giving 12 + 30 + 8 + 5 = 55 reports, or 55%.

Step 3. Expanding through the inferred broaderTransitive links also reaches cost-utility analysis, two levels down. The count for a concept $c$ is

$$N(c) = n_c + \sum_{k \in T(c)} n_k$$

where $N(c)$ is the number of reports returned for concept $c$, $n_c$ is the number of reports indexed to $c$ itself, $T(c)$ is the set of concepts $k$ for which "$k$ broaderTransitive $c$" is inferred, and $n_k$ is the number of reports indexed to concept $k$. For economic evaluation $T(c)$ holds the four other concepts, so

$$N(c) = 12 + (30 + 45 + 8 + 5) = 12 + 88 = 100$$

where 12 is the count for economic evaluation and the bracket adds the counts for its four descendants. Recall rises to 100%.

Step 4. A query typed as "CUA" matches no preferred label. Matching against alternative labels as well finds the cost-utility analysis concept and its 45 reports.

Step 5. A search for cost-effectiveness analysis returns 30 + 45 = 75 reports. Had the curator filed cost-minimisation analysis under cost-effectiveness analysis, the same search would return 30 + 45 + 5 = 80, while economic evaluation would still return 100. Query expansion is only as good as the broader links, so a change to the scheme changes the evidence a reviewer screens.

Uses in evidence work and modelling

The same mechanics carry over to several tasks. A systematic review search can draw synonyms and narrower terms from a published vocabulary, and the identifiers make the expansion repeatable. In data extraction, tagging each extracted item with a concept URI rather than free text lets results from different reviews be pooled by meaning. For a cost-of-illness study based on electronic health record data, a code list written as a SKOS scheme with explicit mapping types shows which source codes were matched exactly and which were moved up to a broader concept. In model documentation, citing the concept URI of each input ties a parameter to one written definition. Each use supports digital interoperability.

Common misreadings of SKOS data

Four misreadings of SKOS data come from reading more into its links than the standard puts there.

1. Reading broader as "is a kind of". A broader link may join a whole and a part, as in the Primer's example of vehicles, cars and wheels. Summing costs down a hierarchy that mixes kinds with parts, or that gives a concept two parents, can count the same resource use twice.
2. Asserting the transitive properties by hand. Writing broaderTransitive links into the data, or a direct broader link to every ancestor, breaks the convention that keeps the direct hierarchy readable.
3. Treating a close match as an exact match. Close matches do not chain, and a chain of them across three code systems can drift in meaning. Using sameAs instead merges records and can make the data inconsistent.
4. Expecting SKOS to catch missing content or close a list. Under the open world assumption a missing label, definition or mapping is not an error, and no scheme can declare that its list of concepts is complete.

Sources

• Baines D, Ashley M. Health Economics Ontology (HEO), version 1.3.1. Zenodo; 2026. https://doi.org/10.5281/zenodo.23516371
• Isaac A, Summers E, editors. SKOS Simple Knowledge Organization System Primer. W3C Working Group Note, 18 August 2009. https://www.w3.org/TR/skos-primer/
• Miles A, Bechhofer S, editors. SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009. https://www.w3.org/TR/skos-reference/
• Observational Health Data Sciences and Informatics. Chapter 5, Standardized Vocabularies (chapter leads Reich C, Ostropolets A). In: The Book of OHDSI. OHDSI; 2021. https://ohdsi.github.io/TheBookOfOhdsi/StandardizedVocabularies.html