Dynamic Ontology: Four Change Types That Must Not Share One Auto-Update Mechanism

The article opens by observing that recent papers and articles use the term "dynamic ontology" to describe very different phenomena: medical terminology matching, ontology version evolution, real-time industrial equipment state in semantic graphs, and runtime semantic negotiation among agents. Although all use "dynamic" and "ontology," the object that actually changes differs in each case. Conflating these changes in engineering leads to dangerous practices such as treating a new fault code as a model change, writing real-time sensor data into the semantic baseline, solidifying a one-off agent negotiation result into an enterprise standard, or allowing an LLM to modify a published ontology directly.

Dynamic ontology does not mean the model can change at any time; rather, on a stable business semantic and governance baseline, terminology mapping, model evolution, runtime state, and agent negotiation each change under their own controlled lifecycles.

The author proposes a four-fold classification (not a standard from the cited works but an engineering synthesis) and uses a production-line fault-handling agent as a running example. After the system goes live, four concurrent changes may occur:

A new supplier's equipment reports a local fault code X7-TempDrift that must be mapped to the existing "spindle temperature drift" fault type.

The factory introduces a new equipment type, requiring new object types, states, and fault relationships in the equipment model.

Equipment on line 3 continuously updates its temperature, speed, current work order, and repair status.

The lead repair agent temporarily negotiates with scheduling, spare-parts, and personnel agents to compose a minimally disruptive remediation plan.

These correspond respectively to terminology mapping, model evolution, runtime state, and agent negotiation (runtime semantic negotiation). They may coexist on one platform but cannot share a single change mechanism.

A summary comparison captures the essence:

Terminology Mapping

Object That Actually Changes: Raw values, candidate concepts, standard URIs, candidate scores

Must Remain Stable: Business objects, attributes, relationship contracts

Primary Owner: Data, terminology, and business owners

Typical Time Scale: Request-level or batch-level

Model Evolution

Object That Actually Changes: Object types, relationships, states, constraints, action semantics

Must Remain Stable: Published baselines and historical evidence

Primary Owner: Business model owners and platform governance team

Typical Time Scale: Release-level

Runtime State

Object That Actually Changes: Object instances, states, events, observations, freshness

Must Remain Stable: State definitions, source authority, fact boundaries

Primary Owner: Source systems, data platform, object runtime team

Typical Time Scale: Event-level

Agent Negotiation

Object That Actually Changes: Intents, candidate capabilities, composite plans, temporary authorization scopes

Must Remain Stable: Security policies, action contracts, transaction bottom lines

Primary Owner: Agent Runtime, security, and business owners

Typical Time Scale: Task-level

The comparison forces the team to ask: what exactly is changing right now — a mapping, the model, a business fact, or a temporary collaboration?

First Dynamic: Terminology Mapping Changes, Not the Business Schema

Dynamic Ontology in Practice advocates a pragmatic layering: a small, stable business schema receives extraction results, while large reference ontologies (NCIt, HGNC, etc.) serve as standard identifier, definition, and synonym catalogs. New textual expressions do not immediately remodel the business graph; instead, raw values are first matched to reference terms.

In the production-line scenario, the enterprise has already defined stable objects: Equipment, Alarm, FaultType, WorkOrder. When a supplier reports X7-TempDrift, the system can use code tables, vendor manuals, synonyms, and vector similarity to propose it as a candidate mapping for "spindle temperature drift."

Each candidate mapping record must retain at least:

Original fault code and raw text

Candidate standard concept and URI

Source terminology library and its version

Matching method, score, and threshold

Status: confirmed, pending review, or rejected

Confirmer, timestamp, and applicable scope

The article notes that "coverage rate" — the proportion of input categories for which the terminology catalog finds high-scoring candidates — helps detect new terms, abbreviations, and input distribution drift. High coverage only means a similar candidate was found, not that the mapping is semantically correct.

Therefore, this dynamic mechanism changes mapping records and candidate knowledge, not the business schema. When many new terms persistently cannot be accommodated by existing business concepts, they become evidence for model evolution but must not bypass business review to auto-promote as new concepts.

Second Dynamic: Models Can Evolve, Published Baselines Must Not Be Overwritten

When the factory truly introduces a new equipment type with distinct states, failure modes, and repair requirements, the ontology model itself changes.

Guidelines for a Dynamic Ontology (KMIS 2011, arXiv 2012) attempts to merge ontology evolution and version management. Its VersionGraph distinguishes schema operations from instance operations, recording author, timestamp, change context, operation set, and predecessor version, forming a new version after validation. While the paper's specific technical design (embedding version metadata in the ontology, linear predecessor chains, Jena event mechanism, Wine Ontology examples) need not be copied verbatim, its enduring judgment remains valid:

Version management cannot be retrofitted after the model is already chaotic; every ontology change should start from a candidate change set, undergo semantic analysis, impact assessment, dependency propagation, and business validation, then form a new immutable baseline.

For the production-line fault model, a candidate change set must at least explain:

Why a new equipment or fault type is added

Which objects, relationships, states, and constraints are modified

Which terminology mappings, data adapters, rules, and object projections need adjustment

Which queries, agent contexts, and action contracts are affected

Whether the change is compatible or breaking

Who approves, and what real data and competency questions are used for regression validation

The "dynamic" in ontology evolution means the model can continuously publish new baselines, not that the stable production version can be overwritten in place.

Third Dynamic: Equipment State Changes, Ontology Definitions Do Not

Building Ontology-Driven Intelligence for Industrial AI Agents layers industrial semantic systems into data flow, data intelligence, and Agentic AI layers. UNS and MQTT handle data flow across PLC, SCADA, MES, ERP, CMMS, QMS; the semantic layer defines what equipment, materials, personnel, work orders, faults, and quality results mean.

This layering highlights a critical boundary: real-time data streams are not real-time ontology models.

The ontology model can define:

Equipment has running, abnormal, shutdown, and maintenance states

Alarms may indicate certain faults

Faults affect production work orders and line capacity

Repair operations require qualified personnel

Shutdown, scheduling, and spare-parts withdrawal belong to distinct action types

But "Equipment A on line 3 at 10:35 has temperature 92°C, is executing work order WO-1847, last maintenance was 847 hours ago" is a concrete object's runtime state. It should be continuously updated by source systems, event streams, and object projections — not generate a new ontology model version on every change.

An object runtime can organize these current facts under unified semantics, but it is not a replacement for source systems. A state projection must at least indicate:

Concrete object identity and associated objects

Observation time, event time, and current freshness

Source system, source record, and data version

Mapping, semantic model, and rule versions used

Fact conflicts, latency, and missing status

Whether trace-back reconstruction and reconciliation are possible

Thus, the value of industrial ontology is not turning every sensor reading into an ontology change, but enabling agents to understand continuously changing equipment facts under stable business meanings.

Fourth Dynamic: Agents Can Temporarily Negotiate, Not Invent Execution Permissions

Liquid Interfaces pushes "dynamic" toward radical runtime collaboration. It does not require participants to share a complete global ontology and fixed interfaces at design time; instead, agents discover capabilities, clarify semantics, compose partial quotes, and generate temporary collaboration structures around the current intent.

The paper's core message lifecycle is:

intent → offer → accept / reject → execute → complete → dissolve

This approach benefits open, heterogeneous, fast-changing multi-agent ecosystems. For example, the lead repair agent can express "arrange equipment A maintenance within 4 hours without affecting today's core delivery." Scheduling, spare-parts, and personnel agents each offer adjustable slots, available parts, and qualified staff, then compose candidate plans.

But "semantics negotiated" does not equal "executable." In enterprise systems, the negotiation result must still pass:

Equipment current state and data freshness re-verification

Operator qualification, work permit, and safety isolation checks

Scheduling rules, delivery constraints, and risk policy validation

Human confirmation or approval for high-risk operations

Explicit action contracts, idempotency keys, expected state versions, and failure handling

Source business system transaction execution and result receipt

A safer path is:

Intent expression → Capability discovery → Temporary semantic negotiation → Candidate execution plan → Deterministic policy & action contract validation → Controlled execution → Receipt & audit → Dissolve temporary negotiation context

Temporary interfaces can dissolve, but executed business actions, authorization decisions, semantic versions used, and execution evidence must not disappear with them. Hence, dynamic negotiation fits better as an adaptation and planning mechanism before deterministic execution, not as a replacement for APIs, MCP, permission gateways, and business transactions.

Summary

"Dynamic ontology" is not a single capability that can be handed to an engine.

When new expressions appear, terminology mapping changes.

When business definitions change, the model baseline changes.

When concrete objects continuously update, runtime state changes.

When participants in open environments temporarily compose, agent negotiation context changes.

They can provide evidence to each other, yet each has distinct authority sources, time scales, and risk boundaries.

Only by first identifying what exactly is changing can we decide who confirms, which system it enters, which version is used, and how it is accepted.

The next article will discuss why the four change types cannot share one "auto-update" button and how enterprises can build a traceable change-routing mechanism.