Defined Boundaries
Specify the domain, purpose and intended users before creating classes. Clear scope prevents unnecessary duplication and uncontrolled expansion.
ONTOLOGY / ENGINEERING & DEVELOPMENT
Ontology
Engineering.
KNOWLEDGE DESIGN / 001
Discover how ontologies move from scientific requirements to precise knowledge models through conceptual design, formal representation, logical testing and long-term maintenance.
SCIENTIFIC KNOWLEDGE MODELING
Knowledge needs more than structure. It needs precision.
Ontology engineering combines domain expertise with formal modeling, computational logic and quality assurance. The result is a knowledge representation that can be examined, reused and refined as scientific understanding evolves.
MODEL / VALIDATE / PUBLISH / MAINTAIN
FIG 01 / LIFECYCLE
What is ontology engineering?
Ontology engineering is the systematic process of developing and maintaining ontologies. It involves identifying a domain of knowledge, defining relevant concepts, establishing relationships and representing them using an appropriate formal language.
Unlike simply assembling a list of terminology, ontology engineering requires explicit modeling decisions. Developers must distinguish a class from an individual, select meaningful relations and decide which logical statements accurately describe the domain.
In biomedical research, this may involve defining cell types, biological processes, sample categories or experimental observations. A well-engineered ontology helps different systems interpret those concepts consistently and supports their reuse across studies.
Ontology engineering is iterative. New scientific evidence, changing research requirements and community feedback can make revisions necessary. Quality assurance and maintenance therefore belong to the development process, rather than being treated as optional final steps.
003 / DESIGN PRINCIPLES
The foundations of a reliable ontology.
Good ontology engineering balances scientific meaning, formal consistency, community needs and long-term interoperability.
Clear Meaning
Provide precise, human-readable definitions. Labels alone may be ambiguous, especially across scientific disciplines.
Stable Identity
Assign persistent identifiers to ontology entities so records can continue to reference the same concept across releases.
Interoperability
Reuse existing ontology entities and established relationships where appropriate rather than recreating equivalent concepts.
Formal Precision
Define axioms carefully so reasoning systems can derive intended consequences without introducing unwanted classifications.
Maintainability
Document changes, manage versions and provide a process for expert review and community contributions.
004 / DEVELOPMENT WORKFLOW
From an idea to a maintained ontology.
A typical development lifecycle moves from scientific requirements through formal modeling, technical validation and community publication. These phases are repeated as the ontology evolves.
01 /
Define requirements and competency questions
Identify what the ontology must represent and what questions it should help answer. For example: "Which cell types are subclasses of immune cell?" Competency questions help assess whether the model supports its intended purpose.
02 /
Review and reuse existing ontologies
Search established resources for relevant terms, identifiers and relations. Reuse compatible content and document the source of imported knowledge.
03 /
Create the conceptual model
Define the principal classes, their definitions, subclass relationships and relevant properties. Domain experts help ensure that the proposed model reflects accepted scientific knowledge.
04 /
Implement formal axioms
Represent the model using a suitable language such as OWL. Add logical restrictions only when their interpretation is justified and understood.
05 /
Test, validate and review
Use reasoning tools to investigate consistency and class satisfiability. Check definitions, naming conventions, expected query results and domain-expert feedback.
06 /
Publish, version and maintain
Release documented ontology versions, preserve identifier stability and record changes. Use community feedback and new scientific evidence to improve future releases.
005 / MODELING EXAMPLE
Engineering a cell classification.
Consider a simplified biological model containing the concepts Cell, Immune Cell and Macrophage. An ontology engineer might represent Immune Cell as a subclass of Cell, and Macrophage as a subclass of Immune Cell.
This classification makes it possible for an OWL reasoner to infer that Macrophage is also a subclass of Cell, by transitivity of the subclass relation.
The example demonstrates how explicit logical statements can produce further consequences. However, a formal biomedical ontology should reuse appropriate concepts from established resources and be reviewed for scientific accuracy.
MODEL 002 / SUBCLASS INFERENCE
Original conceptual illustration. The inferred relation follows from the stated subclass hierarchy. It does not imply that all biomedical relations are transitive.
006 / ENGINEERING TOOLS
Tools for modeling, testing and delivery.
Software tools support the practical development of ontologies, but cannot replace expert judgment about scientific meaning.
| Technology / Tool | Main Purpose | Typical Engineering Task |
|---|---|---|
| Protégé | Ontology editing environment | Author classes, properties and OWL axioms |
| OWL 2 | Formal ontology representation language | Specify definitions and logical relationships |
| OWL reasoners | Logical inference and consistency checking | Identify unsatisfiable classes and derive hierarchy relationships |
| SHACL | Constraint validation for RDF graphs | Check required properties and data shapes |
| ROBOT | Ontology automation and quality-control utilities | Generate reports, manage releases and check ontology content |
| Git | Version control and collaboration | Track changes, review contributions and maintain releases |
007 / QUALITY ASSURANCE
Testing an ontology beyond syntax.
A file can be syntactically valid and still contain poor definitions, incorrect relationships or missing scientific concepts. Ontology evaluation must therefore examine several complementary qualities.
Structural correctness
Confirm that ontology files parse successfully and use the intended representation language and syntax.
Consistency and satisfiability
Use suitable reasoners to detect logical contradictions and classes that cannot have instances under the stated axioms.
Competency questions
Test whether the ontology, together with relevant data where needed, can answer the questions for which it was designed.
Constraint validation
Apply explicit validation rules when records must contain particular properties or follow a defined data shape. SHACL checks are conceptually distinct from OWL reasoning.
Domain-expert review
Verify that definitions, relationships and classifications accurately reflect accepted domain knowledge and use appropriate evidence.
Release quality
Ensure that ontology identifiers remain stable, deprecated terms are documented appropriately, and changes are traceable between versions.
008 / BIOMEDICAL RESEARCH EXAMPLE
Engineering knowledge for single-cell biology.
Single-cell RNA sequencing experiments generate large collections of cellular expression profiles. Researchers assign biological labels to groups of cells, but these labels can vary between laboratories.
Ontology engineering helps represent cell types using consistent identifiers and hierarchical relationships. This makes annotations more comparable across datasets and supports searches involving broader classes of cells.
Illustrative competency question
A research platform may need to retrieve all datasets annotated with macrophages or their subclasses. A carefully modeled cell-type hierarchy can support this classification task, provided that the relevant data and reasoning or query configuration are available.
Requirement:
Find datasets annotated with a
Macrophage or its subclasses.
Model:
Cell
└── Immune Cell
└── Macrophage
Expected capability:
Use the ontology hierarchy to
support broader cell-type search.
In a production environment, established cell-type identifiers should be reused wherever suitable, rather than defining conflicting replacement concepts.
009 / STANDARDS & REFERENCE RESOURCES
Essential resources for ontology developers.
Explore recognized specifications, community guidance and practical development tools.
01 /
W3C ↗
W3C OWL 2 Primer
Introduction to formal ontology modeling, classes, properties and logical semantics.
02 /
OBO ↗
OBO Foundry Principles
Community practices for open, interoperable, documented and maintained biomedical ontologies.
03 /
Protégé ↗
Protégé Ontology Editor
Widely used environment for ontology creation, editing and exploration.
04 /
W3C ↗
W3C SHACL
Standard language for expressing and validating constraints on RDF data graphs.
05 /
ROBOT ↗
ROBOT Ontology Tool
Automation tools for ontology reporting, transformations and reproducible workflows.
06 /
Dashboard ↗
OBO Foundry Dashboard
Automated evaluations and quality reports related to OBO Foundry principles.
010 / FREQUENT QUESTIONS
Ontology engineering, explained.
What is the goal of ontology engineering?
Its goal is to develop explicit, consistent and maintainable representations of domain knowledge that can be understood and reused by people and software systems.
What are competency questions?
Competency questions describe the information needs an ontology should support. They help define its scope and evaluate whether its design is useful for the intended application.
What is the difference between OWL reasoning and SHACL validation?
OWL reasoning derives logical consequences under the semantics of an ontology. SHACL evaluates RDF data against specified constraints. OWL typically uses open-world reasoning, while SHACL can check requirements such as mandatory property values.
What are ontology design patterns?
They are reusable modeling solutions to recurring knowledge representation problems. Design patterns can improve consistency and reduce repetitive modeling effort, but should be adapted to the domain and its requirements.
Why must scientific ontologies be maintained?
Scientific knowledge evolves as new entities, evidence and classifications become available. Maintenance supports corrections, updates, documented deprecations and continued interoperability.