Knowledge Graph Insights

Lulit Tesfaye

Generative AI has prompted a flurry of experimentation in enterprises, resulting in a parade of failed pilots, unproven PoCs, and unrealized return on investment.

Lulit Tesfaye helps companies improve and optimize their AI capabilities by adding semantics to their enterprise architectures. This puts their precious knowledge assets in a context that machines can actually work with. A crucial part of that context is the interoperability that standards like RDF enable.

We talked about:

her work at Enterprise Knowledge as Partner & Vice President, Knowledge, Data, and AI Solutions
the publication of Bridging Knowledge, Data, and AI: Harnessing the Semantic Layer Framework to Drive Intelligence, which she co-authored with colleagues at EK
her professional path from software engineering and applications development to her current role
how generative AI has increased data teams' workloads, leading to numerous pilots and PoCs, which has exposed the need in enterprises for semantic context
her definition of a semantic layer
"knowledge assets," a foundational concept that she uses to talk about data, content, information, expertise, and any other assets to which can append metadata
how she and colleagues see the distinction between the two types of semantic layers: data and analytics layers and semantically modeled layers, and the benefits of the latter
the framework she uses to convey the benefits of a semantic layer to executives
the swing of the enterprise architecture pendulum back towards monoliths, as enterprise solutions providers like ServiceNow acquire semantic tool companies
the importance of interoperability standards like RDF in semantic systems
examples of use cases that are best suited to labeled property graphs and RDF knowledge graphs and how she sees the debate about which to use going away soon
two common failure points in semantic layer projects:

starting with tools, not competency questions
insufficient skillsets and lack of leadership support


the use of multiple levels in a semantic layer in large, complex organizations
emerging trends she sees in semantic architectures:

the ubiquity of AI
the need to design for machines
the need for investment in a context layer
the disappearance of the artificial lines between structured and unstructured knowledge assets
the evolution of enterprise operating models


the importance of staying focused on our knowledge assets and adopting solutions that are based on standards and enable interoperability

Lulit's bio
Lulit Tesfaye is a Partner and the Vice President at Enterprise Knowledge, LLC., the largest global consultancy dedicated to knowledge and data management. Lulit brings over 15 years of experience leading global initiatives, specializing in information and data management solutions and integrations. Lulit is most recently focused on applying practical knowledge management, data governance, and semantic data foundations to optimize organizational information assets – providing the structure, context, and explainability needed to support responsible and effective enterprise AI.
Connect with Lulit online

LinkedIn
Enterprise Knowledge

Video
Here’s the video version of our conversation:

https://youtu.be/E6Yz6GEop7M

Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 52. Knowledge management and data engineering were already changing even before ChatGPT arrived. Now, with the proliferation of AI, the boundaries are blurring between structured and unstructured
data and other knowledge assets. As a partner at a prominent knowledge consultancy, Lulit tess fai sees every day the implications of this change, chief among them the need for semantic layers built for interoperability on a solid foundation of industry standards.
Interview transcript


Larry:
Hi everyone. Welcome to episode number 52 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Lulit Tesfaye. Lulit is currently the Partner & Vice President, Knowledge, Data, and AI Solutions at Enterprise Knowledge, the big famous consulting agency in the DC area. She's also the co-author of the recent book, or maybe forthcoming, I'm not sure, but I've seen it online so I know it's coming. Bridging Knowledge, Data, and AI: Harnessing the Semantic Layer Framework to Drive Intelligence, which she wrote with her co-authors, her colleagues at EK. Well, welcome, Lulit. Tell the folks a little bit more about what you're doing these days.

Lulit:
Thank you, Larry. Thanks for having me. I'm happy to be here and have been looking forward to this conversation. That's a very kind introduction, so I appreciate that. So, maybe a good way to start would be a little bit from the journey over the, without dating myself, I'll say I've been in this space close to 20 years at this point and it's been not a direct or linear path given how things are evolving, but the short version of it is started in working within software engineering and applications for data and information in that space, which led to me joining Enterprise Knowledge after I met the co-founders about a decade ago.

Lulit:
And then our focus was in knowledge management primarily, which traditionally is considered as learning and development or training or relegated to librarians, so to speak, information architecture and so forth. But over the past five years specifically, we've been seeing a big shift towards the silos in a way dissolving between the different types of these groups within organizations and where information or knowledge sits. So, we think in terms of structured and unstructured data, unstructured being content, PDFs, and all the things that you have in your files and folders, whereas structured data has been traditionally for data and analytics teams.

Lulit:
And the biggest swing that we have seen thanks to especially generative AI, is that unstructured data, which is really 80%, 90% of your organizations, I'll call it knowledge asset, came into the purview of data teams, data and analytics teams because of generative AI. And that was what led to this big focus on knowledge management for data as well as handling structured data. So, I think we've all gone through the pilot phases for POCs and pilots for AI with the pilot purgatory, all the failed efforts. That has been the journey, especially over the past, I would say five years is working with organizations that have been experimenting and embracing AI or today trying to wrangle what we call the AI pilot sprawl, scenario that exists.

Lulit:
So, to give you an example, one of our clients recently said we just cataloged over 150 pilots, AI pilots, and we haven't seen the return on investment as we should. Good experimentation, good learning, but we need to put an end to it and have a strategic path. So, this is where we are today. All the pilots and POCs for many different reasons that I can get to either have failed or have stalled. And at the same time, there are a lot of things in production that I would commend the organizations leading that. But the biggest failure and a big part of our journey has been the backbone, the core, the semantics or the context for AI as the lens that AI sees your organization, that has been the core of it. Just to answer maybe in a long way what we've been working on over the past few years.

Larry:
Yeah, I think the first time I met you, you did a talk about the semantic layer at that data summit in London, the one that Henry Stewart Events puts together. And I've been following your work about semantic layers since then. And what you just talked about, that's kind of the classic sort of framework that people use to connect this, like the data stuff you're talking about, the KM. But I'm really curious, in the knowledge graph world, everybody talks about knowledge engineering. And what you just described seems like the setting the stage for a big shift from knowledge management to knowledge engineering. Does that make sense? And if so, how does it fit in how you see with things right now?

Lulit:
It does. And I think maybe the best way to answer that would be to take a step back and really define what we mean by semantic solutions or specifically a semantic layer, because I think there's a lot of confusion in this space. It's funny, we start the book with it's all about semantics, right? It is truly about semantics. And the key definition that I would make here distinction is semantic layer is not something new. In fact, we're just chatting. It celebrated its 25th year anniversary this year. It's come a long way I think. And what we mean by semantic layer is we are talking about the shift from the focus from the physical data itself to the data about the data, so the meta aspect of it.

Lulit:
So, this means abstracting the physical data with definitions, business glossaries, metadata, the aboutness of the data, taxonomies to control some of these vocabularies that are very unique to your organization, what fits under our product, list of product, list of services, ontologies to be able to relate those concepts, these vocabularies that you have to your real world entities. This customer owns this product, has bought this product and needs this type of marketing material or training material. How do you connect to these pieces? That's where ontology allows you to explicitly make that machine-readable, places things.

Lulit:
And then when you apply this model, this semantic model on your assets, and I am collectively going to call going forward data content and information and expertise, anything you can append metadata to, knowledge assets, then you have your graph, your Knowledge Graph. So, this is what we mean when we talk about a semantic layer and the components that sit within semantic models....

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

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