Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
When the idea of the semantic spectrum was introduced 25 years ago, it was meant to be a conceptual tool to help programmers and architects understand the relative benefits of different levels of semantic effort.
Now, a couple of decades later, Jessica Talisman has repurposed the model as a way to organize the actual process of developing enterprise knowledge infrastructure, which she shares in her new book, “Ontology Pipeline: A Framework for Knowledge Engineering.”
We talked about:
- her new book, “Ontology Pipeline: A Framework for Knowledge Engineering”
- the inspiration she took from Obrst’s original semantic spectrum
- her language-first approach to ontology
- her pre-RDF semantic work with standards like Dublin Core
- the three “warrants” from library science that guide functional requirements specification
- the origins of her book in a 2018 Department of Justice project and its conceptual development in subsequent projects
- how the ontology pipeline emerged from her process of incrementally delivering artifacts in projects
- the importance of teasing out and addressing assumptions that can derail ontology projects
- the crucial need to meet an organization where its at in terms of its current semantic capabilities
- how her education-first approach helps get enterprise buy-in for ontology projects
- how using RDF in vocabulary and taxonomy work paves the way to broader ontology work
- the power of working with concept graphs, in particular its benefits in AI architectures
- the benefits of symbolic representations of concepts like attribution and provenance in AI systems
- the dual nature of her book as both an instruction manual and an ongoing reference resource
Jessica’s bio
Jessica Talisman is a Semantic Engineer and Information Architect with more than 25 years of experience building knowledge infrastructure across enterprise architecture, e-commerce content systems, digital libraries, and knowledge management.
She has led semantic architecture initiatives at Adobe, Amazon, Overstock, Pluralsight, Senzing, Vanguard, the Department of Justice and client engagements spanning the Smithsonian and the USC Shoah Foundation.
Jessica is the creator of the Ontology Pipeline™ — a framework that moves from controlled vocabularies through taxonomies, thesauri, and ontologies to fully realized knowledge graphs — and founder of Contextually LLC, her consultancy in ontology modeling, NLP integration, and knowledge graph design. She also works with The Knowledge Graph Academy, a cohort-based program training the next generation of ontologists and semantic engineers.
Jessica publishes the Substack newsletter Intentional Arrangement. Her book, Ontology Pipeline: A Framework for Building Knowledge Infrastructures(Technics Publications), arrives September 2026.
Connect with Jessica online
Order Jessica’s book
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 57. When the idea of the semantic spectrum was introduced 25 years ago, it was meant to be a conceptual tool to help programmers and architects understand the relative benefits of different levels of semantic effort. A couple of decades later, Jessica Talisman repurposed the model as a way to organize the actual process of developing enterprise knowledge infrastructure, which she shares in her new book, “Ontology Pipeline: A Framework for Knowledge Engineering.”
Interview transcript
Larry:
Hi everyone. Welcome to episode number 57 of the Knowledge Graph Insights Podcast. I am super extra delighted today to welcome to the show Jessica Talisman. Jessica, if you’ve been living under a rock, just in case, I will introduce her as the person. She’s the owner and founder of Contextually, a knowledge graph consultancy. She’s an instructor and a curriculum designer with the Knowledge Graph Academy with Tony Seale and Veronica Heimsbakk and Katariina Kari. She’s also the author — and this is what we’re going to talk about today — of the forthcoming book, Ontology Pipeline: A Framework for Knowledge Engineering. So welcome, Jessica. Tell the folks a little bit more about what you’re up to these days.
Jessica:
Thank you. So yes, I am working as a consultant and so I’m working with clients and customers. Also, to Larry’s point, teaching and developing new curriculum and new course options for Knowledge Graph Academy soon to be released. And then my book, Ontology Pipeline, is based off of a framework I developed that was a riff on the old semantic spectrum, but is a composable and decomposable way to build knowledge infrastructures. And the book will be released and available somewhere around the September 16th and 17th.
Larry:
Excellent. I’ll probably drop this on either the August 31st or September 1st. So folks will have a couple of weeks. I’ll put a link to the book in there. Well, that’s interesting. I didn’t know that this was originally a riff on the semantic spectrum. Are you talking about Obrst’s original semantic spectrum and then the subsequent. Yeah, talk a little bit about that.
Jessica:
Yeah. So I felt like it was an abstraction at the time of where semantics lived, but those of us within the semantic and knowledge engineering space have always acknowledged that semantics does exist on the spectrum. And when I say semantic, I mean context and meaning type of semantics where we introduce ontologies and taxonomies and these information and knowledge artifacts. But they are varying … You can think of it as a spectrum of maturing structures to be able to go from something where you’re just simply giving context and meaning all the way to introducing formal logic into a system. So that’s where we start with controlled vocabularies. That’s step one. The second step is metadata schemas, which is a super important step that’s most overlooked, I think. Then taxonomies, then thesauri, then ontologies and then knowledge graphs. So it’s a framework that brings you through the iterative states of building a knowledge infrastructure.
Larry:
Yeah. That’s so funny. I knew that it paralleled that, but I hadn’t thought about that was the riff on it. Because the thing I really appreciate about your work is that you come out of this ancient tradition of library science and well, duh, you’re going to take a language-first approach. And so vocabularies make a sensible starting point from that way as well. Was that just … Not serendipity, but just like, well, duh, that’s just the way the world is. You start with vocabulary and build from there.
Jessica:
Yeah. Well, and I think it really came out of working. I started my career back in the late 1990s and it was right at that precipice when RDF was being introduced and I was working on this huge Steven Spielberg project, largest visual history catalog ever. To make two to six minute segments of this video available to end users. And we had more than 11 and a half years of footage back to back. So if you imagine this huge catalog, how do you make these little clips? It was well before YouTube and clips. Discoverable. So it was very, very early proof of concept and that at the time was based entirely on language because we had to tag content, we had to have consistency.
Jessica:
So we essentially built a thesaurus library or librarian style that really emerged out of the library sciences and cataloging practices and records and those sorts of things. You can think of it as the golden records. But the idea was having this consistency because where do we define meaning as humans? And that’s what it really was working towards. And thinking about how do I present something that is a repeatable process within an organization that logically makes sense that starts with humans, which is how we define things. Because ultimately when we build a knowledge infrastructure, it’s about how humans define this meaning, the first step is not how machines define meaning.
Larry:
Yeah. There’s so much in there. There’s five podcasts just in what you just said, but I’m really curious about when you said defining meaning in that project. 30 years ago, you don’t have RDF, you don’t have SKOS, you have-
Jessica:
We have Dublin Core. We had Dublin Core.
Larry:
Oh, right. So you have your library tooling.
Jessica:
I had the library.
Larry:
Yeah. Tell me about, I guess maybe a quick contrast between how you did it then, just quick overview of how you use Dublin Core for the … And I assume that was key to your metadata strategy and everything that drove that. And then how would that unfold today?
Jessica:
Oh gosh. And you know what? Actually, that’s a really good point. I would say that a lot of the practices and a lot of the core tenants of those types of systems … So using Dublin Core, which has a more mature standard for data catalogs, which is called DCAT, and we also have DPROD, which is for data products. There are these really cool W3C standards that have evolved out of the library sciences that are based on Dublin Core. Dublin Core is not … It’s so elegantly designed because the Dublin Core format first started as 15 core elements, and those core elements were like title, description, author, all of the basic metadata that you would want to apply to things with digital ecosystem. So it was that formative … It doesn’t declare anything as a class or a property. The original thing was you just had 15 elements that could be used to describe documentation in a digital space. So that one … And I think of it as a seed, that one seed emerged into this whole family of standards that are used to describe things in digital ecosystems.
Jessica:
So for example, in an enterprise, what we tend to do … And this also comes out of the library sciences and Dublin Core. Is we implement something. And I talk about this in my book in the metadata chapter. Is we implement a metadata application profile. I did this actually with Paco in Senzing is bringing them through an application profile, which is basically your documentation, your style guides, the rules of the road. How are we going to reconcile? And it doesn’t mean one metadata schema to rule them all. It’s how do we connect all of this language and meaning across an entire organization and have that meaning able to be communicated to both machines and humans? So it really speaks to interoperability. It speaks to system design. It speaks to the process of categorization, of defining meaning, of the social aspects of what so much of the industry has been trying to tackle with context. We’re starting to see this emergence of people now starting to think about knowledge management. How do you manage knowledge? It’s very social. It’s as much technical as it is social, but I would say at this point it’s more social than technical because it’s about agreements. It’s about understanding how our systems work, how definitions and meaning are translated between humans and machines.
Larry:
Hey, one thing I want to go back. Dublin Core, that goes back to the ’60s or something, right? It was one of the oldest-
Jessica:
It was the ’90s.
Larry:
It was the ’90s?
Jessica:
The ’90s, yeah. And those original standards, and it was a bunch of librarians and a few technicians that met. It was actually out of Dublin, Ohio. It’s less romantic that-
Larry:
Oh, that’s where. Okay.
Jessica:
Which is where the OCLC is founded, which is the library, the organization that basically governs all library systems throughout the world.
Larry:
But it was still quite an early …
Jessica:
Very early.
Larry:
Yeah. So now I want to go back to the Steven Spielberg project and Dublin Core. So you had Dublin Core, that was the main tool that you had. How did you manage the people part of that? Who were you convincing to do stuff to make that project work?
Jessica:
What was so interesting, and I think this speaks to the ethos that a librarian brings to the table in how we architect systems. Is there is a core function in librarianship where you always … And we hear this all the time when we build products. Is we should be building for our users. The irony is that what I’ve observed over 30 plus years of the practice is that we tend to, when we do system design, we build for each other more so than for our end users. So what we do and what we did then was you create functional requirements. You cannot pass go without functional requirements where the functional requirements for the system, and then you have warrant, and it’s not like a warrant for arrest or anyone’s in trouble. The idea of warrant is your users, so you’re building for three different warrants. One is user warrant, one is literary warrant, and one is organizational warrant. How does that translate? Well, the semantics, the actual meaning of these things separate from the environment you’re in is the literary. The organizational are the needs of the organization, and the third is the user, the end user. How is this going to benefit the user? So you build functional requirements with those three different users in mind, those three different components in mind.
Jessica:
And so we built the system to serve a function much like when we create competency questions for ontologies, what questions does the system have to answer? So it was an agreement amongst us, but always keeping the end goal in mind, which is how we are building a system together. Now, I will tell you that the documentation’s available online from that original project and the thesaurus guidance, but we started that project, it didn’t work, and this speaks the first time round. We actually had to go in and rip out the whole insides and redesign the whole metadata and symbolic system inside of that build halfway through. We had to go back to the drawing board because we realized that we overlooked the separation of events of how we were architecting events. We needed events to be separate from the core metadata that was descriptive. You have administrative, structural and descriptive metadata.
Jessica:
I think that’s a lesson learned that I do believe is important to pull into the work in general is that your first draft of anything, your first go round at building an ontology, of building a taxonomy, it may be horrible and you may have to go back and redesign and the second one’s going to be better and the third one’s going to be even better, but it’s like anything in learning a new trade or a new way of thinking or doing things is that you’re immersed in having a methodology towards the madness. This is not about vibe. We’re not vibe coding. When you design a system, you should not be vibing that system. It’s something that’s intentional, that’s planned, that’s architected, but brings in those core components like functional requirements, who you’re building this for, what does success look like, what questions do you want the system to answer?
Larry:
Now you got me super curious now about … I’m thinking of all the inputs into the evolution that led us to the current moment of ontology practice. It feels like we’re figuring out some stuff, some best practices and optimal ways to do this. And you come from this library science, you’re working with Dublin Core in this really cool, very much a librarian project. Now I’m just picturing this vague thread from functional specs in that to your first discovery of competency questions and how they work in an ontology engineering project to your current, and let’s get into the book a little bit then. How did these prior experiences affect how you organized the book?
Jessica:
Yeah. It’s not like I came up with this framework out of thin air. It actually evolved out of coming up with this framework while flying the airplane. First in 2018, I was working at Department of Justice and I had to have a way to communicate the work and to chunk out the work while still … I needed to be able to produce artifacts along the way that engineers and different users could test that we could actually get our hands dirty with and implement and test to make sure that what we’re building is working or does its job. So obviously if we go zero to 60 and introduce ontology modeling right out of the gate, I have never had that work at an organization. It just doesn’t. It’s meeting the consumers, the producers, the organization where they’re at.
Jessica:
And so after Department of Justice, I went on to the next organization, it was overstock.com. And as I was socializing this and working with the organization, we won. It was like where there was this initiative that was really interesting. And I think more organizations should do this. But you created a cross team. This was 2019. The objective was … And this was almost gamified. That at the organization you had to assemble a cross talent team, cross-functional team to come up with an initiative that would proclaim certain objectives and deliverables that would solve a company problem or an organizational problem. So you gamify it. And so it was fun and there were prizes, and so you got to work with people you didn’t normally work with, but you got to then have the engineer, the machine learning engineer, the project manager, the project manager, the SEO person, and collaboratively work on something. And then basically the C-suite voted based on the presentations and ranked all of the projects of who would get the funding, and they chose the top three projects out of a sea of … I think there were more than 30 projects that were proposed.
Jessica:
That’s where I really codified the ontology pipeline. I wasn’t calling it that then. And it was a way for me to educate while doing. It was a way for me to create artifacts while I’m building and saying, “Here’s the controlled vocabulary. I cleaned this up, defined everything for you, here you go.” And then we would test it. And then we’d shape it into a taxonomy and we would take some of the learnings from the testing. Back in that day at Overstock, we were using BERT, which is a transformer model. It’s a precursor to the current LLM state we’re in. So we had a lot of fun working together on this project, and the whole point was with a massive catalog with millions upon millions of SKUs and products in two different sites that we were working with, can we improve findability and discoverability from both search and SEO and all of these different avenues? We had the ability to measure our successes as well.
Larry:
And that educate while doing, it doesn’t surprise me that that’s how it works because that’s how you work now. You’re doing a lot of consulting work, your real life work, applying this stuff, but you’re educating like crazy, you’re writing a book, so you’re walking the walk, walking the talk, you’re educating while doing. So in terms of the book again, is that just the foundation for the whole thing of like, “Hey, here’s what’s going on-”
Jessica:
Yeah. Exactly. And also the lessons learned where I’ve gone on consulting gigs or worked with other ontologists where these really expert, proficient, talented, incredibly brilliant ontologists would come into the organization and they’d go off into a cave and they build the ontology, but there was always the gap in meaning. Where the ontologist, because they’re building based upon current data systems and not realizing that those data systems aren’t clean, they’re not well-defined. Categories like other, miscellaneous. You’re dealing with data systems and in a lot of cases, metadata that’s just plain missing. You have tables and rows and columns and catalogs that aren’t exactly well-defined and accessible to the ontologist. So I was also seeing the problem. Sorry. I was also seeing the problem from the other direction in that we had these brilliant ontologists that would come into the project and I would try to mitigate and bridge the gaps. So what does that look like? It’s you build an ontology, the first one’s not quite right because the definitions and the meaning of the underlying systems wasn’t quite right.
Jessica:
So one of the risks that exists in building ontologies is you make a lot of assumptions about the underlying systems. And fortunately or unfortunately, I think it’s one of the best things that any organization can do is actually going through by way of defining meaning within things like just what do these words mean? What does the metadata mean? What does the words in our semantic layers mean? Whatever it is, that then sets the foundation for a really well-constructed and truthful and honest ontology, one that is actually going to do its job based upon the state of the underlying data.
Larry:
So the way you just described it … Because those are the stakeholders that are of concern in this thing. Well, there’s the top down, bottom-up, different ways you can approach ontology design. But that’s really interesting that as you engage ontologists in this, did you have any trouble getting them on board with this semantic spectrum that you’re manifesting from the vocabularies to the metadata to the taxonomies? Where did you meet the ontologists, I guess?
Jessica:
Well, this is what’s interesting. What it comes down to is funding, enterprise funding. And this is just the hard reality. Is that if you go and you implement an ontology, like a full beautiful logical reasoning engine, and you present that to the enterprise, are your systems capable? Do you have the skill sets in place? Can you reproduce what you’ve built elsewhere in the organization and does talent exist to maintain and build those systems? So what I have found time and time again is when you communicate the message to your organization and you’re starting to build these systems like taxonomies on … RDF systems. RDF-based systems. Most organizations are not equipped right now. And what they’re funding is that base layer. You’re meeting an organization where it’s at. Now, it may sound cruel, it may sound like a hard dose of reality, but the truth is if people in the organization and the talent and the technology is not quite up to speed with where you are, you can deploy a gorgeous, beautiful ontology and knowledge graph, but it doesn’t mean anything if the enterprise cannot make sense of what you’ve built.
Jessica:
So if you want sustained funding, if you really do want to roll out a program and you can really leverage and get the most out of what ontologies have to offer, you have to start at that foundation. I’ve had so many clients come to me and say, “We tried ontology, it failed because the enterprise wasn’t ready or the ontology broke after the ontology consultant left. We weren’t able to maintain the system. We didn’t know how to query it.” There’s real practical problems with-
Larry:
And this must be a factor for 10 worse now with the arrival of generative AI and all that’s entailing. And both that as just a dynamic that’s driving the whole workplace, but in particular the growing need for all this talent that already doesn’t exist. This seems super important. What’s your advice to executives and people who are, one, helping them understand the need to fund this, two, to make it sustainable? It’s not like a project, it’s not like a POC you’re building here. You got to build a sustainable thing. And then how do you … Whatever, the training, the recruiting, all the stuff that is entailed and building the talent?
Jessica:
Yeah. It’s an education first approach. So I’m going through this in real time at an unnamed large Fortune 50 organization, and I will tell you that most people, most organizations are funding AI initiatives, that’s where the money’s coming from. So the first question is how is this going to improve my AI implementations, truthfulness, memory, any of the things that come along with ontologies? Then they want the message to … They’ll pay a large consultancy to come up with a deck that will communicate the message in a lot of cases at the larger companies. But the idea is that you have to lock in the messaging. What does everyone do with this? How does everyone on the ground … I’m talking about every single person from a content strategist to a data analyst, what is their role in this process? How did they contribute to this knowledge infrastructure? What are the habits they need to change? What does this look like?
Jessica:
So I’d mentioned application profile. It is a chapter in my book and I walk through what’s included in the application profile. But the idea is give a high level and design first for things like Dublin Core for DCAT that it’s going to be the connective tissue across your organization. It’s things like crosswalks between systems. It’s how do you reconcile language? It’s like you can allow for autonomy, meaning that you can have a distributed vocabulary SKOS vocabulary system, but how do you match concepts across those SKOS taxonomies? There’s mapping relations. That’s a big concept for most people on the ground and for most organizations. It’s like, oh, we can have a distributed, unified, controlled vocabulary system with definitions in RDF. You get people playing in that sandbox and they start playing and getting tactile and working with RDF, you are going to be able to find the people naturally that are drawn to this work because they’re getting to understand RDF, how to write it, how to work with it, what that data model looks like, look at SKOS, understand that the documentation and standards in the W3C world, which is an entire ecosystem of the ontology standards, that is the entry point.
Jessica:
And so that controlled vocabulary taxonomy thesaurus, you’re residing in that SKOS RDF vocabulary world. And I actually bought … I actually built an open source tool available to everyone because it is probably one of the most important entry points is getting people understanding this ecosystem because from there, what else Larry lives in RDF and the W3C ecosystem is ontology. So it’s like a natural transition into that work and you’re adding complexity, but you understand the foundations and the fundamentals is the point.
Larry:
That’s really interesting. So this focus on vocabularies and taxonomies, which is more accessible to people, they’ll have done something like that somewhere. Very few proper ontologists in that cadre that you’re onboarding to this. But this is the gateway drug, you get them hooked on SKOS. It is the gateway drug. Yeah, that’s …
Jessica:
And for AI, SKOS is lighter weight and it’s super powerful. If you imagine you have a concept with unique identifier, that one unique identifier for that one concept has a preferred label, alternative labels, documentation properties, definitions, linked data, that in and of itself drives huge value for AI and disambiguating what things mean. You can define your entire enterprise or business with that right there. And to be able to boost reliability, memory, certain implementations like people that are just using Promptsi, working at one organization right now where they have a curated list of skills for Claude, and having a SKOS skill and helping to drive that reliability, but also having where you can choose your taxonomy skill because of the area of the organization you’re in, that’s a concept graph. Most people don’t talk about concept graphs. Concept graphs are incredibly powerful because you’re able to encapsulate meaning and language, and we seem to forget we’re working with language models, so it is incredibly powerful for that. Not to mention that once you have ontologies, you can use those labels as annotations on your ontology classes and properties, which gives labels to the ontology, human-readable labels to the ontology.
Larry:
Again, so much of this is about getting people comfortable with this. Because RDF is like … It’s funny to me. And one thing I’ll just plug your course, the Knowledge Graph Academy, if you just want to get your hands dirty and write some Turtle files, it’s a great way to do it and to see how really quite simple it is. It’s just as easy as working in JSON or markdown files or whatever. I guess the ties you just mentioned, accounting for writing a SKOS Claude skill and things like that, what else are you doing to onboard? Because so much of the funding that’s being allocated now is more for generative AI stuff. Are you having success in repurposing a little bit over towards the symbolic AI knowledge representation side?
Jessica:
Yeah. And I think you just hit on it. You’re sneaking that in terms of symbolic AI. That what we’re building, you build a SKOS taxonomy in RDF, it is symbolic AI. It is a form of symbolic AI. And what we’re all playing with and what we’ve been exposed to is generative AI, which is probabilistic and statistical. So if you combine symbolic with generative, you end up with neurosymbolic AI, and that’s not a new field or domain, but it counterbalances the unpredictability sometimes of statistical probability-based models. That’s just guessing the next word. The one thing we have to realize is that originally there’s a long, long history to explain how we ended up where we are now. I wrote a piece on this, I think about a month or two ago, about the history. It’s basically about augmentation, automation in the neurosymbolic loop. So I wrote an article about this that actually is a nice history of how we ended up where we are now. And a big part of that historically is that generative AI had always been marching towards this idea of more data equals better, which went very well hand in hand with the big data movement that we’re still in, but starting to emerge from.
Jessica:
So part of the promise of symbolic is more like that it lends description and meaning and logic to the system to help to drive reliability, to build things like memory, which are so important and people are starting to realize provenance, which is really, really important, like attribution and provenance and be able to have more resilient systems while also … And it’s been proven time and time again, I have a bunch of research on this. That implementing things as simple as a thesaurus can decrease token spend by 89%. So with that being another concern, the actual savings of using a symbolic system makes the system more resilient, but also less expensive to operate.
Larry:
Yeah. I think the more of that data we can get out like … Like “Hey, your token go a little high. We got a vocabulary that can help you with that.” Hey Jessica, I can’t believe it. We’re coming up close to time. But before we wrap up, I want to make sure, is there anything last, anything you want to revisit from the conversation or just want to make sure we share before we wrap up?
Jessica:
I think it’s important. The one thing is my book is meant to be, if anyone remembers libraries … I hope they do. Is that my book is meant to be also a reference book. It’s meant to be something that people should dog ear, should bookmark, should own, should scribble on, should go back to time and time again in that each chapter produces an artifact which you can test. And it’s meant to be really a playground. I have lots of really good little nuggets in there in terms of competency questions, how to build those, how to elicit knowledge when it’s tacit, which I know a lot of people have been trying to figure out those practices. How to build, how do you determine how to construct your vocabularies? How do you approach leadership? Those types of things are embedded within the book. I really built it for the practitioner and for the new person who’s trying to figure out their entry point into this world of knowledge.
Larry:
Nice. That’s so great. And as you were just rattling that off, I’m like, any one of those could be a whole other series of podcasts, just eliciting text and knowledge on its own. No. So that’s awesome. And I hope everybody gets the book and just dog ears it to death. And one very last thing, Jessica, if folks want to follow you or connect online, what’s the best places to find you?
Jessica:
So LinkedIn, I have some activity there. Substack, I have a newsletter called Intentional Arrangement, which is the title of my second book. And the Knowledge Graph Academy, of course. So if anyone’s interested in learning or taking a Knowledge Graph course, we are going to be launching our business course, our leadership and business course, which is a two-hour-long course. So keep your eyes open for the fall for that one. But definitely order my book. Feel free to reach out. I always enjoy talking to people.
Larry:
Very cool. Well, yeah, I got a sneak peek at it and I can definitely recommend it. Well, thank you so much, Jessica. It’s always a blast to talk, but this was really fun.
Jessica:
Thank you, Larry. It’s always fun talking. We’ll have to follow up.
