Data ontology, explained with one example built four ways: taxonomy, ontology, knowledge graph, semantic layer. Plus how Palantir's Ontology works.

Ka Ling Wu
Co-Founder & CEO, Upsolve AI
10 min

Ask three data platforms what an ontology is and you’ll get three answers. Palantir says its Ontology is “not a ‘semantic layer’.” Microsoft says its new ontology “provides a common context layer.” Databricks calls it “the context layer your AI agents are missing.”
They’re all describing the same underlying idea, a data ontology, from different angles. This guide defines it plainly, then shows one business example built four ways (as a taxonomy, an ontology, a knowledge graph, and a semantic layer) so the differences are visible rather than abstract. It also covers how Palantir’s Ontology actually works and what an AI agent really needs.
Key Takeaways |
|---|
|
What Is a Data Ontology?
A data ontology is a formal, shared model of the things a business cares about (entities such as customers, contracts, and invoices), their attributes, how they relate to each other, and the rules that constrain them. It describes what data means, independently of how it’s stored, so people and machines interpret it the same way.
In simple terms, a data ontology is the agreed-upon answer to “what is a customer here, and how does it connect to everything else?”
Where the Word Comes From
“Ontology” comes from philosophy, where it means the study of what exists. Computer science borrowed it in the 1990s. Tom Gruber’s widely cited definition calls an ontology a specification of a conceptualization: an explicit description of the concepts in a domain and the relationships between them. The W3C later standardized the idea as the Web Ontology Language (OWL), which is “designed to represent rich and complex knowledge about things, groups of things, and relations between things.”
Ontology vs Data Model
A data model describes storage: tables, columns, data types, and foreign keys. An ontology describes meaning: a Customer holds Subscriptions, an Invoice is billed to exactly one Customer, and an Active Customer is one with at least one live subscription. As Databricks puts it, “A schema describes how data is structured. An ontology describes what that data means in the context of the business.”
You can change the data model (split a table, rename a column) without changing the ontology. That separation is what makes an ontology durable. A semantic model sits between the two: business meaning, scoped to analytics.
The Components of a Data Ontology
Every ontology, whatever the tool, is built from the same parts. The names change by vendor, which is half the confusion:
Concept | OWL / RDF | Palantir | Microsoft Fabric IQ | Warehouse equivalent |
|---|---|---|---|---|
Kind of thing | Class | Object type | Entity type | Table |
A specific thing | Individual | Object | Entity instance | Row |
Attribute | Datatype property | Property | Property | Column |
Relationship | Object property | Link type | Relationship type | Foreign key join |
Constraint or rule | Axiom, restriction | Function, action validation | Rule | Check constraint or business logic |
The warehouse column is the important one for analytics teams. If your tables are well described and your keys are declared, you already have the skeleton of an ontology.
One Example, Four Ways: Taxonomy, Ontology, Knowledge Graph, Semantic Layer
The clearest way to understand these terms is to model the same business domain in each. We’ll use a subscription business with three concepts: Customer, Subscription, and Invoice.
Data ontology vs taxonomy vs knowledge graph vs semantic layer: one subscription-business example modeled four ways

As a Taxonomy
A taxonomy only says what kind of thing something is. It’s a hierarchy of “is-a” relationships, usually expressed in SKOS, the W3C standard for taxonomies and thesauri:
Customer → Enterprise Customer, SMB Customer
Subscription → Monthly Subscription, Annual Subscription
Invoice → Open Invoice, Paid Invoice, Overdue Invoice
A taxonomy can’t tell you that a subscription belongs to a customer. There are no relationships across branches.
As an Ontology
An ontology adds typed relationships, properties, and rules. Here’s a minimal version in Turtle (RDF syntax), with illustrative names:
On top of that structure, the ontology states rules in business terms. An Active Customer is a Customer with at least one Subscription whose status is active or past due. An Overdue Invoice is an open Invoice past its due date. There’s still no data here, just the shape of meaning.
As a Knowledge Graph
A knowledge graph is the ontology populated with real instances. Enterprise Knowledge’s shorthand is that ontology + data = knowledge graph. With fictional data:
Because the rules travel with the graph, a reasoner can infer that INV-8873 is an Overdue Invoice once its due date passes, and that Acme Corp is an Active Customer. That makes multi-hop questions natural: “Which active enterprise customers on the Pro plan have overdue invoices?”
As a Semantic Layer
A semantic layer takes the same concepts and makes them computable. It maps them to warehouse tables (dim_customers, fct_subscriptions, fct_invoices), declares the joins, and defines metrics that compile to SQL:
ARR =
SUM(fct_subscriptions.mrr) * 12wherestatus IN ('active', 'past_due')Overdue AR =
SUM(fct_invoices.amount)wherestatus = 'open' AND due_date < CURRENT_DATEDimensions: customer segment, region, plan
A semantic layer is less expressive than an ontology. It can’t reason about classes. But it’s deterministic: ARR computes the same way every time, in every tool. The dbt Semantic Layer and the Cube semantic layer work this way; our semantic layer tools comparison covers the rest.
Comparison Table
Taxonomy | Ontology | Knowledge graph | Semantic layer | |
|---|---|---|---|---|
Models | Categories | Classes, relationships, rules | Real instances + their connections | Metrics, dimensions, joins |
Answers | “What kind of thing is this?” | “How do things relate, and what rules apply?” | “What is true right now?” | “What’s the number?” |
Standards and tools | SKOS | OWL, RDF; Palantir, Fabric IQ | RDF triple stores, Neo4j | dbt, Cube, LookML, Snowflake, Databricks |
Maintained by | Librarians, data stewards | Knowledge engineers, domain experts | Data and graph engineers | Analytics engineers |
What breaks without it | Inconsistent categorization | Conflicting definitions across systems | Multi-hop questions | Metrics that differ by dashboard |
Ontology vs Knowledge Graph
A knowledge graph is not the same as an ontology. The ontology is the schema. It defines what kinds of nodes and edges can exist and what they mean. The knowledge graph is the data: actual customers, actual invoices, actual links. Neo4j’s explanation puts it well: the knowledge graph is what you build, while taxonomies and ontologies are the blueprints.
IBM defines a knowledge graph as a network of real-world entities and their relationships, made of nodes, edges, and labels, and notes that ontologies provide its formal structure. Knowledge graphs earn their keep on multi-hop questions and on unstructured text. Microsoft’s GraphRAG research, for example, showed that an LLM-built entity graph beats plain vector retrieval on “global” questions over large document collections.
Ontology vs Semantic Layer
The simplest distinction is meaning vs measurement. An ontology defines what things are and how they relate. A semantic layer defines how to compute numbers about them. They overlap on entities and joins, which is why the terms get blurred.
The overlap has a useful edge case. In dbt Labs’ 2026 benchmark, the dbt Semantic Layer answered 100% of in-scope questions, but the remaining misses were questions that needed “too many entity hops for MetricFlow.” Traversing many relationships is precisely what ontologies and knowledge graphs are built for. A metrics layer handles the number; an ontology handles the path to it.
One more caution: in knowledge management circles, “semantic layer” sometimes means the opposite. Enterprise Knowledge describes a semantic layer built on taxonomies, ontologies, and knowledge graphs. If two people disagree about which contains which, they’re probably from different fields.
What Is Palantir’s Ontology?
The Palantir Ontology is the layer inside Palantir Foundry that maps an organization’s data and models to real-world objects, their relationships, and the actions people (and AI agents) can take on them. Palantir’s docs call it “an operational layer for the organization” that in many settings “serves as a digital twin of the organization.”
Objects, Properties, and Links (the Semantic Half)
Object type: “the schema definition of a real-world entity or event”, such as
EmployeeorFlight. Each object is one instance, such as a specific employee.Property: a characteristic of an object type, like a flight’s departure time. Properties can serve as primary keys.
Link type: “the schema definition of a relationship between two object types”, such as Flight → Aircraft or Employee → Manager.
Interface: a shared shape that several object types implement. For example,
AirportandManufacturing Plantboth implement aFacilityinterface.
Actions and Functions (the Kinetic Half)
This is what makes Palantir different from a catalog. Action types are “the definition of a set of changes or edits to objects, property values, and links”, and edits can be written back to operational systems. Functions let developers write business logic in TypeScript or Python that reads properties, traverses links, and makes edits. Palantir describes the full Ontology as semantic elements (objects, properties, links) plus kinetic elements (actions, functions, dynamic security).
Ontology vs Foundry vs AIP
Foundry is the data platform.
The Ontology is the layer within Foundry that turns datasets into objects, links, and actions.
AIP is Palantir’s AI tooling built on top of the Ontology. AIP Logic, for example, is a no-code environment for LLM-powered functions that take Ontology objects as input and can edit them.
The Ontology SDK (OSDK) gives developers typed access to the Ontology from TypeScript, Python, and Java.
Why Palantir Says It’s “Not a Semantic Layer”
Palantir argues that a thin semantic layer can’t capture how an enterprise actually works. Its Ontology integrates data, logic, action, and security, and it is “designed to represent the complex, interconnected decisions of an enterprise, not simply the data.” In Palantir’s framing, semantics must be paired with kinetics.
Ontology in AI: Why Agents Suddenly Need One
LLMs are good at language and bad at guessing your business. An ontology gives them the missing structure, and the evidence is consistent:
data.world (2023): GPT-4 answered 16.7% of insurance questions correctly from SQL and 54.2% from an ontology-backed knowledge graph. On high-complexity schemas, SQL scored 0% and the knowledge graph scored 35.7–38.5%.
data.world follow-up (2024): Adding ontology-based query checks and LLM repair raised accuracy to 72%, with another 8% answered “I don’t know” instead of guessing wrong.
An independent 2026 ablation on the DABStep benchmark found that semantic content drove most of the gain, lifting hard-task accuracy from 13.9–37.0% to 55.1–77.4% across four models. Agent scaffolding alone added 0–15 points. Governed agents also issued zero data-modifying statements, compared with 166 for ungoverned ones.
Databricks reports that Genie with Ontology answered 84.5% of 28 enterprise questions correctly on the first attempt, compared with 52.4% for the strongest general-purpose coding agent tested. Databricks itself calls this an internal benchmark.
The pattern: model scaffolding helps a little. Encoded business meaning helps a lot.
The 2025–2026 Ontology Wave
Microsoft Fabric IQ (announced November 2025) includes an ontology item with entity types, relationships, rules, and actions, bootstrapped from existing Power BI semantic models. It imports and exports OWL and RDF. As of October 2026 it is still in preview.
Databricks Genie Ontology (June 2026) is described as “a new self-improving context layer” that extracts business knowledge from tools like Slack, Jira, and Confluence. It builds on Databricks metric views in Unity Catalog.
Snowflake doesn’t use the word. Its equivalent, Horizon Context, is branded a governed context layer. Its semantic piece is Snowflake semantic views.
Formal vs Operational Ontologies
This is the distinction that resolves most of the confusion. A formal ontology (OWL, RDF) is built for logical reasoning and interoperability between systems. An operational ontology (Palantir, Fabric IQ, Genie, Upsolve Data Models) binds business objects to live data, permissions, and sometimes actions, so software and agents can use them. Analytics teams almost always need the second kind. It’s also why vendors increasingly use ontology and context layer interchangeably.
How to Build a Data Ontology for an Analytics Agent
You don’t need a PhD in OWL or a triple store to give an analytics agent an ontology. You need the operational minimum:
Model the head first. List the 10–20 entities your most common questions touch: customers, accounts, subscriptions, invoices, products.
Describe tables and columns in business language. Include units, exclusions, and which table is the source of truth. A good data dictionary is the starting point.
Declare keys and relationships. Primary and foreign keys are your ontology’s links.
Write canonical definitions for the metrics people argue about, such as ARR, active customer, and churn.
Capture allowed values and permissions. Statuses, plan tiers, and regions, plus who can see what, enforced outside the model.
Then version it, test it against real questions, and add a definition every time an agent gets something wrong.
Don’t Have a Semantic Layer or Ontology Yet? Start Here
Upsolve Data Models is the first layer in Upsolve’s agent stack, and we call it the Ontology for a reason. It holds exactly the operational minimum above:
Entities and relationships: Register your tables with descriptions, types, and primary and foreign keys.
Vocabulary: Store canonical definitions, analysis approaches, and output formats in a versioned system prompt.
Allowed values: Mark columns as selectable, and Upsolve pre-caches their values nightly or on your schedule, so the agent knows every contract status before writing SQL.
Permissions: Enforced deterministically, never delegated to the agent.
No semantic layer, dbt project, or OWL file is required. Start from your warehouse and add definitions as gaps appear.
Frequently Asked Questions
What is data ontology in simple terms?
A data ontology is an agreed map of the things your business cares about and how they connect. It defines what a customer, an order, or an invoice is, what attributes each has, and the rules that apply, so every system and person interprets the data the same way.
What is an example of an ontology?
A simple business example: a Customer holds one or more Subscriptions, each Subscription is on one Plan and generates Invoices, and an Overdue Invoice is an open invoice past its due date. Well-known published ontologies include the Gene Ontology, SNOMED CT for clinical terms, FIBO for finance, and Schema.org.
Is a knowledge graph the same as an ontology?
No. An ontology is the schema: the types of things and relationships that can exist. A knowledge graph is that schema populated with real data. Put simply, ontology plus data equals knowledge graph.
What is the difference between an ontology and a semantic layer?
An ontology defines meaning: entities, relationships, and rules. A semantic layer defines measurement: how metrics compile to SQL. They overlap on entities and joins, but the semantic layer is built for consistent numbers and the ontology for consistent understanding.
What is an ontology in AI?
In AI, an ontology is structured business knowledge an agent can use to interpret questions and data correctly. Grounding LLMs in an ontology or knowledge graph has tripled question-answering accuracy in published benchmarks, mainly by removing guesswork about what terms mean and how tables connect.
What are the types of ontology?
Ontologies are commonly grouped into four types: upper ontologies (very general concepts like time and space), domain ontologies (one field, such as medicine or finance), task ontologies (a specific activity), and application ontologies (one system or use case). Most business ontologies are domain or application ontologies.
Sources
Palantir: The Ontology system (Architecture Center). https://www.palantir.com/docs/foundry/architecture-center/ontology-system/
Palantir: Ontology overview. https://www.palantir.com/docs/foundry/ontology/overview/
Palantir: Object types overview. https://www.palantir.com/docs/foundry/object-link-types/object-types-overview/
Palantir: Link types overview. https://www.palantir.com/docs/foundry/object-link-types/link-types-overview/
Palantir: Action types overview. https://www.palantir.com/docs/foundry/action-types/overview/
Palantir: AIP Logic overview. https://www.palantir.com/docs/foundry/logic/overview/
Microsoft Learn: Fabric IQ ontology overview (preview). https://learn.microsoft.com/en-us/fabric/iq/ontology/overview
Databricks: Data Ontology Defined: The Context Layer Your AI Agents Are Missing. https://www.databricks.com/blog/data-ontology-defined-context-layer-your-ai-agents-are-missing
Databricks: Databricks launches Genie One (Jun 16, 2026). https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team
Snowflake: Horizon Context: The Governed Context Layer (Jun 2026). https://www.snowflake.com/en/blog/horizon-context-governed-context/
Tom Gruber (1993): A Translation Approach to Portable Ontology Specifications. https://tomgruber.org/writing/ontolingua-kaj-1993.htm
W3C: Web Ontology Language (OWL). https://www.w3.org/OWL/
W3C: SKOS Simple Knowledge Organization System. https://www.w3.org/2004/02/skos/
Sequeda, Allemang & Jacob (arXiv, 2023): A Benchmark to Understand the Role of Knowledge Graphs on LLM Accuracy for Question Answering on Enterprise SQL Databases. https://arxiv.org/abs/2311.07509
Allemang & Sequeda (arXiv, 2024): Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue! https://arxiv.org/abs/2405.11706
Ye (arXiv, 2026): Context layer ablation on DABStep. https://arxiv.org/abs/2609.22259
dbt Labs: Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update. https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026
Neo4j: Taxonomy vs. Ontology vs. Knowledge Graph. https://neo4j.com/blog/knowledge-graph/taxonomy-vs-ontology-vs-knowledge-graph/
IBM: What Is a Knowledge Graph? https://www.ibm.com/think/topics/knowledge-graph
Enterprise Knowledge: What’s the Difference Between an Ontology and a Knowledge Graph? https://enterprise-knowledge.com/whats-the-difference-between-an-ontology-and-a-knowledge-graph/
Enterprise Knowledge: What Is the Difference Between a Semantic Layer and a Context Layer? (Mar 2026). https://enterprise-knowledge.com/what-is-the-difference-between-a-semantic-layer-and-a-context-layer/
Edge et al. (Microsoft Research, arXiv): From Local to Global: A Graph RAG Approach. https://arxiv.org/abs/2404.16130
Upsolve AI: Data Models. https://upsolve.ai/features/data-models

Try Upsolve for Embedded Dashboards & AI Insights
Embed dashboards and AI insights directly into your product, with no heavy engineering required.
Fast setup
Built for SaaS products
30‑day free trial






