Ontology-Driven Data Governance: Mapping Data Assets to Business Semantic Assets

Introduction: From Business Modeling to Asset Mapping

The previous three articles covered: (1) why ontology-driven governance must start with business scenarios, not table fields; (2) how to conduct business research and visual modeling to capture objects, processes, states, rules, data sources, and agent opportunities; (3) how to build a business semantic model organizing objects, relationships, processes, states, rules, metrics, data evidence, and action contracts. However, a semantic model alone is insufficient — it must connect to existing data assets to support real governance, semantic query, quality validation, and high-quality dataset construction. The core question becomes: Which data proves which business facts?

Data Assets Are Not Naturally Semantic Assets

Enterprises possess many data assets: database tables, fields, metrics, reports, datasets, interfaces, logs, documents, knowledge bases, model outputs. Yet these are organized from a system-implementation perspective (source system, data type, calculation logic, API response, storage location). They do not answer business-semantic questions:

Which business object does this data correspond to?

Which object state does it reflect?

Which business fact does it prove?

Which business rules constrain it?

Can it support a specific metric definition?

Can it be safely invoked by downstream services?

Without this mapping, data assets remain merely "managed data" rather than "data understandable by business and systems." Ontology-driven governance attaches existing assets to the business semantic model, returning data to its business context.

Mapping Is Not Field Explanation, But Business Fact Alignment

Traditional metadata governance provides field descriptions (e.g., customer_id: customer number, order_status: order status, create_time: creation time, overdue_days: overdue days). These are necessary but insufficient. Semantic mapping asks further: customer_id → which customer object? order_status → which state set of the order object? create_time → order creation, submission, or system ingestion time? overdue_days → what is the calculation start point?

Can this field serve as evidence for "overdue fact"?

Can it trigger risk alerts or business reminders?

Mapping places fields back into business objects, states, rules, and actions, turning "data structures" into "business semantic evidence."

Eight Categories of Data Assets to Map

Business system tables — core objects: customer, order, contract, case, device, ticket, transaction, strategy, risk event.

Fields — map to object attributes, states, time, amount, quantity, category, identifier, relationship keys.

Metrics — map to business object, statistical scope, time window, dimension, state condition, calculation rule, applicable scenario.

Documents — contracts, reports, case files, transcripts, plans, regulations, meeting minutes, retrospectives; key evidence for facts and rules.

Logs — operation, process, invocation, audit, device, model inference logs; support process tracing, accountability, behavior analysis.

Interfaces — not just data outlets; may represent business actions, query capabilities, validation capabilities, external data enrichment.

Model outputs — predictions, classifications, recognitions, scores, summaries, agent-generated results; must declare source, confidence, applicability boundaries, suitability as business judgment basis.

Human confirmation results — approvals by business, review, risk, expert personnel; critical feedback for high-quality datasets and rule iteration.

All assets must answer: Which business fact does it support?

Seven Mapping Relationships

1. Object Mapping

Map semantic object types to primary tables, extension tables, relation tables, state streams, behavior records, document objects, interface return objects. One business object often spans multiple tables.

Customer → customer_main, customer_profile, customer_risk_tags

Order → order_table, order_detail, order_state_stream

Device → device_ledger, sensor_data, maintenance_records

2. Attribute Mapping

Map object attributes to fields, document fragments, interface return items, or model extraction results; note source, type, update time, reliability, nullability.

3. State Mapping

Map business states to field values, process nodes, log events, or human confirmations. A state like "completed" may require multiple concurrent conditions:

Process node ended

Approval result = passed

Result document generated

Archival status = completed

4. Relationship Mapping

Map inter-object business relationships to foreign keys, join tables, document references, log correlations, graph relationships, or rule-derived links (e.g., customer-order via order table, case-material via case catalog, device-alert via time-series data and device ID).

5. Rule Mapping

Map business rules to validation conditions, metric thresholds, process constraints, risk rules, permission rules, invocation constraints. Key points:

Which data satisfying conditions means rule triggered.

Which data missing means rule undecidable.

Which data conflicts mean human confirmation needed.

6. Evidence Mapping (Core)

Map fields, documents, logs, interfaces, model outputs to business facts. Example: "Customer has overdue risk" requires multiple evidence types:

Repayment schedule

Actual repayment flow

Overdue days field

Collection records

Customer communication minutes

Risk scoring model output

Manual review conclusion

7. Service Action Mapping

Map future serviceable actions to interfaces, tools, process nodes, or pending tasks (e.g., query customer info, validate material completeness, generate risk description, initiate review, form alert suggestion). This step only identifies data, rules, and business nodes per action; semantic service publishing comes later.

Outputs of Mapping

Mapping yields business semantic assets, not a plain metadata catalog:

Business object data mapping — which tables, fields, documents, interfaces, logs support each object type.

Business fact evidence chain — which data jointly prove a fact; primary vs. auxiliary evidence; human confirmation requirements.

Metric caliber mapping — how metrics derive from objects, states, time windows, dimensions, calculation rules.

Semantic lineage — beyond technical lineage (source→target), explains what data represents in business semantics.

Serviceable data assets — which data can be queried, referenced, validated, explained, or wrapped as services.

High-quality dataset candidates — semantically mapped and evidence-validated data, ready for RAG, model evaluation, agent testing, business analysis.

Two Pitfalls to Avoid

1. Pursuing Full-Volume Mapping

Attempting to map all systems, tables, fields at once creates another massive metadata project. Better: prioritize assets that support the current business scenario's closed loop and value validation — core objects, key states, key rules, key metrics, key evidence — then expand incrementally.

2. Mapping Only Structured Data

Critical business facts often reside in documents, logs, images, audio/video, human confirmations, model outputs, external data. Ignoring them leaves semantic assets inherently incomplete. In intelligent applications, document fragments, log records, model outputs, and human feedback are vital for judgment, explanation, and retrospective.

Relationship with Traditional Metadata Governance

This step does not negate metadata governance. Metadata governance provides visibility, manageability, traceability of data assets. Ontology-driven mapping adds a business semantic layer on top:

Metadata governance answers: What is this data? Where from? Where to?

Business semantic mapping answers: What business fact does this data represent? What judgment can it support? Who can invoke it?

The two are complementary, not substitutive. Without metadata governance, semantic mapping lacks asset foundation; without semantic mapping, metadata governance struggles to serve business judgment, high-quality dataset construction, and intelligent applications.

Summary & Next Step

Ontology-driven data governance's third step maps tables, fields, metrics, documents, logs, interfaces, model outputs, and human confirmations to the business semantic model, answering "Which data proves which business facts?" Once resolved, data becomes queryable, verifiable, traceable, explainable, and invocable business semantic assets. The next article will cover publishing these semantic assets as Agent-usable semantic services.