Competency questions and vocabulary design

Ontology engineering should begin with questions and decisions, not with a blank diagram. A competency question states something the resulting knowledge system must be able to answer or validate. “Which suppliers provide components used by products affected by an active recall?” is better than “model suppliers,” because it exposes required identities, relations, temporal conditions, and evidence. A set of representative questions becomes an executable scope boundary: terms that support no question or policy require justification, and questions that cannot be answered expose missing structure.

Separate a taxonomy, a schema, and an ontology. A taxonomy organizes concepts, usually with broader and narrower links. SKOS is appropriate for controlled vocabularies, thesauri, subject headings, and mappings between concept schemes. A data schema describes expected fields and structures. An ontology makes semantic claims about classes, properties, individuals, and logical relationships. These artifacts can cooperate, but one should not be mislabeled as another. A product-category thesaurus does not automatically define the legal conditions under which a product is a medical device.

Build a term inventory from competency questions, existing standards, source fields, reports, and conversations with domain stewards. Classify each candidate as a class, relation, attribute, code-list concept, individual, or process artifact. Prefer relations that name stable domain meaning: suppliesComponent, governedByPolicy, or supersedesVersion. Avoid predicates that encode interface wording, report layout, or one source system’s column name unless the graph explicitly models that source schema.

Names are an interface. Give every term a stable IRI, a preferred label, a concise definition, examples, ownership, and status. Use alternative labels for search and migration, not as competing canonical terms. State whether labels are language-specific. Definitions should distinguish neighboring concepts and state necessary boundaries. “Customer: someone who buys things” is too vague for a system that must separate account holders, payers, beneficiaries, and authorized contacts.

Model relations explicitly enough to answer questions without deriving meaning from text labels. If an incident affects an asset through a deployed software version, represent the deployment and version relations rather than a generic relatedTo edge. Generic edges may aid exploratory search, but they destroy the ability to validate paths, apply policy, and explain why an answer follows. Every high-value relation should have expected subject and object kinds, temporal interpretation, provenance expectations, and an owner.

Reuse established vocabularies when their semantics fit. Reuse is not copying a familiar name onto a different concept. Read the source definition, domain assumptions, and version policy. Importing a large ontology merely to use two terms expands reasoning and governance surface area. A safer pattern is to depend on a small documented subset or map a local term to an external one with an explicit strength of correspondence. Exact equivalence is a strong logical claim, not a convenience for search.

Competency questions should cover positive, negative, temporal, provenance, and authorization cases. Ask not only “Which controls mitigate this risk?” but also “Which asserted mitigation lacks approved evidence?”, “Which claim was valid on the decision date?”, and “Which answer is visible to this role?” These questions prevent the ontology from becoming a static catalog detached from operations.

Use examples and counterexamples to review every important class. If Contractor is disjoint from Employee, can a person legitimately hold both relationships at different times or through two organizations? If yes, the model probably needs time-scoped roles rather than mutually exclusive person classes. Domain experts often resolve ambiguity faster with boundary examples than with abstract diagrams.

Version the vocabulary from the first release. Term status should include proposed, active, deprecated, and retired. A deprecated IRI should remain resolvable and point to migration guidance. Never silently reuse an old IRI for a new meaning. Competency questions, definitions, examples, mappings, and tests belong in the same review workflow as the ontology artifacts. The result is a semantic contract, not simply a set of triples.