Competency Question

Competency questions are initially expressed in natural language (e.g., English) by domain experts and stakeholders. This ensures the ontology's requirements are grounded in real-world business needs and are understandable without technical knowledge. Examples include:

• "Which employees are certified to operate a specific piece of machinery?"
• "What is the current inventory level for part number X across all warehouses?"
• "List all projects managed by a department that exceeded its budget last quarter." This formulation precedes their formal translation into logical queries.

The primary function of competency questions is to delineate the scope of the ontology. They act as acceptance criteria; an ontology is considered 'competent' if it can provide answers to all defined questions. This process:

• Identifies key concepts and relationships that must be modeled.
• Prevents scope creep by providing a concrete, testable benchmark for completion.
• Aligns stakeholders by making abstract modeling goals tangible and verifiable. They bridge the gap between high-level business objectives and the precise, formal structure of an ontology.

Competency questions serve as the direct input for formalizing the ontology's structure. Each question is systematically decomposed and mapped to ontological components:

• Nouns and noun phrases often become classes (e.g., Employee, Project, Machine).
• Verbs and relationships become object properties (e.g., manages, isCertifiedToOperate).
• Attributes and descriptors become data properties (e.g., budgetAmount, inventoryLevel).
• Quantifiers and conditions inform axioms and constraints (e.g., "exceeded its budget" implies a data property comparison). This mapping ensures the resulting OWL or RDFS ontology is directly fit for purpose.

Once formalized, competency questions are translated into executable SPARQL queries or DL queries. These translations create a test suite for the ontology and its populated knowledge graph. This enables:

• Validation: Verifying the ontology's logical structure can support the intended queries.
• Knowledge Base Testing: Confirming that after data integration (ontology population), the system returns correct, complete answers.
• Regression Testing: Ensuring ontology modifications or extensions do not break existing query capabilities. This transforms qualitative requirements into quantitative, automated quality checks.

The process of formalizing and testing competency questions is inherently iterative. It often reveals gaps, ambiguities, or new requirements, driving ontology refinement. Common cycles include:

1. Question reveals missing concept: A question about "project risk level" may expose the need for a RiskAssessment class.
2. Formalization exposes ambiguity: "List senior staff" requires defining the property yearsOfService and a specific threshold.
3. Query results are incomplete: Missing data or property chains indicate needed inference rules or data cleanup. This iterative loop continues until the ontology reliably answers all questions, ensuring a robust final model.

It is critical to distinguish competency questions from end-user queries. They serve different purposes in the system lifecycle:

• Competency Questions: Are design-time artifacts. They are comprehensive, used to define the ontology's schema (TBox). They cover edge cases and establish the boundaries of what the system should be able to answer.
• User Queries: Are run-time operations. They are specific, ad-hoc questions executed against the fully populated knowledge graph (ABox) using the schema defined by the competency questions. In essence, competency questions define the capability of the system, while user queries exercise that capability on specific data instances.

These questions establish the boundaries of a production ontology.

• Can a single production line assemble multiple product variants?
• What are the mandatory quality control checks for a finished component?
• Which supplier provides the raw material for a specific batch?
• Is a machine that is undergoing maintenance considered 'available' for scheduling?

Answering these requires defining classes like ProductionLine, ProductVariant, QualityCheck, and properties like hasSupplier, hasMaintenanceStatus.

These questions force precise definitions of financial entities and their interactions.

• Does a corporate merger terminate all existing contracts of the acquired entity?
• Can an individual be both the beneficiary and the trustee of the same financial instrument?
• What is the chain of ownership for a security that has been re-hypothecated?
• Is an internal transfer between accounts at the same bank considered a 'transaction'?

Modeling the answers clarifies complex relationships like terminates, hasRole, hasOwnershipChain, and class distinctions like InternalTransfer vs. ExternalTransaction.

These questions model temporal states and procedural dependencies in patient care.

• What conditions must be satisfied before a patient can be discharged?
• Does a 'prescription' expire if the associated 'diagnosis' is later invalidated?
• Can a 'clinical trial protocol' be amended after patient enrollment has begun?
• Is a 'lab specimen' considered valid if the patient fasted for fewer than the required hours?

Answering these requires defining states, events, preconditions, and temporal constraints for classes like PatientStay, Prescription, and ProtocolAmendment.

These questions identify and disambiguate core logistical concepts.

• Is a 'shipment' the same entity if its contents are split across multiple trucks?
• What defines a 'delay': a missed internal milestone or a breach of customer contract?
• Does a 'warehouse' refer to the physical building, the legal business unit, or the logical inventory pool?
• If a product is recalled, are all items in transit automatically considered 'non-compliant'?

These questions drive the creation of distinct classes (e.g., PhysicalShipment, LogicalShipment) and precise property definitions (e.g., hasComplianceStatus).

These questions test the ontology's ability to derive implicit knowledge through reasoning.

• If a contract clause is governed by California law, does the entire contract fall under that jurisdiction?
• Are all signatories to a non-disclosure agreement automatically bound to all its amendments?
• If a regulation cites another revoked regulation, is the citation still valid?
• Can a person be held liable for an action performed by an autonomous agent they deployed?

Answering these requires modeling complex axioms, property characteristics (transitivity), and rules that allow a reasoner to make correct inferences.

These questions verify the ontology can support regulatory reporting and audits.

• List all data processing activities where customer biometric data is involved.
• For a given financial transaction, can all intermediary entities in the payment chain be identified?
• Which manufacturing processes used a chemical that has since been added to a restricted substances list?
• What personal data attributes were collected from users under a previous version of our privacy policy?

These questions ensure the ontology captures necessary historical data, lineage properties (e.g., usedSubstance, collectedUnderPolicy), and supports retrospective queries.

An ontology is a formal, explicit specification of a shared conceptualization for a domain of interest. It defines the classes (concepts), properties (relationships and attributes), and constraints (rules) that represent knowledge. Competency questions are used to define the scope and requirements of an ontology during its design phase, ensuring the resulting model can answer the necessary queries about the domain.

An ontology design pattern is a reusable, well-documented solution to a recurrent modeling problem. Using established patterns promotes consistency, interoperability, and best practices. Competency questions help identify which design patterns are most appropriate. For example, questions about events and their participants would lead a designer to apply a Event or Participation pattern.

Ontology evaluation is the systematic assessment of an ontology's quality against defined criteria such as correctness, completeness, and fitness for purpose. Competency questions serve as a primary gold standard for evaluation. The ontology's ability to correctly and completely answer the full set of competency questions is a direct measure of its competency and utility for the intended task.

SPARQL is the standard query language and protocol for retrieving and manipulating data stored in RDF format. Once an ontology is implemented and populated, competency questions are operationalized as executable SPARQL queries. The process of translating a natural language competency question into a precise SPARQL query validates the ontology's expressivity and the completeness of the underlying data.

In software and systems engineering, requirements engineering is the process of defining, documenting, and maintaining stakeholder needs. In ontology engineering, competency questions are the direct analog to functional requirements. They are elicited from domain experts and stakeholders to concretely define what the knowledge system must be able to do, guiding the entire development lifecycle.

Knowledge graph completion refers to techniques for inferring missing facts (links) within an existing knowledge graph. The scope defined by competency questions directly informs what constitutes a "complete" graph for a given use case. If a competency question cannot be answered due to missing relationships, it highlights a target for completion algorithms like link prediction.