Is ontological engineering the same as ontology engineering?

The terms commonly refer to the same general discipline of building and maintaining ontologies.

Must the ontology describe an entire industry?

No. A clearly scoped model for a particular application can be more useful and maintainable than an unnecessarily broad one.

Can an existing ontology be reused unchanged?

Sometimes, but its meanings and assumptions should first be checked against the intended task and data.

AI Glossary / Graphs and symbolic AI / Intermediate

Ontological engineering

Definition

Ontological engineering is the disciplined work of designing, evaluating, and maintaining explicit models of the concepts and relationships in a domain. These models, called ontologies, help people and software use information with consistent meanings. The work includes deciding what distinctions matter, expressing them clearly, and checking that the resulting model supports its intended questions and applications.

What it means

An ontology is more than a collection of labels. A model of equipment may distinguish equipment types, individual machines, locations, and maintenance events. Relationships explain how these entities connect, while definitions and axioms state what follows from those connections.

Engineering the ontology means making these choices deliberately rather than allowing database fields or software conventions to define them accidentally. Different applications can justify different levels of detail. A model for finding product manuals need not contain every distinction required for tracking individual repairs.

How it works

Begin with the purpose and scope, including questions the model should help answer. Identify useful existing vocabularies and examine whether their meanings match the task. Gather important domain terms, define the relevant classes and relationships, and document examples and boundaries.

Express the design in a suitable representation and populate small illustrative cases. Review it with domain experts and inspect what queries or inferences it supports. A class hierarchy should represent genuine specialization: every instance of a subclass must also qualify as an instance of its superclass.

Development is iterative. Unexpected examples can expose missing distinctions or overly strong assumptions. Changes should be evaluated against the intended uses and documented so that dependent applications can understand their effects. Automated logical checks can help, but they do not replace judgment about whether the model represents the domain appropriately.

Three practical examples

Equipment knowledge: separate product families, physical assets, and service events so that manuals and repair histories are connected correctly.
Information integration: align the meanings of concepts used by different departments before combining their structured data.
Knowledge-based assistance: define a shared domain vocabulary that supports precise queries and interpretable answers from a knowledge base.

Think of it this way

Think of designing a shared filing system together with clear rules for what each folder and cross-reference means. The design succeeds when different people can place and retrieve information consistently.

The analogy is limited because formal ontologies can express logical relationships that go beyond filing. A reasoning system may derive additional classifications from stated axioms, so a small modeling change can affect more than where a document is stored.

Worked example

Suppose a service team needs to answer, “Which physical printers of model M7 have recorded maintenance events?” Start with classes Printer, PrinterModel, and MaintenanceEvent. Introduce a hasModel relationship from a printer to its model, and an concernsPrinter relationship from an event to a printer.

Create distinct individuals p10 and p11 as printers, m7 as a printer model, and e3 as a maintenance event. State hasModel(p10,m7), hasModel(p11,m7), and concernsPrinter(e3,p10). A query for printers of m7 with a recorded event returns p10 from these facts.

If the design had represented M7 only as the same object as p10, it would mix a product type with one physical machine. If the event linked only to m7, the model would not identify which individual printer was serviced. The competency question exposes why both distinctions are needed.

The absence of an event for p11 does not automatically establish that it was never serviced. That conclusion requires an explicit completeness assumption about the event records. This original example tests the proposed structure and its limits; it is not a claim that an ontology alone verifies the history of real equipment.

Illustrative case study

Fictional case: a company starts an equipment ontology by copying its database column names. Reviewers later discover that the word model refers to a product type in one source and an individual machine record in another.

The team returns to its intended questions, adds concrete examples for each concept, and documents separate mappings from the sources. It then reruns its example queries after each revision. The case illustrates an iterative design correction, not a measured integration result or a requirement to rebuild every existing data system.

Common misconceptions and mistakes

More classes do not automatically make a better ontology. Extra distinctions can increase maintenance work without helping the intended application. Equally, a tiny model can be inadequate if it merges entities that users need to distinguish.

A subclass is not the same as a part. A printer component can be part of a printer without being a kind of printer. Confusing these relations can produce incorrect classifications.

An ontology editor cannot settle all conceptual disagreements. Logical consistency is valuable, but a consistent model can still answer the wrong questions or encode an inappropriate assumption. Domain review and application testing remain necessary.

Business use

Ontological engineering can make business data more understandable and reusable across tools. It is especially useful when different teams use the same words differently or when automated reasoning requires explicit relationships.

A project should identify who approves meanings, which applications depend on them, and how changes will be communicated. Useful deliverables include definitions, examples, scope decisions, mappings, and tested questions, alongside the formal ontology itself. Success should be assessed through the intended use, rather than the number of terms or the visual complexity of a diagram.

Check your understanding

Why must the maintenance event in the worked example identify a physical printer?

Answer: Linking only to the product model cannot tell the query which individual machine was serviced. The task requires a distinction between type and instance.

Related terms

Learn next

Write three questions that a small domain model should answer. Create a handful of instances and test whether the proposed concepts and relationships provide the necessary distinctions. Then study ontology languages and their reasoning assumptions before adding stronger axioms.

Ontology

Sources

Natalya Noy and Deborah McGuinness, Ontology Development 101: https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html — scope, competency questions, iterative development, and class-versus-instance design.

Tom Gruber, It Is What It Does: https://tomgruber.org/writing/bio-ontologies-2000.pdf — ontologies as designed artifacts and explicit representational choices. The printer model, query, and organizational scenario are original illustrations.

Previous: Ontological commitment Next: Ontology