Ontology Integration: Reuse Master Data and Interfaces Instead of Rebuilding Systems

Context: Replenishment Assistant and Data Integration Concerns

An equipment company plans a replenishment assistant. The warehouse system manages inventory, the procurement system manages purchase orders, and product master data has been maintained for years. A proposal suggests loading all relevant data into a graph database first, then building an ontology around products. The warehouse manager raises three questions: inventory changes daily — who ensures the copy stays current? Where will future purchase orders be created? When numbers differ, which side wins? These questions must be resolved before choosing a database. The core principle: ontology should clarify what data means, not force a full data migration.

The Big Data Technology Standard Promotion Committee's guide (https://mp.weixin.qq.com/s?__biz=MzU0NzczNjAwMw==∣=2247527204&idx=1&sn=f3b35d82e49c41e4b140d992f643f3f8&scene=21#wechat_redirect) also states that existing systems can usually be reused; whether to copy data or build separate storage depends on query, update, and permission conditions.

Start with One Product, Don't Rush to Move the Whole Catalog

A purchaser asks: "Does Warehouse 1's 6204 bearing need replenishment?" First, three things must be clarified: which exact bearing, how many usable units remain in Warehouse 1, and how many are on order but not yet fully received. The purchase order shows "not fully received" — its validity and expected arrival date must be checked. Only after these numbers are clear can the replenishment quantity be calculated using demand and replenishment rules.

The warehouse system uses product code MAT00421; the procurement system uses P1087. Both are labeled "6204 bearing" but specifications and seal types must be verified. Packaging differences also matter: is it the same product counted in boxes vs. pieces, or are they managed as different products? Names alone cannot be merged.

The team checks existing master data and code mapping tables. Assuming confirmation that both codes map to the same product, a unified identifier SKU6204 already exists. This mapping is reused; original system codes stay unchanged.

Next, quantities: warehouse returns 120 pieces available stock; a procurement line shows 12 boxes remaining unfilled, each box 10 pieces. After confirming the line uses 10 pieces per box, conversion yields 120 pieces — but one figure means "usable in warehouse", the other "ordered but not received". They cannot be treated as the same number.

First confirm which product and which warehouse, then examine what each quantity represents. Existing mapping tables continue to serve; fill gaps only where missing.

The Model Says "Available Inventory" — Where Does the Program Actually Query?

Linking "Product" and "Warehouse" with an "Inventory" attribute produces a quick graph. But the purchaser wants to know how many are truly usable, not just a table count.

Assume the warehouse system already has an "Available Inventory Query" that accounts for allocations, freezes, etc., and returns unit and data timestamp. First, ask warehouse and procurement staff: can this number be used for replenishment analysis? If yes, call the existing interface — no need to fetch raw balances and let the assistant guess usability.

If the interface only returns book quantity, identify which allocations and statuses must be excluded, then add supplementary queries or calculations. Renaming a field "Available Inventory" does not change its content.

"How available inventory is calculated" must be confirmed by business users. The warehouse system provides records; developers encode the code mapping and query conditions so the returned number matches business needs.

For example, querying SKU6204, the integration program first finds its warehouse code MAT00421, adds the Warehouse 1 code, and queries. The returned quantity must include unit and data-as-of timestamp. For purchase orders, the procurement system's P1087 is used. Both refer to the same bearing; results are labeled "Available Inventory" and "Unfilled Purchase Quantity" with source record locations preserved.

Projects using RDF (subject-predicate-object) can reference W3C's R2RML mapping language (https://www.w3.org/TR/r2rml/). It allows generating RDF from relational databases or keeping data in place with virtual access via queries. The choice still requires planning for updates and permission checks. This is cited as an example, not a requirement for the replenishment project.

OPM (Object-Process Methodology) helps business users discuss "What changes when inventory is allocated?" After clarification, data and interfaces must still be verified to confirm where those changes are queryable.

Direct Query, Add Cache, or Replicate

Querying a few products vs. thousands may warrant different approaches. Within one project, some queries can be direct, others cached.

Call original interface or use authorized read-only view — When query scope is small, original system can handle load, and you prefer not to store another copy. Additional responsibilities: interface rate limits, timeouts, access permissions, and data-as-of timestamp.

Add cache for frequent queries — When the same query is repeated often and business tolerates some result latency. Additional responsibilities: when to refresh, how to detect stale results, prevent returning User A's restricted data to User B.

Sync partial data for query use — When batch analysis would impact original system, or historical snapshots are needed. Additional responsibilities: can subsequent inserts/updates/deletes be synced? What latency? How to reconcile?

Build index or graph storage — When confirmed existing queries cannot meet relationship traversal, search, or speed needs. Additional responsibilities: can it keep up with source changes? Does investment actually improve query performance?

For a few products in Warehouse 1, try the existing interface first. If queries are too slow or volume affects normal warehouse operations, then consider cache or replica. For large-scale analysis, don't insist on "no data movement" and force the operational database to run heavy queries repeatedly.

Microsoft's Cache-Aside pattern (https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside) warns that when source data changes, the cache may not update automatically — expiration and refresh must be managed. In the replenishment context, a cached result may be acceptable for trend viewing, but too stale for deciding today's replenishment quantity.

Even direct calls to the original system must check whether the backend reads from a replica. The data-as-of timestamp on each side must be determined together, and business must confirm acceptable latency.

Small time gaps can still cause double-counting. Example: a receipt just increased available inventory in the warehouse, but the procurement system hasn't yet reduced the unfilled quantity. Adding both numbers counts that batch twice. Reconcile with receipt records, or have the program check whether both sides have synchronized; if unclear, do not use the combined total for replenishment decisions.

Even if the query is correct now, another replenishment may occur between query and order submission. Final submission must still pass the original system's business checks — execution logic is discussed later.

If You Store a Copy, You Must Trace Back to the Original Record

Suppose the team decides to periodically sync inventory for batch filtering. Beyond quantity, retain: product and warehouse codes, source record reference, data-as-of timestamp, retrieval timestamp, and which version of the code mapping was used. Storing only "120 pieces" leaves no audit trail days later.

Critically distinguish "data as of when" from "when I retrieved it". Retrieving at 10:05 a dataset as of 10:00 must not be labeled "10:05 inventory". If the interface doesn't provide the data-as-of timestamp, record the gap explicitly — do not substitute retrieval time.

Assume an outbound shipment at 10:02 reduced inventory, but the replica hasn't updated. If historical inventory viewing is allowed, show the timestamp normally; if judging current replenishment, re-query — if unavailable, stop. Do not label stale data as "current inventory" just because the interface happened to be unavailable.

Replica permissions must also be checked. If the source system revokes a user's warehouse access, the assistant must not continue returning that data via cache. Retention periods and access rights for historical records need separate agreements.

Inventory adjustments and purchase order creation remain in the original systems, following their permissions and processes. This replica serves only query and analysis. If the original business record is wrong, the responsible person corrects it in the source system; if the mapping was wrong, fix the mapping and update affected replicas and indexes.

Don't let query convenience turn into both sides being writable with no one responsible for reconciliation.

Turn Integration Arrangements into an Assignable Table

Writing only "Product → Procurement System, Inventory → Warehouse System" leaves developers chasing people. Record the clarified details in a table.

Is it the same product? Reuse confirmed SKU6204, MAT00421, P1087 mapping. Record mapping version & applicability; return only user-authorized info. If mapping mismatch or maps to multiple products — do not merge; escalate to master data owner.

Is it the same warehouse? Verify both sides' "Warehouse 1" codes & actual scope; clarify how unfilled quantities are allocated to warehouses. Restrict queryable warehouses by user permissions. If warehouse mapping unclear or split quantities unknown — confirm with warehouse & procurement leads.

Warehouse 1 available inventory Call warehouse interface by product & warehouse codes; retain caliber, unit, source. Mark data timestamp; business confirms max acceptable latency; server checks warehouse permissions. If timeout, data too stale, or missing key status — pause related judgment; warehouse interface owner investigates.

Unfilled purchase orders Query procurement line details, validity status, target warehouse, unfilled qty, expected arrival date. Convert boxes↔pieces per doc/packaging basis; check permissions, data timestamp, and whether both sides' receipt updates are consistent. If missing conversion basis, expected date, or receipt mismatch — list issues for procurement lead.

In practice, fill in interface/view names, field locations, acceptable latency, update mechanism, and contact persons. Flag unresolved items for follow-up.

"Unfilled" must combine with document status. Cancelled or closed orders, even with unfilled quantities, cannot count as future supply. How valid status, returns, and partial receipts factor in must be confirmed by procurement lead and implemented in the query.

If existing query services already handle these, let the assistant call them directly. The ontology clarifies shared meanings across applications; if existing programs can query accordingly, keep using them.

Before Go-Live, Deliberately Break a Few Queries

Test with normal records, then with broken mappings, stale data, or interface failures. Below are expected behaviors — must be verified by actual runs.

Mapping confirmed, timestamp meets agreement, user authorized — Return Warehouse 1 inventory & unfilled purchase qty for same product, each labeled with meaning, unit, source, timestamp.

Same name, actually different spec — Do not merge inventory & purchase records; flag mapping conflict, retain audit entry.

Purchase order in boxes, no reliable conversion factor — Retain original quantity & unit; do not auto-convert to pieces for calculation.

One side's data significantly lagging beyond agreed threshold — Indicate which side needs re-query; do not issue current replenishment conclusion.

Receipt increased available inventory, unfilled qty not yet reduced — Verify receipt linkage & sync progress; if unclear, do not combine both quantities for replenishment decision.

Warehouse query timeout or partial paginated results — Tell user data incomplete; do not display as "zero inventory".

User only authorized for Warehouse 1 — Server enforces fetch & return scope; cache and replica must not leak other warehouse data.

During testing, within permission bounds, cross-check every returned figure against the original interface or record. Run multiple rounds at projected usage volumes — measure response time, errors, and whether the original system withstands load. One user querying correctly is not enough; concurrent usage must not slow warehouse operations.

Also in test environment, change a code mapping or simulate source field changes — verify caches, indexes, and queries update accordingly. Clarify who receives change notifications, who updates, who re-validates.

Once data retrieval is solid, replenishment rules and order workflows take over — each has its own checks; data integration cannot cover them all.

Summary

Returning to the warehouse manager's initial concerns, the solution should let him see: where each number comes from, how old it is, who to contact when sides disagree; order creation and inventory adjustments still follow original system processes.

Start with one bearing in Warehouse 1, query end-to-end, fill gaps as found. If existing interfaces suffice, integrate them first; only when a replica is truly needed, plan its updates and reconciliation. Future discrepancies will have clear ownership.

After data is retrieved, if the LLM suggests replenishing 100 units but the rule engine calculates differently — how to handle? The next article discusses division of labor among ontology reasoning, LLMs, and business calculation.

References

W3C, R2RML: RDB to RDF Mapping Language , Sections 1, 2, 4. Describes relational-to-RDF mapping and processor options for materialization or virtual access; does not guarantee specific product performance, update, or permission capabilities. Case and integration decisions are author-designed. URL: https://www.w3.org/TR/r2rml/

Microsoft Learn, Cache-Aside pattern , Problems and considerations. Explains cache expiration management and consistency limits with source data; latency, permission, and exception handling conventions in this example are author recommendations. URL: https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside