Ontologies Let Systems Reuse Meaning

One application calls a thing a “component.” Another calls it an “asset.” A third stores it as a line in a purchase order. The words may refer to the same physical object, different stages of its life, or different kinds of things altogether. If a system joins the records because the labels look related, it may create an answer nobody intended.

An ontology is an explicit description of concepts and their relationships. It lets a team say what counts as a component, how a component relates to an assembly, what an asset record describes, and where apparently similar terms must remain separate. That definition sounds modest. The work behind it is not. People need to decide which distinctions are useful, whose language is being represented, and how the model changes when a new case exposes its limits.

The model can outlive its first program

An early expert system might contain its domain assumptions inside the rules of one application. The next application would have to reconstruct them. Separating the subject model from the program made knowledge more reusable. A search tool, a configuration system, and an analysis service could refer to the same concepts while performing different tasks.

This is one reason Stanford’s Protégé project matters. It developed from tools for building specialist knowledge systems into a widely used environment for constructing and maintaining ontologies. Mark Musen’s history of the project follows that evolution and its use in biomedical knowledge resources, where definitions and relationships cannot be treated as incidental labels. (Musen, “The Protégé Project,” 2015)

Imagine a clinical classification used by researchers, care systems, and public-health reporting. A change to one concept can affect several different uses. It matters whether a term has been renamed, narrowed, replaced, or split. A shared model gives those applications something to coordinate around, but it also makes stewardship unavoidable. Someone must decide whether the change is warranted, record the reason, and examine its consequences elsewhere.

Formal does not mean complete

An ontology can express that one class is a kind of another, that a relationship connects particular types of things, or that a combination is inconsistent with the model. Those checks can be valuable. They do not guarantee that the model has chosen the right concepts, or that a record placed under a valid class is true.

The danger is especially clear when two organizations exchange information. They may agree on a label while disagreeing about its boundary. An “inspection” might mean a visual check in one system and a documented test in another. Mapping the two as equivalent makes integration easy and the resulting evidence ambiguous. The knowledge engineer has to inspect the work behind the words, not only the words themselves.

Nor does an ontology need to describe the entire world. A model for one decision may deliberately omit distinctions that another decision needs. A useful ontology is explicit about its purpose, scope, and revision process. Claiming universal completeness would make it harder to maintain and easier to misuse.

The 1990s turned the engineer’s attention toward such shared conceptual models. In the next decade, Web standards made the ambition wider: represent meaning in forms that could travel between systems and organizations, not merely between programs built by one team.