Every silo is its own context
Dave McComb has been building enterprise systems for fifty years and running Semantic Arts for twenty-five. His rule of thumb is one application for every ten employees, so a hundred-thousand-person company is running ten thousand databases that each name, structure and identify everything differently. That is also his answer to the age of context: the problem was never a shortage of it, it is that every silo has its own. Along the way he explains why an LLM will hand you an ontology that opens cleanly in Protégé and looks like exactly what you asked for, why that is the trap rather than the win, and what he found when he put semantic lenses back on his own accounting system after twenty years of not looking at it.
This episode hasn't aired yet — check back soon.
Dave McComb
Author of The Data-Centric Revolution, Software Wasteland and Semantics in Business Systems, and originator of gist, the minimalist open-source upper ontology now in its fifteenth version after two decades and more than a hundred data-centric projects. He started at Arthur Andersen building enterprise information systems in the 1970s, co-founded Velocity Healthcare where he patented the first fully model-driven architecture, and founded Semantic Arts in 2000. Its clients have included Procter & Gamble, Goldman Sachs, Schneider Electric, LexisNexis, Dun & Bradstreet and Morgan Stanley.
What we'll cover
- 01Fifty years from Arthur Andersen to Semantic Arts, including the part where the dot-com bubble took the investment bankers away overnight and left the patents behind.
- 02One application per ten employees: the rule of thumb that means a hundred-thousand-person company is running ten thousand databases that all name everything differently.
- 03"It's not that there's no context. There's way too many." Every silo is its own context.
- 04How he defines an ontology, and why a formal definition a machine and a human both agree on is the whole point, worked through two different valid definitions of "customer" inside one bank.
- 05The three traps of letting an LLM build your ontology: it learned from bad examples, it inherits your local schema's assumptions, and productivity gains push you the wrong direction.
- 06Why a large enterprise genuinely runs on a few hundred concepts, and why nobody can hold a million of them.
- 07Ford made 1.9 million vehicles in 1924 and 2 million in 2024, on paper and pencil the first time. Eight percent growth per century, and what that says about essential complexity.
- 08The data-centric strangler fig: lift data into the graph, move use cases over one at a time, switch the legacy system off when there is nothing left.
- 09Rebuilding accounting from the ground up on a graph, why commitments and fulfilment turn out to be the model, and the book that came out of it.
- 10A tour of gist's periodic table, and the client who listened to the Sherpa pitch and said they would rather have a helicopter.
Related episodes
Context lives in the relationships
Jessica Talisman has been building knowledge systems since 1997, when Steven Spielberg's Shoah Foundation hired her to catalog Holocaust survivor testimony, on VHS, into two-to-six-minute segments. Twenty-five years of library science and enterprise information architecture later (Amazon, Adobe, Overstock, and the Department of Justice among them), she watches the AI industry rediscover her discipline and hand it to the marketing department. Her central claim in this episode: context is a property, not an object. It lives in the relationships between things, and the document you paste into a window carries none of them, which is why a bigger window changes nothing. She walks through the Ontology Pipeline, her iterative alternative to the big-bang ontology project: define a controlled vocabulary, test it against your LLM, earn the SKOS taxonomy, then the metadata schemas and lightweight ontologies, with a shippable artifact at every stage. Along the way: why roughly three quarters of your organization's context never made it into the database, why taxonomy is the early readiness test for whether you can operationalize an ontology at all, why this is not a data problem, and why you augment before you automate. All from a guest who named her company Contextually years ago and now cringes at the word.
Bring the graph to the data
A citizen in Italy asks a public chatbot when their civil-service exam is. The honest answer keeps moving: dates get corrected, sessions get cancelled, and amendments pile up across official notices. Ask a language model alone and it answers confidently, sometimes with a date it picked at random, sometimes with a session that no longer exists. Giuseppe Futia built the knowledge graph that keeps the answer current. It does the deterministic cross-document work an LLM cannot be trusted with, matching each amendment to the exam it modifies, superseding old versions, cascading cancellations, and staying auditable throughout, inside a production pipeline behind a chatbot he says serves close to a million citizens. A former La Stampa journalist with a PhD from Politecnico di Torino, and the first European guest on the show, he also opens up the regulated side of his work: healthcare data that cannot leave the country, inference that runs on premise, and patient records he is not allowed to move even inside his own infrastructure. His portable lesson is the entry point. Prove value on one well-defined task the institution already needs, then earn the right to expand.
Relationships should be the product
Himanshu Singh has built knowledge graphs three times at three very different scales: a politics subgraph inside Microsoft's Satori, a zero-to-one product graph at eBay, and now Netflix's Entertainment Knowledge Graph, where he leads engineering. The line he keeps returning to is that relationships should be the product. Node count is not the measure, and a graph that duplicates what already lives in your CRM or your warehouse is mostly cost. He is notably relaxed about technology choice, pointing out that Netflix built its own real-time graph abstraction over a key-value store because no native graph database could absorb their write volume. What he is not relaxed about is data quality at the point of entry, because once bad data is in a graph and connected to everything else, undoing it is very hard.