Ontology-Driven Enterprise Metric Federation: From TBox to Unified Reasoning

Core Philosophy

The approach rejects stitching raw SQL into a single wide table. Instead it uses ontology (TBox) for unified modeling → multi-source federated access → indicator assetization → unified reasoning layer → permissions and distribution . Metrics become computable assets on the ontology; source systems only supply facts (ABox), while the ontology defines semantics, lineage, and calculation rules.

1. Building the Operational TBox Skeleton

Top-Level Core Entities

Business Subjects : group, company, factory, workshop, project, customer, supplier

Time Dimensions : day/week/month/quarter/year, settlement cycles, production batch cycles

Business Domain Entities : order, procurement, inventory, work order, quality record, logistics batch, financial voucher, cost center

Metric Asset Entities (key):

Raw Collection Metrics : direct readings from source systems

Derived Metrics : computed via lineage, aggregation, formulas, time-series reasoning

Baselines / Targets : budgets, plans, benchmarks, alert thresholds

Relationship Links (Foundation for path Navigation)

Company → owns → Factory

Factory → produces → WorkOrder

WorkOrder → consumes → MaterialBatch

WorkOrder → links → QualityRecord

WorkOrder → belongsToCostCenter → FinancialVoucher

Metric → sourcedFrom → DataSourceInstance

DerivedMetric → dependsOn → RawMetric / OtherDerivedMetric

Key point: Do not force all source table structures into the ontology. Source systems are "fact providers"; the ontology is the "semantic view layer." The same business object (e.g., work order) exists in ERP, MES, and finance — alignment uses business key + business code , not database primary keys.

2. Multi-Source Ingestion Layer: Feeding ABox Facts

Each business system gets a "data source adapter" with three mixed modes:

1) Real-Time Push (Event)

ERP order placement, MES work reporting, inventory outbound → MQ / Webhook / CDC → adapter → write to ontology fact store (Memgraph + MySQL), tagged with sourceSystem, sourceTable, businessCode, collectionTime. Suits high-frequency operational actions.

2) Scheduled Pull (Batch Snapshot)

Financial ledger, budgets, monthly costs, settlement data are period-closed. Scheduled jobs pull periodic snapshots from APIs/views/databases to refresh "period facts" in the ontology, avoiding uncommitted data in metric calculations.

3) Federated Query (No Landing)

Cold data, large history tables, external systems that shouldn't be migrated use federated operators: when reasoning traverses that link, dynamically call source APIs/queries, return fact sets to the chained DSL pipeline ( path.PASS.filter.sum). Good for occasional drill-back and historical benchmarking, not high-frequency dashboards.

Every fact must carry metadata tags: source: which system (SAP / Yonyou / Kingdee / MES / WMS / data warehouse) businessKey: global business code (work order number, purchase order number) dataScope: time window, organizational scope confidence: data trustworthiness (closed? provisional estimate?)

Pitfall: Different systems use the same word for different things. Example: "Cost" — MES means manufacturing cost, finance means full absorption cost, procurement means landed cost. The TBox must define a "CostType" enum; never mix them directly.

3. Unified Metric Modeling: Metrics as Ontology Entities

Unlike traditional warehouses where a metric is a SQL snippet in a BI dashboard, here a metric is an ontology entity with identity, dependencies, permissions, and invokable by reasoning .

Each metric entity contains at least:

Business Identity : metric code, name, operational domain (revenue, gross margin, unit manufacturing cost, inventory turnover, order fulfillment rate)

Computation Contract : binds a "chained reasoning path" (OntoL DSL), can reference param for time window, org filter, version

Dependency Graph : which raw facts and upstream derived metrics this metric depends on; compile-time DAG generation enables impact analysis and circular dependency detection

Versioning & Effective Strategy : logic changes bump version; monthly reports and KPIs use fixed versions, real-time dashboards use latest

Permission Tags : org-level, field/metric-level; finance metrics hidden from production roles, group metrics hidden from branch plants

Two Metric Types

Atomic Metrics : direct mapping to source facts, minimal chaining; e.g., "Daily Inbound Quantity" — adapter registers source reading as ontology fact

Composite Operational Metrics : rely on main reasoning chain (entity graph path) + sub-chains ( PASS) for cross-domain aggregation

Example DSL idea:

param(period)
.path(Company→Factory→WorkOrder→MaterialConsumptionRecord)
.PASS(Record.settlementPeriod Overlaps param(period))
.filter(Record.costType == "FullCost")
.sum(Record.amount)

This chain is not hardcoded to one system; ontology graph navigation fetches facts across domains and aggregates per operational caliber.

4. Unified Computation Engine: One Reasoning Layer for All Metrics

Compile Time : scan metric DSL, parse path links, PASS temporal judgments, aggregation operators; identify dependent entities and data sources; distinguish pre-computable cacheable metrics from those requiring real-time federated fetch.

Runtime :

Pre-computation (Materialization) : period-closed metrics (monthly gross margin, quarterly turnover) run reasoning ahead, results land in metric cache entities; dashboards query in seconds.

Instant Reasoning : real-time operational dashboards, ad-hoc exploration, self-service querying — dynamic graph traversal + federated fetch.

Transactional Write-Back : if metric results must write back to KPIs, alerts, plan adjustments, use the "behavior function pack + Action" system; reasoning outcomes trigger behavioral write-backs.

Caliber Lock : same metric code = single company-wide calculation chain. No "finance calculates once, production calculates once, leadership dashboard another caliber." If multiple calibers needed, create separate metric versions/branches (e.g., "KPI Caliber Gross Margin" vs "Management Caliber Gross Margin").

5. Unified Permissions, Querying & Distribution

Metric federation ≠ everyone accesses the full operational graph:

Path Permissions : DAG compile-time pre-check; if any segment entity/metric lacks permission, entire metric returns masked or desensitized.

Unified Query Entry : intelligent query layer translates natural language into OntoL chained queries, not per-system SQL; unified param schema, time filter, org filter.

Multi-Endpoint Distribution : same metric ontology exposes multiple views: executive dashboards, management reports, finance system write-back, MCP Skill (for Agent auto-fetching operational metrics), exportable dashboard packs.

6. Reference Layered Architecture

Business Source Layer
ERP / MES / WMS / Finance / IoT / External Supply Chain
  ↓ Adapters (CDC / API / Scheduled Pull / Event Push)
Ontology Fact Layer (ABox)
  Unified Business Entities, Data Source Tags, Global Business Key Alignment
  ↓ TBox Operational Model + DSL Reasoning Engine
Metric Asset Layer
  Atomic Metrics, Derived Composite Operational Metrics, Budget Baselines, Alert Rules
  ↓
Unified Service Gateway
  Metric Query API, Intelligent Query, Operational Dashboards, Behavioral Write-Back, Agent Invocation

7. Comparison with Traditional Approaches

Traditional Data Warehouse : pull → cleanse → wide table → SQL metrics; fixed model, caliber change requires full ETL rerun, high cross-system alignment cost.

Palantir Foundry : ontology + Function code packs; multi-source facts into ontology, complex operational metrics pushed into code function orchestration.

OntoL Approach : ontology graph as semantic foundation, chained declarative DSL for cross-domain reasoning; metrics themselves are assets — shareable, versionable, triggerable for write-back; complex boundaries can plug external Python / MCP hooks as fallback.

8. Three Classic Pitfalls

Forced Unified Primary Keys : don't use database IDs for cross-system alignment; use "business code + business domain + time version" for entity matching, allowing "one business entity, multiple source fact replicas."

Boiling the Ocean : don't migrate all operational metrics at once; start with "Core Operational Metric Set": revenue, gross margin, fulfillment, inventory turnover, unit manufacturing cost. Validate path alignment, caliber governance, caching strategy, then expand domains.

Confusing "Source Caliber" with "Operational Management Caliber" : source data retains raw facts untouched; operational metrics are "ontology-layer views re-aggregated per management rules," with full traceability back to each source system.

9. Minimal Implementation Sequence

Define Operational Domain TBox : org, period, order, production, procurement, finance core entities & relations; establish global business code standards.

Adapter Ingestion : pick 2–3 core systems (e.g., ERP + MES + Finance) for ingestion, feed facts into ontology.

First Batch Metric Assets : select 5–10 high-frequency operational metrics, write DSL reasoning chains, close the loop "source fact → ontology → metric → dashboard."

Dependency & Version Governance : version metric packs, chain fragments, behavior function packs; establish metric change impact analysis.

Scale Out : onboard remaining systems, build unified operational metric portal + intelligent query entry.