Casey Hart is a rare thing: an actual ontologist — the job title Palantir once seemed to have a monopoly on. A philosophy PhD who answered a job ad from Cycorp and spent a decade building knowledge for machines under Doug Lenat and then at Olive, Amazon, Gro Intelligence, and Ford, he spends this episode deflating the word everyone is suddenly selling. An ontology, he argues, is just a summary of what your business cares about and how those things relate — you can start one on a Post-it note. He separates the machine-learning "system one" from the deterministic "system two" that ontologies supply, makes the case for a hybrid, and walks through building one from the ground up: taxonomies, relationships, turtle files and triple stores — or just the metadata, so you get value before migrating a single row. Along the way: why "hallucination" flatters a text generator doing exactly what it was built to do, the open-world versus closed-world assumption, and why vibe-coding an ontology out of an LLM is a fine way in but not a finished asset.
A philosopher-turned-ontologist and founder of Casey Hart Consulting, where he helps organizations understand what ontologies are, what they can do, and how to actually build them. He fell into the field almost by accident — a philosophy PhD from the University of Wisconsin–Madison who answered a posting from Cycorp and spent three years building common-sense knowledge in CycL under Doug Lenat, before developing core ontologies at Olive, Amazon, and Gro Intelligence, and today at Ford. His academic background is in formal and social epistemology, philosophy of science, and metaphysics; he runs the YouTube channel "Ontology Explained" and co-hosts the podcast "Philosophy, Programs, and Prompts," and works most in healthcare, automotive, and energy.
Four clear reads — who should act, and how urgently.
Feed a dataset to an LLM and have it generate a starter ontology — it's a relatively painless way to feel out how the model maps to your data. Just don't ship the rat's nest: valid turtle that compiles is no more "good" than Python that compiles, so keep a qualified hand between the draft and production.
You don't have to move every row into a graph. Model the metadata first — what data you have, where it lives, what the columns actually mean — and you get analyst-time savings and duplicate-column cleanup before any heavy ETL.
If your data always looks the same and you do the same thing with it every time, a plain program beats an ontology. The payoff is reuse and future options — commission one only when you'll actually build on it, and treat it as an ongoing effort, not a deliverable.
An ontology is a summary of what your business cares about and how those things relate. Write down as many true things as you can, leave room to get more specific later, and grow it as it earns its keep. Responsible use of AI — not "responsible AI."
CaseyOne way to conceive of ontology: take the Kahneman-and-Tversky, thinking-fast/thinking-slow view. The fast, gut-reaction part is machine-learning-ish. The slow, logical, methodical part — that's good-old-fashioned AI, and that's where ontology sits: building a model that can ground those reasonings. Philosophers turn out to be pretty good at exactly that — stop, reflect on your assumptions, formalize them, see how they fit into arguments that generate the inferences you want. That combination of carefulness and a little creativity suits the field.
VivekYou were building ontologies before transformers. When these models arrived and became so important to so many people, when was the point you realized: this still needs exactly what you do — it needs a system two, this is only a system one?
CaseyI was never that sold on it being everything. LLMs are super cool; they do lots of awesome things. But they still fit under the machine-learning umbrella. Fundamentally you've got training data, and you're building a model that compresses the information in it. A lot of that text correlates with important knowledge — but as you compress it down, it's just not possible that it has a total understanding of what the world is like. It's a little pejorative to say all an LLM does is guess the next word, but there's something importantly true about it: it's a pattern predictor for the kind of sentence you'd see in the training data. That's not inference; that's not knowing facts about the world and reciting them. So you end up with these hallucinations.
CaseyThe thing that bothers me about "hallucination" is that I almost just want to call it a bug — we have a text generator and it's generating bad text. But calling it a hallucination gives it an excuse, and makes it seem more psychologically sophisticated than it is. If someone cut the brake lines on my car and it ran into the garage instead of stopping, and the manufacturer said "the car made an educated decision that stopping was unwise," I'd say no — the car wasn't thinking, you gave me a bad product. Yet when LLMs screw up, we make them seem even smarter: it's so sophisticated that it's messing up. That's not right.
VivekWe tend to use "generation" more than "hallucination." It's generating stuff — when it aligns with your point of view it's fine, and when it doesn't, that's when people call it a hallucination.
CaseyInstead of calling it a bug, which suggests we can remedy it — the thing wasn't doing anything wrong. It was performing exactly as intended: making text in accordance with the vector spaces, the weights, and the random-number generators you assigned it. It did what we asked. It just turns out we don't like all the things we asked it to do.
VivekYour first stint as an ontologist was in a proprietary representation language, very different from the OWL and RDF world where most of the conversation happens today. What was that like, and what carries over?
CaseyAt Cycorp the language was CycL, a Lisp variant. The big differentiator: Cyc wanted a very robust, expressive language, so a predicate could relate as many objects as you liked. In OWL/RDF you basically have two-place relations — you're making a graph, nodes connected by edges. "Casey ate pizza" — Casey and pizza are nodes, "ate" is the edge. At Cyc I could say Vivek and Casey and Josh do a podcast together — an n-ary relation with as many participants as I want. Now you're not in a two- or three-dimensional graph, you're in n-dimensional space. And Cyc's mandate was common-sense reasoning, so you represent facts as generally as possible: not "my tennis racket fits in my tennis bag," but "smaller objects can fit inside larger ones."
CaseyAt Cyc we had an insult for the OWL/RDF folks — they only get to say things in three-word sentences, how ridiculous is that? Then I went and played with it myself. In some ways it's way simpler, easier to express stuff; other times I'm upset I have to find tricks to say the more fine-grained thing. But you can reify: instead of "Casey married to Josh," say there's a marriage event with participants Casey and Josh, and hang dates on it. RDF-star — RDF 1.2 — lets you express the statement itself as a subject. But reifying the event and reifying the statement turn out to be isomorphic, so I don't think 1.2 actually buys you more expressivity — Ora Lassila, one of the semantic-web Mount Rushmore guys and on the W3C committee, feels about the same. What it does give you is another place to hang metadata: who made an assertion, how confident you are in it.
JoshuaSo where do you sit — more symbolic, more neural?
CaseyThe right answer is a hybrid. Machine learning is obviously really useful, but it's error-prone, computationally expensive, and not transparent. There are lots of times you have to trust the output — and I'm not going to trust something that says "I ran six billion computations, generated these vectors, now take the chemotherapy." No thank you. So the right answer uses a machine-learning approach where you have the right data and want to generate new insights, but it also has to have a grounded world model and a set of reasons and inferential steps that explain why I should be compelled by the output of the machine.
VivekFor people who aren't philosophy or math grads, "ontology" is just an English word — so when someone says their chatbot has an ontology problem, it's hard to make sense of. And they've had amazing experiences with LLMs: the model just gets me. How do you bring them up to speed?
CaseyYes, we want gut reactions from a lot of experience — a medical case: I looked at 15,000 patients with similar biomarkers, and 10,000 had a hip replacement in their sixties. That's useful. But you couple it with what we understand about how the world works — anatomy, how joints work, what promotes joint health. The ontology lays out: here's what we understand the world to be like, here are facts and laws about how it works, and that runs in conjunction with the statistical knowledge. Another way in: everyone who uses LLMs now knows prompt engineering and context give you far better answers, and a lot of what's happening there is you're grounding the model — take X, Y, and Z for granted. An ontology is doing much the same thing: here's a bunch of stuff we say is true and how the pieces relate. Feed parts of that graph into the LLM and you get better results.
VivekSo how do I actually build one — and once I have it, how does my agent access ontologically enriched data, if that even means a thing?
CaseyA really common integration isn't even agent-centered. Organizations have a ton of data and don't even know what they have — new analysts take six months to find where data lives, then hit a database with 5,000 columns nobody understands. So one use of an ontology is to say: here are the kinds of things your organization cares about. If you're an airplane manufacturer, you care about airplanes and all their parts, so build a taxonomy of the mechanical parts, plus the things every company has, like HR and employees. Then map your databases in: this database is about these things, these fields tell me about these properties. Now you query it — "what datasets do we have about airplane-wing tensile strength?" — and it returns where they live and which column holds it. Simple, but hugely valuable: it shortens analyst time, and it surfaces seven columns all claiming to be the same thing so you can ask whether they really are.
CaseyHow is this realized? Most of the time I'm dealing with .ttl turtle files, stored in a repository and loaded into a triple store — Amazon Neptune, GraphDB, Apache Jena, whatever — and that's what you run queries against. To build the turtle files, the first and most important step is to pay me lots of money. But really: you need someone qualified. You can take third-party upper ontologies off the shelf, and in biomedicine there's BioPortal — but if you have no ontology experience, be careful, because you can't evaluate whether it's any good. It's like me deciding to vibe-code a production app: I'll end up with a rat's nest. Fine to get going, but for production-worthy work you need someone who can oversee it. The nuts and bolts: build the taxonomies and classes — the kinds of things you care about — define the relationships, fit it into OWL/RDF syntax, and build an ETL to get your data into that format.
CaseyThis is why I suggested the metadata strategy. If you go metadata-first, you don't have to transform every row — you just say this database has this name, lives in this place, and is about these types of information. So you're not on the hook for migrating all your data into a graph. Put the metadata in the graph and you already get value out of it.
JoshuaWe need ontologists, we need people like you to consult. But who inside the organization owns that asset in the end?
CaseyGreat question, and I don't think there's a single answer. An ontology is part of the knowledge layer, the semantic layer — and the grand vision is that all your data can be oriented within it, so it doesn't live in any one place. If the goal is better, future-proofed data schemas, I probably live with the data engineers. If it's making an LLM speak the customer's language and grounding it in what your clients know, I'm more on the product side. But however you slice it, an ontologist ends up interfacing with the engineers building the architecture that houses the ontology, and with the product people who know how the model makes a difference to the user.
VivekMost small and mid-sized businesses don't have a knowledge-management function at all — their response to it is part cringe, part "how boomer are you?" But they badly need a system two to make their agents reliable. How painful is that transition for them?
CaseyThere's a trap: thinking the semantic layer is this huge, wonderful thing that holds all your information and gets you to ASI. You can't do that. Like any initiative, ask: what's a problem I have right now that I can solve incrementally, show value, and reuse the infrastructure over time? A lot of smaller orgs tell me "ontology sounds cool," and it turns out their data always looks the same and they do the same thing with it every time — don't build an ontology for that, write a program. But I worked with a small equipment-rental client who wanted smart suggestions: we built a taxonomy of the products and said what those products are capable of, so when someone needs to repair a blacktop lot, haul away waste, and lift people up to fix the streetlights, you can ask which machines lift people. A relatively small model, real value.
CaseyIt sounds more complicated than it is. My recent kick: an ontology is a summary of the stuff your business cares about and how those things relate to each other. You can have an ontology by writing it on a Post-it note and sticking it to your laptop screen — that's a first pass, and it already has benefits. There's a little bit of ontology that's just data therapy: sit down and ask what my data looks like, what I'm actually using, what these things mean, am I using the same term everywhere or different terms for the same thing. Asking those questions is valuable even if you never do a single other thing with the ontology.
CaseyOne thing feels so natural to me but clearly isn't to a lot of the software world: the open-world versus closed-world assumption. Closed world says if it's not provably true in our data model, it's false — we assume the model fully encompasses everything. The open-world model — the OWL/RDF way — says if it's not provably true in my model, maybe I just don't know about it. I asserted Casey is an employee and didn't give his social security number; that doesn't mean he doesn't have one, just that I don't have it in my dataset. People used to closed-world schema building feel they've got to get it all in up front, and that's not the way to think about ontology. Build as much of the model as you need to answer the questions you have, say as many true things as you can, and let it grow. Though there are times I do want to close the world — if I don't have an SSN for an employee, throw an error; that's what something like SHACL is for.
CaseyAsking an LLM to build an ontology for your dataset and seeing what turns out is a great, relatively painless way in. Just don't fall prey to it the way you would if you'd asked it to write your program — it'd do some good stuff and some really stupid stuff. It compiling, and being valid turtle, doesn't mean it's any good, the same way it can make Python that compiles. Run with it in the responsible ways of using generative AI — not "great, looks like we don't need ontologists after all."
Open this episode in your assistant with the summary, key points, and a link to the full transcript — then put the insights to work in your own context.
Opens in a new tab · shares only this episode's public transcript link
Karthik Soman invented KG-RAG — knowledge-graph-based retrieval augmented generation — while building biomedical knowledge graphs at UCSF, and now leads enterprise-scale agentic AI at SAP America. One question carries from a PhD in computational neuroscience to the enterprise: how do you build intelligent systems that actually work in the real world? His answer isn't a better accuracy number but a different kind of answer — one a human can trace, question, and learn from. He walks through the case that convinced him: enriching patient records with a 40-million-node biomedical graph surfaced an olfactory-receptor gene that flagged Parkinson's five years early, catching a prodromal case a clinician had missed — not because the model was more accurate, but because it pointed at a mechanism. Then he moves to the enterprise, where the curated ontologies of biomedicine don't exist. You lean on the topology already inside your documents. Graph-based reasoning turns out to be a sixty-year-old idea that LLMs merely made usable on the fly. And a graph earns its keep over vector RAG in specific places — multi-hop questions, smaller models, private data the model never saw — before the least glamorous advice in AI: data hygiene first, then AI hygiene.
Melli Annamalai has spent 27 years at Oracle watching technology waves crest and break — multimedia retrieval, the semantic web, big data, property-graph analytics, and now knowledge graphs for AI. As the Distinguished Product Manager who leads graph technologies there, she makes an argument you rarely hear from a database vendor: a knowledge graph is one tool in the kit, not the destination. She traces why semantic-web tech stalled for two decades: a steep learning curve, a custom RDF/OWL/SPARQL ecosystem, and a year-and-a-half payback that senior management wouldn't fund. Then what AI finally changed, and where these projects still quietly fail — over-engineering everything into a graph, tuning and tooling gaps, and the security officer who shuts it all down. Along the way, a working definition of "ontology" for non-technical buyers, natural language as the new query language, and Oracle's converged-database bet to collapse the graph, vector, and agent layers into the place the data already lives.
Tony Seale spent two decades stitching together siloed data inside investment banks — Lehman, Deutsche Bank, UBS — until he concluded the hard part was never the model, it was the data. Now widely followed as "the knowledge graph guy," he makes a precise argument: a large language model is rented intelligence you don't own, while the ontology and knowledge graph you build are the durable IP that stays inside your organization. He walks through the neuro-symbolic loop — why LLMs are continuous and knowledge graphs discrete, and why you cycle between them rather than pick one — coins Seale's Law on how marketing hollows out a word's meaning, and warns that companies that don't consolidate their "ontological core" will watch their advantage quietly leak out. Along the way: semantic data products and the DPROD standard, why true open standards (schema.org, W3C) beat vendor "open," and why the agentic web arriving next makes getting your data estate in order the only move that counts.
The hybrid Casey argues for — machine-learning "system one" paired with a grounded, deterministic "system two" so the output is one you can trust.
The plain-language version of Casey's demystification — an ontology as a summary of what your business cares about and how those things relate.
Start with metadata, not migration — mapping what data you have and where it lives before you convert a single row into a graph.