Building Business Semantic Models for Ontology-Driven Data Governance

This article continues a series on ontology-driven data governance. The previous article covered step one: identifying business objects, processes, and states through research, value narrative, and visual modeling. This article focuses on step two: establishing a business semantic model that makes business knowledge machine-understandable, queryable, constrainable, and invokable.

Business Model vs. Business Semantic Model

Many confuse business models with business semantic models. A business model describes how the business runs: what objects exist, which processes they participate in, how processes change states, which rules constrain actions, and which roles make judgments. It creates a shared language for business people, product managers, architects, and data governance teams.

A business semantic model goes further, focusing on machine interpretability, computability, and reusability. It defines how objects become concepts, how relationships form standard semantics, how states become decidable conditions, how rules become executable constraints, how metrics bind to business calibers, and how actions become Agent-invokable capabilities. The business model clarifies the business; the business semantic model turns it into semantic assets that systems can use.

Don't Treat a Field Dictionary as a Semantic Model

A common mistake is starting from database tables, fields, metrics, and reports. While fields are important for later data asset mapping, beginning with them conflates system implementation with business essence.

For example, a database field named status is just a state column. In a business semantic model we must ask: which business object owns this status? What are its legal values? Can states transition between each other? Who triggers state changes? What rules constrain transitions? Which states represent normal, abnormal, completed, risk, or failure? Which Agent actions can be triggered by this status?

Similarly, a metric like "overdue rate" is not just a formula. From a semantic perspective we must define: what is the overdue object? From which time point does overdue calculation start? Are business types distinguished? Are special states excluded? Is the result used for statistics, alerting, or performance evaluation? Who has permission to view and use it? Can an Agent trigger reminders or handling suggestions based on this metric?

Therefore, a business semantic model must start from business objects, relationships, states, rules, and actions, then map back to fields and metrics.

Eight Core Contents of a Business Semantic Model

In ontology-driven data governance, the business semantic model captures eight categories:

Concept Types : core business objects such as customer, order, device, case, personnel, contract, work order, material, evidence, strategy, risk event, etc. These are not table names but objects truly identified, managed, judged, and operated in the business.

Relationship Types : explicit definitions of how objects relate (e.g., customer owns order, device generates alarm, case contains material, contract constrains fulfillment, work order links to handler, risk event affects strategy). Without these, systems see only scattered data without business context.

State Types : states like pending, processing, completed, abnormal, overdue, closed, confirmed, rejected, warned, expired. States bind to business objects and must define legal transitions.

Process Types : business processes are not simple flow lines but causes of state changes. Actions such as application, approval, inspection, warning, handling, review, re-examination, archiving, and retrospective can change object states and trigger rules, metrics, and Agent actions.

Rule Constraints : often underestimated, including process rules, risk rules, compliance rules, metric caliber rules, action trigger rules, manual confirmation rules, etc. Rules give the model constraint and validation capability.

Metric Calibers : metrics must bind object, time, scope, dimension, state, calculation rules, and applicable scenarios. The same metric may have different calibers in different scenarios; ambiguity leads to errors in querying, analysis, and Agent invocation.

Data Evidence : specifies which data supports which business facts. Sources include business system fields, documents, logs, APIs, sensors, manual confirmations, model outputs, or external data. Evidence is not simple lineage; it must state which business fact each data item proves.

Action Contracts : to serve AI Agents, the model must express actions such as query, validate, compare, generate, alert, recommend, dispatch, initiate review, create pending confirmation items. Each action defines inputs, outputs, permissions, preconditions, manual confirmation requirements, and result logging.

This distinguishes the business semantic model from ordinary knowledge graphs, metric systems, or data dictionaries: it not only describes the business but also supports system and Agent invocation.

Transforming Business Model to Semantic Model

Business modeling outputs cannot be directly fed to technical systems; a semantic transformation is needed. The recommended path:

Business Objects → Concept Types

Object Relationships → Relationship Types

Business Processes → Process Types or Event Types

State Changes → State Types and State Transitions

Business Rules → Rule Constraints

Data Sources → Data Evidence and Semantic Mapping

Agent Opportunity Points → Action Contracts

Example: In a customer risk identification scenario, the business model might state: customer generates transaction behavior; transaction triggers risk identification; risk identification creates risk event; risk event enters review; review approval triggers handling suggestion. The semantic model further clarifies: what concepts are customer, transaction behavior, risk event, review task, handling suggestion? What is the relationship between customer and transaction? How does transaction trigger risk event? What states does a risk event have? Which rules decide whether to enter review? Which data proves transaction anomaly? At which nodes can an Agent perform retrieval, comparison, explanation, or suggestion?

Relationship Between Business Semantic Model and Ontology Model

The business semantic model need not start as a full ontology engineering effort. Discussing classes, properties, axioms, OWL, RDF, SPARQL too early alienates business stakeholders. A better approach: first build a business semantic model in business-friendly terms, then gradually formalize it into an ontology model. The business semantic model is a semantic expression for business-system collaboration; the ontology model is a more formal, computable, inferable, reusable expression. The ontology model is important but not the starting point. Begin with business scenarios, objects, processes, state changes, and rule constraints; only after these stabilize should they be abstracted into concepts, relationships, attributes, constraints, and inference rules.

Control Granularity of the Semantic Model

A common pitfall is trying to model everything, leading to bloated, unmaintainable models. The principle: model around the current business scenario, not the entire business world. A good model supports key judgments in the current scenario, not maximum concept count. In the pilot phase, prioritize:

Core objects that affect the business closure loop

Key relationships that determine business judgments

Critical states that influence rules and metrics

Business rules that must be validated

Data evidence that supports result verification

Agent actions that can form a closed loop

Other content can be extended later. The goal is not a vast concept universe but making business semantics truly serve data, models, and Agents.

Deliverables of Step Two

After establishing the business semantic model, at least the following deliverables should be produced:

Business Semantic Glossary : unified names and definitions for core concepts, relationships, states, processes, rules, and metrics.

Concept Relationship Model : shows relationships among core objects, distinguishing strong constraints from reference relationships.

State and Process Model : defines object states, state transitions, and processes that trigger state changes.

Rule and Metric Caliber Specifications : extracts key business rules and metric calibers from natural language into verifiable, discussable, maintainable rule assets.

Data Evidence Inventory : maps data sources, fields, documents, logs, or APIs to the business facts they support.

Agent Action Contract Inventory : lists invocable Agent capabilities, required inputs, outputs, manual confirmation needs, and logging mechanisms.

These artifacts are not ordinary documents; they form the foundation for subsequent data asset mapping, semantic quality rules, semantic service publishing, and Agent capability design.

Summary

In ontology-driven data governance, step two is not building tables or knowledge graphs immediately, but establishing a business semantic model. The business model answers "how the business runs"; the business semantic model answers "how the business is understood and invoked by machines." It organizes business objects, relationships, processes, states, rules, metrics, data evidence, and action contracts into queryable, constrainable, reusable, and serviceable semantic assets. Once this step is solid, step three can begin: mapping existing data assets (tables, fields, metrics, documents, logs, APIs, model outputs) to the business semantic model, clarifying which data supports which business facts. Only then does ontology-driven data governance truly move from "business modeling" into "data asset governance."