Knowledge Graph Insights

Ora Lassila and Adrian Gschwend

Even as RDF has become ubiquitous in enterprises and across the web, its awkward handling of reification — the ability to refer to other statements in a graph — has limited its wider adoption.

RDF 1.2 addresses this with the reifier: a new element that lets you attach provenance, confidence, and source directly to a relationship — including claims you're tracking but not asserting as true.

We talked about:

Ora and Adrian's extensive experience and backgrounds in the RDF community
how the need to better handle reification led to the development of RDF 1.2
the W3C's use of the term "recommendation," which many/most people would think of as a "standard"
the recent advancement of the RDF Concepts and Abstract Syntax and RDF Semantics specifications to "candidate recommendation" status
the new RDF triple term - and how it permits references to RDF statements that have not been asserted
some of the details that made reification difficult in prior versions of RDF: verbosity, inability to scale, etc.
how the ability to reason on data distinguishes RDF graphs from labeled property graphs
the high quality of the RDF 1.2 W3C working group and their confidence that their work has accounted for all of the important considerations that might arise
the challenges of dealing with the needs for both backward and forward compatibility
how committee specifications like RDF 1.2 compare with less collaborative vendor specifications
how RDF saves BMW millions of lines of code when reasoning over car features
how standards-setting has evolved over time, from codifying existing practices 30 years ago to more proactive approaches today
Adrian's appreciation for the working group volunteer contributors and how they exemplify the values of open standards, open source, and open data
Ora's observation about the truly open and transparent nature of the working group and the many benefits open standards, including the ability to avoid vendor lock-in

Ora's bio
Dr. Ora Lassila has been working on the Semantic Web since 1996, first exploring possibilities for knowledge representation on the Web—work that launched the W3C RDF activity—and later pursuing his ideas about using autonomous agents on the Web—something that became the original Semantic Web vision as articulated in the 2001 Scientific American article he co-authored. All this was preceded by several years of research work on knowledge representation, ontologies, agents, planning, and other classical AI technologies.

He is currently an Associate Director of Data Engineering and Governance at Accenture, working on topics like ontologies and knowledge graphs. He is also the co-chair of the current W3C RDF & SPARQL Working Group that is defining the next version of the RDF standard.

His prior positions include Principal Technologist (in the Neptune graph database team) at AWS, Managing Director (Head of Ontology Engineering) at State Street, Research Fellow (Head of Agent Research) at Nokia Research, and Project Manager at Carnegie Mellon University, among several others.

Dr. Lassila’s knowledge representation software flew onboard the NASA Deep Space 1 probe to the Asteroid Belt in the 1990s. He is also a Grand Prize Winner of the Obfuscated C Code Contest. He received his Ph.D (D.Sc) and M.Sc degrees at the Helsinki University of Technology.
Connect with Ora online

LinkedIn

Adrian's bio
Adrian Gschwend is the founder of Qlevia AI, an operational knowledge platform for enterprise AI, designed to help organizations turn complex, evolving data landscapes into reliable, real-time systems.

For more than a decade, Adrian has focused on making knowledge graphs scale, both technologically and in real-world applications. As an engineer, he has worked hands-on with enterprises and public institutions to solve complex data integration challenges, building systems that reflect how businesses actually operate and evolve over time.

Adrian has a strong background in open source and open data, contributing to large-scale government platforms in Switzerland and Europe, as well as working with organizations such as BMW. He also serves as co-chair of the World Wide Web Consortium RDF 1.2 Working Group.

His perspective is that while AI has advanced rapidly, most organizations still operate on fragmented and disconnected data. He is focused on closing that gap by building systems where data, context and decision-making come together into a reliable operational layer that adapts with the business.
Connect with Adrian online

LinkedIn
email: adrian at qlevia dot com

Resources mentioned in this interview

RDF 1.2 Concepts and Abstract Data Model
RDF 1.2 Semantics
The Semantic Web, Scientific American, May 2001

Video
Here’s the video version of our conversation:

https://youtu.be/VlRsTyHDdY8


Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 50. The standards that make the World Wide Web work are built on the volunteer labor of experts like Ora Lassila and Adrian Gschwend. Ora and Adrian co-chair the working group that is bringing a powerful new capability to the W3C RDF standard. In previous versions of RDF, reification has been a verbose and complex process. RDF 1.2 introduces a new rdf:reifies property that simplifies and streamlines the ability to refer to other triples in a graph as first-class objects.
Interview transcript

Larry:
Hi, everyone. Welcome to episode number 50 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Ora Lassila and Adrian Gschwend. Sorry, Adrian. My German is horrible at this point, but Ora's just started a new job at Accenture. That's really exciting. Maybe we'll talk a little bit more about that. Most people know him as like a longtime Neptune person at AWS. Adrian is the also well-known long time at Zazuko and now is the CEO at Qlevia. Anyhow, welcome to both of you. Maybe Ora, start with you. Tell the folks a little bit more about what you're up to these days.

Ora:
Yeah, thanks, Larry. Well, you pretty much said the important part, I'm just in the process of having switched jobs, but I am also the co-chair of the RDF and SPARQL Working Group at W3C, and have been that for quite some time now. That's, I guess, the important part here. Of course, I've had long history with RDF and started this whole thing back in the late '90s.

Larry:
Yeah, that's a little bit of an understatement to say that you've been involved a little while, but we can talk more about that later. Adrian...

Adrian:
Thank you, Larry. Happy to be here as well. Yeah, so well known probably for Zazuko, for a lot of the open source tools we do in the RDF knowledge graph domain. Some people know me for Qlever and QLeverize as well, where I'm a chief commercial officer right now. Qlevia, is basically my try to not have to talk about graphs anymore, so I want to scale the technology but solve problems, and for the first time venture funded, so that will be the next hopefully fantastic years.

Larry:
Oh, that's exciting. Looking forward to hearing more about that, and I neglected as I introduced you, the reason you're here is that you're co-chairs of this committee.

Adrian:
True.

Larry:
Yeah, so one of you talk a little bit about, and maybe Ora, the history of the project and how the need to upgrade to 1.2 came about.

Ora:
Right. Well, so we go all the way back to the first version of RDF. In the late 90s, it introduced something that we call reification, which basically lets you talk about RDF statements, so RDF graphs are all about statements, where you say things like, "Adrian's nationality is Swiss." That would be like a statement, but then sometimes you need to talk about the statements themselves. So if, for example, if I wanted to say, "Adrian believes that the moon is made of cheese," I don't necessarily want to say the moon is made of cheese, but I want to talk about the fact that Adrian might think this way. And so, reification was a mechanism to accommodate something like this. Interestingly, if you look at the draft versions of the first RDF specification, the reification kind of started out fairly close to the top of the specification, and in consecutive version, it moves further and further back. I always think that, once it got published, it became sort of the most misunderstood and most hated part of RDF in many ways.

Ora:
It's a little cumbersome and misunderstood, because I think people took some of the stuff too literally, but over the years, people have suggested various ways of "fixing this," and a little over 10 years ago, there was a paper called Reification Done Right that was written by a couple of my former AWS colleagues. That got people sort of reengaged with the idea of reification really should be fixed somehow, and it turned into a community group at W3C, called RDF Star. Community groups at W3C have this kind of like a lightweight process. They cannot produce specifications. They can only produce final reports, which can then be input to working groups at W3C, which can be chartered to produce actual WTC recommendations. When I say recommendation, for those listeners of yours who don't know, recommendation is the term that W3C uses for something that some other organizations might call a standard. I think that sort of originally the term implies that W3C has no enforcement authority of any kind. People implement the recommendations if they think that they're a good idea and that they promote interoperability.

Larry:
Interesting. I always wondered, because the authority before, as a candidate recommendation, I always thought that was kind of odd language, but that explains that.

Ora:
Right, so the end goal here is to produce something or publish something that's called a recommendation,...

Daniel Davis

Long before Foundation Capital published their "trillion dollar opportunity" article about them, Daniel Davis had been building a platform for context graphs.

Daniel's work in complex domains like aircraft safety and autonomous vehicles, as well as his study of quantum mechanics, gave him insights that led him to explore ways to ground probabilistic AI systems in the logic and knowledge they'd need to deliver trustworthy information. He settled on context graphs as the best way to accomplish this.

Daniel was introduced to knowledge graphs by his co-founder Mark Adams, and he has immediately become an RDF evangelist, aiming to not only proselytize the tech but to also make Mark's cat Fred famous in the process.

We talked about:

his role as co-founder at TrustGraph
his work to make his co-founder Mark Adam's cat Fred famous
his diverse background in defense, autonomous vehicles, and cybersecurity
how the complexity and vast scope of compliance requirements around autonomous vehicles led to his interest in context graphs
how the arrival of ChatGPT and GPT-3, and his knowledge that probabilistic systems wouldn't be up to the task of delivering legally compliant information, served as a catalyst for his current work
how a friend's article about the Foundation Capital "trillion dollor opportunity" post led to his Context Graph Manifesto
his hypothesis, based on conversations with several friends at big consultancies, that the sudden interest in context graphs arose from executives reviewing their many failed 2025 AI proofs of concept
his definition of a context graph: "a graph structure that is optimized for AI usage"
the influence of his friend Vicky Froyen's 2019 presentation on context graphs at the first Knowledge Graph Conference
the three elements he sees in a context graph - decision traces, provenance and explainability, and feedback - and the power of combining them in a single graph system
their use of ontologies like PROV-O
the importance of a context capability in complex domains like military airworthiness
how his background in quantum mechanics and mathematics led to his awareness of the limitations LLMs from their introduction
how he balances the probabilistic nature of the universe with the needs of practical applications that entail legal obligations
his surprise at the lack of attention that a lawsuit between Amazon and Perplexity is getting, given its huge implications for AI agent systems
their goal at TrustGraph of making graph technology and ontology design easier and more accessible
a cliffhanger about the implications of LLMs not understanding time

Daniel's bio
From military aerospace, space-to-air-to-sea mesh networks, autonomous vehicles, and enterprise infrastructure, Daniel has made of career of making the most complex systems work together. Whether it's cyberphysical systems or data, interoperability and guaranteed performance have always been top priorities with a mission-first mindset. Co-Founding TrustGraph represents a multi-decade quest to improve decision making through access to better knowledge.
Connect with Daniel online

LinkedIn
X

Resources mentioned in the interview

TrustGraph.ai
TrustGraphAI YouTube channel
Context Graph Manifesto
Collibra's Context Graph, Vicky Froyen's 2019 Knowledge Graph Conference presentation

Video
Here’s the video version of our conversation:

https://youtu.be/npjErvR7oXY

Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 49. When Foundation Capital published their article about the trillion-dollar opportunity presented by context graphs, many people were hearing about the concept for the first time. Not Daniel Davis. He's been developing an open-source context graph platform since 2023. His work in complex domains like aircraft safety and autonomous vehicles, as well as his study of quantum mechanics, have led him to explore ways to ground probabilistic AI systems in logic and knowledge.
Interview transcript

Larry:
Here we go. Hi everyone. Welcome to episode number 49 of The Knowledge Graph Insights podcast. I am really delighted today to welcome to the show Daniel Davis. Daniel's the co-founder and co-creator at TrustGraph, which is an open-source software project that builds graph stuff that we'll talk about today, based in San Francisco. And welcome to the show, Daniel. Tell the folks a little bit more about what you're up to these days.

Daniel:
Oh, wow, Larry. That's a lot to unpack there. I mean, how much time do you have? Yes, I am the co-creator of TrustGraph with Mark Adams, who is a bit more well-known in the graph community than me, but he likes building graphs. He doesn't like talking about them so much. And I'm confident that he would agree with me on that. Although I am trying to make his cat Fred famous, because I'm actually working on a new video on our guide to understanding RDF, which is something that a lot of people have asked us about, and how Mark taught me RDF so many years ago with three simple sentences about his cat Fred. But TrustGraph is what we've been working on for the past few years now. And we've had a couple of different ways of trying to explain it to people, whether it's a context operating system, context development platform.

Daniel:
Some might even think of it like a context science platform, which I think is kind of an interesting analogy as well. But I myself have quite a diverse background, spent a lot of time in DOD aerospace, came out to Silicon Valley almost 10 years ago to work on the autonomous vehicle industry, focusing on cybersecurity and safety. And that's why I write articles about things like determinism and information risk and trying to attribute value to information. But in that world, I also was doing complex knowledge work where you read one document that's 800 pages long, and then you have to read a statement that references another document, or maybe it references 12 other documents, and you just keep tracing down this chain of references, and then you have to understand which one of these documents actually takes precedence. Why did these statements conflict with each other?

Daniel:
Do they conflict with each other? How do I try to come to some sort of opinion about this? And in the safety critical world, opinions aren't allowed. It's not like auditing for enterprises that you can have opinions. They take a much grimmer view on that. And that's where that word determinism comes in and whether determinism means what people think it means. And how is that for an introduction?

Larry:
Well, it's perfect, because it sets up all the things we want to talk about. The first thing I want to talk about, I think, well, it's so hard to choose, but the reason you came to my attention is, I forget, somebody ... Oh, my friend Jochen in Munich brought you to my attention. And I was like, "Whoa, this guy's been talking about context well before December of 2025," which is when apparently the rest of the world started thinking about context and context graphs. Tell me a little bit about maybe the story of your connecting with Vicky or however. I mean, that combination, we were talking before we went on the air about your experience with autonomous vehicles, discovering Vicky and his interest in context graphs. And then a lot of what you just said is a reason to need not the context graphs to do the stuff you want to do. So, maybe talk a little bit about your journey into the context realm.

Daniel:
Well, so much of this comes from the problem I was trying to solve in the autonomous vehicle world. This is work that I've been doing for years in DOD aerospace with risk management and cybersecurity and safety, and just running complex programs. It's so much about the paperwork and how you make decisions, how you justify those decisions, how you comply with regulations, understanding the regulations. And for autonomous vehicles the scope was just unprecedented when you look at the number of things that could go wrong. And we could literally talk for the next few days, just me rattling off scenarios, and you'll go like, "Wow, I never thought of that. I never thought of that. Wow, wow." And you just start going like, "How do you manage this?" And well, that was what I was sought out. That's what I was having to solve. And looking at all the different ways of doing this and trying to combine a Bayesian approach with risk management and realizing the data sets were going to be huge and how do you manage that.

Daniel:
And it kind of turned out to be an unsolvable problem at the time. And around that time, because I was working at Lyft, I got brought up to manage a lot of the issues that were going on with the Lyft actual IPO, which again, more regulatory stuff with the SEC and how processes are applied across the entire enterprise, how these comply with SEC regulations and expectations and how this was audited. And just even how we were measuring our cybersecurity performance as a company, how that was getting reported to the board. Again, very similar problem, just slightly different problem space, slightly smaller scope. And around that time Mark's company, Trust Networks, was actually acquired by Lyft, and I met him and I got introduced more to graphs and knowledge graphs. I actually hadn't even worked with knowledge graphs prior to that. I was much more in deterministic structures and DOD aerospace.

Daniel:
I was the one always saying, "Why are we writing in this Python? We should write it all in Ada." And all the people would just look at me and go, "What is Ada?" And I would do that just as a joke, but also partially believing it. I still advocate Ada. I like Ada, even if it makes developers cry. It was designed to make developers cry, because it always works, but that's another story. And that was back in what, 2018, 2019?...

Veronika Heimsbakk

With interest in knowledge graphs growing by the day, Veronika Heimsbakk is busier than ever with her efforts to connect the data engineering, information architecture, and ontology practices that drive modern knowledge engineering.

Best known as an advanced knowledge graph practitioner and a leading expert on the SHACL standard, Veronika also regularly shares her knowledge through her writing, university courses, and professional workshops.

We talked about:

her work at Data Treehouse, creating tooling for data people to get on board the knowledge graph journey
how she helps data engineers find their overlap with knowledge engineering
her work to build bridges between data engineers, information architects, and ontologists
how she meets data engineers on their own turf by using simple Python scripts to put their data frames into a knowledge graph
how public sector compliance requirements drive demand for RDF solutions
the powerful tool that helps her communicate with a variety of stakeholders and collaborators: coloring pencils
how she works with information architects and enterprise architects
her take on graph visualizations, that they're rarely very useful in helping her communicate with engineers and business people
her approach to balance top-down ontological approaches and bottom up data engineering approaches in knowledge graph construction
her early work with SHACL and her appreciation for its applicability to a wide range of use cases beyond simple data validation
her take on the ongoing OWL versus SHACL discussion
her preferred tool for turning modeling sketches into RDF code: WebProtégé
how her work with the Norwegian maritime authorities reduced caseworker time on regulatory tasks from several weeks to a few seconds
her upcoming masterclass at the Knowledge Graph Conference on transitioning from data engineering to knowledge engineering

Veronika's bio
Veronika Heimsbakk is a knowledge graph specialist at Data Treehouse with over a decade of experience in semantic knowledge graph technologies. Throughout her career as a consultant, she has served as a developer, architect, advisor, and team lead, working with public and private sector clients across Europe, with a strong focus on the public sector in recent years.

Veronika is the author of SHACL for the Practitioner (2025). She is a regular guest lecturer on SHACL at the University of Oslo and has delivered the SHACL Masterclass at various venues for several years. In 2024, she was recognised as one of Norway's Top 50 Women in Tech.

On Substack, Veronika writes From Data Engineering to Knowledge Engineering, a practical article series that shows data engineers how to build knowledge graphs using familiar tools like Python, Polars, and maplib, covering everything from ontologies and SPARQL to SHACL validation and reasoning. An eager advocate for logic and linked data, she champions knowledge graphs in a landscape increasingly dominated by predictive approaches.
Connect with Veronika online

LinkedIn
Substack
SHACL for the Practitioner book
e-mail: sh at veronahe dot no

Video
Here’s the video version of our conversation:

https://youtu.be/cY8rhPoXepE


Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 48. Ontology design and knowledge graph building are truly team sports, requiring collaboration across a variety of business and engineering disciplines. Few practitioners are as experienced at bringing these teams together as Veronika Heimsbakk. As both a consultant and as an author and educator, she helps business and public sector stakeholders, data engineers, and knowledge architects understand each other's languages and appreciate each other's practices.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 48 of the Knowledge Graph Insights podcast. I am extremely delighted today to welcome to the show Veronika Heimsbakk. If you've ever been to the Knowledge Graph Conference, Veronika's just, you know her already. She's just the most engaging presence there. She's always got her Norwegian KitKat bars and her Polaroid camera and doing awesome workshops on SHACL and other things. But welcome to the show, Veronika. Tell folks a little bit more about what you're up to these days.

Veronika:
Thank you, Larry, and thank you for having me. Yes, these days I'm up to in using familiar tooling to get started with knowledge graphs and harvesting all the knowledge graph capabilities and graph traversals as opposed to JOINs and tabular things. Yeah.

Larry:
Well, this feels like a year in which a lot of that might be happening. A lot of data engineers, there just seems to be so much excitement and interest in knowledge graphs and ontologies. And it's so important to meet people where they are on their journey into that. And you know, you're involved with, I know the data folks in Helsinki and we didn't talk about your background. You're currently a knowledge graph specialist at the Data Treehouse. And previously, you've done consulting like at Capgemini. So you've done a lot of this work hands-on. You wrote a book about SHACL, and you do workshops and a lot of teaching. And part of that whole mindset of yours is currently, maybe not... I guess it's focused on helping data engineers become knowledge engineers. Is that an accurate way of putting it?

Veronika:
Or at least not fully transitioning maybe from data engineering to knowledge engineering, but finding that intersection of a skillset that's truly powerful in working with ontologies because we have seen the rapid interest and popularity of ontologies lately when large language models took the world by storm. But I've also experienced during my years as a consultant that the ontology things and the knowledge graph aspects, they are usually a concern of the information architects and those who work with concepts and terms and setting them into context and everything. But the information architecture departments usually don't talk to the people working on the data and making applications. So why should we create ontologies that are machine-readable in semantic models? They are a database schema in itself. They are fully usable by data people, but there is something in between there that's hard to grasp.

Veronika:
So I want to build this bridge because when I was finished at the uni, I started as a Java developer on Symantec Tech project. So I've been doing a little bit of data engineering myself in the early days going from tabular data to RDF and knowledge graphs. But I see that this isn't something that should be separated, of course, if you want to be data-driven, ontology-driven in your applications, you need the data people on board if you're going... Successful project.

Larry:
Yeah, that's really interesting too, because it seems like there's at least a couple of things there. Just the common language between information architects, data engineers, and knowledge engineers, but then also, in any communication project, meeting them on their own ground. And that probably applies both in the human natural language that you're talking to people about, but also in the technology to implement stuff. And I know that's what you're doing in your day job now, but can you talk a little bit about how you're making knowledge graphs and knowledge engineering more accessible to data engineers?

Veronika:
Yes, of course. The company that I work for, we create a framework for doing exactly that, like working with knowledge graphs using data frames. So I've been working a lot with that lately and writing a lot of articles on the topic and how you can transition from a tabular data format to queryable knowledge graph, doing graph traversals and answering questions you even didn't know you had, right? But the way that I work is usually together with clients, is applying simple tooling on their tabular data. And these days, most people work in data frames, right. So going from a Polars data frame to queryable knowledge graphs only require three, four lines of Python code by using, for example, maplib, which is a Python framework for handling knowledge graphs as data frames. And you can even get your SPARQL query answers back as a data frame to push further in your data pipeline.

Veronika:
So you have all these capabilities of graph traversal in answering questions, but also, in inference and enrichment and automating enrichment of completing metadata, for example, and doing validation with SHACL, for example. You have all these knowledge graph capabilities that you can put on top of your existing data infrastructure.

Larry:
Are there classic use cases where... Is there higher demand in some industry verticals for this kind of thing?

Veronika:
Recently, in Norway at least, I've seen a rapid demand for like, "Hey, I have all my data in this data lake," like Databricks or Snowflake or whatever. But the information architecture folks, they're building ontologies or they want to reuse the national standards. Like in Norway, we have a set of national standards that are expressed in RDF. It's SKOS for concepts and terms. It's DCAT for data catalogs and it's CPSV for core public services and to be able to describe them. And it's a demand for the public sector to comply to those. And when they have data in Databricks, for example, how can we connect to these national standards or to our internal ontologies with the data in Databricks to make the ontologies operational?

Veronika:
So that's a use case that I stumble across a lot lately. And I've actually written about this recently because I did a teeny tiny project on that at the Culture Heritage Directorate in Norway. And that again, it's like four lines of Python inside Databricks and you have your ontology operational on your data.

Larry:
Interesting....

Joe Reis

When Gartner declared 2026 "The Year of Context," Joe Reis leapt into action, immediately writing a good-natured satirical article about "context products," "context lakes," and the "analyst singularity."

It's a fun article that exemplifies Joe's no-nonsense approach to industry education and concludes with a serious point — "context does matter, and most organizations are terrible at it."

We talked about:

his forthcoming data modeling book, "Mixed Model Arts"
the origins his satirical post "Gartner declares 2026 the year of context"
our speculation on how the word "context" came to the fore
how his decades of experience help him fine-tune his hype detectors
"the one equals 10 dilemma" via which leaders extrapolate AI benefits that senior programmers gain onto less-skilled engineers
the challenges that executives miss of building a semantic layer
the endless quest for "silver bullets" over solving fundamental business problems
the relevance of Einstein's definition of stupidity in the AI hype cycle
how the big AI providers are like the ISPs of the 1990s
how generative AI has accelerated and improved his workflows
the trepidation around AI that he feels when he visits Silicon Valley and San Francisco
the unprecedented pace and scale and context of the current AI hype cycle
the role of the knowledge community in the current tech environment

Joe's bio
Joe Reis, a "recovering data scientist" with 20 years in the data industry, is the co-author of the best-selling O'Reilly book, "Fundamentals of Data Engineering." He’s also the instructor for the wildly popular Data Engineering Professional Certificate on Coursera, in partnership with DeepLearning.ai and AWS.

Joe’s extensive experience encompasses data engineering, data architecture, machine learning, and more. He regularly keynotes major data conferences globally, advises and invests in innovative data product companies, writes at Practical Data Modeling and his personal blog and hosts the popular data podcast "The Joe Reis Show." In his free time, Joe is dedicated to writing new books and articles and thinking of ways to advance the data industry.
Connect with Joe online

JoeReis.xyz

Joe's writing and podcast

Gartner Declares 2026 The Year of Context™: Everything You Know Is Now a Context Product
Fundamentals of Data Engineering (O'Reilly), Joe's bestselling book
Practical Data Modeling
Personal Blog
The Joe Reis Show

Video
Here’s the video version of our conversation:

https://www.youtube.com/watch?v=6A_FWL0hbKM



Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 47. When Gartner recently declared 2026 "The Year of Context," the gauges on Joe Reis' industry hype dashboard maxed out. Joe's a respected veteran of the data profession, known for his best-selling book, Fundamentals of Data Engineering, and for his courses, newsletters, conference keynotes — and especially for his no-nonsense takes on industry trends. He's also a good friend of the knowledge graph community. "Context" is just his latest tech-industry hype take-down.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 47 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Joe Reis. Joe is a well-known figure in the data engineering and data world. He's the co-author of the book, Fundamentals of Data Engineering, which is kind of a category-setting book. He's working on a new book called Mixed Model Arts, on data modeling, and does a lot of other interesting stuff. He's really well known in the conference community. And anyhow, welcome to the show, Joe. Tell the folks a little bit more about what you're up to these days.

Joe:
Hey, what's up, Larry? What have I been up to lately? Just been editing Mixed Model Arts. I just actually finished, I guess, the main edits and just down to the very minor tweaks as of today. So that's awesome. So literally just working on that before we hopped on and I'll be working on that after we're done.

Larry:
Okay, Great. Well, sorry to interrupt your book. I'm a former book editor, so I always feel bad when I interrupt progress like that. Congrats.

Joe:
It's okay. Thank you.

Larry:
Do you have a publisher for the book?

Joe:
That would be yours truly, yes.

Larry:
All right. Okay. Well, anyhow, we'll keep the webpage-

Joe:
We'll talk about that later. Yep.

Larry:
Yeah, with info about where to get it. Well, hey, the reason this conversation came together, there was this great little convergence of meeting of ideas a couple of weeks ago. I had just done a presentation where I was talking about how hyped the AI cycle is. And then in quick succession, I saw a post from Juan Sequeda where he talked about some folks have mixed feelings about Gartner. And then I came across this post you had done, "Gartner declares 2026, the year of context." It was this brilliant satirical piece. Can you talk a little bit about that and what motivated it and just maybe a quick outline for folks?

Joe:
Yeah, I mean, I think spawned from... I guess my social media circles were like Gartner, and all of a sudden I started seeing my LinkedIn feed bombarded with the word context and how Gartner declares this the year of context and... I can swear in your show, right?

Larry:
Yeah.

Joe:
Okay, shit.

Larry:
It's fairly family friendly, but yeah.

Joe:
Yeah, it's all good. So I've seen them and similar research firms in the past declare this, that, or the other thing. And I just felt like this in particular seemed... And no offense to the knowledge graph folks there, whatever, you're all great. And I think it serves knowledge graph community really well, but the year of context I think is jumping in the gun a bit too fast. Where last year was a year of agents, year before that was year of AI or whatever, and it just seems like... It's what I described as the buzzword industrial complex where we jump... Not we, but certain groups in the industry need something new to push onto people in order to keep, I guess, discussions going, in order to keep people attending conferences, in order to keep selling consulting services and all this other stuff.

Joe:
And so I felt like this was really just another instance of it, but I decided that I had had a few spare cycles in between editing my book. So I was like, "Oh, let's just write a satirical piece on this," maybe somewhat satirical, maybe just kind of poking fun at just, I guess, the nonsense of the industry that we keep finding ourselves in over and over again. So that was all there was to it, Larry.

Larry:
Okay. Well, one of the ways you contextualize that was this, I forget what you call it, the conference content capital cycle, this self-reinforcing loop, which appeared to me to mirror this kind of whatever that bizarre financial loop that's keeping the AI companies up. Was that intentional or was I just reading into that?

Joe:
I mean, I don't know if it was intentional, but it's just an observation that I've noticed in that article, and I think a few others, where it was very much... It's a self-sustaining thing where you need the news story, you need this. And it's the same as the AI hype cycle right now where it's just a very circular system. And so just that the money just sort of rotates around and that's just kind of how it is amongst strangely a lot of the same players, which I think is kind of funny.

Larry:
Interesting. Yeah, so maybe we've just stumbled upon some universal dynamic that drives various kinds of hype cycles. But one thing that occurred to me is there's always some fundamental underlying, it's business anxiety or truth or something like that that's driving these things. The context thing, do you have any hunch where that came from? I remember it just hit my LinkedIn feed, what, three or four months ago and it's been constant ever since.

Joe:
I'll ask you this actually. I mean, let me reverse the roles of a host and guest here. I mean, you've been in the knowledge space for a while and I imagine that some manifestation of the word context has come up in your discussions with your peers. So I guess if I'm in your shoes and those of your peers, what's it like to see a word like context or semantics or ontology or graphs becoming these sort of terms du jour?

Larry:
Well, in one sense, it's really gratifying, of course, because we're on the radar screen. You can actually say ontology in public now, which has not been the case for the last 10 years.

Joe:
Yeah, you get jailed for doing that. Yeah.

Larry:
Exactly, yeah. Put you in the stocks in the middle of the courtyard. But no, so it's really interesting. And that's one of the reasons I'm curious about your take on it, because it's like there's these real things that drive it. But in terms specifically of context, I was just reminded just of... Somebody on LinkedIn today just shared a post I did recently about Dave McComb's... I don't want to get too nerdy, but this is a Knowledge Graph Insights podcast, so I'll set a little context. There's this thing in knowledge graph construction. You have the A box, the assertion box, which is like all the things, all the data instances that are in there. Then you have above that, you have the T box, which is the concepts that describe it, the ontology basically, typically.
Dave McComb, who I think you must know, because the data centric enterprise and all that.

Joe:
Mm-hmm.

Larry:
He articulated this notion, I don't know, a couple of years ago of the CBox. And what was really interesting in this post I saw today is that he used it as the categorization box. That's where you put all the taxonomic terms, vocabularies, all that sort of what I think of as the metadata about the data is sort of in there. And I didn't realize at the time,...

Robert Sanderson

Yale University manages huge collections of precious cultural heritage artifacts housed in multiple museums, libraries, and other collections.

Using knowledge graph and ontology engineering design patterns that he has developed over his career, Robert Sanderson helps scholars, researchers, and the general public access information about — and make connections across — millions of unique items in Yale's collections

We talked about:

his work as Senior Director for Digital Cultural Heritage at Yale University
the knowledge graph and ontology engineering design patterns that guide his work
the scope of his work — improving discoverability of Yale's extensive collections of artifacts, facilitating the management of collection information, and even collecting data on physical artifact storage facilities
how their linked data approach lets researchers easily connect information about artifacts and information housed in multiple museums, libraries, and collections
how the growth of LLMs has affected their KG user interfaces
how AI is accelerating their ability to add to their knowledge graph the millions of artifacts in their collections that aren't yet accounted for
the compact nature of their three-billion-triple KG ontology, just 10 classes and 50 relationships
the extensive vocabularies and taxonomies they use
how they handle the need to reconcile the identity of lesser-known people who don't have a Wikipedia page or other authoritative references available
how they balance the competing needs of comprehensiveness and usability as they build their knowledge graph
how knowledge graphs facilitate discoveries that other search tools can't
current opportunities for post-docs to join his team to work on leading-edge AI projects

Robert's bio
Dr. Robert Sanderson is the Senior Director for Digital Cultural Heritage at Yale University, where he works with the libraries, archives, and museums to ensure that data and other digital efforts are coherent and connected. He is the principal architect for Yale’s cross-collection discovery system, LUX, which is built on the Linked Art specifications, for which he is an editor. He is also an editor for the IIIF specifications, was the co-chair and editor for JSON-LD and the Web Annotation data model in the W3C. He has previously worked at the Getty in Los Angeles, Stanford University, Los Alamos National Laboratory, and the University of Liverpool. His current areas of work and research are at the intersections of cultural heritage, knowledge graphs, data usability, and generative AI.
Connect with Rob online

LinkedIn
email: robert dot sanderson at yale dot edu

Rob's LinkedIn post series on KG and ontology design patterns

The 10 Design Principles to Live By
Ontology Design Patterns
Naming Things
Avoiding Reification
Foundational Ontologies
Multiple Inheritance, Not Multiple Instantiation
Predicate Reuse... Meh
Document your ABCs
Separate Query and Description Semantics
Usable vs Complete
acknowledgements

Video
Here’s the video version of our conversation:

https://youtu.be/SMAVyrL3aSU
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 46. When your job is to help scholars and the public discover information about millions of cultural heritage artifacts that are housed in multiple museums, libraries, and other collections, you need a powerful — but also manageable — knowledge graph. That's Rob Sanderson's role at Yale University. He and his team apply time-tested ontology and knowledge engineering design patterns to help people discover — and see the connections between — these precious human artifacts.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 46 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Robert Sanderson. Rob is a professor and the senior director of Digital Cultural Heritage at Yale University, the Ivy League School in Connecticut. Welcome to the show, Rob. Tell the folks a little bit more about what you're up to these days.

Rob:
Hi, Larry. Thank you so much for inviting me to be part of the illustrious lineup of guests on your podcast. So yeah, I'm Rob Sanderson, as you said, Senior Director for Digital Cultural Heritage at Yale. So I work with the libraries, the archives, and the museums and other collecting organizations at Yale to help them to be more connected with linked data organizationally and more coherent in the way that we do things digitally. So our projects really focus on discovery and access to the collections in service of the university mission, which of course is teaching and learning, research, and preparing our students to be the next generation of leaders in the world.

Rob:
So for that, the university invests very heavily in the collections, which is fantastic. We are super proud of the 300 years of collecting that we've done. But we want to make sure that if you can't come to New Haven, you still have as good access to those collections as possible. And the ability to find amongst the many millions of objects that we steward exactly what it is that you need. So a lot of our projects focus on describing the collections in a more computationally tractable way so that that discovery can be better. And also how to manage the information that's associated with the collection, but isn't a museum object or a archival object itself. For example, I have two postdocs that are openly available. So if you are a few years out of your PhD or just about to graduate, do get in touch to work on how to use AI to extract the ownership history or the provenance of particular museum objects from the archival content that we also manage. Equally, how can we align research data sets with the collections? So we also have a natural history museum as well as two art museums. How can we align the environmental datasets that are out there on the web with the natural history specimens that could have been impacted by those environments?

Rob:
Yeah. And then equally, we look at the environment of Yale. So we have a large project at the moment to set up environmental monitoring with sensors for light, for humidity, temperature, and so on, to be able to generate a large data warehouse aligned with linked data with the collections so that we can have evidence of what the effects of the environment are on the collection items themselves.

Larry:
Interesting. That is so fascinating. What a fascinating remit. One quick thing about what you just said. Is that about humidity and temperature and all the things that might affect the endurance of these physical artifacts?

Rob:
Yep. Yes. That's right.

Larry:
Yeah.

Rob:
We have about 200 sensors around the place monitoring every five minutes a new data point, which if you think about it, it's actually not that much data.

Larry:
Yeah. I have to say, I just love that you're doing data stuff along with it. That you're not just sitting in a dusty old room collecting things. You're doing cool modern stuff too. But hey, I want to quickly interject how we met, and I just want to put this in because we won't have time to talk about it today, but I want people to know about this fantastic series you did. That's how we met was somebody drew to my attention the series you've done on ontology design and on knowledge engineering design patterns. And I'll point to that in the show notes, but I just wanted to mention. And the more I think about what you just said, because I didn't know all of this background before we started recording, I'm like, "Oh, this is even better than I thought." So I'll point to that in the show notes.

Larry:
But the main thing I wanted to talk about today is what you were just talking about. This amazing cultural heritage operation that you're running there, especially the knowledge graph component of it and the AI, of course, because we're in the 21st century, and that's all anybody talks about. One of the things we talked about before we went on the air was how AI is accelerating the ability for you to build your knowledge graphs of these cultural heritage artifacts and data. Can you talk a little bit about that, how AI is helping in that?

Rob:
Yeah. Of course. Absolutely. So just a little bit of a background about the knowledge graph itself first before I get to the AI part. So over the past five years, we've built without AI, a very large scale knowledge graph, well, in cultural heritage terms of very large scale, which has about three billion triples in it. And it follows the principles and the design patterns that you mentioned in those posts on Linked Art. It then aligns the people, places, concepts, events, objects, works, collections that we manage here at Yale across the two art museums, Natural History Museum, the dozen or so libraries. There's also a collection of musical instruments, the Institute for the Preservation of Cultural Heritage, and we even have a little outpost in London, in England for art history research that we include. So that work uses the linked art ontology, which is based on the foundational site CRM ontology and is publicly available both in terms of the data, you can just download it. But also in terms of the graph queries, we don't force you to learn SPARQL. We have a user interface on top of it, which allows you to generate queries and find the objects that you are looking for.

Rob:
So one of the things that we noticed first about the user interface is that only about 5% of searches are actually using the graph affordances. Mostly, 95% of the time, people just put in keywords because that's what they're used to. You go to Google, you type in your five favorite keywords that you think might match and you scroll through the results. However, now in 2026, people are more used to typing in full sentences and then having AI take t