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:Highis 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.
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 .
Your team renames "High Risk" → "Elevated Risk". Which IRI suffix causes the fewest problems?