What is an ontology?

Where does the word "ontology" come from?

Ontology started in philosophy as the study of what exists. The word comes from Greek: onto ("being") plus logia ("study").

Computer science borrowed it in the early 1990s. Stanford researcher Tom Gruber wrote the definition people still quote: an ontology is an "explicit specification of a conceptualization."

Translation: you write down, clearly enough for software to follow, what things exist in your world and how they relate.

What does an ontology look like? A simple example

Picture an equipment-heavy operation. Its ontology might say:

• Things (classes): Asset, Project, Person, Invoice, Budget
• Details (properties): an Asset has a serial number, a location, and a status
• Relationships: an Asset gets assigned to a Project. A Person operates an Asset. An Invoice charges against a Budget.
• Rules: an Asset sits on one Project at a time. Every Invoice needs a cost code.

Then you plug in the real stuff. Excavator #14 sits on the Riverside project. Jo operates it. Last week's hire invoice hit Riverside's equipment budget.

Now ask, "What is this excavator costing us on this project?" With an ontology, software follows the links and answers in seconds. Without one, somebody opens four spreadsheets and starts guessing.

What are the parts of an ontology?

Most ontologies use the same five building blocks:

1. Classes: the types of things (Asset, Project, Supplier)
2. Properties: the details each thing carries (status, cost, location)
3. Relationships: how things connect (assigned to, operated by, billed against)
4. Rules: the logic that keeps it honest (one project per asset at a time)
5. Instances: the real records (Excavator #14, the Riverside project)

The W3C's OWL 2 Primer describes the same core pieces: classes, properties, and individuals, plus the statements that tie them together.

Ontology vs. taxonomy vs. knowledge graph

People swap these words constantly. They do different jobs.

Think of the ontology as the rules of the game and the knowledge graph as the live score. A taxonomy just tells you which team each player belongs to. (Neo4j's breakdown goes deeper if you want it.)

What's the difference between an ontology, a context layer, and a knowledge graph?

These three get mixed up a lot, mostly because they work as a team. Here's the short version.

• Ontology: the definitions. What an Asset is, what a Project is, and how they can connect.
• Knowledge graph: your actual records, connected according to those definitions. Excavator #14, the Riverside project, last week's invoice.
• Context layer: the part your AI and apps actually talk to. It takes a question, pulls the right slice of the graph, checks who's allowed to see it, and hands it over with sources attached.

Think of a library. The ontology is the catalog system. The knowledge graph is the books on the shelves. The context layer is the librarian who knows what you're cleared to read and brings you exactly the right pages, not the whole building.

You need all three for AI that works in operations. A graph without an ontology turns into a messy pile of links. An ontology without a graph is theory. And without a context layer, every AI tool and agent goes digging through your data its own way.

Why an ontology vs. a context dump vs. RAG?

There are three common ways to give an AI model your business context. They solve different problems, and they cost very different amounts.

Context dump: paste everything into the prompt (docs, exports, spreadsheets) and let the model sort it out. Easy to start. But you pay for every token on every question, and more isn't better. Chroma's research on 18 models found performance drops as input grows, and Stanford researchers showed models tend to miss facts buried in the middle of long prompts.

RAG (retrieval-augmented generation): search your documents for chunks that look like the question and send only those. Cheaper, and great for "find our policy on X." But it matches text, not relationships. Microsoft Research found standard RAG falls short on questions about a whole dataset, and it struggles to connect facts that live in different systems.

Ontology: the AI asks for the exact records it needs and follows the links between them. "What is this excavator costing us on this job?" becomes a short trip through Asset, Project, Invoice, and Budget instead of a pile of text.

These aren't either/or. Use RAG for documents and an ontology for your operations. The ontology is what keeps AI answers about your actual business short, cheap, and checkable.

Why does an ontology matter?

Your systems stop arguing about words. Your ERP says "job." Your project tool says "project." Your telematics feed says "site." An ontology says they're the same thing, so data finally lines up.

You can answer questions that cross systems. Who's on this project, what equipment is there, what it's costing, and whether anyone already approved it. One question, one answer, instead of a week of reconciling exports.

AI gets grounded in what's actually true. A language model predicts words. An ontology hands it defined things and real relationships to reason over, so every answer traces back to a record you can check.

Every app and agent works from the same picture. When your apps, agents, and teams share the same definitions and the same governance, one team's change doesn't quietly break another team's report.

Knowledge stops living in one person's head. The logic your best operator carries around ("that column is actually the equipment schedule") gets written down where everyone, and everything, can use it.

Why are ontologies important in the age of AI?

AI models are smart about language and clueless about your business. The ontology closes that gap. Here's what that means on the P&L and in the field.

Smaller AI bills. You pay per token. When every question drags in a stack of exports, every answer costs more than it should. With an ontology, the AI pulls a handful of relevant records instead of the whole haystack, so your cost per answer drops as usage grows instead of climbing with it.

Answers you can trust. Less noise in the prompt means fewer wrong turns. And because every answer points back to specific records, your team can check it in seconds instead of re-running the numbers by hand.

Agents that can actually act. An agent that knows an invoice belongs to a commitment, a cost code, and a job can route it to the right approver. A person confirms, and the change lands in your system of record. That's the jump from AI that summarizes to AI that does the work.

Every new use case starts at mile 10, not mile 0. Define your business once and every new app, agent, and dashboard reuses it. No more each team building its own prompts, its own data copies, and its own version of the truth.

Governance that scales. When every app and agent runs on the same data with the same permissions, you know who changed what and why. Without that, one well-meant agent with the wrong access can do real damage to a system you depend on.

Freedom to switch models. Your business knowledge lives in the ontology, not in prompts tuned for one AI vendor. When a better or cheaper model shows up, you can swap it in without starting over.

Do you need a giant ontology project to get started?

Short answer: no.

Ontologies have a reputation for multi-year mapping projects. Some earn it. But you don't need to model the whole universe to run better operations. You need the things your workflows actually touch, built on open standards like the W3C's Web Ontology Language (OWL) and schema.org, so it connects to everything else later.

At Ontollo, that's how we build. We start from your real workflows, map your systems and spreadsheets to standard objects, and keep the tools you already use. The result is one live picture of your operation. We call it your System of Reality.

See how it works for construction →

Can I build an ontology myself?

Yes. The standards are open (like OWL and schema.org), graph databases are easy to find, and AI tools are great at reading messy spreadsheets. The model itself isn't the hard part. Here's what a working ontology actually takes:

1. Model it. Pick the things and relationships that matter, then get finance, ops, and the field to agree on what each one means. (This is more negotiation than engineering.)
2. Map it. Connect every system and spreadsheet, and resolve the duplicates. Job 1042 in your ERP is the Riverside project in your PM tool.
3. Keep it live. Syncs break, fields change, and records go stale. Someone has to own that every week, not just at launch.
4. Govern it. Decide who can see and change what, down to the row, and keep a record of every change and every AI action.
5. Put it to work. Build the apps and agents people actually use, on top of all of the above.

If you have a data team with the time to own all five for the long haul, building it yourself is a real option. Steps 3 and 4 never really finish, though, and that's usually where in-house projects stall.

Ontollo handles steps 1 through 4 as a platform, so your builders and operators can spend their time on step 5. Same data, same governance, for every builder and every team at once.

What's the advantage of working with Ontollo to build out an ontology of my business?

Many organizations choose to partner with a provider to help build out their business ontology. One of the leading providers that large enterprises work with is Palantir.

Palantir did a lot to put "ontology" on the business map. Its Foundry platform is built around one, which Palantir's own documentation describes as an operational layer that ties data to real-world things like shipments and transactions. Deployments typically start with Palantir's forward deployed engineers mapping your systems into the platform.

That's a serious option for a large enterprise signing up for a big, platform-wide transformation.

At Ontollo, we take a different approach:

• Keep your tools. Ontollo sits on top of the systems you already run. No rip-and-replace, and no moving your operation into a new platform.
• Start small, on purpose. We model the minimum set of things your operations workflows need, not the whole universe, so you see value early.
• Built on open standards. Ontollo's model follows W3C and schema.org standards, so it connects to other ontologies and tools instead of locking you in.
• Your people build. Operators and internal builders create apps for their own slice of the work using governed building blocks, instead of waiting on a vendor's engineers.
• Made for operators. Ontollo is built for operations-heavy businesses that need answers and action across field and office, not a multi-year data program.

Similar idea. Very different path to value.

Ontology FAQ

What is an ontology in simple terms?

An ontology is a shared definition of the things in a domain and how they connect. It names the types of things, the details they carry, and the rules that link them, so people and software mean the same thing by the same word.

What is an example of an ontology?

An equipment ontology might define Asset, Project, and Invoice, then say an Asset gets assigned to a Project and an Invoice charges against that Project's budget. With that in place, software can tell you what a specific machine costs on a specific job.

What's the difference between an ontology and a taxonomy?

A taxonomy sorts things into a hierarchy of categories. An ontology goes further: it defines what things mean, how they relate across categories, and which rules apply.

What's the difference between an ontology and a knowledge graph?

The ontology is the model: the types of things and how they can relate. The knowledge graph is your real data connected according to that model. One describes what's possible, the other shows what's true today.

Is an ontology the same as a database schema?

No. A schema describes how one system stores its data. An ontology describes what the data means, independent of any single system, so many systems can share one definition.

Why do ontologies matter for AI?

AI models are great with language but have no built-in sense of your business. An ontology gives them defined things and real relationships to reason over, so answers stay tied to records you can verify.

What is OWL?

OWL, the Web Ontology Language, is the W3C standard for writing ontologies. The first version came out in 2004, and OWL 2 followed in 2009.

Is an ontology better than RAG?

They do different jobs. RAG finds relevant passages in documents. An ontology gives AI exact records and the relationships between them, which works better for operational questions that span several systems. Many teams use both.

Does an ontology reduce AI token costs?

It can. Instead of sending the model large documents or exports, an ontology lets it pull only the specific records a question needs, which keeps prompts shorter and cost per answer lower.