How Ontology Empowers Enterprise Agents Beyond Reasoning: Building a Semantic Infrastructure

Ontology as Business‑Semantic Layer

Ontology is not a separate database; it sits between agents and existing data sources (databases, ERP, CRM, logistics) and describes what data represent, their attributes, relationships, business rules, and how to map to the physical tables.

01 Multi‑Relationship Propagation

Define relationship semantics directly in the ontology so agents can infer implicit impact chains.

# 控制关系：可传递
class controlledBy (ObjectProperty, TransitiveProperty):
    domain = [Organization]
    range = [Organization]

# 集团归属：可传递
class belongsToGroup (ObjectProperty, TransitiveProperty):
    domain = [Organization]
    range = [Organization]

# 担保关系：不可传递（未标记 TransitiveProperty）
class guaranteesFor (ObjectProperty):
    domain = [Organization]
    range = [Organization]

Classification rule that uses transitive closure:

class GroupRiskEntity (Organization):
    equivalent_to = [Organization & (
        hasRiskFlag.value(True) |
        controlledBy.some(hasRiskFlag.value(True)) |
        belongsToGroup.some(hasRiskFlag.value(True))
    )]

Comparison with recursive SQL (illustrated as a list):

New transitive relationship : add recursive query in SQL vs. declare TransitiveProperty in ontology.

Non‑transitive relationship : need extra exclusion logic in SQL (easy to miss) vs. default non‑transitive in ontology.

Classification depends on closure : write recursive JOINs and CASE statements in SQL vs. a single equivalent_to definition in ontology.

02 Schema Mapping Layer

Introduce annotation properties to decouple business concepts from physical schema.

# Declare mapping relationships (AnnotationProperty)
with onto:
    class mapsToTable (AnnotationProperty): pass   # class → table
    class mapsToColumn (AnnotationProperty): pass  # property → column

Customer.mapsToTable = ["onto_customers"]
customerTier.mapsToColumn = ["tier"]   # business concept → actual column
customerRegion.mapsToColumn = ["region"]

Helper that builds SQL from the annotations:

def build_mapped_query(class_name, property_name, value):
    cls = onto.search_one(iri=f"*{class_name}")
    prop = onto.search_one(iri=f"*{property_name}")
    table = cls.mapsToTable[0]
    column = prop.mapsToColumn[0]
    return f"SELECT * FROM {table} WHERE {column} = %s", [value]

Agent code references the business term customerTier instead of the physical column tier. Changing the column name (e.g., tier → customer_level) only requires updating the ontology annotation.

Cross‑System Customer 360 View

Map the same customer entity across multiple systems using the same annotation mechanism.

CRM : table onto_customers, name column name ERP : table onto_erp_contracts, name column legal_name Logistics : table onto_logistics_recipients, name column recipient_name Each system registers its class with an annotation such as mapsToNameColumn. The query engine scans all classes with that annotation, retrieves the corresponding tables and columns, and performs a fuzzy name match across systems. Agents need not know how many systems exist or their schema details.

03 Semantic Query Engine

Declare query concepts as ontology classes; a generic engine reads the annotations and generates the required SQL.

# Annotation properties for query definition
class queryFilter (AnnotationProperty): pass   # list of WHERE clauses
class queryJoin (AnnotationProperty): pass     # list of JOIN clauses

class VIPCustomer (Thing):
    queryFilter = ["customerTier=VIP"]

class PendingOrder (Thing):
    queryFilter = ["orderStatus=pending"]

class VIPPendingOrder (Thing):
    queryFilter = ["orderStatus=pending", "customerTier=VIP"]
    queryJoin = ["Customer:orderCustomerId=customerId"]

Engine method that builds the SQL from a concept name:

def build_semantic_query(self, concept_name: str) -> tuple[str, list]:
    """Read ontology annotations → auto‑construct SQL"""
    concept = self.onto.search_one(iri=f"*{concept_name}")
    filters = concept.queryFilter          # list of WHERE clauses
    joins = concept.queryJoin              # list of JOIN clauses
    # Resolve real column names via the schema‑mapping layer (omitted for brevity)
    # ... build WHERE and JOIN strings
    return sql, params

Adding a new query type only requires adding a class with appropriate queryFilter and optional queryJoin annotations; the engine recognises and executes it without additional code changes.

04 Combined Capabilities

Multi‑relationship propagation, schema mapping, and the semantic query engine together form a complete abstraction layer. Agents interact solely with business concepts; the ontology handles relationship semantics, physical‑schema translation, and query generation.

05 Limitations and Recommendations

Ontology is a bridge, not a replacement for databases or large language models. Implementation difficulty lies in business modeling: defining concepts, resolving conflicts, maintaining mappings, controlling reasoning performance, and governing ontology versions.

Suggested approach: start with a small, closed‑loop use case (e.g., an order‑rule check or a customer‑360 query), demonstrate that the ontology improves explainability, maintainability, and cross‑system reuse, then expand incrementally.