Ontology, Knowledge Graph, Knowledge Base, Data Middle Platform: What's the Difference?

Over the past six months or so, almost everything I've worked with has ended up in an enterprise knowledge graph I built myself: nodes for domains, concrete cases, tech stacks, and common questions, connected by relationships. The reason was simple. You can't talk about enterprise AI adoption without ontology, enterprise knowledge base, knowledge graph, and data middle platform—yet many people can't explain how they differ. Since explaining wasn't working, I built a graph you can actually look at.

Here's a fact that may surprise you: most of these ideas predate large language models. Ontology and the knowledge base go back to the last century. "Knowledge graph" was coined by Google in 2012, and the data middle platform was proposed by Alibaba in 2015. So why did they suddenly become hot again once LLMs took off? To answer that, we need to get the concepts straight first.

Ontology: a skeleton of what must exist

"Ontology" sounds intimidating. In one sentence: an enterprise ontology describes the structure that objectively has to exist in a given domain—what things are in it, how they relate to each other, and what rules they follow.

Take an org chart. Company A has a boss, a director, and a team lead. The relationships are superior and subordinate. The rule is "you pay me, I work for you." Together, those three things form an ontology. It objectively exists, but it's only an empty skeleton with empty slots.

Knowledge graph: filling the skeleton with real people

Now put real objects into those empty slots: the boss is Zhang San, the director is Li Si, the team lead is Wang Er Mazi, a worker who gets worked to the bone. The relationships and rules haven't changed, but it's now Company A's org-chart knowledge graph.

That's the difference: the ontology is the skeleton, and the knowledge graph is what you get once concrete objects are assigned to it. Take a term like "core capability." On its own it's just an empty slot; give it a specific value and combine it with other terms, and you have a graph.

Knowledge base and data middle platform: making material retrievable

The knowledge base is easier. Any form of material inside Company A—documents, policies, manuals, case files—accumulated and stored, is a knowledge base.

Make the ontology, the knowledge graph, and the knowledge base retrievable online, then connect them to data from business systems, and you arrive at what people call a data middle platform. So these four aren't substitutes for one another; they stack. The ontology defines the structure, the graph fills in instances, the knowledge base stores the material, and the middle platform connects all of it to business data.

So why did they blow up again with LLMs?

LLMs didn't make these concepts new. They made the most expensive, labor-intensive steps cheap. Four things stand out from my own experience.

1. Ingestion: from labeling one record at a time to letting the model extract

Building a knowledge graph used to be brutal. First you designed the ontology, then you labeled data one record at a time or wrote rules. In trickier cases you trained a named entity recognition (NER) model. Change industries and you'd basically start over. And there was one killer problem: entity alignment.

Not anymore. Hand a document to an LLM and it extracts entities and relationships directly; a human just reviews. My own material was organized in three minutes. In the past, the amount of manual work involved would have made me not even want to try.

2. Query and output: no more writing a new query for every phrasing

Once the graph was built, querying used to mean writing dedicated query statements, wrestling with templates, or training a relation-extraction model. Phrase the question differently and you might get nothing.

Now you just ask in plain language. When I throw in a random question, I can see entity linking automatically find the key node in the graph—even though the exact sentence I asked isn't in the graph at all. That's automatic filtering. Output works the same way: the graph may not contain the answer, but the LLM can summarize it and tell you clearly. Before, it would just dump everything on you and let you sort it out.

3. Traceability: enterprises need the answer and where it came from

This is the most important point, I think. In many enterprise AI scenarios, what's needed isn't just an answer but how that answer was reached and what it's based on. Reports need to be traceable; conclusions need to be reviewable. Knowledge graphs are a natural fit, because every conclusion corresponds to a path of relationships.

In my setup, when it answers, it highlights every path it used. Open a node and you can see how that path was traversed; the sources below link back to the corresponding nodes in the graph. The answer is no longer a black box—there's a paper trail.

4. The agent's last mile is structured data

Everyone's talking about agents—AI that doesn't just chat but gets things done. But for an agent to act, it has to understand how your company operates, and that's not something ordinary text can explain.

Take equipment fault diagnosis. The fault might still be diagnosed by algorithms like FM or neural networks. But after the model makes its call, it's the graph we built that tells the agent: what the common causes of this fault are, how it was repaired historically, whether there are spare parts, and who's responsible. With that, the agent calls the work-order system and turns it into a task. The reviewer sees the whole trail clearly and just clicks confirm—done.

Final thoughts

That's why ontology is being brought up again: it's not just about letting AI understand the business, but letting AI act within the rules.

Anyone can buy a model. What really separates companies is whether they've rebuilt their business into a structure AI can understand.