1 · The Brief — port operations need a dictionary AND rules

The setup

HARBOUR (fictional) operates a large container port. Three concrete jobs the system must do:

1. Speak the IMDG language. Hazard codes, vessel types, container ISO codes — flat lists, multilingual, edited by an ops team that doesn't read Turtle.
2. Enforce operational rules. A vessel call carrying any IMDG-coded container is a hazardous call. A hazardous call cannot be assigned to a passenger berth. These are constraints — actual semantic statements.
3. Enrich alarms. When telemetry says 'container X is on berth Y', the system must derive 'this is a hazardous assignment' before the alarm reaches the duty officer.

Why SKOS alone fails

SKOS gives us (1) for free. But it cannot say 'a vessel carrying hazardous containers IS a hazardous call'. SKOS is a thesaurus — it does not perform class inference.

Why OWL alone fails

An OWL-only design forces ops to edit OWL files when a new hazard code is published. Every IMDG amendment becomes an ontology release. The cost-to-change is too high for a list that genuinely is just a list.

The hybrid

• SKOS carries the dictionaries (hazard codes, vessel types). Ops edits them in Skosmos.
• OWL 2 RL carries the operational rules. The ontology team owns it.
• The two meet at rdfs:range skos:Concept — the OWL properties point at SKOS concepts, treating them as opaque identifiers.

This separation matches the people who own each artefact. That's why hybrids win in practice.

The hybrid pipeline

Notice that the OWL ontology references SKOS concepts but does not contain them. Ops can publish a new hazard code without touching the rules.