Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
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
- Substack
- SHACL for the Practitioner book
- e-mail: sh at veronahe dot no
Video
Here’s the video version of our conversation:
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. It’s so funny that I’m thinking the last two guests were Rob at Yale, the cultural heritage guy and Joe Reis, the data engineer. So this is, I didn’t realize what a perfect follow on this was from Rob Sanderson and Joe Reis. That’s too great. But as you talk about that, are those national standards that Norway has established, are those expressed in like RDF? And so, that kind of shows the benefit of this knowledge graph connection, it sounds like. Yeah.
Veronika:
Interoperability, yes. So the national standards, they are Norwegian variants of the European application profiles. The EU, they maintain and develop a set of application profiles for well-known global standards as SKOS and DCAT and CPSV. And in Norway, the Norwegian digitalization agency has taken those European application profiles and made them, or they haven’t done too much on them, but added a few resources to make them more relevant for the Norwegian public sector.
Larry:
Well, you just mentioned the interoperability as one benefit, but also extensibility is another benefit of this technology in general. So that ability to do that. That’s very cool. So a huge part of this must be, like you’ve done some clever and elegant technical things to help write some quick Python code, but there must be a lot of education and a lot of human interactions as well. You mentioned the challenge of communicating between the information architects, the data engineers. Can you talk a little bit about the social engineering part of this?
Veronika:
Absolutely. And that depends also on who I’m talking to, right? Because if I’m talking to a SQL developer, I use a different language than talking to a domain expert that doesn’t know a thing about SQL or knowledge graphs or whatever. But what I tend to come back to when working together with the domain expertise or with data people, so to say, is my coloring pencils. Before we hit record, I showed you this box that I have of coloring pencils because I’m going on a job journey next week to outreach again. But being able to work like hands-on and knowledge graph being quite easy to visualize these kind of data structures and being able to map your mind down to the paper and talk around that particular drawing and being able to iterate as you draw, that’s a very powerful tool, I think.
Veronika:
And for me as an ontologist, that’s very easy to translate to a knowledge graph also. I make it machine-readable. But yeah, back to education, yes, been doing a lot of workshops lately on knowledge graph like end to end, not only the SHACL stories, but also continuing teaching knowledge graphs end to end, starting with the bare basics of what is a concept, what is a term, what is the definition, and how do we put them into context and ending up in the OWL world or the SHACL world? It’s a full-day course.
Larry:
Yeah. Hey, one thing, you’re at an intersection where one of the things we’re good at is disambiguation of terms, and there’s often these terms that overlap. The difference between how an object-oriented programmer talks about a class and how an ontologist talks about that, does that come up and do you have sort of disambiguation tricks?
Veronika:
Absolutely. And one term can mean different things based on what perspective you have and what context it appears in. And I think that’s where knowledge graphs is so immensely good because you can capture those perspectives and different kinds of views on the same thing because we already have vocabularies that we can use to express those kinds of perspectives, like for example, SKOS, that contains a lot of different views on the world, like identity, relationships and synonyms and hidden labels, all those kinds of things.
Larry:
Yeah, exactly. And so there’s so much… So it sounds like a lot of this is just not simply… But largely, a lot of translation and interpretation going on between these disciplines. One thing that I’m really curious about your interactions with information architects, because that hasn’t come up as much in a lot of my conversations. So I’m really curious about, are these enterprise information architects or people working on digital products or platforms or what kind of folks are you interacting with there?
Veronika:
Well, it’s those folks that create business glossaries, for example, or that maintain a set of domain specific terms for their organization and concept curation and stuff like that. And also, those who set them in context like EA Sparx folks, like typing in different objects, drawing a line between them, but it’s not machine-readable semantics, so to say. And they’re used to working on business objects and drawing lines and creating context, but not in a machine-readable manner. It’s purely visual in most cases, and sometimes, it appears as some kind of XML schema.
Larry:
Yeah, that’s a common thing that comes up just in general around graphs and knowledge graphs in particular, is I think, the initial appeal to so many people is the ability to visualize stuff like that. And then, but helping people tease out the difference between the concepts and the instances of them and the categorization stuff that goes along with it. And also, going from those, your colored pencil drawings or a Miro board or whatever to a machine-readable thing, are there different workflows? You just mentioned that IAs are working one way, and I imagine the data engineers are probably using UML diagrams or something like that. Is there a visual translation component to what you’re doing as well?
Veronika:
Well, to be honest, Larry, I don’t find those visual components that helpful really.
Larry:
Ah, okay.
Veronika:
That’s me. But I know that a lot of people are intrigued by knowledge graphs because they look very fancy when you display them as a graph on screen and you can drag and drop around and everything. But as soon as you get more than 10, 15 nodes, it becomes messy. And in a knowledge graph, you have billions and billions of nodes that… When you are operating on your actual data. But of course, like a tooling for visualizing during development or in communication with domain experts, I see it’s a useful tool, but for me in my daily work, I don’t use that much. But on approaches, yes, an ontologist would typically do the things I described, like working on paper in an iterative manner, making the model machine-readable, and that’s top-down approach when you have the model connecting it to data.
Veronika:
But you can also work like a bottom-up approach, like I described with data frames going from a data frame to RDF and then connecting to ontologies. So you meet halfway. I think that’s the intersection, right? The data people need to know how to construct IRIs, how to use ontology documentation in order to connect the data to those models. And an ontologist have to know how I can make my ontology available for the data people. And then they meet in that intersection where you have that overlap of skillsets. And that when you create a fully operational knowledge graph project on real data, being ontology driven.
Larry:
Yeah, no, and I think a lot of what you’re talking about there is just the different ways that people handle the notion of abstraction, that you know the kinds of data you have, the kinds of concepts you’re working with and stitching them. I love the way… Everybody talks about the bottom up, top down thing, but I’ve never seen it so explicitly sorted out as the top down part is the ontology engineer often. They’re obviously going to be concerned with the bottom up, and the data engineers is the bottom up part of it. Yeah, that makes perfect sense.
Larry:
Hey, one thing I want to make sure I get to is how SHACL fits into all this, because that’s how you’re… I think a lot of people know you as the SHACL expert. And you’ve mentioned it a couple times in a couple of these, and you’ve written a book about it, which is awesome and extremely well received as near as I can tell. Tell me, and SHACL is just one of this family of languages that sits on top of the RDF spec. How did you take an interest in SHACL, to the point that you wrote a book about it, and how does it fit into your overall work?
Veronika:
Oh, wow. We only have 30 minutes, you said?
Larry:
I know. Yeah, it’s no pressure.
Veronika:
No pressure. Okay. So first, I heard about SHACL in 2016 from a friend of mine, Håvard Ottestad, which is also the author behind RDF4J’s SHACL engine actually. But anyway, me and Hova, we were colleagues at a consultancy firm very early in my career, and we were going to implement a service for the public sector. And we implemented the SHACL engine at that project before it became standardized. So the vocabulary looked a bit different than it does today, but the mechanisms were still the same. And I really felt like this is so useful for real life data projects, right? Because the open world assumption and being able to reason about data is awesome. But when it comes to a real-life project, where we’re going to comply data and make them conform to a set of rules, you can’t do that in OWL. You can’t validate data in OWL. And there is so much need for data validation, being able to ensure that you have high data integrity with good quality data, and that’s where SHACL come into play.
Veronika:
And that’s what was really intriguing to me. And since I came in at such an early point, I was able to follow the standardization process at the beginning and also see where it went. And today, there is so wide set of use cases for using SHACL. Everything for data validation to being able to describe rules and constraints and creating regulatory rules as code, to generating HTML forms using SHACL or to be able to drive user interfaces. So it’s so much more than just data validation at this point. And that’s very fun to see. And I wanted to cover that breadth in my book also.
Larry:
Yeah. I forget, were you involved with… There must’ve been a SHACL working group at the W3C or did you get involved with that as well?
Veronika:
No.
Larry:
Oh, interesting.
Veronika:
I’ve never been in a company that is a W3C member, so I’ve never been a part of those working groups, no. But I followed the development and now, there is SHACL 1.2 coming up, so I followed the development there also, and especially around SHACL rules, which is very interesting. So yeah, I’ve never been a part of the standardization process, but I’m an eager spectator.
Larry:
Yeah, exactly. Well, not only a spectator, but I’m sure that as soon as it comes off the committee desk, you’re the first person doing something with it, I’m going to guess. Yeah. Back to the education part, something you said a minute ago about the… Oh, shoot, what was it? I’m spacing on a little bit. Oh, I know, it often comes up on LinkedIn, the OWL versus SHACL, as if there are things in opposition to one another. Is that a valid dichotomy or is that just some LinkedIn…
Veronika:
I think it’s like clickbait if I’m going to be honest, but just let me quickly find something that I wrote in my book. Yes, I wrote that, “SHACL is not fair to replace OWL, and that the two standards are designed for different purposes and serve different capabilities.” So I think comparing OWL and SHACL is a bit useless because they’re designed for different things and they work perfectly fine together. OWL is an open world logical declarative language where you could create steps in inferencing for reasoning capabilities while SHACL is closed-world, deterministic validational language.
Larry:
Interesting. Yeah, and that’s why early in the book you emphasized the open world and closed world assumptions. And with that, I don’t remember exactly how you set that up, but that makes a lot of sense.
Larry:
Hey, I want to go back a little bit too. The other thing I was just thinking about revisiting is that transition from all these drawings and conversations with people into machine-readable code, whether it’s OWL or SHACL or whatever it is. I worked briefly at metaphacts, whose metaphactory product that attempts to make that collaboration, facilitate that collaboration, but it’s also like, and a lot of the huge enterprises that do this, I know I can’t even say their names, but I know from talking to people there, they have internal teams building tooling around this, but there’s not really that much commercial stuff to facilitate that modeling part. Because I’ve done this, I’ve been in the UX world a lot and it’s always just distressed me to no end that you got to have these two-day workshops and everything is captured in a Miro board or FigJam board, and it’s not data, it’s just words on a canvas. How do you do that transition from drawings to machine readability? What’s that? Do you have a workflow or how does that happen for you?
Veronika:
Yeah, thank you for asking that. Yes, the drawings themselves can happen in many ways, either with coloring pencils or live on Teams with my ReMarkable whiteboards and everything. But the point is you get a drawing in the end that’s not machine-readable. And what I do, and also, together with my clients that have been trained for doing this, is take that drawing and type it into any modeling tool of choice. And I usually come back to WebProtégé. WebProtégé is very simple and it’s collaborative and it’s nice to look at, and it has SKOS implemented. So you can use the SKOS resources in the tool. And I really like it. And that also have graph visualizations for individuals if you want to see the graph visualization.
Veronika:
But together with my clients, I’ve experienced that WebProtégé is in its simple form that it is with active history feed and being able to comment on resources to one another, being this collaborative about the model, it’s a very useful tool. So the drawing, it consists of nodes and edges, right? So all the nodes are classes and all the edges are either data properties or object properties. It’s very simple. And then you have the domain people coming in applying pref labels and definitions and examples and scope notes and all those SKOS things onto the different kinds of resources.
Larry:
Yeah. The way you just said it, I’m sure that’s how every ontologist works, but you explained it as succinctly as anybody I’ve heard. So that’s awesome. And WebProtégé, that’s interesting is I didn’t realize what a good collaboration tool it was. Is it because it’s web-based? Is that the main benefit because you can…
Veronika:
Yeah, probably. But also, all the source code of WebProtégé is available on GitHub. So you could actually clone the repo and spin it up internally so you don’t have to use the web-based one, but you can spin one up on your own infrastructure. And I’ve done that also in other projects and being able to work collaborative in a closed-like environment.
Larry:
Oh, interesting. Okay. I didn’t… Yeah. Oh, okay. Yeah, I have not played enough with that. I need to play with the tooling more. And want to go back just a little bit to the book. One of the things in your SHACL book is all those case studies. There’s like, I don’t know how many there are at the end. I can’t remember.
Veronika:
10, I think.
Larry:
But the whole last half of the book is case studies. And you talked a little bit earlier about the Norwegian adaptation of EU regulations and stuff. Are there other favorites or case studies that really seem to resonate with people when you talk about the benefits of SHACL?
Veronika:
Yes. And I have to say that I’ve worked mainly with the public sector and every single organization within the public sector exists because of a regulation. Everything boils down to the requirement, the regulatory requirements in everything they do. And I’ve spent four years implementing machine-readable regulations at the maritime authorities and proved that we are able to eliminate caseworker time by several weeks to a few seconds in several use cases. And that’s a huge, huge, huge cut in time and money for the public sector. And those kinds of use cases are very interesting to my clients. So, I’ve been working a bit with that. And I’ve also just started at a new client last week, Friday last week, actually, that we’re also going to look at use cases like that. So I’m very looking forward to pursuing that track again.
Larry:
That also gives me a chance to ask one AI LLM question, at least in this interview, that sounds like the kind of thing where a natural language interface might be a benefit to a civilian user of these systems. Is that showing up in your workflows and these architectures that you’re building?
Veronika:
Yeah, absolutely. And we have experimented a little bit with that without any huge values yet, but things are rapidly getting better also. And I think also, the organizations I work with has been a bit behind on not having the newest and best model available. So you get… Results out of that. But yeah, absolutely. I see the benefit on having this generative AI thing, being able to construct good SPARQL queries and being able to translate SPARQL result sets as natural language.
Larry:
Exactly. It also occurs to me as I ask that question that maybe that benefit you described from several weeks to a few seconds, it’s probably worth taking time to learn a different interface too. You probably don’t… It’s a natural language would be the icing on the cake, but just having that capability seems like the real benefit here.
Veronika:
Absolutely.
Larry:
Cool. Hey, I can’t believe it. We’re coming up close to time already, Veronika, and we could literally talk about this forever. But before we wrap up, is there anything last, anything that you want to revisit from the conversation or that you just want to make sure we share before we wrap up?
Veronika:
Oh, wow. We’ve been touching so many points, Larry, but I could maybe finish with that. I’m going to New York next month to the Knowledge Graph Conference, and I’m going to throw a masterclass on how you can go from data engineering to knowledge engineering in a few very few familiar steps, so how you can acquire that intersection of skills, right?
Larry:
Nice. Well, having been to a couple of your workshops, I can strongly recommend that folks do that. And I’ll drop this episode a couple weeks before KGC, so folks will have time to register for that. Hey, one very last thing, Veronika. If folks want to follow you or connect online, what’s the best way to connect?
Veronika:
Well, LinkedIn and Substack are my hubs at the moment. Otherwise, you could feel free to send me an email also.
Larry:
Okay. Well, I’ll get those in the show notes as well, as well as some of the resources you talked about. You mentioned a couple things earlier. Anyhow, we’ll make sure we get all that in the show notes. Well, thank you so much, Veronika. It’s always a pleasure chatting, and this was particularly awesome.
Veronika:
Thank you.
