Module 4

Vocabulary Patterns

Design IRIs that are persistent, opaque, and web-addressable.

The Core Principle: Opaque and Persistent

A concept's IRI is its permanent identity. Once published and used by other systems, changing it breaks every link that points to it. Two rules:

  • Persistent — the IRI must not change even if the concept is renamed or deprecated.
  • Opaque — the IRI should not encode meaning that could become wrong. risk:High is problematic if you rename "High" to "Elevated" — the IRI is now misleading forever.

IRI Suffix Strategies

The base URL is fixed; you choose the suffix for each concept. Click a strategy below to explore it in the builder.

IRI Builder
Example IRIs
<https://example.org/risk/1>
<https://example.org/risk/2>
<https://example.org/risk/3>
<https://example.org/risk/4>

Version IRIs

A version IRI (owl:versionIRI) is a separate, version-specific IRI on your ConceptScheme. The main scheme IRI always resolves to the latest version; the version IRI is a permalink to a specific snapshot.

version-iri.ttl
<"tok-iri">https://example.org/risk/BushfireRiskLevels>
    a skos:ConceptScheme;
    owl:versionIRI  <"tok-iri">https://example.org/risk/BushfireRiskLevels/2.1> ;
    dcterms:title"Australian Bushfire Risk Levels"@en .
Quick Check

Your team renames "High Risk" → "Elevated Risk". Which IRI suffix causes the fewest problems?

Module 3