Ontologies: Describing Concepts and Relationships Formally

What Are Ontologies in Computer Science?

For a conceptual model, domain experts must determine which kinds of things belong to the domain under consideration and which relationships hold between them. Field names alone are insufficient: the permitted inferences from the statements also need a defined meaning.

In a production context, relevant classes might include “Product,” “Material batch,” “Task,” “Measurement,” and “SOP version.” An ontology can additionally express that every material batch is a batch, that a task uses material or produces an intermediate product, and that a measurement has a value and a unit. Such statements form a shared vocabulary that does not depend solely on field names or the logic of an individual application.

The W3C OWL 2 Primer describes an ontology as a set of precise statements about a particular part of the world. OWL 2 provides classes, properties, individuals, and data values for this purpose. The meaning of the statements is formally defined, enabling suitable programs to check consistency and infer implicit information.^[1]

An ontology is therefore neither merely a glossary nor automatically a complete representation of reality. It is a deliberately developed model. Its quality depends on whether concepts are chosen correctly in domain terms, boundaries are set transparently, and changes are maintained in a controlled manner.

Example: Connecting Concepts Along a Batch Process

A simplified, illustrative conceptual model specifies that every material batch is a batch. The specific object M-204 is stated to be a material batch. The subclass relationship therefore also entails that M-204 is a batch. A query for batches can account for this inferred membership if the corresponding inferences are evaluated.

The converse is not permitted: if P-31 is described only as a batch, it does not follow that P-31 is a material batch. Nor can release be inferred from membership in the Batch class. That would require further statements and, where appropriate, suitable axioms.

Suppose the model also declares Material batch and Equipment to be disjoint classes. If M-204 is assigned to both classes, these statements contradict one another under the specified axioms. The contradiction shows that the data or modeling need review; it does not decide which assignment correctly reflects operational reality.

Other axioms can describe inverse properties or excluded class memberships, for example. Such a definition must fit the domain: whether a relationship is transitive cannot be inferred from its everyday name alone.

The example describes the role of formal statements: they make certain inferences possible and others impermissible. Neither the actual identity of M-204 nor its release is established in this way without appropriate data capture and substantive review.

A Missing Statement Does Not Automatically Mean “False”

OWL generally operates under the open-world assumption. If information is absent, it is not automatically considered false; it may simply be unknown.^[1] This distinguishes ontological reasoning from many database and business rules that assume a closed body of data.

For example, if the statement that batch M-204 is released is missing, an OWL reasoner cannot infer from that alone that the batch is on hold. Its release status may not yet have been recorded. For an operational process, precisely this distinction can be crucial: “not released,” “release unknown,” and “release not required” are three different states.

Different names do not automatically have to denote different things either. Two identifiers can refer to the same real object unless their difference is explicitly established. Conversely, similar-sounding terms must not be merged without review. Identity therefore needs its own domain rules and stable identifiers.

The open world is not a defect of the ontology but part of its semantics. It is suitable for distributed knowledge that can be extended. Operational checks that depend on completeness additionally require validation or application logic that specifies exactly which information must be present in a particular situation.

Reasoning Is Not a Required-Field Check

A domain or range statement in OWL can infer class membership from a relationship. It does not simply work like an input form that rejects an object previously classified differently. Further axioms can produce a contradiction; that is a different question from whether a required field is present.[1]

SHACL can check a specific RDF dataset against defined conditions.[4] The application must additionally determine the consequence of a finding. Neither a logical inference nor a structural report grants operational approval by itself.

The Basic Building Blocks

Ontologies are built on a few basic elements that together form an expressible model:

Classes are not folders in which records are physically stored. They describe sets of individuals with a shared meaning. An individual can belong to several classes: a specific batch can simultaneously be a “Material batch,” an “Object on hold,” and “Inventory requiring testing.” The memberships do not automatically exclude one another.

Properties connect individuals to one another or assign values to them. OWL distinguishes object properties and data properties, among others. “Task uses batch” connects two individuals. “Measurement has numeric value 7.2” connects an individual to a data value.

RDF Schema already provides terms for classes, subclasses, properties, domains, and ranges.^[3] OWL 2 extends the expressive possibilities with equivalence, disjointness, property characteristics, complex class descriptions, and cardinalities, among other features.^[2] How much formalization is useful depends on the use case. A small, understandable model can be more reliable than an extensive ontology whose statements no one can confidently assess anymore.

Ontology, Taxonomy, Data Model, and Knowledge Graph

Several kinds of models organize information but serve different purposes. A taxonomy typically structures concepts hierarchically. It might place “Raw material,” “Intermediate product,” and “Finished product” under the broader concept “Material object.” This supports navigation and classification but does not yet describe all domain relationships.

A data model defines the structures an application stores: tables, fields, data types, keys, and technical dependencies. It can specify precisely that a batch_id field is required. Without additional semantics, whether a batch means the same thing as a lot in domain terms, when it counts as released, or which role may grant release often remains hidden in program code, documentation, or human knowledge.

An ontology focuses on meaning. Classes categorize things, properties describe relationships or values, and axioms formulate general statements about the domain. It can state that every released material batch is a tested material batch or that “uses material” is the inverse of “is used in.” Such statements can be used independently of a specific screen or table structure.

Knowledge Graphs connect statements about entities: task A-17 uses batch M-204; measurement P-91 belongs to this task; person R-8 reviewed it. An ontology can formally describe the concepts and relationships used. It may itself also contain statements about individual objects. The distinction therefore does not strictly separate instance data from concepts: here the focus is on formal meaning, whereas a knowledge graph focuses on connected knowledge and its use.

Ontologies Need Domain Responsibility and Versions

A reliable ontology does not emerge from collecting as many terms as possible. It starts with specific questions: Which objects must be unambiguously recognized across system boundaries? Which relationships are needed for reviews or analyses? Where do different names currently cause misunderstandings?

Domain experts and technical modelers must define concepts together. Understandable definitions, examples, and counterexamples are helpful for every class and property. Test data show whether the intended inferences actually arise and whether unintended statements become possible. Reasoners support consistency checks but do not replace substantive approval.

Changing a concept can affect queries, integrations, and rules. Ontologies therefore need versioning, reasons for changes, and a migration strategy. It should be possible to add new concepts without silently reinterpreting the meaning of historical data. Obsolete concepts can be marked as such and linked to successors in a controlled manner.

Operational knowledge models go a step further: they connect concepts and relationships to validity, process states, and specific points of effect during work. An ontology can provide a formal semantic building block for this purpose. Operational use must additionally define when particular knowledge is used for a particular task.

What Ontologies Do Not Provide

An ontology does not make false input data true. It can reveal contradictions or infer additional statements if the necessary axioms are present. Whether a measurement value was recorded correctly, a sample was representative, or a person actually performed a task cannot be decided from the conceptual model alone.

A shared vocabulary does not automatically produce functioning integration. Identifiers must be mapped, formats transferred, versions aligned, and responsibilities governed. Semantic interoperability requires the participating systems to use exchanged information with the same domain meaning. An ontology can contribute to this, but does not resolve every integration task.

Excessive formalization can also create unnecessary complexity. Every additional rule increases not only expressiveness but also the need for testing, maintenance, and explanation. For operational systems, it is therefore crucial to introduce only axioms whose domain meaning is understood and whose effects have been tested.

Finally, every ontology represents only one perspective on a bounded domain. Concepts can be used differently depending on the market, product, process, or regulatory context. These boundaries should be documented rather than assuming universal validity.

A Counterexample Tests the Boundary of the Axiom

A counterexample shows whether the model draws the intended boundary even where an apparently plausible inference would be impermissible.

A useful ontology makes such distinctions testable. Its axioms therefore need understandable examples and counterexamples, along with controlled maintenance. Formal precision can then help identify unintended inferences before applications build on them.