Knowledge Graph Insights

Larry Swanson

Interviews with experts on semantic technology, ontology design and engineering, linked data, and the semantic web.

  1. 1 DAY AGO

    Giancarlo Guizzardi: Ontology, Semantics, and Explainable AI – Episode 51

    Giancarlo Guizzardi For nearly three decades, Giancarlo Guizzardi has researched and advanced the field of semantics and the practice of ontology and conceptual modeling. His work on the Unified Foundational Ontology (UFO), the OntoUML pattern language, and AI explainability are just a few of the accomplishments that make him an exemplar of the "full-stack ontologist." We talked about: his broad-ranging ontology and other responsibilities work at the University of Twente in the Netherlands the origins of the term ontology in computer science in 1967 George Mealy's assertion that "every data makes an ontological commitment" his take on the idea of capital O Ontology, both the conceptual tooling to build ontologies as digital artifacts and the design patterns that guide their creation how his insight that conceptual modeling is the foundation of any system led to his development of the Unified Foundational Ontology (UFO) his goal with UFO to give engineers tooling to reuse ontology patterns without having to expose them to the complexity of the underlying ontology itself the resulting OntoUML pattern language his belief that ontology engineering should separate conceptual modeling from design and implementation his take on the difference between verification and validation in ontology design how conceptual modeling and engineering implementation often end up in the hands of a "full-stack ontologist" how the ideas in his paper on "Explanation, Semantics, and Ontology" support explainable AI Giancarlo's bio Giancarlo Guizzardi is a Full Professor of Computer Science the University of Twente, The Netherlands, where he chairs the Semantics, Cybersecurity & Services (SCS) department. He is also a co-founder and co-director of the NeXAI Competence Cluster in the same university. He has been active for nearly three decades in the areas of Formal and Applied Ontology, Ontology Engineering, Conceptual Modeling, Enterprise Computing and Information Systems Engineering, working with a multidisciplinary approach in Computer Science that aggregates results from Philosophy, Cognitive Science, Logics and Linguistics. He is the main contributor to the upcoming ISO/IEC international standard 21838-5 Unified Foundational Ontology (UFO) and to the OntoUML modeling language. He is an associate editor of several journals including Applied Ontology and Data & Knowledge Engineering, chair of the Steering Committee of the International Conference on Conceptual Modeling (ER), member of the Advisory Board of the International Association for Ontology and its Applications (IAOA), and an ER fellow. Finally, he has extensive technology-transfer experience developing industrial ontologies in sectors such as Health, Cybersecurity, Risk Management, Space, Finance, Energy, Distributed Software Development, Digital Journalism, Complex Media Management, Government. Connect with Giancarlo online LinkedIn GiancarloGuizzardi.com Resources mentioned in this interview Another Look at Data, George Mealy's 1967 paper Explanation, Semantics, and Ontology Ontology, Ontologies and the “I” of FAIR Unified Foundational Ontology (UFO) OntoUML Video Here’s the video version of our conversation: https://youtu.be/JtsC8nQNFF0 Podcast intro transcript This is the Knowledge Graph Insights podcast, episode number 51. The origins of the practice of ontology in computer science go back almost 60 years, well before the current era of knowledge graph technologies. Since then, ontology researchers like Giancarlo Guizzardi have demonstrated the importance of distinguishing between conceptual modeling and the symbolic language that implements the model. Giancarlo's latest work shows that genuinely explainable AI is impossible without formal ontology and semantics. Interview transcript Larry: Hi everyone. Welcome to episode number 51 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Giancarlo Guizzardi. Giancarlo is a professor at the University of Twente in the Netherlands. Welcome, Giancarlo. Tell the folks a little bit more about what you're doing these days. Giancarlo: Hi, Larry. Thanks for having me. It's a pleasure to be here talking to you. As you said, I'm a professor here in the Netherlands. I'm the head of a group called Semantics, Cybersecurity, and Services. So as the name says, everything we do is grounded on semantics and ontologists. And we call ourselves full-stack ontologists. Giancarlo: So we work from very theoretical issues. So sometimes I even publish in philosophy journals, to very practical issues of... So we go from building ontologies in philosophy, ontology in computer science, modeling languages, tools, ecosystems of tools for ontology engineering, and to implementation of ontologies in large-scale settings. So we've been doing this for quite a while in many different domains. Giancarlo: The group now is very focused on cybersecurity, on risk management and on social and legal issues. So the service part refers to that. And it's a big group, around 70 people here in the Netherlands. Larry: Oh, wow. I didn't realize it was that big. Well, and that scope that you described, and I love that you describe yourself as a full-stack ontologist because there were a number... I just came back from KGC and there were a number of presentations there that they take the semantic layer and divide it into five or six layers of its own, a lot of which aligns with what you just said. Larry: But one of the things you talk about, and I think it fits into this, with this deep varied ontology practice spanning a bunch of different domains, different levels from the highbrow ontology stuff to the in-the-weeds data stuff. You argue that capital O, Ontology, like a proper philosophically grounded... Or I don't know exactly what you mean by that, but tell me more about what you mean by capital O, Ontology, and why it's essential for engineering practice? Giancarlo: Yes. Ontology, capital O, is basically... So the term refers to three different things, ontology. It refers to, originally in philosophy would refer to a particular theory about a given domain. So what exists in a given domain? So one interpretation is what exists behind a certain description? The ontologist, whatever, a certain description assumes to exist in the world in order for that to be true. So we can see how that connects with data. Giancarlo: So there is a quote that I like very much from a guy called Mealy. Mealy is the creator of Mealy Ontology in computer science. He was the PhD supervisor of Peter Chen, the guy that created entity relationship diagrams. So grandfather of conceptual modeling. Mealy writes this paper in 1967 called Another Look at Data, which the first reference of the word ontology in computer science, by the way. So we are talking about ontology in computer science since '67. Giancarlo: And Mealy has this nice quote. He says, "data are a theory, a fragment of a theory of the real world." So he's saying every data makes an ontological commitment. This is absolutely inevitable. In fact, any type of representation makes an ontological commitment. So even if you have a kind of Python code that has variables like customer and purchase order and product and so on, you are committing to a given theory of the world of what kinds of things exist with which properties, under which constraints, and so on. Giancarlo: And Mealy makes his reference to ontology basically saying, we need to make that explicit, interoperability in a sense. So he's not using these words, but he's saying computer scientists are obsessed with symbols and with symbol manipulation, but we need to look beyond the symbols at what kind of theory of the real world is behind that symbolic structure. Giancarlo: So this is a definition of ontology, it's whatever is behind a symbolic structure. In computer science in another area in AI, particularly in the end of the '70s with Pat Hayes and so on, ontology became the structure itself. So the representation of that theory in the background. So these are two interpretations of ontology. Ontology as whatever is in the background, whatever is assumed by a representation, or the representation itself. Giancarlo: Well, the representation only justifies its name if it's a representation of the ontology in the background. Otherwise, we could just call this data structure or data model. Ontology, capital O, is a area that allows you to, let's say, flesh out, review, make explicit what is the theory of the real world, which is behind a certain symbolic structure in a systematic way. Or in other words, Ontology, capital O, is an area that will give you instruments, conceptual tools to build ontologies as artifacts. Otherwise, we're going to need to invent these conceptual tools. Giancarlo: So typically Ontology, capital O, will deal with the most general aspects of reality, like what are events, what are objects, how objects relate to their parts, how events relate to their parts, what kind of properties can objects have, what kind of relations can connect objects and so on and so forth. What kind of types exist, how types relate to each other forming taxonomic structures, very general theories. Giancarlo: So I see these theories as kind of not only conceptual tools, but actually as kind of patterns. So let me give you an example. So imagine if you have a theory of events that says an event is something which happens in space and time, events have parts. So there is a mirror logical structure in events of events. These parts can be related by different types of temporal relations, by causal relations, objects participate in events. So events are kind of dependent entities. In order for them to exist something needs to participate in this event. Giancarlo: So you have this theory,...

    32 min

  2. 11 MAY

    Ora Lassila and Adrian Gschwend: RDF 1.2 Working Group Update – Episode 50

    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,...

    36 min

  3. 29 APR

    Daniel Davis: Grounding Generative AI with Context Graphs – Episode 49

    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?...

    39 min

  4. 20 APR

    Veronika Heimsbakk: Connecting Data Engineering and Knowledge Architecture – Episode 48

    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....

    30 min

  5. 6 APR

    Joe Reis: Fighting “Context” and Other Tech-Industry Hype – Episode 47

    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,...

    35 min

  6. 16 MAR

    Robert Sanderson: Building Yale’s Cultural Heritage Knowledge Graph – Episode 46

    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

    37 min

  7. 2 MAR

    Max Gärber: Agentic AI Built on a Knowledge Graph Foundation – Episode 45

    Max Gärber The promise of agentic AI is being realized in systems like the Service Copilot that Zeiss microscopes provides for its field service engineers. The system integrates technical documentation, subject matter expertise, and user-generated insights which are orchestrated and shared with a suite of AI agents. While it relies heavily on modern LLM technology, it's the system's solid knowledge graph and metadata foundation that make it a success. We talked about: Max's work "turning information into value" at PANTOPIX, a technical documentation and information processes consultancy based in Germany a recent client project working with Zeiss to help their field service engineers operate more efficiently how their prior knowledge management and machine learning work helped them not only cope, but thrive, at the arrival of ChatGPT and LLMs the immediate positive stakeholder feedback they received as they incorporated LLMs into their knowledge architecture how they extended the iiRDS standard with a custom ontology and taxonomies and integrated topic mappings into their system and workflows an overview of the system architecture and tooling, which includes both a graph database and a vector store, an ontology and taxonomy management tool, and documentation of best practices their evolution from simple prompt engineering and RAG approach to an agentic orchestration architecture a few of the agents in their architecture: a planning agent that organizes and orchestrates a content agent that replaces the original RAG system a troubleshooting agent which surfaces past solutions the good problem they experienced of managing enthusiastic user adoption of the new system the unexpected benefits to the Zeiss sales team of the system how subject matter expertise, user generated content, and other insights are captured and used the crucial role of knowledge management practices, structured content, and semantic technology in building the foundation for an organization's AI capabilities Max's bio Maximilian Gärber is Partner and Principal Technical Consultant at PANTOPIX. Max has been working in the field of technical communication for over 15 years. As a Partner and Technical Consultant at PANTOPIX, he is responsible for the technical consultation and implementation of projects. In addition to project management, Max is responsible for data modelling and process optimization in relation to product information (migration, publication, translation) and product catalogues. He is also responsible for product development and ensures that innovative solutions for our customers are continuously developed and optimized. Connect with Max online LinkedIn PANTOPIX Resources mentioned in this episode Industrial Knowledge Graph meets Agentic AI: Service Copilot at ZEISS RMS slide deck Service Copilot from ZEISS article Video Here’s the video version of our conversation: https://www.youtube.com/embed/ttQOHvvxPyw Podcast intro transcript This is the Knowledge Graph Insights podcast, episode number 45. When you're a field service engineer dealing with both the typical challenges of information overload and the need to maintain complex machinery like a high-end Zeiss microscope, you'd really benefit from an intelligent knowledge management system, one that integrates technical documentation, subject matter expertise, and user-generated insights. That's exactly what Max Gärber has built - an agentic AI system grounded in a solid knowledge graph foundation. Interview transcript Larry: Hi everyone. Welcome to episode number 45 of the Knowledge Graph Insights podcast. I am really excited today to welcome to the show Max Garber. Max did a really interesting presentation at the Semantics conference in Vienna last fall, and I've been trying to get him on the show ever since. So here he is. I'm excited to have him here. Max, he's a partner and a technical consultant at PANTOPIX, a consultancy based here in Germany. Welcome, Max. Tell the folks a little bit more about what you're doing these days. Max: Yeah, thanks Larry. Thanks for having me. Yeah, great show. And yeah, we are mostly concerned with helping mainly our industrial customers structure their content and integrate it from various sources into their systems, delivery systems, wherever it is needed. So yeah, it's mainly consultancy on data modeling, on how to do information processes and how to get the best out of your data, so to say. So our mission here is literally turning information into value. Larry: Oh, I love that. That's a great tagline for a consultancy. Well, you did the use case, the case study you talked about in Vienna was really interesting to me. This issue of Zeiss microscopes, in particular their research microscopy solutions arm, which is these big, expensive, complex machines that require a lot of service. Can you talk a little bit about how you got involved with Zeiss and what you do to help them? In particular, the thing you talked about in Vienna was about the system to help their field service engineers. Can you talk a little bit about that project? Max: Yeah, exactly. The main objective there was helping the field service engineer to get the information in that situation when they need it and in the format they need it. That is essentially the bottom line of it. And it started essentially as a knowledge management project. Zeiss, RMS, they have been really into structuring, getting structured content, adding proper metadata to it so it can be used in various cases. The idea has been to integrate from various sources, spare part system, for example, or the manuals from the technical documentation or ticket information and get them into one system so there's a single point of access for the service technicians. So they don't need to spend a lot of time in all of the different systems that there are to get the information about that case they are currently working on because there's a lot they need to consider when servicing or troubleshooting a microscope. Max: And yeah, that project evolved into what is now the Service Copilot because I think it was in early '22 when we started the project. And one part of it was to not only integrate all of that information in one place, but also recommend content to the service technician. So, if you were working on a specific case, so the ticket was known, the product was known, you should get a recommendation of articles, "Hey, this is how you install this and that component," for example. So we actually worked a lot on labeling tickets. We actually had a custom labeling interface and used, let's say, classical machine learning approaches to get that recommendations done. Max: And it worked not so good, but that was also the same time when GPT, I think it was 3.0 or 3.5 came out. And yeah, we were faced with that situation that there was a new technology available that looked like it could do everything and much more what we were currently doing without much effort. So we really faced the situation there to either stop the project or reinvent ourselves, I would say. Larry: I love that juncture. We were talking a little bit before we went on the air about you were really concerned at that point as this arose, but then it turns out that the prior work you had done, the knowledge management work you had done and the machine learning skills and workflows and things you developed, it turns out you ended up being, to my mind, it looks like from that demo I saw in Vienna, at the leading edge of hybrid AI architectures and agentic AI. Max: Yeah, I mean, totally. It evolved really quickly. At the point where we looked into GPT and what language models could do, we asked for, "Hey, can we do some quick prototyping research on this and see if we can replace, let's say, the machine learning pipeline that we had with language models?" And it worked really well from the start. So in the beginning, we had 15 service technicians as pilot users that were constantly evaluating the system and giving us feedback, "Hey, that's good, that's not good." And they said immediately, "Well, this is working really well." I mean, they tried, of course, at the very beginning to trick the system and ask the hard questions. And if you look at the content that they are provided, a service manual, it has hundreds of pages and the products that they are servicing, they look quite similar, but they are quite different. Max: So there's a lot of variants in what components you can use, how you configure the system, how you buy it. So it's really important that if you have a certain product variant, you don't mix that up. And if you look at how the content is, it is very similar. So of course they have the same structure or a very similar structure and certain, let's say, chapters or topics, they are always very similar. So how you install electron microscope A is very similar to how you install electron microscope B, but it's the little differences that are really important if you are doing that installation procedure. If you forget one of those steps, of course, you will fail or you could even do some harm to the system. So it's really important that you not only have similar content or similarity in, let's say, the retrieval of the content, but you can actually know, "This is content for product A and this is content for product B." Max: So all of the work that went into structuring the content, adding metadata to each of the topics and connecting the metadata based on what entities are linkable, the RAG system that we implemented then, it could actually filter out all of the content that was not relevant to the specific question or use case. So the answers were quite good from the beginning. Larry: Yeah. I want to elaborate a bit on the evolution of your RAG architecture, and for folks who don't......

    36 min

  8. 16 FEB

    Quentin Reul: Solving Business Problems with Neuro-Symbolic AI – Episode 44

    Quentin Reul The complementary nature of knowledge graphs and LLMs has become clear, and long-time knowledge engineering professionals like Quentin Reul now routinely combine them in hybrid neuro-symbolic AI systems. While it's tempting to get caught up in the details of rapidly advancing AI technology, Quentin emphasizes the importance of always staying focused on the business problems your systems are solving. We talked about: his extensive background in semantic technologies, dating back to the early 2000s his contribution to the SKOS standard an overview of the strengths and weaknesses of LLMs the importance of entity resolution, especially when working with the general information that LLMs are trained on how LLMs accelerate knowledge graph creation and population his take on the scope of symbolic AI, in which he includes expert systems and rule-based systems his approach to architecting neuro-symbolic systems, which always starts with, and stays focused on, the business problem he's trying to solve his advice to avoid the temptation to start projects with technology, and instead always focus on the problems you're solving the importance of staying abreast of technology developments so that you're always able to craft the most efficient solutions Quentin's bio Dr. Quentin Reul is an AI Strategy & Innovation Executive who bridges the gap between high-level business goals and deep technical implementation. As a Director of AI Strategy & Solutions at expert.ai, he specializes in the convergence of Generative AI, Knowledge Graphs, and Agentic Workflows. His focus is moving companies beyond "PoC Purgatory" into production-grade systems that deliver measurable ROI. Unlike traditional strategists, he remains deeply hands-on, continuously prototyping with emerging AI research to stress-test its real-world impact. He doesn't just advocate for AI; he builds the technical roadmaps that translate the latest lab breakthroughs into safe, scalable, and high-value enterprise solutions. Connect with Quentin online LinkedIn BlueSky YouTube Medium Video Here’s the video version of our conversation: https://youtu.be/J8fgIezoNxE Podcast intro transcript This is the Knowledge Graph Insights podcast, episode number 44. We're far enough along now in the development of both generative AI learning models and symbolic AI technology like knowledge graphs to see the strengths and weaknesses of each. Quentin Reul has worked with both technologies, and the technologies that preceded them, for many years. He now builds systems that combine the best of both types of AI to deliver solutions that make it easier for people to discover and explore the knowledge and information that they need. Interview transcript Larry: Hi, everyone. Welcome to episode number 44 of the Knowledge Graph Insights podcast. I am really delighted today to welcome to the show Quentin Reul. Quentin is the director of AI Strategy and solutions at expert.ai in the US in Chicago. So welcome, Quentin. Tell the folks a little bit more about what you're up to these days. Quentin: Hi, thank you, Larry, for accepting me and getting me on your podcast. So my name is Quentin Reul. I actually have been around the RDF and the knowledge graph since before it was cool in the early 2000. And today, what I'm helping people in news, media, and entertainment is to see how they can leverage all of the unstructured data that they have and make it in a way that can be structured and they can make their content more findable and discoverable as part of what they are offering to their customers. Larry: Nice. And I love that you've been doing this forever. And one of the things we talked about before we went on the air was your early involvement in the SKOS standard. Can you talk a little bit about your little contribution to that project? Quentin: Yeah. So for this, we do know what SKOS stands for Simple Knowledge Organization System. It's a standard that has been created by the W3C standard around 2005. And being at the University of Aberdeen in Scotland, we had a lot of involvement with the W3C voicing the web ontology language and SKOS. Quentin: For SKOS, I was actually working on my PhD, and the idea of my PhD was to look at two ontologies and trying to map entities from one ontology to the entities in the other one. And a lot of the approach that were taken at the time were either leveraging philosophical kind of representation. And there was not really a lot of things that were looking at linguistics. So the approach that we were taking was looking at WordNet and using the structure of WordNet and maps that to the linguistic information, so the labels that were associated with nodes in the taxonomy. Quentin: But to do that, we needed to have a structure that was transitive. And at the time, SKOS only had broader and narrower, and they didn't have the transitive property. So my contribution was to push for the W3C standard and SKOS to include the SKOS broaderTransitive and SKOS narrowerTransitive, so that I could now have that if A broader B and B broader C, that A broader C was also correct, and having that description logic structure that would enable that. Larry: Well, that's so cool. I love that you have your ideas are ensconced in this 20-year-old standard now. But hey, what I wanted to talk about today and really focus on, I know I was excited to get you on the show because you're doing a lot of work in the area of neuro-symbolic AI, the idea of integrating LLMs and other machine learning technologies with knowledge graphs and other symbolic AI stuff. Larry: It's one of those things that everybody's talking about, but I haven't had the chance to talk on the podcast with many people who are actually doing it. So I'm hoping that you can help the listeners take the leap from this conceptual understanding of the natural complimentary nature of them to actually putting them together in an enterprise architecture. I guess maybe start with the strengths and weaknesses of each of the kinds of AI that we're talking about here. Quentin: Yeah. So if we look at the history of AI, symbolic AI was a thing that came up in the '70s and led to the first AI winter and the second AI winter for that matter. But where they were very good was in the structure and the explainability. So if you aren't very well set set of rules or predictive kind of aspect, it would do it consistently, repeatably, and all of that type of things. Quentin: Now, when you were trying to adopt a rule-based system for new data, it would die off because you had never seen that or a new set of rules or a new set of business requirements, it would just not handle that. And that's where machine learning really helped in making that transition to where we are today. Quentin: And the LLM, contributing further to that, in as much as the machine learning was pretty good at dealing with new patterns, as long as it was similar to the data that you were training with. I think one thing that the LLMs have really shine is in the way that it's able to surface things that you were not predicting from the data. Quentin: One thing that I think that we could have predicted or seen from the data if we had LLMs back in 2020 is we could probably have seen the topic of COVID emerging a bit earlier than what it did. And the reason is, it's because it's very good at surfacing things that it's never seen before. It's able at interpreting the language and analyzing the language in its structure. And by the sentence structure, understanding that things are very similar, and you may use different words for them, but now you're able to interpret them. Quentin: So if we think about information retrieval in the '90s, 2000s, and even in the 2010s, the way that we were doing a lot of these things was using control vocabulary, CISORI, or other dictionaries, and they were used to do query expansion. So you add a keyword, you were looking in the dictionaries, the dictionary were doing an expansion, and then you add something else. Quentin: Well, now with the LLM, that kind of expansion is intuitive to the actual LLM because you had seen so many different aspect and so many occurrence of text that it can actually predict and see what these different terms are associated with a holistic concept. Quentin: Now, that's a good thing. On the bad thing, the LLMs don't have ... Well, they have a cutoff point or knowledge cutoff point, which means that when they are trained, they are trained of information that is in the past. So they're not always that great at predicting, especially current event or information about things that are happening today, they're not very good at that. Quentin: I think if I look at the data, generally between the release of a new model and the nature of the data or the cutoff point, it's about six months to a year. This is like going a bit slower now or shorter in terms, but you have to remember that the time that it takes to train these models, we're speaking about days, weeks, and sometime months as opposed to hours with machine learning models. So they're expensive as well from that perspective. Quentin: Another aspect that they don't have, it's a knowledge base to just take a higher level from a knowledge graph, like the knowledge base. So it's not able to disambiguate information in a large corpus. It's very good to do entity linking within the context of one document. Quentin: So if you pass it one document, let's say a financial document, and it refers to Acme as an enterprise, if Acme is mentioned several times during the document, it will infer that there is only one entity and that entity is Acme. Quentin: But now, imagine that you have a group of financial reports, and these financial reports refer to Acme, a bakery in Illinois, and Acme, a construction company in Maryland....

    30 min
See All (50)

About

Interviews with experts on semantic technology, ontology design and engineering, linked data, and the semantic web.

Information

  • Creator
    Larry Swanson
  • Years Active
    2024 - 2026
  • Episodes
    50
  • Rating
    Explicit
  • Copyright
    © Copyright 2026 Larry Swanson & Elless Media
  • Show Website
    Knowledge Graph Insights

You Might Also Like