A place for every IRI.

Why a policy at all

Namespaces are the one design decision that is genuinely hard to undo. Rename a class and you fix a few files; change a namespace and you break every dataset, query and downstream system that ever referenced it. So the rules below are deliberately strict and deliberately few — a small scheme, applied without exception, is what lets the model grow for years without an identity crisis.

This is the fourth of the ontology-engineering briefs, alongside Start with the questions, Model the domain, not the message, and Build it in modules.

Every minted IRI is https, on the host data.chubb.com, and structured as /{root}/{layer}/{module}/{local-name}. The path is not decoration — each segment carries meaning a reader and a machine can act on.

The first segment after the host is the load-bearing one. It separates the three kinds of thing an insurance ontology names, so a class, a controlled-vocabulary code, and a business fact never share an address space:

Chubb-minted names use slash namespaces with a trailing slash, so a term appends directly (…/policy/Policy). The vendored W3C standards keep their own canonical hash IRIs — skos:, org:, time: — and are never re-minted under data.chubb.com.

These are normative. MUST rules are invariants a reasoner or a reviewer can check; SHOULD rules are strong defaults you break only with a recorded reason.

A controlled vocabulary — a list of perils, claim statuses, currencies, lines of business — is not part of the model’s shape; it is a governed set of values. Modelling each code as an OWL class explodes the class hierarchy and forces a reasoner to carry hundreds of trivial subclasses. The right tool is SKOS: each code is a skos:Concept, grouped into a skos:ConceptScheme, and referenced by the ontology — not baked into it.

Because a scheme is neither pure schema nor transactional data, it gets its own root, parallel to the other two:

The policy for SKOS schemes

• One scheme, one namespace. …/vocabulary/{layer}/{scheme}/, versioned and prefixed exactly like an ontology module (NS-4 through NS-8 apply unchanged).
• Concepts, not classes. Each code is a skos:Concept with skos:inScheme, a skos:prefLabel, and a stable skos:notation (the business code). The IRI local name is a readable token, never the raw code alone.
• Reuse SKOS itself; never re-mint it. Use skos: at http://www.w3.org/2004/02/skos/core# (vendor it once at your foundation layer and import where needed).
• Link from the ontology by reference. An ontology property ranges over the concept (claim:hasPeril rdfs:range skos:Concept), and instance data points at the shared concept — so the code list evolves without touching the T-Box.
• Keep schemes in their own files. Never inline a controlled vocabulary into a domain ontology module; a scheme versions on its own clock.

# /vocabulary/ins/peril/ — a governed code list, separate from the model
@prefix peril: <https://data.chubb.com/vocabulary/ins/peril/> .
@prefix skos:  <http://www.w3.org/2004/02/skos/core#> .

peril:  a skos:ConceptScheme ;
        dct:title "Chubb Peril Types"@en ;
        owl:versionInfo "0.1" .

peril:Flood a skos:Concept ;
        skos:inScheme  peril: ;
        skos:prefLabel "Flood"@en ;
        skos:notation  "FLD" .          # the stable business code

# the ontology references the scheme — it does not contain the codes
claim:hasPeril  rdfs:range skos:Concept .   # values drawn from peril:

When you build on core, agreement or a domain module — a new line of business, a regional variant, a partner model — the temptation is to add your terms into the module you are extending. Don’t. That is the single most damaging namespace mistake, because it puts terms you own into a namespace you don’t govern, and destabilises the foundation everyone else depends on.

Choosing the layer for a new module

• Cross-domain & reusable (a concept many lines share) → a new fnd/ module. A high bar — foundation changes are slow and heavily reviewed.
• A new line of business or domain → its own layer beside ins/: …/ontology/marine/cargo/, …/ontology/cyber/policy/. The layer names the business domain.
• A regional or tenant variant → a distinct module that imports the base, e.g. …/ontology/ins/policy-uk/ — never a fork of the original file under the same IRI.
• Enterprise meta or governance → misc/.

# A Marine Cargo line of business — its own namespace, built on the upper modules
@prefix mrc:    <https://data.chubb.com/ontology/marine/cargo/> .
@prefix policy: <https://data.chubb.com/ontology/ins/policy/> .
@prefix core:   <https://data.chubb.com/ontology/fnd/core/> .

<https://data.chubb.com/ontology/marine/cargo/>
    a owl:Ontology ;
    owl:imports <https://data.chubb.com/ontology/ins/policy/> ;
    vann:preferredNamespacePrefix "mrc" ;
    vann:preferredNamespaceUri <https://data.chubb.com/ontology/marine/cargo/> ;
    owl:versionIRI <https://data.chubb.com/ontology/marine/cargo/0.1> .

mrc:CargoPolicy  rdfs:subClassOf policy:Policy .   # extend by subclassing…
mrc:Jettison     rdfs:subClassOf core:Event .      # …never by editing policy or core

Two ways to extend — one right, one wrong