ContextOps

Every few years the industry mints a new word — knowledge graph, grounding, now context — and within a few quarters vendors have stretched it until it means nothing. Alan Morrison has been tracking that pattern for over three decades, and this episode is about the cost nobody stops to add up: what happens when the word your team is building an architecture on has already been hollowed out by marketing.

Alan spent 20 years at PwC leading the firm's Technology Forecast publications, and is now the independent voice behind The GraphRAG Curator (graphrag.info), publishing on knowledge graphs, neurosymbolic AI, and the semantic layer underneath the current AI hype cycle. In this conversation, he explains why the problem was never the model — it's the data feeding it. Why "interoperability" in the AI era isn't a JSON export like the old SaaS migrations were. Why most large enterprises are stuck with one foot in application-centric architecture and one foot in a data-centric future they haven't committed to. And why he thinks this is the biggest change-management problem companies have faced since they retooled for wartime manufacturing.

Alan also walks through the "foxes and hedgehogs" model for getting knowledge-graph pilots past the innovation-pocket stage into firm-wide adoption — and makes the case that leadership's first job isn't picking the right vendor, it's building immunity to the hype cycle itself.

Stephane Fellah first ran into RDF in 1999, on a geospatial standards project, years before most of the industry had heard the term "semantic web." He founded Geoknoesis LLC, spent 12 years as Chief Knowledge Scientist at Image Matters running projects for DARPA, NGA, and SOCOM, and now edits the HSML specification for the IEEE Spatial Web standard. He joins Vivek Khandelwal to argue that large language models did not make his 25-year case for semantics obsolete - they made it easier to sell.

They cover why GML (the geospatial data standard) was originally written in RDF before Microsoft and Oracle pushed the market toward XML, what a real AI-generated "ontology" looks like when it fails (one insurance client ended up with 15,000 classes describing what should have been a few hundred), how to scope an ontology around business decisions instead of a borrowed philosophy or a database schema, why property graphs like Neo4j solve a different problem than knowledge graphs do, and his closing case for AI agents needing verifiable credentials.

Karthik Soman went from a PhD in computational neuroscience at IIT Madras to building biomedical knowledge graphs at UCSF, where he invented KG-RAG and helped build SPOKE, a graph connecting 40 million biomedical concepts across more than 70 million relationships. He now works on enterprise AI and data analytics at SAP. He joins Vivek Khandelwal and Joshua Thomas to explain why a knowledge graph caught a case of Parkinson's disease that a specialist missed, and what that means for the AI everyone is trying to make trustworthy today.

They cover why comparing LLMs to the human brain is comparing apples and oranges, how KG-RAG produced a 71% relative improvement in question answering on a smaller open-source model, why a "loose" knowledge graph built straight from document structure can outperform a formal ontology when no curated vocabulary exists, what NSF's Proto-OKN and NIH's Biomedical Data Translator project teach enterprises about standardizing data across silos, and why he ends nearly every consulting conversation the same way: data hygiene first, then AI hygiene.

Melli Annamalai has led graph technology product management at Oracle for the second half of her 27 years there, after a NASA-funded PhD in satellite image retrieval, early semantic web work, medical imaging search, and Hadoop-era big data.

She joins Vivek Khandelwal and Joshua Thomas to make an unusually candid case against overselling knowledge graphs, and to explain the converged-database approach Oracle is betting on instead of moving data into a separate graph layer.
They talk through why RDF and SPARQL never won broad enterprise adoption despite decades of investment, why she still says she hopes the current AI-driven wave of interest doesn't fail, what actually separates an ontology from a comment or annotation, how to start building an ontology without the year and a half of upfront investment the old approach demanded, and what Oracle means when it says agents, property graphs, and vector search all run inside one SQL-addressable database.

Key takeaways:

- Semantic web technology stalled the first time around because it needed its own tooling ecosystem, its own query language (SPARQL), and a learning curve senior management wouldn't sign up for. SQL just kept working.

- Melli's own hedge on the current AI-driven knowledge graph wave: "I hope it doesn't fail." The line between what an LLM can do, what vector search can do, and what a graph is actually needed for is still not clearly drawn.

- An ontology, in her definition, is a schema for your data: a precise description of what things are and how they relate, more shareable and less ambiguous than a text annotation.

- Projects fail most often from over-engineering (converting everything into a knowledge graph instead of keeping relational data relational), immature tooling, and a security team that vetoes an unfamiliar vendor after the work is already done.

- Oracle's pitch is convergence: property graphs, RDF/SPARQL wrapped in SQL, vector search, and PL/SQL-defined AI agents all run inside one database, so the same data doesn't have to move to a different system to be queried a different way.

Knowledge Graphs have become glamorous, and Himanshu Singh's first question is whether you need one at all.

Himanshu leads engineering on Netflix's entertainment knowledge graph, and built knowledge graphs before that at eBay and at Microsoft Bing. His test is unsentimental: when relationships are sparse and predictable, the metadata on a node will carry them and a graph is the wrong tool. Graphs earn their operational cost when the connections are dense and the paths worth traversing cannot be predicted in advance. As he puts it, relationships should be the product.

In this conversation he explains what Microsoft, eBay and Netflix actually had in common, why a graph database is not the same thing as a knowledge graph, how business context should shape an ontology rather than the reverse, and what graph quality does to agent reliability. His closing advice is about what cannot be undone. Keep bad data out of the graph in the first place, because once it is connected, deleting one node means reasoning about every node around it.

Most knowledge graph advice assumes a blank slate. Giuseppe Futia works at CSI Piemonte, a forty-year-old public sector IT company serving administrations across Italy, where replacing the architecture was never on the table. He is a Senior Data Engineer there, a Fellow at the Nexa Center for Internet and Society at Politecnico di Torino, and a co-author of Knowledge Graphs and LLMs in Action. His answer was to change one piece of the pipeline and leave the rest alone.

The case is a chatbot that helps Italian citizens navigate public job competitions, where exam dates are amended constantly and the corrections arrive as documents that contradict each other. Feeding that pile to a vector database produced hallucinations. Modeling each session as a chain of nodes, one per amendment, gave the chatbot a deterministic answer and left a full history to debug against. Giuseppe also explains why established institutions are the hard case, and why ontology work should start from the questions your organization needs answered rather than a top-down definition of "customer".

The industry consensus for AI is simple - put a human at the end. Let the agent work, then have someone check the output. Mike Dillinger argues the opposite. Human effort gets multiplied by every agent downstream, so the humans belong upstream, designing schemas, setting priorities, and doing the domain modeling that becomes the guardrails.

Mike is a computational linguist who built and led the team curating LinkedIn's economic graph, where 150 million job titles were compressed into roughly 5,000 concepts. He now builds graph validation tooling at Hypergraf. He explains why a knowledge graph is a database and deserves the same scrutiny, why labels without definitions are the most expensive mistake in the field, and what happened when one pharma company's graph returned everything for every query. Along the way: taxonomies versus ontologies versus knowledge graphs, why embeddings are not a source of truth, and the neuro-symbolic case for changing the feature space instead of adding more data.

Bigger context windows do not give an organization shared meaning. Three hundred employees pasting different documents into their own prompts produce what Jessica Talisman calls the "cowboy deployment methodology."

Jessica explains what has to exist underneath reliable enterprise AI: defined vocabulary, explicit relationships, persistent knowledge, testing, and governance. The work can be slow and unglamorous, but it is also iterative. A controlled vocabulary becomes something you can use and test before progressing to taxonomies, ontologies, and knowledge graphs. Reliability starts with doing foundational work.

AI teams chase each new model release as though more capability will fix their production agents. Tony Seale argues that the model is rented intelligence. The durable asset is the ontology: the structure that captures how your organization thinks and what its data means. Tony spent more than a decade integrating siloed systems inside investment banks, including Deutsche Bank and UBS. Today, he is known as The Knowledge Graph Guy.

In this conversation, Tony explains why context is not a pile of text in a prompt. Context comes from the connections between facts. He breaks down ontologies, knowledge graphs, continuous versus discrete representations, and why enterprises need both neural creativity and symbolic precision. The discussion also turns to ownership. Can you switch models without rebuilding your organization’s intelligence? Can you move your ontology between vendors? And what happens when competitors use swarms of agents to piece together the knowledge your organization has never formally captured?

Tony’s advice is simple: concentrate on your data first. Organize what your business knows, own the structure that gives it meaning, and rent the models that operate on top of it.

Tony on LinkedIn: https://www.linkedin.com/in/tonyseale

The Knowledge Graph Guys: https://knowledge-graph-guys.com

A CTO has a 2M-token context window and thousands of recorded cancer-care calls. The plan sounds simple: pipe them in and ask the model to evaluate provider performance. Elliott Risch explains where that approach works, where it quietly stops catching the contradictions that matter, and why "the computer made a mistake" will not hold up when patient safety or a legal record is at stake.

Elliott runs R&D on semantic AI at Enterprise Knowledge. Drawing on his background in mathematical logic, he separates inductive systems, which make highly educated guesses, from deductive systems, which enforce rules that must hold every time. The conversation covers what a semantic layer actually does, how enterprises can govern the context supplied to an LLM, and the question every CTO should ask before adopting another AI platform: Who owns the meaning of your company, and can you move it?

Elliott on LinkedIn: https://www.linkedin.com/in/modusponens

Enterprise Knowledge: https://enterprise-knowledge.com