Start with the questions, not the classes.

The argument, up front

Left to instinct, a modelling effort drifts toward describing the world — endless classes, ever-finer distinctions, no natural finish line. Competency Questions flip the polarity: they turn a vague “model the domain” into a concrete, checkable list of “the system must be able to answer this.” That is a requirement you can build to and a test you can pass. It is also, conveniently, the exact way your team already thinks.

A Competency Question (CQ) is a plain-language question that your ontology — once built and populated with data — must be able to answer. The set of CQs defines the competency of the model: its job description. The idea comes from Grüninger & Fox (1995) and is now the backbone of modern ontology methodologies.

You already use this pattern under other names. A CQ is the ontology’s equivalent of a user story, an acceptance criterion, or — most precisely for a database engineer — the query the schema must be able to serve. If you would never design a table without knowing the reports it has to feed, you already believe in Competency Questions.

The bridge to what you already know

Anatomy of a good CQ

A well-formed CQ quietly names the pieces of the model you will need. Read this one and watch the vocabulary fall out:

Notice what happened: without drawing a single box, the question named four classes and four properties — every one of which already exists in policy.ttl and coverage.ttl — and told us they belong together. The question is doing the modelling. (It even reaches the role-reification pattern: policy:Producer is defined as whatever core:hasRole policy:ProducerRole, realized through the policy:producer property.)

Especially for a team without deep ontology experience, starting from questions is not just tidy — it is the thing that keeps the project finishable, honest, and yours.

You do not invent CQs — you harvest them. They are hiding in the work your organisation already does.

Where to find them

• Existing reports & dashboards. Every KPI on a dashboard is a CQ someone already needs answered.
• Your SQL query logs. The queries analysts run most often are competency questions in disguise — the highest-value ones.
• Stakeholder interviews. Ask an underwriter or adjuster: “What do you need to look up to do your job?” Write down the questions verbatim.
• Operational decisions & regulations. Anything the business must decide or report on is a question the model must support.

The recipe for one good CQ

Good vs. weak — the same intent, two outcomes

This is where CQs earn their keep. A validated CQ is a passing test — and this is the part of the workflow that will feel most familiar to an engineer. The technique has a name: test-driven ontology development.

Turn each CQ into a runnable test

Take a CQ, hand-craft a tiny bit of example data (a handful of individuals — the ABox), then write the SPARQL query that answers it. If the model can return the right answer, the CQ passes. If you can’t even express the query, the model is missing a class or property — a precise, actionable gap.

# The CQ, made executable against the real vocabulary — this IS the acceptance test
PREFIX policy:   <https://data.chubb.com/ontology/ins/policy/>
PREFIX coverage: <https://data.chubb.com/ontology/ins/coverage/>

SELECT ?coverage ?premium ?limit ?deductible
WHERE {
  ?policy   policy:policyNumber   "PN-100" ;
            coverage:hasCoverage  ?coverage .
  OPTIONAL { ?coverage coverage:hasPremium    ?premium }
  OPTIONAL { ?coverage coverage:hasLimit      ?limit }
  OPTIONAL { ?coverage coverage:hasDeductible ?deductible }
}

Every term here resolves to something real: policy:policyNumber, coverage:hasCoverage, and the three money properties whose ranges (Premium, Limit, Deductible) are all core:MoneyAmount. Run it against a sample policy in resource/: rows back → the module supports the question. Nothing back, or a term you can’t even name → you’ve found exactly what to fix, before anyone builds on top of it.

Check coverage in both directions

A living test suite

Keep the CQ-to-SPARQL tests and re-run them whenever the module changes. Like a regression suite, they catch the day a “small refactor” quietly breaks a question the business depends on. Run against the current modules, your validation dashboard looks like this:

Why does that last one fail? Writing the query is the diagnosis — two lines simply can’t be filled in:

# "Which OPEN claims exceed their coverage limit?" — attempting it exposes the gaps
SELECT ?claim ?incurred ?limit
WHERE {
  ?policy policy:policyNumber   "PN-100" ;
          policy:hasClaim       ?claim ;
          coverage:hasCoverage  ?cov .
  ?cov    coverage:hasLimit     ?limit .          # ✓ Limit exists (⊑ core:MoneyAmount)

  # ✗ nothing records whether a Claim is open or closed
  # ?claim claim:hasStatus claim:Open .

  # ✗ nothing gives a Claim its incurred amount
  # ?claim claim:incurredAmount ?incurred .

  # FILTER(?incurred > ?limit)   ← cannot run: ?incurred never binds
}

That single GAP is the whole method working as intended: an unambiguous, prioritised instruction for the next iteration — give claim:Claim a status and an incurred amount — discovered by a test, not by a production incident. It even points at a clue already sitting in the model: policy:PolicyStatus is declared as a class, yet no property connects a policy to one. A CQ just told you to finish it.

Put together, CQ-driven modelling is a short, repeatable loop. Build one module at a time; each pass through the loop leaves you with a small, tested, trustworthy piece.

Here is the whole method compressed into a single small module, so the shape is concrete.

You need no new tooling to begin — a shared doc and a whiteboard are enough for the first pass. Here is a 90-minute agenda that produces real output.