0/7
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.

Increment Recommended

Sequential integers: /risk/1, /risk/2 …

✓ Simple, fully opaque
✓ No meaning to go stale
✗ Gaps appear on deprecation

UUID Recommended

Random: /risk/a3f8c2d1-…

✓ Collision-proof, no coordination needed
✗ Hard to say or type from memory

Preferred Label Avoid

Derived from label: /risk/HighRisk

✓ Human-readable at a glance
✗ Breaks when labels change

Hierarchical Avoid

Encodes position: /risk/fire/high/extreme

✓ Self-describing
✗ Breaks on hierarchy reorganisation
🔧 IRI Builder
Example IRIs

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
<https://example.org/risk/BushfireRiskLevels>
    a skos:ConceptScheme ;
    owl:versionIRI  <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