--- title: "What Is a Data Ontology? Definition, Layers, and Examples" slug: "what-is-a-data-ontology" author: "Mikel Amigot" date: "2026-07-16 10:00:00" category: "Premium" topics: "data ontology, semantic layer, knowledge graph, AI agents, enterprise AI" summary: "A data ontology is a structured, machine-readable map of your organization's entities, relationships, and actions that AI agents reason over. Definition, the two layers, ontology vs database schema, a concrete cross-system example — and an open-source, self-hosted implementation you own." banner: "" thumbnail: "" --- ## The Short Answer **A data ontology is a structured, machine-readable map of an organization's entities, attributes, relationships, and actions — the shared vocabulary AI agents reason over instead of guessing across raw tables.** It has two layers: a semantic layer (the nouns — entity types, attributes, relationships) and an operational layer (the verbs — actions, functions, permissions). Together they form a digital twin of your organization and the single source of truth for every agent. Unlike a database schema, an ontology describes the world in human-readable business terms, so a bank's "Account," a hospital's "Patient," or a university's "Student" means the same thing to every agent and every team. ibl.ai ships an open-source implementation — MIT-licensed at [github.com/iblai/ontology](https://github.com/iblai/ontology) — that runs self-hosted inside your network. You own the ontology and the data, and you run any model on top. ## What Is a Data Ontology? A data ontology is a structured representation of your organization that AI agents can reason over — not a pile of tables, but meaning. It answers two questions: what exists in your world, and what can happen in it. **The semantic layer — the nouns.** Entity types model real-world things: students, courses, patients, accounts, cases, equipment. Attributes capture their characteristics — enrollment date, grade level, capacity, balance. Relationships define how entities connect: a student *enrolls in* a course, a course *belongs to* a department. **The operational layer — the verbs.** Actions define permissible changes — enroll a student, approve a request, update a record — each with validation rules. Functions encode logic, like calculating a GPA or assessing a risk score. Permissions govern who can do what, at every level. Together, these layers form a digital twin of your organization — a complete, navigable map that AI agents use to understand context, make decisions, and take action. The ontology becomes the single source of truth for every agent. That "every agent" part is the point. Model an entity once and every downstream application — dashboards, agents, reports, integrations — reuses the same definition, so the cost of launching the tenth agent is a fraction of launching the first. ## What Are the Main Types of Ontologies? Ontology research traditionally distinguishes four types by scope, and the distinction is worth knowing before you build one. **Upper (foundational) ontologies** define universal, domain-independent concepts — object, event, process, time — meant to be shared across every field. **Domain ontologies** model one field's vocabulary: finance, medicine, law, education. **Task ontologies** describe the steps of a generic activity — diagnosing, scheduling, approving — independent of any one domain. **Application ontologies** combine a domain and a task for one specific system, which makes them precise but hard to reuse. For enterprise AI, the type that matters is the **organizational ontology**: a domain ontology of *your* institution. Not "medicine" in the abstract, but your hospital's patients, providers, claims, and approval rules. Not "education," but your university's students, courses, and prerequisites. The best practice is to start with what people already call things. If your teams say "student" and "course" — or "matter" and "claim," or "case" and "benefit" — those are your entity types. The ontology should feel familiar to domain experts, not like learning a new system. ## Data Ontology vs Database Schema A database schema describes tables; a data ontology describes the world. A schema tells you a `stu_enrl` table joins to `crs_catalog` on a foreign key. An ontology tells you a Student *enrolls in* a Course, that enrollment has rules, and who is allowed to change it. Three differences make that more than a naming exercise. First, an ontology is **human-readable by design** — expressed in familiar business terms, so domain experts can explore and validate data directly without writing queries or waiting on engineering. Second, **relationships carry meaning**. A schema's foreign key says two rows are linked; an ontology's relationship says *how* — one-to-many, prerequisite, supervision, ownership — so an agent can traverse chains of context, not just join tables. Third, an ontology has an **operational layer schemas lack**: actions with validation rules, functions that encode logic, and permissions at the schema, row, and field level. A schema stores state; an ontology also governs change.
Dimension Database schema Data ontology
Describes Tables, columns, foreign keys Entities, relationships, actions — the world
Vocabulary Technical (stu_enrl, crs_id) Business terms (Student, Course, Claim)
Scope One system at a time Every system, unified into one graph
Relationships Joins without meaning Typed connections agents can traverse
Change & governance Not modeled — handled in app code Actions, functions, permissions built in
An ontology is also not the same thing as RAG or a vector index — retrieval finds similar text; an ontology models entities, relationships, and governed actions. The full comparison is in [ontology vs RAG](https://ibl.ai/blog/ontology-vs-rag). ## Why Do AI Agents Need a Data Ontology? Because grounding removes the translation layer where hallucinations creep in. LLMs work with tokens, not institutional knowledge — point an agent at raw, contradictory silos and it guesses, confidently. With an ontology, agents operate on the same structured knowledge humans use. The economics compound from there. **Build once, reuse everywhere:** a well-modeled entity type serves every downstream agent, dashboard, and report, so new use cases plug into the existing ontology instead of requiring fresh data pipelines. The tenth agent costs a fraction of the first. **Every agent benefits from every improvement.** Add a new entity type or relationship, and every agent that touches that domain immediately gains access. The investment compounds instead of fragmenting into one-off integrations. **Decisions become data.** Every action taken through the ontology — an approval, a classification, an override — is recorded and queryable. One user's insight becomes another agent's input, and audit trails are built in, not bolted on. And governance holds by construction: agents inherit the same permissions as the users they serve — no special access, no backdoors. The deeper failure analysis is in [why AI agents fail without an ontology](https://ibl.ai/blog/why-ai-agents-fail-without-an-ontology). ## An Example: One Ontology Across Real Systems Here is what a data ontology looks like in practice, using ibl.ai's [AI Data Unification](https://ibl.ai/service/ai-data-unification) service. A typical institution runs an SIS, an LMS, a CRM, a data warehouse, and a dozen SaaS tools — none of which agree on what a "student" or a "customer" is. The unified layer connects them in place. Databases — PeopleSoft, Oracle, Postgres, Snowflake — connect through the Google MCP Toolbox. REST-based systems — Canvas, Salesforce, Jira, ServiceNow, Workday — connect through custom MCP servers defined in tools.yaml. Source credentials never leave your network. It ships with defaults for 22 systems across higher education and enterprise — from Ellucian Banner and Slate to HubSpot, Okta, Slack, and Zendesk — each seedable with one command. The same pattern serves a bank's core systems, a hospital's EHR-adjacent stack, or an agency's case systems. Access is governed, not open. Version 1 is read-only by design, verified by a seven-test safety suite that halts provisioning if any write succeeds. Every MCP request carries the user's Microsoft Entra ID JWT, so an agent sees exactly what that user is allowed to see — row-level scoping included. The result: one MCP server, behind your firewall and identity provider, that any authorized runtime — ibl.ai, Claude, Cursor, or your own apps — queries as the single source of truth. No data extraction, no VPN to a vendor's cloud, no third party holding your records. ## Who Owns the Ontology? With most managed AI vendors: they do. Hosted tools ingest your data into *their* index, in *their* cloud, under *their* schema. The knowledge layer — the most durable asset in the whole stack — lives on someone else's servers, and you rent access to it. ibl.ai inverts that. The ontology implementation is open source and MIT-licensed at [github.com/iblai/ontology](https://github.com/iblai/ontology) — Python 3.11+, 163 passing tests, 85% coverage. It runs inside your perimeter: your cloud, your VPC, on-premise, or fully air-gapped. You own the code and the data. It is also model-agnostic. The ontology grounds any LLM — Claude, GPT, Gemini, Llama — and you switch models anytime, because the knowledge layer is yours, not a feature of one vendor's model. Pair it with [Agentic OS](https://ibl.ai/product/agentic-os) to deploy agents that act on the unified graph. That matters for regulated buyers — financial services, healthcare, government, education — where "where does the knowledge layer live" is a compliance question, not a preference. ibl.ai is family-owned and operated from New York, NY: a long-term partner, not a vendor that ships a license and disappears. ## Frequently Asked Questions ### What is a data ontology in simple terms? It's a machine-readable map of your organization: the things that exist (students, accounts, patients), how they relate (a student enrolls in a course), and what can happen to them (approve, enroll, update). AI agents read it to reason about your world instead of guessing. ### What is the difference between an ontology and a knowledge graph? The ontology is the model — the entity types, relationship types, and action rules. The knowledge graph is that model populated with your live instances and connections. In practice the two ship together: the ontology defines the graph's shape, the graph holds its data. ### Is a data ontology the same as a semantic layer? The semantic layer is one of the ontology's two layers — the nouns: entity types, attributes, relationships. A full data ontology adds an operational layer — the verbs: actions, functions, permissions — so agents can act within governed rules, not just read definitions. ### Can you own and self-host a data ontology? Yes. ibl.ai's implementation is open source and MIT-licensed at github.com/iblai/ontology, deployed inside your network — cloud, VPC, on-premise, or air-gapped. It queries your systems in place over MCP, so you own the code, the graph, and the data it maps. --- To go deeper: the modeling primitives — entity types, interfaces, derived attributes, semantic search, governance — are laid out in the [ontology framework](https://ibl.ai/ontology). For deployment, [AI Data Unification](https://ibl.ai/service/ai-data-unification) stands the layer up inside your network, and [why AI agents fail without an ontology](https://ibl.ai/blog/why-ai-agents-fail-without-an-ontology) covers what happens when you skip it.