2 · Competency Questions — what the model must answer

Fifteen prioritised CQs and what each one tells us about the model. If a CQ can't be answered in SPARQL, the ontology has a gap.

0/2 done

Theory — Competency questions

The Golden Rule of Ontology Design

According to the widely adopted NeOn methodology, Competency Questions (CQs) are the ultimate functional specification of an ontology. Think of them as unit tests for your knowledge graph.

The rule is absolute: If a stakeholder's CQ cannot be answered by executing a SPARQL query against the ontology and its data, then the ontology has a gap and is fundamentally incomplete.

We always document CQs before writing a single line of Turtle. They are distilled directly from stakeholder interviews and categorised by priority (P0, P1, P2).

MedaCore CQ Catalogue (Extract)

P0 — Critical Path (Must answer or the project fails)

  1. Which assessments are currently classed as 'reportable' based strictly on the regulator's definition?
  2. For a specific drug, can you list every 'serious' adverse event that occurred in the last 90 days, along with its linked exposure?
  3. If a case is flagged as 'reportable', provide the exact logical inference chain that led to that decision.

P1 — Important (Must answer for v1.0 release)

  1. Which patients were simultaneously exposed to Drug X and Drug Y at the moment an event occurred?
  2. What is the total count of reportable cases, grouped by drug and quarter?
  3. Out of all intake channels, which one generated the highest number of malformed (rejected) reports last month?

P2 — Enhancements (Nice to have for v2.0)

  1. What is the average time delay between the clinical onset of the event and the actual submission of the report?
  2. Which causality assessments were manually downgraded by a physician after the initial AI review?

How CQs Drive Engineering Decisions

You aren't just writing these down to make management happy; they directly dictate the code you write:

  • CQ1 forces us to create a formally defined OWL class called :ReportableCase, enabling dynamic querying.
  • CQ3 literally dictates our software stack: it forces us to choose an explainable reasoner (like HermiT or openllet, which provide logical justifications) rather than a faster but silent reasoner.
  • CQ6 tells us that the intake channel must be modelled as a data property attached directly to the :Report entity, preventing us from overlooking this vital data pathway.

Reading in progress · 0 of 2 activities done