Improving Supply Chain Visibility with Shared Ontological Terms

In short: supply chain partners each run their own ERP, WMS or TMS with their own names for the same things — a shipment, a batch, a quality incident. A shared ontology layer gives every partner a common, machine-readable vocabulary to map their own data against, without forcing anyone to rebuild their system.

A retailer calls it a "shipment." The warehouse that packed it calls it an "outbound consignment." The carrier that moved it calls it a "load." All three records describe the exact same physical event, but nothing in any of the three systems says so. Multiply that by every entity a supply chain tracks — batches, quality incidents, inventory counts, delivery exceptions — and the result is a network of partners who can each see their own slice clearly and almost nothing about anyone else's.

The usual fix is a point-to-point integration: build a custom mapping between Partner A's fields and Partner B's fields, then do it again for every other pair of partners who need to exchange data. That approach scales badly, because the number of mappings grows with the square of the number of partners, and every new partner means renegotiating field definitions from scratch. A shared ontology layer replaces the pairwise mappings with a single, common vocabulary that every partner maps to once. Building that kind of shared platform — the software that lets every partner publish and consume data against one common model instead of a tangle of bilateral integrations — is the kind of system-level engineering YuSMP Group's SaaS platform engineering team builds for clients who need partner data to interoperate without forcing anyone to replace what they already run.

Why the Same Shipment Looks Different in Every System

Every system in a supply chain was built to solve one company's problem, not the network's problem. A warehouse management system optimizes for picking and packing, so it models a "consignment" around pallet locations and pick lists. A transportation management system optimizes for routing and billing, so it models a "load" around stops, weight and freight class. A retailer's inventory system optimizes for shelf availability, so it models an "incoming shipment" around expected arrival date and purchase order number. All three are correct descriptions of the same underlying event, written in three incompatible schemas.

This divergence is not a data quality problem that better validation would fix — the records are each internally consistent and accurate for their own system. It is a semantic problem: no shared definition exists for what a "shipment" is across the three systems, so there is nothing to validate against in the first place. Fixing it requires adding a layer above the individual schemas, not cleaning up the schemas themselves.

What a Shared Ontology Layer Actually Adds

A shared ontology layer defines a small set of classes — Shipment, Batch, Quality Incident, Inventory Position — with formal properties and relationships that do not belong to any single partner's system. It is not a replacement for the warehouse system, the carrier's TMS, or the retailer's inventory platform. It is a common target that each of those systems maps to, the same way several regional electrical outlets can all connect to one universal adapter without any of them changing their own socket.

Mid-level ontologies like the Common Core Ontologies are built for exactly this role: general enough to apply across industries and systems, specific enough to carry real structure — a Shipment has an origin, a destination, a set of contained items, and a status, each formally defined so a query can reason over them rather than just display them as text.

How Does Ontology Mapping Work Across Partner Systems?

Mapping works by connecting each partner's local field to the shared class it represents, not by changing the partner's field. The warehouse's "consignment ID" maps to the shared Shipment class's identifier property. The carrier's "load number" maps to the same Shipment class, just through a different local field name. The retailer's "incoming shipment" maps there too. None of the three systems is touched; what exists afterward is a translation table between each local schema and the one shared vocabulary.

Once that mapping exists for all three partners, a query can ask "where is Shipment #4471 right now, and has it had a quality incident at any stage?" and get an answer that spans systems that were never designed to talk to each other, because the question is phrased in terms of the shared classes rather than any one partner's internal fields.

A Practical Example: Tracking a Shipment Across Three Partners

Consider a shipment of refrigerated components moving from a manufacturer's warehouse, through a third-party carrier, to a retailer's distribution center. The warehouse system records a "consignment" with a pack date and a batch code. The carrier's TMS records a "load" with a pickup time, a temperature log, and a delivery confirmation. The retailer's inventory system records an "incoming shipment" with an expected arrival window and a receiving inspection result.

Mapped to a shared ontology, the pack date, pickup time and delivery confirmation all become properties of one Shipment instance rather than three disconnected records. The batch code links to a Batch instance that carries its own quality attributes. The carrier's temperature log and the retailer's receiving inspection both attach to that same Shipment as Quality Incident candidates if a threshold is crossed. A single query — "show every shipment where cold-chain temperature exceeded tolerance between pack and receipt" — can now be answered across all three partners' data without anyone exporting a spreadsheet by hand.

Where Supply Chain Visibility Projects Go Wrong

The most common mistake is trying to get every partner to adopt the same schema instead of mapping each partner's existing schema to a shared layer. Partners have no incentive to rebuild systems that work fine for their own operations just to satisfy one counterparty's integration project, and pushing for schema unification usually stalls the whole initiative. Mapping to a shared vocabulary asks much less of each partner and gets adoption faster.

The second mistake is skipping versioning on the shared vocabulary itself. As more partners join and new entity types get added — a new Quality Incident subtype, a new Inventory Position attribute — older mappings can silently break if the shared classes change underneath them without a version boundary. Treating the shared ontology like any other piece of shared infrastructure, with versioned releases and backward-compatible changes where possible, keeps a growing partner network from becoming its own source of integration failures.

Frequently Asked Questions

Does this mean all our partners need to adopt the same software?

No. A shared ontology layer is a mapping target, not a replacement for anyone's ERP, WMS or TMS. Each partner keeps their own system and their own schema; what changes is that their shipment, batch and incident fields each get mapped to the same set of common classes, so the systems can be compared and queried without any partner migrating platforms.

How is this different from EDI standards we already use?

EDI standards define fixed message formats for specific transactions, such as an advance shipping notice or a purchase order. An ontology defines the underlying classes and relationships those messages refer to, independent of any particular message format. The two are complementary: EDI moves the data between partners, while the ontology gives every partner the same definitions for what the fields in that data actually mean.

Do we need to model the entire supply chain before we see value?

No. Most teams start with a narrow slice, such as mapping shipment and quality incident data between two partners, and expand from there. A shared ontology layer built around a small number of entities that already matter operationally delivers value immediately, and new partners or data types get added as mapping targets without redesigning what already works.

Who maintains the shared ontology once multiple partners rely on it?

Typically the party coordinating the integration — often the hub partner in a hub-and-spoke supply chain, or a neutral platform layer all partners connect through — owns the shared vocabulary and its versioning. Individual partners maintain their own local mappings from their system to the shared classes, but the classes themselves need a single owner so the vocabulary does not fragment.

Can this work if a partner refuses to share their internal data model?

Yes, because the ontology only requires a partner to expose the mapping from their own fields to the shared classes, not their internal schema itself. A carrier can publish that their "consignment ID" maps to the shared Shipment class without disclosing anything else about how their system is built, which keeps the integration workable even when partners are reluctant to open up their internals.

Does this require real-time integration, or can it start with batch data?

It can start with batch data. The ontology defines what the data means, not how fast it moves. Many teams begin by mapping nightly export files from each partner system to the shared classes, proving the model works, and only add real-time or near-real-time feeds once the mapping itself is stable and trusted.

For a more formal treatment of ontology interoperability at industrial scale, see Ontology Interoperability: A Comprehensive Framework for Industrial-Scale Applications.