Does knowledge engineering always require an ontology?

No. Rules, frames, logical statements and other representations may be appropriate. An ontology is one important tool.

How does it relate to data engineering?

Data engineering emphasizes acquiring, moving and managing data; knowledge engineering emphasizes its meaning and use in reasoning. A project can need both.

Can language models assist?

They can propose terms, relations or draft rules, but proposals still need source grounding and task-specific validation before becoming maintained knowledge.

AI Glossary / Graphs and symbolic AI / Intermediate

Knowledge engineering

Definition

Knowledge engineering is the work of designing, building, testing and maintaining systems that use explicitly represented domain knowledge. It connects subject expertise with representations, reasoning methods and usable software so that a system can answer defined questions or support particular tasks.

What it means

The work begins with what people need the system to do, not with a choice of database or rule language. A team must decide which distinctions matter, where the knowledge comes from and what conclusions the system is permitted to draw.

Knowledge acquisition obtains and clarifies content. Knowledge representation expresses that content in a usable form. Knowledge engineering includes both, together with implementation, integration, evaluation and maintenance. It often involves collaboration between domain specialists and technical staff.

The goal is not necessarily to encode everything known about a domain. A useful model is scoped to its purpose and makes important assumptions visible. A valid ontology can still fail to answer the intended questions.

How it works

Specify the task and write representative questions the system should answer. Identify sources, users and maintainers. Define the core vocabulary, including the difference between categories and individual objects, then choose an appropriate representation and reasoning approach.

Populate a small model and test it against concrete cases. Check both intended conclusions and conclusions that should not follow. Revise ambiguous concepts, incomplete rules and unsupported assumptions before expanding the knowledge base.

Integrate the result with the application and establish how new information will be reviewed, versioned and retired. Changes to a concept or rule can affect many answers, so maintenance needs regression examples and traceable dependencies. The process is iterative.

Three practical examples

A catalog team distinguishes a product model from individual physical units so availability is attached to the correct object.
A support application uses a reviewed vocabulary and routing rules, with tests for missing information and exceptions.
A scientific-data project aligns terms from several sources while preserving differences that matter to later queries.

Think of it this way

Think of designing a city map for a particular traveler. Choosing landmarks, symbols, scale and update procedures all matter; merely drawing more streets does not guarantee a useful map.

The analogy captures purposeful modeling. A knowledge-engineered system additionally needs explicit interpretation and computational behavior, so its design must explain how stored information produces answers.

Worked example

A library model that confuses a title with its copies

A fictional library wants a system to answer which physical copies can be lent now. It holds two copies of the title River Atlas: P1 is available, while P2 is currently on loan. A digital edition E1 also exists, but digital access is outside this pilot's lending scope.

The first model stores only the title T and a single Available(T) value. If that value is true because P1 is available, an application may incorrectly present P2 as available as well. If it is false because P2 is on loan, the system hides P1. One title-level status cannot express the required distinction.

The revised model creates separate objects for T, P1, P2 and E1. It records CopyOf(P1, T) and CopyOf(P2, T), classifies P1 and P2 as physical copies, and stores their individual statuses. E1 is represented as a digital edition rather than being silently treated as a physical copy.

For this invented pilot, CanLend(c) requires that c is a physical copy, has status Available and has a current handling-clearance record. Suppose P1 meets all three conditions, P2 has status OnLoan, and E1 is digital. The expected lending answer is P1 only.

The test set should also include a physical copy with no clearance record and an item with conflicting statuses. Those cases need defined behavior instead of an invented default. These invented pilot rules are not universal library policy.

Illustrative case study

The fictional Cedar Library team initially measures progress by counting imported records. During a demonstration, staff discover that the assistant cannot distinguish the two River Atlas copies.

Cedar returns to its original question and separates bibliographic identity from copy-level state. A librarian reviews the vocabulary, a developer adjusts the queries, and the team adds the four-object example to its regression checks. It also records that digital lending is outside the pilot rather than labeling digital editions unavailable in general.

When a copy changes status, the system updates the relevant item record and re-evaluates the answer. This fictional case connects modeling to maintenance.

Common misconceptions and mistakes

Knowledge engineering is just interviewing experts. It also includes modeling, implementation, testing and upkeep.
A larger knowledge base is always better. Extra content can introduce irrelevant distinctions, conflicts or maintenance costs.
One correct ontology exists for every domain. Different purposes can justify different models, with different tradeoffs.
A passing software test proves the knowledge is true. It can verify implemented behavior without establishing the accuracy of the underlying assertions.

Business use

Knowledge engineering can make expert reasoning and shared definitions more inspectable and reusable. It is useful when a project needs stable terminology, explicit relationships or traceable conclusions across applications.

Define success through the questions and tasks the system must handle. Track answer correctness, unresolved cases, review effort and the consequences of updates. Keep domain ownership visible: technical teams can implement a rule precisely while still needing specialists to confirm its meaning. Clear scope and documented assumptions make a model easier to assess.

Check your understanding

Why is an availability property on the title insufficient for the library's question?

Answer: The question concerns individual physical copies, which can have different statuses at the same time. The representation must preserve those separate identities and their copy-level conditions.

Related terms

Knowledge acquisition
Ontology engineering
Knowledge representation
Knowledge base
Inference
Validation
domain model
competency question
provenance
change management

Learn next

Choose a small catalog and write three questions its users need answered. Identify which refer to categories, individual objects or changing states. Build a minimal representation, then invent one case that exposes a missing distinction before adding more records.

Sources

Noy and McGuinness describe iterative modeling, scope and question-driven ontology development: https://protege.stanford.edu/publications/ontology_development/ontology101.pdf

Research on knowledge-engineering practices and reference architecture: https://arxiv.org/abs/2404.03624

Davis, Shrobe and Szolovits discuss the roles and tradeoffs of knowledge representation: https://groups.csail.mit.edu/medg/ftp/psz/k-rep.html

The River Atlas model and Cedar Library case are fictional examples developed for this entry.

Previous: Knowledge compilation Next: Knowledge extraction