Austin Kronz opened episode four with an observation. Almost every customer conversation he has now includes some version of the same question: what about ontologies? Vendors are selling them. Buyers are asking for them. Hardly anyone agrees on what the word means. A discipline with thirty years of research behind it has become a line item in AI budgets, and most of the people funding it could not define it.
So start there. An ontology is where a business writes down what its things are and how they are allowed to relate. What a customer is. What a product is. What can connect to what, and what cannot. That work is decades old, and it has mostly been paid for in fields where a wrong definition is expensive, like biomedical research and finance. Inside everyone else it was the project that got shelved, because the strategy was to collect more data rather than describe it better. Then the returns on collecting more data ran out.
Jessica Talisman has spent 25 years building this kind of infrastructure, and created the Ontology Pipeline. Her argument in this episode is that most teams enter that pipeline at the wrong end. They reach for the ontology while their own terms are still undefined, and an ontology built on undefined terms hardens the mess instead of fixing it. Austin pressed on what that means for the question the series keeps circling. Is the ontology the context layer, one component of it, or a rebrand.
Q: Ontologies have existed for decades. Why are enterprises funding them now?
Talisman dates the shift precisely, and it is recent. Through the big data era, roughly the early 2000s until frontier models became available, enterprise attention went to collection, storage, and query. Ontology work was real work, but inside a company it was the project that got shelved.
"The work that was deprioritized was the ontological work."
Then the returns on volume ran out. Adding more data stopped making models measurably better, and models trained on machine-generated content get less performant, not more. That is when attention moved from how much data you have to how well it is described, which is why data definitions, metric layers, and semantic layers all came back into the conversation at once.
RAG gave teams the first live proof. Those early implementations leaned on ontology work to hold their accuracy together, and for most organizations that was the first time careful description visibly changed the behavior of a system they had already shipped.
"What's changed is we're realizing that description is what matters."
Cost is the third driver, and it is the one that moves budget fastest. An ontology is encoded once and reused, so agents stop working out the same meaning on every run. Austin described the version every team recognizes: the invoice arrives, and behind one basic answer sit hundreds of tool calls the agent looped through to figure out what your terms meant.
Q: What has to exist before you build an ontology?
An ontology structures your data as classes, the things that define your domain, then declares rules for how those things relate. Some things can be related to each other. Some cannot. Once definitions and constraints are both in place, a human and a machine can read the description of a thing and arrive at the same answer. Talisman calls that descriptive access.
The failure she sees most often is teams skipping straight to it. They assume the labels and definitions already sitting in their semantic layer are enough, then model on top of them. Her example is a category called "other," which is a junk drawer with no definition. Formalize that as an ontology and you have made the ambiguity permanent.
"An ontology doesn't magically fix things. An ontology requires that hard work of defining and understanding your domain in order to properly structure it as an ontology."
The order she recommends:
- Controlled vocabularies: the agreed terms, wherever they currently sit. SharePoint, Confluence, Jira, your catalog.
- Taxonomies and thesauri, encoded in SKOS, which expresses that vocabulary as RDF triples.
- The ontology, which reuses the definitions your taxonomy already settled.
- The knowledge graph, which is an architecture built on all of the above.
SKOS is the training wheels. Teams learn to model and query RDF on something small, and the definitional work carries forward into the ontology instead of being redone. Talisman notes that the World Bank, Getty, Wikidata, and several EU governments publish vocabularies this way, so the format is already well represented in the material these models trained on.
Q: Can an LLM build the ontology for you?
It can expand one. It cannot start one. Give a model a framework that defines the overarching things in your environment, plus some guidance, and it will extend that structure fast. Ask it to build from scratch and you are asking for something it has no way to produce.
"It's a statistical probability machine. It doesn't encode meaning. It doesn't naturally understand the meaning of your organization."
"Digital asset" at a financial institution and "digital asset" at an ed tech company are two different things. Nothing in the model tells it which one is yours. That first definition has to come from your organization, and how you write it matters as much as that you wrote it. Talisman's example: teams routinely define employee as a class, so when that employee leaves they get erased. Define person as the class and employment as a property, and the status changes while the history survives.
Her practical starting point is deliberately small. Take a subset of the terms that matter, structure them in a spreadsheet with definitions, run it through SKOS Play, and get RDF back. Use that vocabulary in a project folder or a RAG setup and check whether the agent improves. Before building anything larger, write competency questions: the specific questions the ontology has to answer. They scope the build, and they become the evals you validate against.
"We do not build ontologies until we form competency questions."
Q: Is the context layer just a new name for the ontology?
Talisman's answer is no, but not because the two are unrelated. The ontology is one component of the context layer, and context layers, like knowledge graphs, can be built in many different architectures.
The word doing the most damage is graph. A graph is an architecture, not a definition. It may include indexing, NLP, a knowledge base, a vector store. A property graph can run schema-less, which leaves nothing holding your descriptions stable over time. An RDF graph works inside declared constraints. Your taxonomy and thesaurus encoded in SKOS are already a concept graph, and Talisman's view is that for plenty of implementations, that is enough.
"A graph itself involves more than an ontology, more than a schema, otherwise we'd just be talking about schemas and ontologies."
What she would push teams to examine instead is metadata. A metadata application profile maps how data moves, which systems are in play, and how meaning is represented across them. That map tells you which capability each requirement actually needs: where a taxonomy is sufficient, where an ontology earns its cost, and how much context a specific job requires. It is also, she noted, the part of the conversation nobody is having.
The claim worth carrying out of the episode is the one she flagged as controversial before she made it. Context exists in the relationship between things. If that holds, the things have to be defined before any of the relationships mean anything.
Episode five takes the graph question head on. Emil Eifrem, CEO and co-founder of Neo4j, joins Prukalpa Sankar on August 19 to argue whether graph databases are the foundation of the context layer or just where the structure gets stored. Register here.
