These briefs are written for the people who build and maintain the Chubb ontology — data analysts and engineers, not just ontologists. Each one is self-contained and grounded in real modules, vocabulary and conventions, so the examples are the actual policy, claim and coverage you already work with.

They are meant to be read in order, but any one stands alone. Together they answer a single question: what does it take to grow a domain model that stays comprehensible, testable and trustworthy for years?

The four briefs

Read the series

01 Requirements · what to build

Start with the questions →

Build every module from Competency Questions — the requirements, the test suite and the finish line, written in language your whole team already speaks.

The questions decide what to build, and prove when to stop.

02 Anti-pattern · what not to copy

Model the domain, not the message →

Why deriving an ontology from JSON or XML transport encodings freezes the accidents of a wire format into your axioms — and what to do with messages instead.

Mine messages for terms; derive structure from the domain.

03 Architecture · how to structure it

Build it in modules →

The case for a layered set of cohesive, independently-versioned modules connected by a directed, acyclic owl:imports graph — and how to draw the seams.

Every edge runs upward, so the graph can never cycle.

04 Naming · how to name it

A place for every IRI →

One namespace scheme for ontology modules, SKOS vocabularies and instance data — ten rules, the live registry, and how to mint namespaces when you extend the upper ontology.

Mint in your own space; import the foundation; point upward.

The thread that runs through all four

Let the questions decide what exists, keep the messages out of the model, give each concern its own module, and give every thing its own stable name. Four decisions, made deliberately, are most of what separates an ontology that lasts from one nobody dares touch.

Beyond the four briefs

From model to working system

05 Encoding · how to serialize it

One graph, many encodings →

RDF is one abstract graph with many concrete syntaxes. How to choose — Turtle, JSON-LD, N-Triples, RDF/XML — for ontologies, vocabularies and instance data, with the criteria and the scenarios where each wins.

The encoding cannot shape the model — so choose it freely, and late.

06 Governance · how to version it

Version with intent →

A guideline for versioning ontologies: a permanent ontology IRI plus a per-release versionIRI, semantic versioning by consumer impact, a breaking-change taxonomy, deprecation over deletion, release metadata, changelog capture, and a validated publish workflow.

Classify every change by who it affects — then bump, deprecate, and publish.

★ Strategy · from ontology to enterprise graph

The Chubb Enterprise Knowledge Graph →

A virtual-first (OBDA) architecture strategy that turns the ontology into an enterprise semantic layer over federated data — mappings, federation, entity resolution, executable governance, serving, and a phased roadmap.

The four briefs build the model; this one puts it to work across the enterprise.

07 Integration · how to map sources to it

From tables and endpoints to meaning →

A strategy for mapping the two source shapes you have — relational databases (R2RML) and Web APIs (RML or adapters) — onto one semantic model, with stable IRIs, a materialize-vs-virtualize decision, and mappings engineered like code.

A database is a schema, an API is a message — map both to the meaning.

08 Reference data · controlled vocabularies

A vocabulary you can govern →

Why code lists, taxonomies, thesauri and glossaries all belong in SKOS — one governed set of concepts, kept out of the class hierarchy — and how any domain team extends a scheme it doesn’t own by mapping from its own namespace.

Model the values as concepts; map across schemes, never squat.

09 Pitfalls · what to avoid

How a model goes wrong →

A field guide to twenty recurring anti-patterns — category errors, misread open-world logic, and discipline lapses — each with the tell that gives it away and the fix. A hub that ties the whole series together.

Most bad axioms fail one of three questions — learn to ask them.

10 Scale · cleaning an inherited hierarchy

The taxonomy trap →

Pull “organization” from Wikidata and you get 107,042 types — nearly all correct, nearly all useless. Seven pitfalls that pose a role, a dimension, an instance, or a category mistake as a type, and the pipeline that folds 107,042 nodes down to ~2,100.

Ask of every node: a kind, a state, a place, a role, or a particular?

11 Languages · which one for the rule

RDFS, OWL or SHACL →

Three languages with three jobs: RDFS names and relates terms, OWL defines their meaning for a reasoner, SHACL validates the data. A guideline for choosing by intent — infer or reject — with one requirement run through all three.

Reasoning adds facts; validation rejects data — never swap the two.

12 Abstraction · database vs meaning

A logical model is not a semantic model →

Conceptual, logical and physical form one ladder toward storage. The semantic model looks like a fourth rung beside the logical model — but it answers a different question, under open-world semantics with global identity, and mistaking one for the other wrecks a knowledge graph.

A logical model is a container; a semantic model is a theory of the domain.

13 The destination · anatomy & use cases

The knowledge graph in use →

What a built enterprise knowledge graph is made of — ontology, resolved entities, vocabularies, mappings, a governance spine — and the four families of use case it powers: integrate, discover, reason & detect, and govern, grounded in insurance.

Not a warehouse you finish — a living layer of meaning you grow.

14 Process & trust · how it records what happened

Workflows and provenance →

Model the business processes the graph describes and the pipelines that build it on one PROV-O backbone — entity, activity, agent — with plans vs. executions, provenance granularity, and the three clocks, so every fact can say where it came from and by what process.

Model the process as data — and the graph explains itself.

15 Reuse · standing on standards

Don’t reinvent the vocabulary →

Why the generic parts — time, parties, places, money, codes, metadata, provenance — should be reused from standard ontologies (SKOS, PROV-O, OWL-Time, W3C Org, Dublin Core, FIBO). Which to use, the criteria for choosing, how to import/extend/align, and when not to.

Reuse the generic; reserve your effort for what makes you different.

16 Trust · securing the graph

The connected graph is the risk →

Security, access control and privacy for an enterprise graph: why unification, inference and aggregation make it harder than a table; access-control models and granularity (RBAC/ABAC/ReBAC/labels); the super-user pitfall; personal-data rights including erasure; and defense in depth.

Who is the principal, what can they infer, and is any of it personal?

17 Process & tooling · building it with an LLM

From chaos to production →

Unconstrained, an LLM produces five characteristic failures — hierarchy explosion, concept–instance confusion, inconsistent taxonomy, property sprawl, modeling by association. Constrained generation with guardrails and an eight-step workflow tames them, and a governed pipeline turns the ontology itself into APIs, apps and agents.

The model didn’t get smarter — the process got disciplined.