From Ontology to CBE: The Four-Layer Ladder for Flexible Ontology Application

Introduction

In ontology engineering, the questions "what the world is" and "how a system views the world" are often conflated, leading to modeling-by-table and hard-to-use ontologies. Starting from the dialectic of ontological uniqueness and ontological perspectivity, this article traces the key path from objective ontology, through perspective ontology, to component-based engineering. It further analyzes the core gaps when static knowledge moves toward dynamic systems and proposes the layered engineering paradigm "Unique Ontology → Perspective Ontology → CBE" to provide a systematic approach from data-driven domain knowledge extraction to executable system models.

1. One Table, Three Systems: What the World Is vs. How We View It

Consider a physical table. From an objective standpoint, it is a piece of furniture made of wood or metal, with height, area, material, and a stable physical identity regardless of observer or context. This perspective-independent existence is called Ontological Uniqueness .

When the same table enters specific systems, its semantic role changes with functional requirements:

In a classroom scheduling system , it becomes a "seating unit for two students."

In a restaurant ordering system , it is a "service surface" linked to kitchen, waiters, and payment.

In a warehouse management system , it turns into a "storage surface" or even an attribute "usable floor area of 120×60 cm."

The physical entity has not changed; the system perspective has. This semantic variation formed by different system perspectives is termed Ontological Perspectivity . It is not relativist sophistry but an architectural decision: functional requirements decide which objective entities become components, which inherent relations become attributes, and which physical boundaries become interfaces. "What the world is" (a table) and "how the system views the world" (seating unit, service surface, storage surface) are two distinct questions.

Barry Smith and Pierre Grenon (2004) articulated a similar view as "Realist Perspectivalism" : "The view that any given domain of reality can be viewed from a number of different ontological perspectives, all of which can have equal claim to veridicality." BFO operationalizes this principle as parallel SNAP (3D/continuant) and SPAN (4D/occurrent) sub-ontologies—accommodating incommensurable perspectives within an upper scaffold. This article extends that idea from "temporal existence modes" to "system functional modes": Unique Ontology corresponds to the cross-perspective consensus layer constrained by realism; Perspective Ontology corresponds to the legitimate perspective layer adopted by a specific system function.

2. The Perspectival Trap in Bottom-Up Ontology Construction

When building ontologies bottom-up from business descriptions, code, and database tables, a common mistake is treating these sources as direct reflections of the objective business world. In fact, they are already sediments of system architecture decisions: table structures reflect technical choices, business terminology reflects organizational changes, class hierarchies reflect design patterns. They are inherently not "objective ontologies" but "perspective-based ontologies."

This explains why "table-driven ontology construction" rarely yields ontologies fit for actual business. In a school scenario, Student, Teacher, and Course are independent entities; student course selection is a relation between them. But table-driven mapping turns the enrollment table into a class StudentCourseEnrollment alongside Student and Course, with object properties hasStudent, hasCourse. The technical structure for maintaining database joins is promoted to a domain entity at the same level as core concepts. The result is not an abstraction of the objective educational domain but a conceptual replication of the existing database architecture.

Worse, subsequent reasoning stays constrained by the original system perspective. When new needs arise—e.g., modeling "enrollment" as an auditable business event with lifecycle states (pending, confirmed, dropped)—the StudentCourseEnrollment class remains bound to the join table's semantics, making it hard to extend states/behaviors or map cleanly to new component architectures.

The core issue: such methods do not build ontologies; they replicate systems using OWL syntax. Primary keys, foreign keys, and joins reflect data organization under a specific architecture, not the domain's semantic structure. Mapping every table to an ontology class conflates "how the existing system organizes business objects" with "what objectively exists in the domain," blurring the boundary between system perspective and domain ontology.

Therefore, ontology construction must explicitly separate two incompressible phases:

First extract the perspective-neutral objective ontology (Unique Ontology) — answering "what irreducible objective entities and relations exist in this domain?"

Then overlay the perspective ontology (Perspective Ontology) per concrete system needs — answering "how should these entities be organized to support this system's functions?"

Only by clarifying both can we fundamentally avoid "technical artifacts promoted to domain entities."

Sometimes the objective ontology can be sourced from upper ontologies (abstract but lacking application detail). A method called SnapShot CQ uses competency questions to extend and refine the objective ontology into a perspective ontology.

If the goal is only static knowledge retrieval (e.g., Ontology Application Generation), Unique Ontology + Perspective Ontology suffice. But for digital twinning and planning questions (e.g., core network alarm root-cause, network configuration optimization), two further gaps must be bridged—addressed in sections 3 and 4.

3. Ontology Twin: Two Gaps from Semantic Ontology to Executable System

Given both ontologies, can we build an ontology twin—a digital mirror semantically aligned, reasonable, and evolvable? Not yet. Two critical gaps remain.

Example: building an ontology twin for a chain restaurant using code-based simulation to model business processes and runtime state, supporting analysis and optimization of seating, ordering, checkout, staff scheduling, etc.

Unique Ontology : Table is a physical entity with attributes material, surfaceArea, height; subclass of Furniture; related via locatedIn to Floor, Room. This cross-system objective base.

Perspective Ontology (restaurant operations): Table is an important concept linked via hasOrder to Order, servedBy to Waiter, seatedAt to CustomerParty. Table becomes a semantic node in the service flow.

With concepts and rich semantics, one might think loading them into a graph database plus sensors yields a twin. Two gaps prevent that.

Gap 1: Concept Independence ≠ Component Independence

Perspective Ontology establishes that Table is an independent concept semantically linked to Order, Waiter, CustomerParty—solving the cognitive problem of whether Table deserves separate identification.

But it does not solve the engineering problem : which module owns Table? Is its state externally visible? Can other modules directly modify its attributes?

PO defines Table hasOrder Order as a semantic relation. In code, this raises component design questions:

Create a separate TableService microservice exposing Table state via API?

Make Table a private data structure inside FloorManager, with external access only via FloorManager.assignOrderToTable()?

If two tables merge into one large table, who encapsulates that logic? Does Table component maintain merge state?

When Kitchen needs a table's order status, does it query Table directly or query OrderService and reverse-lookup?

Perspective Ontology is silent on these. Its boundary is the semantic boundary (is this concept worth identifying?); the system boundary is the encapsulation boundary (who owns state, what contract is exposed?). The former is "how to view the world"; the latter is "how to put the world into a black box."

This gap is filled by Component-Based Design (CBD) —the static encapsulation design phase of CBE, complementing BIP's dynamic behavior phase.

SDD + harness offer some architectural guidance but remain implementation-focused, insufficient for a unified component design method.

CBD asks not "is Table an independent concept?" but "should Table be encapsulated as an independent component?" Component means explicit interfaces, hidden internal state, replaceable encapsulation. PO solves "is Table worth viewing as independent concept"; CBD solves "is Table worth encapsulating as independent component"—different purposes, not interchangeable.

Gap 2: Existence ≠ Evolution

Assume CBD done; we have TableComponent encapsulating table state with operations seatCustomer(), placeOrder(), checkout().

Ontology defines Table with attribute serviceStatus ∈ {Idle, Occupied, Cleaning}—a static state space description (Being).

Real restaurant runtime state flows:

Customer seated → Occupied → Waiter orders → OrderPlaced → Kitchen serves → Serving → Customer pays → PaymentPending → Payment done → Cleaning → Cleaning done → Idle

Ontology and CBD specify that Table has serviceStatus and how it's encapsulated, but cannot describe runtime evolution rules:

What events trigger state transitions?

What preconditions for Occupied → Cleaning (e.g., all associated orders paid)?

Time bounds for transitions?

Which other components receive event broadcasts on transition?

Ontology describes Being; systems need Becoming. This is an incompressible chasm between ontology and system dynamics. It is bridged by BIP (Behavior-Interaction-Priority) , an Architecture Description Language and coordination language.

BIP core concepts:

Behavior : each component's internal state machine (finite automaton or Petri net) describing what it can do in each state and how it transitions.

Interaction : components collaborate via ports and connectors, synchronously or by broadcast.

Priority : when multiple interactions fire simultaneously, priority rules decide execution order.

With these three primitives, BIP can express arbitrarily complex component coordination patterns (Sifakis 2011), making dynamic evolution logic fully transparent and verifiable. BIP's compiler formally generates C++ code from system descriptions and provides formal deadlock checking.

The table below summarizes the four layers of ontology twin simulation software and their roles.

4. Flexible Application Generation and Planning Problem Solving

Simulation software can evaluate "how the restaurant runs under a given schedule," but the real engineering value lies in planning problems : not verifying a known plan, but finding the optimal plan in a huge configuration space—e.g., "how to schedule staff to maximize table turnover, minimize labor cost, and minimize customer wait?"

Structure: search a vast configuration space for parameter combinations optimizing an objective function. The BIP simulation kernel already performs precise dynamic replay; the next step wraps it as a flexible solving engine that accepts any valid configuration and returns objective function values, providing a stable evaluation basis for optimization algorithms.

Flexible applications are AI-generated for "disposable development," but AI code reliability is the bottleneck. A three-layer progressive mechanism turns generation from "black-box guessing" into "construction under constraints":

Layer 1: SDD injects design patterns. Traditional Specification-Driven Development answers "what software should do"; SDD further answers "how software should be organized." It defines configuration format, mapping rules, objective functions, and injects verified design patterns—e.g., pipeline for config parsing, adapter for state injection, observer for metric extraction. These are mandatory constraints: AI must follow structural templates, drastically shrinking search space from open coding to fill-in-the-blank construction.

Layer 2: Harness provides runtime verification. AI-generated flexible software must run on Harness's deterministic track. Harness not only drives simulation but acts as an "automatic examiner based on SDD": it checks correct config parsing, correct initial state injection per SDD mapping rules, and extraction of all agreed metrics at simulation end. Any deviation from SDD spec is caught by Harness assertions.

Layer 3: Ontology formally verifies program results. Runtime verification confirms "behavior conforms to spec" but cannot guarantee "semantics conform to reality." The application requirements ontology serves as final judge: does AI code let Table directly manipulate Kitchen (violating Perspective Ontology's semantic boundaries)? Does it introduce concepts absent from the ontology? Does it replicate database join-table error patterns into config mapping logic? Ontology reasoning enables semantic-level formal verification of program results—errors unit tests miss, Harness runtime checks miss, but ontology catches instantly.

Verified flexible software presents a minimal interface:

Input: a system configuration (staff count, open tables, menu structure, etc.)

Output: a set of objective function values (turnover rate, wait time, labor cost)

Optimization algorithms—Monte Carlo, genetic, Bayesian—treat this flexible software as a black-box function. They need not understand BIP state machine internals nor know the code is AI-generated; they only trust the evaluation results.

The complete value chain:

Objective ontology defines "what objectively exists in the restaurant" (staff, tables, orders, ingredients).

Perspective ontology defines "what matters in this system" (schedule config, service flow, state transitions).

CBD encapsulates perspective concepts as replaceable simulation components.

BIP gives components precise behavior and interaction rules, forming the simulation kernel.

SDD + Harness generate flexible application code from specification.

Application requirements ontology verifies AI-generated code hasn't drifted from domain semantics.

References

[1] Smith B, Grenon P. The Cornucopia of Formal-Ontological Relations. Dialogue on Globalization, 2004. (BFO / Realist Perspectivalism original paper, theoretical basis for SNAP/SPAN sub-ontology architecture)

[2] Smith B, Grenon P. Basic Formal Ontology: A Continuation of Basic Formal Ontology. IFOMIS Technical Report, 2004. (BFO overall framework description)

[3] Sifakis J. Component-Based Construction of Distributed Systems. Proceedings of the IEEE, 2011. (BIP three primitives—Behavior, Interaction, Priority—and proof of formal expressive power)

[4] Sifakis J. Modeling and Verification of Distributed Systems Using BIP. Springer, 2011. (BIP compiler, deadlock detection, code generation engineering implementation)

[5] Basu A, et al. Rigorous Component-Based System Design Using the BIP Framework. IEEE Software, 2011. (BIP industrial embedded system application cases)

[6] AsiaInfo 2030 Lab. Ontology Modeling Methodology Discussion. Feishu Cloud Document, 2026. (Internal discussion material on SnapShot CQ method)