Domain Analysis and Scope Definition

Introduction to Domain Analysis and Scope Definition

Before writing a single line of RDF or defining an OWL axiom, an ontology engineer must establish exactly what the ontology is meant to represent—and, just as importantly, what it will exclude. This process, known as domain analysis and scope definition, is the bedrock of any successful semantic modeling project.

A common mistake made by software engineers transitioning into knowledge representation is treating ontology design like Object-Oriented Programming (OOP) class design. In OOP, class design centers on operational properties—methods, behaviors, state changes, and execution logic. Ontology design, by contrast, centers entirely on structural properties—taxonomic hierarchies, semantic relationships, and explicit domain assumptions. We are not modeling what an object does in a system; we are modeling what a concept is in reality.

To ensure an ontology remains focused and structurally sound, we must rigorously define its boundaries using proven methodologies before moving into formal logic.

The Four Foundational Questions

The classic “Ontology Development 101” methodology, developed by Noy and McGuinness at Stanford University, provides a widely adopted framework for initiating a modeling project. It requires stakeholders to answer four foundational questions:

1. What is the domain that the ontology will cover? (e.g., Financial derivatives, human anatomy, supply chain logistics).
2. For what are we going to use the ontology? (e.g., Data integration across disparate databases, enabling GraphRAG for an LLM, semantic search).
3. For what types of questions should the information in the ontology provide answers? (This leads directly to Competency Questions).
4. Who will use and maintain the ontology? (Determines the required expressivity and whether tools like Protégé or custom web interfaces are needed for maintenance).

Answering these questions prevents the most common cause of ontology project failure: scope creep.

Defining Requirements with Competency Questions (CQs)

In traditional software engineering, we use user stories. In ontological engineering, we use Competency Questions (CQs). CQs are user-oriented interrogatives that define the functional requirements and boundaries of the ontology. If the ontology cannot answer a CQ, it is incomplete. If the ontology contains classes and properties that do not serve any CQ, it is over-engineered.

CQs exist in two states during the development lifecycle:

• Informal CQs: Expressed in natural language. These allow business stakeholders and domain experts to define requirements without needing to understand semantic web standards.
• Formal CQs: Translated into formal query languages (like SPARQL) or Description Logic (DL) axioms. This allows engineers to programmatically verify the ontology against the requirements.

ESAO#14 Competency questions

The 5-Type CQ Typology

To prevent vague or poorly structured requirements, modern ontology engineering frequently utilizes a typology to categorize CQs. According to the framework established by Maria Keet, CQs can be categorized into five distinct types:

1. Scoping (SCQ): Defines the boundaries of the domain.
   • Example: “Which specific investment products are available to retail clients in the EU?”
2. Validation (VCQ): Used to test if the model enforces constraints correctly.
   • Example: “Can a retail customer simultaneously hold a wholesale discount tier?”
3. Foundational (FCQ): Addresses high-level ontological categories and core definitions.
   • Example: “What constitutes a ‘Financial Transaction’ in this domain?”
4. Relationship (RCQ): Targets how concepts link together.
   • Example: “Does a ‘Regional Manager’ supervise a ‘Branch Employee’?”
5. Metaproperty (MpCQ): Deals with the logical characteristics of the properties themselves.
   • Example: “Is the ‘reports_to’ relationship transitive?” (i.e., If A reports to B, and B reports to C, does A report to C?)

Translating CQs into Foundational Classes

Once a robust set of CQs is established, the next step is translating the nouns and verbs from these questions into foundational classes (OWL Classes) and properties (OWL ObjectProperties and DatatypeProperties).

Let’s take a Relationship CQ: “Which employees report to the Director of Engineering?”

1. Identify Candidate Classes (Nouns): Employee, Director, EngineeringDepartment.
2. Identify Candidate Properties (Verbs/Relations): reportsTo.
3. Establish Taxonomy: We recognize that a Director is likely a specific type of Employee. Therefore, Director becomes a subclass of Employee (Director rdfs:subClassOf Employee).
4. Define Domain and Range: The property reportsTo will likely have a domain of Employee and a range of Employee (or a subclass like Manager).

By systematically extracting these terms from the CQs, you build a foundational glossary that is perfectly scoped to the business requirements.

Caveats, Trade-offs, and Common Mistakes

As you transition from domain analysis to formal modeling, be aware of several critical pitfalls that frequently trap novice ontology engineers.

The “Model-the-Universe” Trap

Without strict adherence to CQs, engineers frequently attempt to represent the entire business domain rather than limiting the classes and properties to the minimum required. If your business only needs to query the location and status of a server rack, you do not need to model the specific materials of the server’s motherboard. Stick strictly to the CQs.

The “CQs Are Not Enough” Fallacy

A major pitfall is assuming that because an ontology successfully answers all its CQs via SPARQL queries, it is logically sound. As highlighted by Keet and other researchers, an ontology can satisfy all competency questions while still containing severe taxonomic errors or poor modeling practices. For example, you might accidentally model Employee as a subclass of Department rather than a member of it. A SPARQL query might still return the right employees for a department, but the underlying logical structure is fundamentally broken. CQs test coverage, not structural quality.

Treating CQs as Static Documents

In practice, domain requirements evolve. Surveys of ontology engineers show that treating CQs as a static, one-time upfront phase (a “waterfall” approach) often leads to project failure. CQs must be authored, tested, and refined iteratively alongside the ontology’s development lifecycle. As stakeholders see early graph visualizations, they will inevitably generate new CQs.

Summary

Domain analysis and scope definition form the critical first step of ontological engineering. By leveraging the four foundational questions and rigorously defining Competency Questions across the 5-Type typology, you establish a clear boundary for your model. Translating these CQs into foundational classes ensures your ontology remains grounded in actual business requirements. However, always remember that while CQs guarantee your model answers the right questions, they do not automatically guarantee the logical elegance of your underlying taxonomy.