What Is an Ontology? 9 Questions to Understand Ontologies & Their Role in AI Agents

01 What Is an Ontology?

Imagine a Beijing driver arriving in Nanjing for the first time, tasked with taking a passenger to Nanjing South Railway Station. The driver cannot start immediately because they don't know which roads are one-way, which channels prohibit ordinary vehicles, or whether the destination is a bus or train station. They need a map, a legend, and traffic rules.

AI entering an enterprise faces a similar situation: general knowledge fails here . For example, a telecom AI asked "Why can't my phone number order a 5G package?" cannot answer from training data alone, nor easily via database or RAG queries, because it requires understanding business knowledge such as:

A phone number represents a user

User fees are charged to an account, which may be in arrears

Arrears accounts cause package change requests to be rejected

Without this business knowledge, even if AI can query data, it doesn't know what to query, along which relationships, or why it fails. The role of an ontology is to give AI a "navigation map" of the enterprise business world — defining concepts, relationships, and rules so AI can safely reach its destination.

Ontologies have existed in AI and knowledge engineering long before today's large models; RDF, OWL and other standards predate them. Palantir Ontology is a successful product implementation that brought attention to ontologies, but Palantir did not invent ontologies.

02 Why Are Ontologies Hotter in the Agent Era?

Traditional software operates through fixed menus and processes (OA, CRM, SCM). Field meanings, data associations, and business rules are hard-coded — like giving the new driver a fixed set of actions to reach the destination without a map.

Agents differ: users can propose new tasks at any time; agents must autonomously understand intent and execute tasks with higher certainty requirements. Enterprise agent task complexity and high certainty demands dictate the need for a precise, unified, structured "language" to express business knowledge — an ontology.

For instance, a telecom building multiple agent systems needs all agents to uniformly understand customer, account, user, product, and package concepts and relationships. If each project rewrites prompts or skills to provide domain knowledge, it's tedious and prone to inconsistency. With a unified ontology, these concepts and relationships are maintained once, reusable across agents within permission scopes, and changes propagate without modifying every agent.

Ontologies aren't mandatory for every agent. If business concepts are few, relationships simple, and understanding consistent, a clear wiki, data dictionary, or API spec may suffice.

03 How Does an Ontology Differ from a Database? Does It Store Data?

Relational database veterans often wonder: aren't users, accounts, orders, products and their relationships already in the database?

Database stores concrete business data (facts):

Customer C01 has user U05

User U05 uses number 138xxxx

User ordered product P20, paid via account A07

Account A07 current balance is 0

Ontology defines how these data should be understood:

Customer, account, and user are three distinct business concepts

Phone number is a resource used by a user

Ordering a product creates an order; using a service creates a bill

Which relationships can derive new business facts

Database records what happened in the business world; ontology explains the business world itself.

Can't Database Schema Explain Data Relationships?

Schema, ER diagrams, and data dictionaries are important for understanding systems. If the system is simple, table names clear, relationships simple, they may suffice. But database schema is often designed to serve system implementation first:

A business object may be split across multiple tables for performance

Some relationships hide in code (e.g., foreign keys)

The same business concept may have different names in different systems

Ontology extracts these scattered business meanings and re-represents and connects them uniformly. It doesn't negate database schema but adds a cross-system shareable business interpretation layer.

Does an Ontology Store Data?

Typically, it does not directly store business data. Ontology concepts, relationships, and constraints need persistence, but data like "Customer C01" or "Product P07" remain in CRM and other business systems. Ontology connects to these sources via mappings — e.g., "this 'User' business concept is stored in the CRM database's users table." Databases remain the authoritative source of business data; ontology's main purpose is to give scattered data consistent business meaning.

Note: Some graph databases used to store ontology definitions (e.g., GraphDB) can also store business data.

04 What Is the Relationship Between Ontology and Knowledge Graph?

Both have nodes and edges, both can use triples (subject-predicate-object). The difference mirrors ontology vs. database:

Ontology focuses on the conceptual/semantic layer. It defines types, relationships, and constraints in the business world. Example:

5G package is a type of tariff package

User can order 5G product

User's bill is paid via account

Knowledge graph typically focuses on the factual layer. It records specific objects and relationships that have occurred. Example:

User U05 ordered product P20

"Enjoy 299" package is a 5G package

User U05's bill is paid by account A07

Both can be written as triples, but represent different levels — analogous to "class" vs. "object" in OOP.

Must they appear together? Not necessarily. A small knowledge graph can exist without strict ontology, using simple nodes and relationships. As the graph grows, divergent team understandings may require ontology to unify meaning. Ontology can also exist alone for business modeling, system design, and data standards, but cannot be used for concrete fact judgment and reasoning. They can complement: ontology provides concepts and rules; knowledge graph (possibly with relational DB) stores concrete facts. Ontology makes knowledge graph data easier to understand consistently; knowledge graph enables ontology for query and reasoning.

05 How to Express an Ontology? What Standards Exist?

How to write ontology definitions so machines understand? Beginners should know these semantic expression standards.

RDF/RDFS: Define Concepts and Basic Relationships

RDF provides the basic triple structure; RDFS adds classes, properties, hierarchies. To express: "User" and "Product" are business concepts; "Order" is a relationship from User to Product.

Simplified diagram: User - Order - Product Formal RDF/RDFS (simplified):

# Define two business concepts
tel:User rdf:type rdfs:Class .
tel:Product rdf:type rdfs:Class .

# Define "Order" relationship:
# Relationship from "User" to "Product"
tel:Order
    rdf:type rdf:Property ;
    rdfs:domain tel:User ;
    rdfs:range tel:Product .

This defines relationships between business concepts, not that a specific user ordered a specific product, nor that all users ordered all products.

OWL: Define More Complex Logical Relationships

For transitivity (Service A contains B, B contains C → A contains C), disjointness (user cannot be both prepaid and postpaid), cardinality restrictions, OWL is needed. Example: "A product order must associate with exactly one target product."

# Each product order must associate with exactly one product
tel:ProductOrder
    rdfs:subClassOf [
        rdf:type owl:Restriction ;
        owl:onProperty tel:targetProduct ;
        owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
        owl:onClass tel:Product
    ] .

This describes a restriction on ProductOrder: onProperty targets "targetProduct"; qualifiedCardinality 1 means exactly one; onClass specifies target type is "Product".

Other Common Standards

SKOS : Unify terminology definitions. E.g., "Value-added service" and "VAS" mean the same.

SWRL : Define business rules on top of OWL to infer new facts from existing ones. E.g., "Arrears account → unreceivable order".

SHACL : Validate data against defined constraints, like program validation rules.

SPARQL : SQL for ontologies, query and update RDF.

Ontology involves many standards with a learning curve; the same business semantics can be expressed differently. In practice, modeling tools and AI help avoid hand-writing complex syntax, but understanding what each standard solves is necessary.

06 What Does a Minimal Domain Business Ontology Look Like?

After learning an expression "language", let's build a minimal telecom customer operations ontology for concrete impression.

Basic Concepts and Relationships

First, sketch the ontology skeleton — business concept and relationship diagram (partial). Note: The diagram contains no concrete data like "User U05"; it describes part of the telecom customer operations business world structure.

A usable ontology also needs data properties for concepts (resource status, account balance, order creation time) with types and optionality. Don't copy all database fields; only include properties valuable for business understanding, query, validation, and reasoning, otherwise it becomes another database design.

Hierarchies and Relationship Constraints

Further define in the ontology:

Individual customer, corporate customer, VIP customer are all subclasses of Customer

Individual and corporate customers must be disjoint

New installation order, change order, cancellation order are subclasses of Order

Each product adopts one tariff package

Each bill contains at least one fee item

These rules describe the business itself, not specific business data.

Data Validation Rules

Define checks for factual data:

A user cannot use multiple numbers

Phone number must match a format

Order product price must be >= user level minimum price

Data validation rules may resemble relationship constraints (e.g., each bill at least one fee item), but validation rules check concrete data; relationship constraints describe fixed relationships.

Business Control Rules

Define rules that derive business conclusions:

If user's ordered product adopts a 5G tariff package, then user is identified as a 5G user

If user's fee account is in arrears and submits any order, then that order is not accepted

This small ontology now contains concepts, relationships, hierarchies, constraints, data validation, and conditional rules.

How to Test Modeling

Beginners can use WebProtégé in-browser to create classes, properties, relationships without installation; for local reasoning and more plugins, use Protégé Desktop . Models export to Turtle, RDF, OWL files or into dedicated databases like GraphDB.

Recommended workflow: Let AI generate initial model from above definitions, then import into Protégé for review. AI writes syntax, but business experts must confirm alignment with actual business.

07 How Is This Minimal Ontology Used in an Agent?

You can't just hand an OWL file or graph database to an agent and expect instant omniscience.

First, connect ontology concepts to enterprise systems: e.g., number resource maps to resource system data, bills from billing system, orders generated in CRM — ontology handles business semantics; business systems provide data; agent orchestrates logic.

Assume an agent task: "Change user of number 13688888888 to 299-yuan 5G package; if not possible, tell me why."

Agent follows this process combining ontology:

LLM understands user intent : LLM judges user wants package change for specified number, target 299-yuan 5G package, needs to start order process.

Trigger pre-order check : Based on constraints (Skill, tool description, Workflow), agent must run pre-order check, invoking "pre-order check" tool.

Pre-order check tool performs:

Align business meaning with ontology : Agent aligns its understanding with ontology: phone number is a NumberResource used by User; "299 package" is a TariffPackage; TariffPackage adopted by Product, Order processes Product. Agent determines relationship paths and needed data:

NumberResource ← uses — User — feeChargedTo → Account

and

User — submits → Order — processes → Product — adopts → TariffPackage

. These paths aren't reliably derivable from LLM common sense; they're enterprise-specific business definitions.

Retrieve factual data from business systems : Via data mapping rules (ontology can define), call business system APIs to get: number 13688888888 used by User U05; U05's fee account is A07, currently in arrears; 299-yuan tariff package corresponds to Product P299. These concrete data come from business systems, not ontology reasoning.

Load facts and execute ontology reasoning : Organize facts per ontology relationships, add pending order O01, inject into ontology. Ontology reasoner (open-source or DB-built-in) first checks data integrity via validation rules, then infers: A07 is an arrears account; U05's fees charged to A07; U05 preparing to submit O01; therefore O01 is an unreceivable order.

Agent decides whether to execute : Based on reasoning result, agent decides not to start real order process, replies: "Number 13688888888's fee account is currently in arrears; per order acceptance rules, package change cannot be processed now. You can check arrears bill or complete payment first."

Division of labor:

LLM: understands rough user intent

Ontology: aligns business concepts, understands relationships

Business systems: provide real data

Ontology reasoning: derives deterministic conclusions

Agent: chains these capabilities together

Ontology here doesn't replace LLM thinking; it supplements business knowledge LLM cannot reliably grasp from general knowledge alone.

08 How to Judge Whether My Agent Needs an Ontology?

New tech concepts often lead to "hammer looking for nails" — applying ontologies to all AI apps. Before adopting, ask:

Do the same business concepts across different systems have ambiguities?

E.g., CRM "customer" means contracting party; another service system "customer" may mean caller. If only helping employees understand terms, a data dictionary or wiki may suffice; but if multiple agent systems need to align these concepts, ontology shows value.

Do complex relationships need cross-scenario reuse and reasoning?

Querying an account balance directly via a tool needs no understanding of account relationships. But answering "Why can't this number change to a 5G package?" requires connecting number resource, user, account, product, tariff, order, and applying order rules. If only one complex scenario, an aggregated API encapsulating queries and judgments may work. But if this business relationship group must be repeatedly combined across multiple AI scenarios — e.g., which account pays for a number, which users an arrears account affects, what products a user uses and how priced, how a product tariff change impacts users and orders — then ontology is worth considering.

Does the same business knowledge need sharing across multiple agent systems?

Customer service agent, marketing agent, risk control agent may all need to understand customer, user, account, product concepts and differences, and handle "how user finds paying account", "how order links product" relationships. If each agent explains via prompts/skills separately, it's repetitive and hard to keep consistent; ontology providing shared business knowledge is meaningful — unified modeling, centralized maintenance.

Do business judgments need traceable sources and evidence?

AI explainability and traceability: when AI says "this business fails", you need a definite answer. Using ontology for understanding and judgment lets AI state complete decision evidence and reasoning chain more deterministically.

Thus, using ontology isn't just because "business is complex" or "tech is advanced". Evaluate the above questions carefully, combine with your objective conditions (modeling and maintenance capability), then decide.

09 How Should Enterprises Conduct Ontology Modeling and Application?

Even if you adopt ontology, don't start with a "grand ontology" covering all business. More practical: pick a clear-value scenario, start from concrete business problem, model iteratively, connect data, validate effects, build a "minimum viable ontology", then expand to more scenarios and domains.

Building a "Minimum Viable Ontology"

Select business scenario as "entry point" : Choose a domain with clear scope and obvious value, define a concrete business problem as entry point, build minimum viable ontology. E.g., "package change" scenario to build agent capability.

List business capability questions : Clarify what questions the agent application must answer. E.g., who uses this number? Who pays the fees? What product currently ordered? What current tariff? Why can't a certain package be processed? These questions determine model content and serve for later acceptance.

Unify business concepts and boundaries : Involve relevant business departments and experts to confirm terminology meanings, boundaries, exceptions. E.g., what do "customer", "user", "order", "bill" refer to, what business relationships, are individual and corporate customers disjoint, what constraints on package change, what VIP privileges, etc.

Build minimal business knowledge model : Define only concepts, attributes, relationships, constraints, rules needed to answer capability questions, while retaining necessary identifiers, sources, and validity periods. Minimal isn't fewer the better, but just enough to support a complete business scenario's capabilities; covering all relevant business knowledge.

Map real business data sources : Specify which system each business concept's data comes from, via which interface; if multiple possible sources, which is authoritative. E.g., bills from billing system; user info and relationships from CRM.

Start with read-only applications to expand capabilities : First let application use ontology for query, association, judgment, and reason explanation; after accuracy stabilizes, gradually open low-risk, approvable, rollback-capable business operations. E.g., first let agent analyze order impact, later consider allowing order submission.

Accept "minimum viable ontology" by business results : Ontology is a means, not an end. Acceptance shouldn't just count concepts and relationships created; more importantly, check if business processing performance, judgment accuracy improved. Business owners continuously confirm concepts and rules; architects maintain model, data mappings, versions; source system owners ensure data quality.

Once a small model truly enters business flow and produces results, expand along adjacent problems: first vertically integrate within same business domain across other scenarios and processes, building complete domain model; then attempt horizontal cross-domain semantic alignment, e.g., connect customer operations with marketing, product planning domain ontologies.

In summary, ontology's value is drawing a business map understandable by both humans and AI — suited for enterprise environments with many business concepts, complex relationships, and numerous systems. But ontology isn't a panacea; don't chase tech hype into "big engineering". Assess business needs, data foundation, modeling maintenance capacity, act within means, start from small scenario, validate value with business outcomes, then iterate and evolve.