Standard Ontologies Aren't Business Schemas: How to Map Changing Terms to Stable Models

Standard Ontologies and Business Schemas Answer Different Questions

The article builds on a previous discussion of four change types in dynamic ontologies, focusing on the first type: the business model stays stable while mappings between external terms and standard concepts continuously update. Many projects fall into two extremes: copying large standard ontologies directly into the application schema, making queries and extraction difficult; or keeping only simple internal fields and enums, leading to synonym accumulation and integration debt.

Business Schema defines what the system stably processes; reference ontologies provide reusable standard concepts; term normalization connects continuously changing raw expressions to both.

The dynamic elements should be candidate matches, mapping records, and review states—not schema modifications triggered by every new term.

Three Engineering Objects with Distinct Responsibilities

The article references Dynamic Ontology in Practice , which advocates a small, stable schema for extraction results, large reference ontologies (e.g., NCIt, HGNC) as standard identifier and synonym catalogs, and a normalization layer to link them. The three objects are:

Business Schema – Answers: which business objects and relationships does the current system stably handle? Typical content: Equipment, Alarm, FaultType, WorkOrder, SparePart and their relations. Consumers: applications, queries, rules, Agents, interfaces.

Reference Ontology / Terminology Catalog – Answers: what standard concepts and identifiers exist in a domain? Typical content: URIs, codes, names, definitions, synonyms, hierarchical relations, versions. Consumers: normalization services, data governance, cross-system exchange.

Term Mapping – Answers: which standard or business concept might a given raw expression correspond to? Typical content: raw value, context, candidates, scores, method, status, evidence. Consumers: data pipelines, manual review, audit, model governance.

The business schema is the published structural contract for applications, not a replacement for the full business knowledge model (which may include processes, states, rules, responsibilities). Only objects, relations, and fields that current applications need to stably consume enter the business schema. Standard ontologies pursue domain coverage and interoperability; business schemas need stability, simplicity, and direct service to current tasks. Their scope, granularity, and evolution responsibilities differ.

For example, in a production-line fault handling scenario, the application may only need stable types like Equipment, Alarm, FaultType, WorkOrder, SparePart. An industry catalog may contain thousands of parts, failure modes, materials, and test methods, but they need not become first-class object types in the application. The existence of a standard concept does not decide business boundaries: whether a "fault" is an occurred fact, an algorithmic candidate, or a pending risk task is defined by real processes, states, and responsibility relations.

Stability Means Changes Must Not Break Downstream Contracts

Stability does not mean immutability. It encompasses four layers:

Identifier stability – Downstream-dependent object types, relation types, and field meanings cannot change without notice due to reference ontology updates.

Semantic stability – The same field cannot mean "device alarm" today and "confirmed fault" tomorrow.

Version stability – Any compatible or breaking change must form a new baseline; historical results must be interpretable under the version at that time.

Responsibility stability – Schema changes are decided by business model and platform governance processes, not triggered automatically by a similarity match.

Thus a stable schema acts as a long-term contract for applications. It can evolve deliberately but does not jitter with every input text, vendor code, or reference ontology update. Reference ontologies are not a "single true world model"; an enterprise may connect industry standards, vendor catalogs, regulatory classifications, and internal term libraries simultaneously, each serving different exchange and governance purposes, possibly describing the same object at different granularities. The normalization layer's job is not to force a single global truth but to record: in what context, based on which catalog and version, the current raw expression was interpreted as what.

Full Normalization Pipeline from a New Fault Code

Continuing the production-line fault example: a vendor device first reports:

Device model: X7
Raw fault code: X7-TempDrift
Raw description: Spindle temperature drifting above baseline
Observed component: Spindle assembly
Operating phase: High-speed machining

The enterprise business schema does not need a new X7TempDrift object type. The system first stores it as a raw alarm fact, then enters the term normalization pipeline:

Preserve raw evidence. Record vendor, device model, fault code, raw text, event time, source record location.

Constrain target type. The current match target is "FaultType", not device type, alarm level, or repair action.

Recall candidate concepts. Use standard codes, approved aliases, keyword/definition retrieval, and vector similarity from the specified terminology catalog to return candidates.

Apply context constraints. Use device type, component, operating phase, unit, and adjacent alarms to exclude seemingly similar but semantically different candidates.

Form mapping judgment. Based on candidate scores, gaps between candidates, source credibility, and business risk, decide: auto-accept, sample review, manual confirm, or leave unmapped.

Publish versioned record. Bind mapping result to business schema version, terminology catalog version, and mapping policy version for downstream queries and Agents.

If finally confirmed as the existing "Spindle Temperature Drift", the system adds a verified alias or code mapping—not a new business concept. Only when field evidence shows the fault has independent states, judgment rules, repair processes, or action constraints not expressible in the current model should a model change request be submitted.

Similarity Produces Candidates, Not Facts

Vector retrieval from reference catalogs is a practical candidate recall method, but the top-scoring result cannot be written directly as a confirmed mapping. Similarity measures proximity in the current representation space, not business correctness or probabilistic confidence. Inputs especially prone to "looks similar, actually wrong" include:

Short abbreviations like OT, PT, MS that map to multiple concepts without context.

Same fault name meaning different things on different device components.

Vendor descriptions mixing alarm cause, fault symptom, and repair suggestion.

Parent/child concepts similar but business rules allow only a specific granularity.

Old and new term names similar but applicable versions and effective times differ.

Therefore production-grade normalization combines multiple evidences:

Exact code match → Approved aliases → Lexical & definition retrieval → Type & source filtering → Vector candidate recall → Context re-ranking → Threshold & risk routing

Short codes suit exact matching and constrained catalogs; long texts benefit more from semantic retrieval; high-risk concepts require higher auto-accept thresholds. No single similarity threshold works for all terms, catalogs, and business risks.

A Mapping Result Must Be an Auditable Contract

Adding only normalized_uri and score to a business node suffices for a prototype but not for production governance. Mappings must retain candidates, context, versions, and confirmation process. A simplified normalization result structure:

{
  "mapping_id": "MAP-20260826-00142",
  "source": {
    "system": "vendor_x_gateway",
    "record_id": "ALARM-84731",
    "raw_value": "X7-TempDrift",
    "raw_text": "Spindle temperature drifting above baseline",
    "observed_at": "2026-08-26T10:35:12+08:00"
  },
  "context": {
    "equipment_type": "CNC_MACHINE",
    "component": "SPINDLE",
    "operating_phase": "HIGH_SPEED_MACHINING"
  },
  "target_type": "FaultType",
  "selected_concept": {
    "business_concept_id": "FAULT-SPINDLE-TEMP-DRIFT",
    "reference_uri": "<from actual reference catalog>",
    "reference_version": "<actual version>"
  },
  "decision": {
    "method": "alias+context+vector_rerank",
    "score": 0.91,
    "status": "confirmed",
    "reviewer": "maintenance_domain_owner",
    "confirmed_at": "2026-08-26T11:08:00+08:00"
  },
  "dependencies": {
    "business_schema_version": "fault-model-2.3.0",
    "mapping_policy_version": "normalization-policy-1.6.1"
  }
}

At least five non-negotiable boundaries: raw_value must be preserved; normalization cannot overwrite raw facts. reference_uri identifies the standard concept, not the device or alarm instance's business object ID. score only explains candidate ranking; it cannot alone prove mapping correctness. status must distinguish candidate, confirmed, rejected, deprecated, and pending arbitration.

Business schema, reference catalog, and mapping policy must all bind to concrete versions.

Mappings may also have applicability scopes and validity periods. For example, the same vendor code may change meaning across device firmware versions, so a single global alias without time boundaries cannot cover all historical records.

Summary

Standard ontologies, business schemas, and term mappings are not three alternative modeling approaches but three distinct engineering objects. Business schemas provide stable structure for applications; reference ontologies supply standard concepts and identifiers; the normalization layer manages the uncertainty between them by preserving raw evidence and producing revocable, reviewable, versioned connections.

Similarity retrieval helps discover candidates but cannot independently produce confirmed facts. A usable normalization result must simultaneously describe raw value, context, candidate basis, catalog version, mapping policy, and confirmation status.

Standards bring interoperability; business schemas provide stability; mapping contracts manage the uncertainty between them.

The next article will discuss why candidate mappings cannot rely solely on similarity scores, and how coverage, manual review, drift, and regression testing should form an operational closed loop.