Episode four of WTF is the Context Layer? Jessica Talisman, founder of Contextually LLC and co-founder of Knowledge Graph Academy, explains ontologies in plain terms, why ontology work went from the deprioritized corner of data teams to the center of AI, how RDF, OWL and SKOS fit together, and how to start small with one area of the business.
0:00All right. While everyone is trickling in, thank you for joining the next episode of WTF is the Context Layer? I'm really excited about today's episode because it's probably one of the most talked about topics. I think every conversation I have today someone is bringing up, "Well, what about ontologies?" And if it's not coming from the customers, certainly the vendor world is talking about ontologies in many different ways, which we'll talk about on today's episode. But thank you for joining. My name's Austin Kronz. I lead AI and data strategy for Atlan and I'm excited to talk about the latest topics in all things AI.
0:33My job, I always say, is just helping organizations build with AI that actually understands your business, and with that comes a lot of challenges because there are a lot of terms being thrown around. I think every company is talking about this word cloud of different buzzwords and topics and, and I don't think anyone really agrees on them. In fact, one of the best questions you could probably ask when you get on a conversation now is, "I hear you're saying this word. What do you mean by that?" And in this case, we're probably talking ontologies today. Oops.
1:05Some of the key questions we're gonna talk about on today's episode, and hopefully answer at the end of this hour, is just ontologies have been around for quite a while. Why did enterprise adoption stall in the first place? If we have AI now, can AI help not only with utilizing ontologies, but can AI help build them? And then is context layer just a new word for ontologies? Is it parts of a whole, or where does this fit in? Is it a rebrand an innovation? Where do we stand on this? And before we get too deep into the episode, I do wanna promote our Context 26.
1:36It's our first AI community conference all about context, so please join us in October. Register early. There will be hundreds and thousands of your peers at this event, so I cannot wait for, for this evolution and this next event. Now, what we've learned episode over episode is that grounding in some slides or some architecture or some diagrams has been really helpful, and much like you building with AI, we are trying to iterate every single episode. And so before we get too deep into the conversation, and I introduce our guest, Jessica I wanted to talk just a little bit about how we've been thinking about context with customers and give us a foundation for today's episode.
2:14So if I take away all of those buzzwords and all of the terminology and product offerings and things that are out there in the market today, the way we've been thinking about context recently is just in these three categories, whether it's knowledge, expertise, or norms. All of this is context that your AI needs to effectively give results. Knowledge, in this case, is just the map of your business, so what do things in your organization actually mean and what is true? Whether that's entities, definitions, descriptions of your data, the relationships, it's the way your company operates and the way it talks about itself to itself amongst each other.
2:49Expertise is how work actually gets done in your organization. This is that procedural knowledge. It's the playbooks, the workflows, the tasks all the things that might live in a document or might just live in the heads of individuals who have been at that company forever.
3:03And the last piece is norms. These are just what is allowed, how do we go about our business, what are the policies, the permissions, the scoping, the paths, all of these guardrails that would actually help an AI navigate questions and tasks effectively. And all of these help answer different types of questions. There's many different types of contexts that sit within the knowledge, expertise, and norms, and that's what leads to many of the categories or buzzwords or topics that we've been discussing on these episodes, whether it's ontologies, graphs, skills, semantic models. Please see the, some of the previous episodes where we cover some of these topics.
3:43Whether it's a question that you are asking an agent and the type of information that that artifact provides, what we're trying to dive deep on, on are each of these topics and how they're actually all types of contexts for your AI agent. So I'll leave this up on the screen just for a second as you can read through it. Ontologies might help you understand who a customer is. The context graph is really the learnings in real time, so how have we actually handled cases like this in the past? Skills are capturing that procedural knowledge so AI can reason through it. Semantic models actually give the, well, what does revenue actually mean in our company?
4:21And data catalog, SQL intelligence, sometimes we just refer to this as AI-ready data. You may have read all about this for the past couple of years, but data catalog is really just what is the authoritative source of truth for the data that I actually need to navigate to. SQL intelligence, essentially there's a lot of information that's baked into the queries that have existed in your BI ecosystems and in your existing infrastructure and so there's a lot of information on, like, how people actually navigate your data estate today that we can mine from SQL patterns.
4:50And of course, in the agentic world, memory becomes important, whether that's semantic memory, whether it's your auditability, or whether it's the more procedural memory. So how are you actually learning from things and feeding it back into that context graph? I'll spare you the architecture diagram because I wanna get into our, our guest but I'd love to talk more about it so feel free to reach out and, and we can dive into each of those. But without further ado, I'd love to introduce Jessica Talisman.
5:15For those who don't know, Jessica is a semantic engineer and information architect who brings over 25 years of experience building knowledge infrastructure across enterprise architecture, e-commerce content systems, digital libraries, and knowledge management. She's the founder of her own Contextually LLC, it's a consultancy, and she's the creator of The Ontology Pipeline, which is a framework that moves from controlled vocabularies through taxonomies, thesauri, and ontologies to fully realized knowledge graphs. And last but not least, her book, The Ontology Pipeline: A Framework for Building Knowledge Infrastructures, will come in September. So Jessica, thank you so much for joining us today to talk more about ontologies and context layers.
Jessica Talisman
5:55Thank you so much. I always love chatting with you, Austin, so excited to be here.
Austin Kronz
6:00Yeah, absolutely. I, I, I know I think Snowflake Summit was the last time you and I had a chance to chat context and ontologies.
6:09And in this world, I think things have changed so much, so in the past sixty days, I would imagine it's a very different conversation. And everyone's at a different point in this journey as well, so the understanding of ontologies maybe early in the summer could be different right now. I wanna start with just a very straightforward question. We're talking about ontologies and AI. Just what is your take on ontology's role in the AI era?
Jessica Talisman
6:35Ontologies are fantastic for descriptive logic. So ontologies describe things within our environments and also can introduce, not always, but they can introduce reasoning, logical reasoning. And I think that's where, you know, there's... If, if we distill things down to common denominators, you know, RDF is the the way that we express. Ontologies can be more complex or less complex, but the idea is introducing description and descriptive logic. And that's the most important thing, and the role with AI is that it helps to disambiguate a landscape. So an example is within any person's domain, digital asset means something different, for example.
7:25So describing that very specifically and defining it very specifically, and defining the relationships between things in your environment in a format that LLMs can easily ingest and parse and understand is is why we're, where most people are drawn to ontologies.
Austin Kronz
7:44Makes sense. Makes sense. So we're talking ontology, as you already mentioned RDF.
8:04Everyone you talk to says it, but how would you ground us on just what is it?
Jessica Talisman
8:10Yes. So what's interesting and, and if you come from a traditional data background you know what, what we tend to do is, is we tend to, at best, when we look at our semantic layers and what have you, we try to name things. Just explicit labels, right? We're labeling things, maybe applying a definition. We see these things get stuck in things like the metric layer, you know, describing what's being measured, but it's just usually a label, maybe a definition at, at best.
8:38But when we move into ontology land, what we're really doing is we're structuring data to be represented as classes, those immutable things that are defined that exist in our space, that define our domain. So it goes a little bit further when we start to create different types of relationships, because what we do when we model ontologies is we also declare rules.
9:00Like things, certain things can be related to other things. Some things cannot be related to other things. When you start to implement constraints with definitions and relationship types, we start to get a, a type of what I call descriptive access. A machine and a human can both access the descriptions of these things and understand the context of these things very explicitly. And I think that's the part that we're missing is like ontology, yes, it, it can be derived from the, the philosophy domain.
9:34We see things popping up, and I've written about this extensively, is things like you know, gene ontology, for example, in, in that, that sort of implementation that is absent, does not have RDF, for example, and that's the way, again, that we're able to describe ontologies. There's been a lot of discussion about, about what defines an ontology and what does not, what is descriptive access, you know, which is how I think we end up in this fragmented world where we start to create these little subsets of ways of describing things, of creating that sort of descriptive access for machines and humans.
10:12So the most important thing to understand is that true ontologies present a type of symbolic— it's called symbolic AI, also known as good old-fashioned AI, GOFAI. So there's a total history to this that dates back to the beginning of artificial intelligence historically, where symbolic AI describes the things in your environment, so you're not just working off of statistics and predictions. You're actually defining and structuring and creating a universe that defines your domain and your business. So it's a little bit more holistic than just describing things in flight as they move through a system. We're actually— It's sort of think of it as a precursor to you know, defining specific systems.
11:00We're trying to define what's in those systems.
Austin Kronz
11:04Gotcha. Makes sense. That's really helpful. And I don't know if I, I'm upset that you're introducing another buzzword of good old-fashioned AI, or it's a great thing because now I have to do an episode on what is GOFAI. All right.
11:19I mean, like, the, the, the version of AI that we're working with is one type of AI, and then we think that's it because that's all that we've been exposed to. But I, I recently wrote a piece about this because in order for us to stand strongly in our philosophy and our implementations with AI, it's really important to understand the prior art and Mm-hmm... AI has been implemented up to this point, and that there's more than one type. So there's really elegant architectures that, that we can get into. So the next episode will be GOFAI, good old-fashioned AI.
11:53Yeah. So you've raised a really interesting point, right? Like generative AI is sort of what brought AI to the mainstream masses, whether it was ChatGPT or just the average consumer now is exposed to AI, and so generative AI might be all that the, the masses know. There's obviously the core group of AI researchers and practitioners that have been building things with AI for decades, and whatever their version of AI may be. I think a lot of people are asking why, why now? There are people that have been involved in ontologies like yourself for many, many years.
12:29What was different today that was different 20 years ago? Has anything actually changed or is it just a Even just going back to 2020, it was a battle to get any of, of my work.
Jessica Talisman
12:39You know, even being hired directly with a company, it, it was always the, the stepchild within an organization. The work that was deprioritized was the ontological work. And I believe that what has happened is we moved, if you think back to the early 2000s, we were in a place and all the way until about this, you know, the, the availability of these frontier models, our, our focus has been on, on big data. It's about collection, storage, and query of data. And data, of course, you've heard data is the new gold, so that was, you know, sort of the, the operating principle for a really long time with organizations.
13:20There are a couple things that happened was, number one, the scaling laws having to do with generative AI. It was realized that, that more data... There, there's not infinite data in the universe. AI is less performant when it trains on its own content, meaning AI-produced content or, or things. And so there, there was a shift when the sort of scaling laws, you know, came into play that we realized more data is not gonna fix this problem. Big data is not gonna fix this problem. All of a sudden it was about the quality, right? So we moved into data quality, data definitions, metric layers. Semantic layers made a comeback and started to be redefined.
14:03So now that we're at this place and we're accepting the, the hard truth that big data does not save us in this instance, then all of a sudden what's changed is we're, we're realizing that description is what matters. There were a ton of papers that came out in research specifically early on produced some by Google, some by by Microsoft, that proved out, and this we saw with the advent of RAG, so retrieval augmented generation. That was the first real dipping the toe in the water of sort of ontology work and its value for AI in driving accuracy and reliability with systems.
14:43And that was like the slow intro to ontology work was, you know, that those early RAG implementations involved ontologies, and so it started gaining attention. And through just experimentation implementations and that sort of trickling out through research, it became apparent that, that AI was, you know, more than just generative and that we needed to counterbalance and describe and define things, which led to context.
15:10So that obviously led to the thing, you know, Anthropic, for example, introducing the context engineering and the context layer, and these sorts of things came into play for specifically that reason because of that shift from big data and scaling, you know, the scaling laws that, that, that became more upfront, and then, and then the requirements to describe and define things.
Austin Kronz
15:36Gotcha. Yeah, that's really insightful. So I, I think there's a lot of people in, probably in the audience that are coming from maybe this data background Yeah... To your point, there's, there's been a lot of, I wouldn't even say attempts, but relatively successful in it, like semantic layers were meant to capture meaning in some way, shape, or form from an organization. But in some ways it was almost bottom up, bottoms up. It was, we have this data, we need to put something around it for it to make sense and have people agree on, like, what do our key metrics mean. How are organizations kind of getting by?
16:09If they don't have a formal ontology today, how are they capturing meaning and, like, where do the wheels kinda come off whenever they start adding— A lot... Enterprises, agents.
Jessica Talisman
16:17Vector databases. Vector databases I think is one sort of false step because you're, you're giving a machine the responsibility of defining your organization's own meaning. That's one place that I see it coming, the wheels coming off. You know, that's, that's sort of this, this brute force type categorization to try to define meaning, so that's one place. You know, and also another thing is not everything's in your SQL databases. Not everything can be described and contextualized from your SQL databases. That's just truth. Or Postgres or whatever. And so having to extend outside of that requires more structuring.
16:59It requires dipping into content, for example, your content repositories, your Confluence, your Slack channels, like things that are not stored or represented in your SQL databases. So it's like that move from data to information to knowledge, I'm not gonna say it's the pure DIKW you know, progression, but, but there is now a requirement to give a more holistic view of the organization beyond just what your databases represent. Like, who is your company? What is your digital thumbprint? And how do you describe the things within that you care about? Tokens have also, and the cost of AI implementations has also come into play here.
17:43So with people being concerned with cost and what have you, the, the reduction in token spend with things like ontology and semantics has made a huge impact and has really sharply focused people's attention towards doing things to, to control those budgets.... And these are the things that, that are available that we know work.
Austin Kronz
18:06Yeah. That constraint, the token kind of resourcing constraint is an interesting Yeah... That usually drives more like efficiency. So would you say ontology is an efficiency component? Because if I just let the latest model reason for hours— Yeah... They probably could figure out some of these questions. But then I'd see the bill— I'd see the hundreds of tool calls and context calls and everything behind the scenes that it looped through just to get what potentially could be a very basic answer.
18:36It's an efficiency piece that ties into memory as well. And so that's why when I was looking at that, that slide that you pulled up with all the different things, I was looking at it and thinking, "Well, that's architecture and that's an output, and that's an output of this implementation." Like, I could almost—... Draw a crazy map of that slide because they're all interdependent. I don't think it's one thing— Yeah... Or the other. Ontology helps you structure repeatable patterns. It helps It's reusable. It's something that once you encode it can become part of your organizational memory, an essential part of that, which also reduces token spend.
19:15So rather than doing implementation sort of ad hoc and on the fly and not necessarily recording different sorts of loops or, or what have you, or having conflicting loops within an organization, the idea is capturing workflows, having reusable patterns, encoding that memory. Like it becomes all part of the entire agent or agentic ecosystem.
Austin Kronz
19:40Gotcha. Yeah. I, I have a bunch of questions on how everything in that slide might relate or differ from one another. I have one more— Yeah... Foundational question maybe.
19:50Your ontology pipeline, and please keep me honest here. I believe the progression is vocabulary, taxonomy, thesaurus, ontology, knowledge graph in a progression.
20:01Where would you say most enterprises think they are versus where they actually are?
Jessica Talisman
20:06I see this all the time where people lean right into ontologies because they think the descriptions and the definitions and their semantic layer, layer suffice. That is a huge mistake. That primary step out of the gate of taking your catalogs, of taking the taxonomy trees and, and sort of that navigation, the navigation principles set out in your SharePoint, in, in your Confluence pages, how you organize your Jira. Like all of that needs to be structured and defined and agreed upon.
20:38You know, I'll give you a classic example at an unnamed company that I'm working with. For example, other, the category other. If you start by allowing the definition or a category like other, which is very ambiguous and basically a junk drawer, and you try to ontologize that or represent it with an ontology, you're starting with no definition. So what I see happening is that people then try to implement an ontology without having reconciled the meaning and description of things, and that can cause a lot of failure because you're actually hardening silos. You're hardening illy ill-defined things. An ontology doesn't magically fix things.
21:23An ontology requires that hard work of defining and understanding your domain in order to properly structure it as an ontology. So that's something that I see as somewhat of a misstep. But also it's the preparation phase. So when we, when we work with taxonomy and ontology and we encode it with SKOS, which is a, a, a RDF data model, Simple Knowledge Organization System, that structures your vocabulary as RDF, which is the same format or way that we express ontologies as triple statements.
21:59So most likely your organization is gonna get its training wheels by working with your SKOS taxonomies and thesauri first to understand how to work with RDF, how to model RDF, how to leverage RDF with LLMs, and then maturing into ontology. That work of defining has already been done. You can carry it over into your ontology work. It becomes much more simple to build an ontology based on the definitions you create in your taxonomy.
22:28And what's interesting is like if anyone wants to see what that SKOS looks like, you can look at the World Bank, you can look at Getty, you can look at Wikidata, you can look at Many of the training sources used for LLMs, the, the top 10 training sources if you look at them, how many of them are also represented as RDF, like simple SKOS vocabularies? A lot. So so they're, they're pretty common models on the, on the internet, the SKOS model, and, and in some EU co-countries...
23:02Well, EU countries and EU itself structures their own vocabularies using SKOS. So it gives you that sort of common surface and a way to leverage also from these open standards and do really cool things, like something we include with taxonomies that's very valuable, and thesauri is linked data, linked data principles, JSON-LD, those sorts of things. You you, you open up the world to these different types of semantic implementations that aren't quite ontology, but they're in that consumable structure. Like anyone who's into the Wiki LLM thing, your next step is to model things using SKOS.
Austin Kronz
23:42Gotcha. Okay. That's, that's really helpful. We were gonna save some time at the end for questions, but I think Igor in the chat actually has a really relevant question to what— Sure... We're talking about right now, which is I'll, I'll let you read it, but I'll try to summarize for, for those just listening in. So essentially saying RDF and OWL may have been pre-LLM problem or solving for pre-LLM problems. Ontology can be a conceptual model in the agentic AI, kind of the gen AI era.
24:13Is there a new way of encoding things or do we need these same concepts in more of like a natural language reasoning model versus maybe more of like the deterministic reasoning systems?
Jessica Talisman
24:24I mean, if you want reasoning and explicit, explicitly described, like introduced descriptive logic, RDF and OWL are The ways. I wouldn't say OWL is absolutely necessary unless you want to introduce that formal reasoning. But at least RDF, where you express those triple statements, which mirrors language in general. Remember— Mm-hmm... We're working with language models. It's a format that's easily ingested and understood by LLMs. So I don't know what that new model would look like unless we want to remove any sort of machine-readable structure and just rely on natural language. I don't know what that would look like.
25:09I mean, what would be the alternative interchange format to describe things if we know that this is something that works? I think that the barrier to entry, which is learning something new. So learning RDF is, is hard, so is learning SQL is hard. But, like, you choose, you know, you... If, if you want to learn this domain and understanding of ontologies and the, the more than 30 years of, of scholarly research in that area it's, it's worth understanding the principles behind it, I think.
Austin Kronz
25:49Makes sense. I'll, I'll skip to a, a question probably in line with this, which is more of, so how has gen AI in particular, like this, this wave of generative AI and just agentic AI in general, changed how the ontology community sees ontologies? Is it, "Nope, s-same principles we've always had, it's just more important than ever," or, you know, agents can consume things in a different way, maybe we'll rethink some of these patterns?
Jessica Talisman
26:19I think there's some interesting implementations. I... Someone in the comments mentioned JSON-LD, and yes, that's like one way that we can express RDF using JSON and linked data. It's fantastic. Like I mentioned before, linked data with SKOS is fantastic. That can be expressed in JSON-LD similar to schema.org. So, you know, there's so many layers and levels within even the ontology domain. So as ontologists, we're playing a lot with neuro-symbolic loops and things like that. So when you combine LLMs with the RDF flavor of semantics, our ontology flavor of semantics, you end up with neuro-symbolic AI. And neuro-symbolic AI is a domain of research and specialty that goes back 30 years.
27:04You know, the Neurosymbolic Conference has been going on, I think it's its 27th or 28th year. And so this is like an entire... If we look at, like, where the ontology world is and how we're working with, with LLMs, we're really testing these neuro-symbolic loops. And it really has to do with augmentation, principles of augmentation first before automation. How do we introduce symbolic symbolism, so s-symbolic AI in the form of ontologies? What's the minimally viable version of that? An example, and I know that we were gonna discuss this, is like can an ontology build an an... Can an ontology be built by an LLM, for example, from scratch?
27:49We, you know, within the ontology world, and this has been proven out time and time again, if you start with the basic framework defining your, your overarching things within your environment, and with some guidance, an LLM can really help to expand your ontology. But building from scratch, you're asking the LLM to do something that it can't do. It's a statistical probability machine, and so it doesn't encode meaning. It doesn't naturally have your memory in there. It doesn't naturally understand the meaning of your organization.
28:29So digital assets within a financial institution is a very different thing than digital assets within, like an organization that, that... Like an edtech organization.
28:57And then there's AI for building the ontology itself, which starts to become a bit of a chicken and egg problem because— Yeah, yeah... Wait, if I'm hearing you correctly, what you're saying is you need some foundation of established meaning Yeah... You, you need context. If you're gonna use an LLM, an agent, you need to give it context, which might Yes... Some starting source of meaning in order for it to even bootstrap or enhance an ontology.
Jessica Talisman
29:26Yes. Yeah. And I'll give you a classic example in the ontology world is, like, I see people all the time starting with ontologies, and the first thing they do is they, they define an employee as a class because ontologies have classes, properties, relations. There's like different components. And so when you define an employee as a class and that employee leaves, then you have basically erased that employee. When you describe a person as a class and your employee is a property of a person, then if that person leaves your company, they don't get deleted.
30:10You can change their status. That person's status can change. It's like these overarching principles for modeling is where, where we are trying to support the persistence and at, at the same time as, as, as our description. So how we model that framework, how we assert the descriptive logic for our business is fundamental to using AI to help to scale and help to build out your ontology. So you need those primary definitions, absolutely.
30:47That's helpful. So I wanna get into, you know, I shared the buzzword slide in the beginning, the word cloud of all these things. As someone who's talking more about context more broadly, where ontology is a huge piece of it in, in our mind, right? We obviously get questions all over the board, right? Like, well, are you using a graph database? Are you... Like, how are you hitting semantic models? How are Like, all pieces of that map that I shared we're getting, we're getting asked about. I guess my first question is, do you find the same thing? But then the question behind that is: how do you start to carve up ontology versus knowledge graph?
31:22Like, how do you manage the conversation between these key terms?
Jessica Talisman
31:25That's a hard one. That's a hard one. So I, I, I tend to, and I, I also include— This will be part of my book, but fundamental is my metadata application profile. Shout out to Senzing because I did this work. It's publicly available in their GitHub, is the metadata application profile. And the purpose of that is most organizations, their breadth is... And, and I mean, like, the way that they proliferate meaning throughout a system oftentimes comes via metadata. So something that I pulled over from the library and information science domain is the concept of a metadata application profile or a MAP.
32:03And that's a way to get an overarching view of your organization, meaning, like, how data moves, what systems are in play, how we represent different things. So first it's understanding your overall organization and then breaking that up into requirements that you can define and classify under, for example, taxonomy, thesaurus, ontology, because ultimately those become core capabilities within your organization, each of those things. If you need a glossary that is in a machine-readable format, easily consumed and understood by LLMs, you're gonna have a taxonomy, right? And that may be enough for your organization to, to have that persistence in meaning and description to carry you through certain types of workflows and agentic you know, implementations.
32:52However, if you need more maturity, it's knowing exactly how much context and what type of context is required for any specific job or implementation. That's the key. So it's starting with that overarching and, and from a traditional data environment, we know that is, like, sort of the conceptual model. And codifying that in a metadata application profile that shows how these systems interact and what's in use and what's in play. So for example, if it's a Collibra instance how do we know we can trust Collibra? How is that represented beyond just what's in Collibra?
33:35How do we unlock the value from that and represent that in a, you know, SKOS RDF format so that we can translate that view into our semantic reality?
Austin Kronz
33:48Gotcha. Okay. So in, in that I didn't hear graph once, which is interesting. So you focus a lot Yeah... Kind of building the foundation.
Jessica Talisman
34:02People don't— Yeah... People go right to graph, and so understanding graph is an architecture. No two graphs are the same. And that's the problem when we start talking about graph right away, like a context graph. Is that a knowledge graph? There was a conversation on LinkedIn about this the other day. It's a sub it's a type of knowledge graph. It is. Now everyone can have their own iteration of it. Is it a property graph? I don't know. Is it a RDF graph? It depends on your lens and what systems you have at play. But a graph itself involves more than an ontology, more than a schema.
34:38Otherwise, we'd just be talking about schemas and ontologies. A graph includes indexing, it may include NLP, it may include your knowledge base. Like, there's a lot to consider. It may include a vector store. There's, there's a numerous ways to, to architect a graph. So when we say graph, are we talking about the bubbles and lines on a page, on a screen that looks really exciting 'cause you can move them around and click on them? Or are we talking about the actual architecture of your graph that's meant to to communicate meaning?
Austin Kronz
35:14Makes sense. I think relationships seem to be the common denominator on these conversations, regardless of the term that's being brought up. It's just how do things in my organizations relate to one another? I think in the data world, generally primary foreign key relationships, we figured out how tables relate to one another. And then when you Yeah... To the conceptual level, like how do concepts relate to one another, people really— Yeah... Gravitate towards...
35:37Depending on where you're coming from, like if you're the architecture person that has to buy technology and deploy it in an organization, I think graph is always the starting point because it's like that's within my reach, and what I can do for my organization right now is kind of buy this thing. Now, there's so many other things that would go into making that successful, Yeah... I am always trying to get to, like, why are you approaching it from this angle?
36:00Like, why would I wanna talk about context for AI? Are you saying— Uh-huh... Ontology? Why are you saying graph or why are you saying semantic? And usually based on your background and what you've done, I can kind of figure out like, okay, your version of context is this one window. Let me either expand how you're thinking about this or kind of explain to you why it's a yes and, and not just Right... Like this is the solution.
Jessica Talisman
36:23I mean, I think something that's interesting, 'cause I, I hear you and I see confusion where you have your property graphs, which can be bound to schemas or can be schema-less, right? So it's anyone's guess who you don't have. If it's schema-less, then how are you describing things and how are you maintaining and defining stability for descriptions? Versus if you have something standardized that's formalized and repeatable so that you have to work within the constraints of what's explicitly represented that, that's a little more of a control, like quality control mechanism. So, Those are two vastly different implementations.
37:05A property graph and a knowledge graph that has, you know, a that's used, uses, uses RDF, for example, or ontology. You can have a concept graph. By the way, your taxonomy and your thesaurus, if and this is rarely talked about, but you're using SKOS and RDF to structure your taxonomies and your thesauri, that's called a concept graph. Is that enough? I'd say in many implementations that I've been involved with, that may be enough, and you again have that persistence in the definitions and at least the broader, narrower, the hierarchical relationships between concepts that's formalized in, in that it's structured and, and maintained and governed.
Austin Kronz
37:51Yeah. So we, we talked a lot about, I think, concepts and how they relate to one another. I think that's, that's really helpful. I, I always try to think back. The first, the first software I built that I, that a, a parent company ended up buying, I will never forget the CEO telling me when I would get on in these, like, very in-depth conversations, like famously said, "Austin, I don't care if you call it Mickey Mouse, just tell me what you actually do with it." Right?
38:19He didn't care about the terminology or anything like that. In an actual organization today, a lot of the drivers of these conversations are we're trying to make agents work for our enterprise. That is, at least in my worldview, what's driving these types of conversations. So what is actually important today, 'cause some leaders I see getting caught up with, "Okay, I hear ontology. I need to go down this path of building an ontology before my agents are successful." Or is there a way to maybe, as Anthropic would refer to it, like hill climb and say, you're not succeeding against your evals with these AI agents.
38:55It's because they don't understand how things relate and, you know, each of these pieces of context, are they additive or is one truly a prerequisite that you have to nail before you can even deploy something in an organization?
Jessica Talisman
39:06I still maintain the, the taxonomies and the thesauri have to be nailed first because if you're expecting people to launch right into ontologies and they haven't structured and defined the underlying things in their business, it's something as simple as like wh-where's your controlled vocabulary for SharePoint? Where's your controlled vocabulary for Collibra? Where's your controlled vocabulary for these things that are locked within your data environments? And let's look at things holistically. So yes, you have to define meaning and the relationship between things, but you cannot do that if you haven't defined the meaning of your things. So one comes before the other. A relationship...
39:48So I'm gonna say something maybe somewhat controversial, but context exists in the relationship between things. That's how context is defined. It's how things relate within your environment. So if that's the truth, then you have to have defined entities or things in order to create legitimate relationships between things. You can't define the relationships if you don't understand what things have relationships. Like, you know, your the relationship between onboarding to like some offsite or your relationship between Confluence pages and your Jira tickets. Like you, you have to define these, these things, and secondarily, documenting workflows. We're not very good at that.
40:38And of course, that leads into the third thing, which is the tacit knowledge collection. So I think that's what the context graph conversation highlighted was the sort of documenting procedures and process and workflows. But, but if you're gonna define meaning, you first have to understand and define the things that have meaning. I know that sounds... But there's no way to have the relationships. You can't say that something is related to or has a certain function within your organization if that other, if that thing is defined as other.
Austin Kronz
41:14Yeah. I think where some of the questions come from are like, are organizations running into the problem statements that then lead them down this path? So for an example, I work with customers all the time that a lot of times context is just baked into whatever agentic platform they start to build. And sometimes these relationships are literally an instruction box, a markdown file, something that just says our... Here is our, you know, I'm just manually typing in or prompting or saying like, "Here is how our company works," and, "Oh, by the way, you know we're a SaaS company that sells B2B," and like it's literally text that an agent reads and it's over.
41:57And then you kind of get to the next level, which is more of like a RAG or a context engineering model where you're actually assembling these facts from supposedly canonical sources of truth, like a Confluence doc, a standard operating procedure, you know, something that's more authoritative, but still needs to be put into a better, more machine-readable, optimized type of format. So to me, that's like slightly more abstracted than just hard coding text into a box. But then I think where you're getting at is everything that you are doing in these phases are just to establish meaning in a more repeatable way.
42:33And ultimately what an ontology is, is approaching it from the other perspective or the other almost, I don't wanna say top-down, but just a different direction. Basically saying you should just establish these key relationships in this meaning so that you don't have to do this work over and over every single time.
Jessica Talisman
42:49Right. And the repeatable pattern, that's like a huge highlight, is, is that goes hand in hand, Austin, with investment. So I had an interaction the other day where someone questioned the ROI on ontologies and graph work given how expensive they are.
43:07I keep on hearing they're very expensive. We pay for databases, and we pay for software engineering and data engineering and invest heavily, I feel like— With one foot still in that sort of big data era, and we're in this uncomfortable transition to having to construct meaning in our organization, we're not fully invested. We are wanting a one-and-done magic bullet that I can build this ontology once and it solves all of my problems magically, and I don't have to invest in the expertise, the work, or the persistent effort. But the truth is that this is like a muscle you have to build in your organization. It requires constant maintenance. It's gonna require expansion and contraction.
43:55Those are the, the hard truths people don't wanna hear. It's a shift in investment because the, the rewards on the other side of that investment, so you're basically putting money in the bank because it's going to decrease your, your token spend. It's going to, to drive more reliability and accuracy and predictability in, in your AI implementations. So that's the other side of this is, is, is this expectation that we're gonna build fast, break things, and we're just gonna throw any context that, that can make this thing work. You know, it's like the hammer and nail situation.
44:34But in fact, this is like a discipline, and it just requires that constant refinement and curation and understanding and description. So that's the other side of, of, of the reality.
Austin Kronz
44:48Gotcha. Okay. I do wanna give it... I know we're 15 minutes left in the hour, so I wanna just let the audience know. Please keep chatting in the comments. We're gonna save some time to make sure we cover all the questions. You can use the Q&A feature as well, but I definitely wanna interact with the audience a bit more. I have a, a few more for you, Jessica.
45:08So let's say we nail ontologies. We we've convinced leadership, yes, this is the investment path we need to go down. It's, it's beneficial. What other types of contexts are necessary for these AI or agentic use cases?
Jessica Talisman
45:23I mean, collection of documents, the metadata layer is really important for being able to connect. And I think, I mean, that's like Atlan's specialty is like how do we translate this into our workflows but also into ontologies? Like the metadata, it's actually one of the OGs, one of the first ontologies to ever come online and on board, was created by librarians. It's called Dublin Core, which was meant to represent documents and documentation online. It's one of the oldest specs, Dublin Core, which became DCAT, which became DPROD.
46:00You have all these different iterations of this, these things that exist in RDF, but do not look past normalizing your metadata and, and in transforming that into sort of an RDF format that's able to introduce that description. So you know, this, this can involve working with Avro and Iceberg tables. Like what does that look like in RDF? How do you describe these things in a repeatable and reliable way to connect the ontology with the taxonomy with your environment?
46:31So I think bringing metadata back to, I know I spoke about metadata application profiles before, but that's really where I see most people getting hung up is they'll build these taxonomies and, you know, the controlled vocabularies that just sort of describe words, and then you have your ontologies. But there's this like middle ground that we talk around when we're talking about workflows, but that really connects to our metadata and how data moves throughout an organization and, and throughout systems.
Austin Kronz
47:04Gotcha. Really helpful. Getting close to the end here, so I wanna make sure there's actionable pieces.
47:13I, I ask every guest, like, what could someone listening to this do tomorrow? If you were to tell all the listeners— Yeah... Go do something the rest of the day or tomorrow morning, like what could they do?
Jessica Talisman
47:26I would say take a subset of really important terms, so vocabulary words within your organization. There's something called SKOS-PL which is a great sort of open source endpoint free, that teaches you how... It's, it's very simple. You structure a spreadsheet in a certain way, and I write about this. I have something called Kitchen Semantics on my Substack that, that walks through how to do this. Structure very simple SKOS vocabulary, which will be an RDF.
47:58So what SKOS-PL does is you structure a spreadsheet with your definitions, your, your terms or your concepts and your definitions, and you upload it into SKOS-PL, and then you export it, and it will return your Turtle or your RDF shape or format. And I encourage people to start to use, experiment and use that RDF vocabulary in some sort of RAG implementation or at least a project-based way to see if it improves agent implementations. Just start playing. It's not...
48:35You know, once you get that structure and you get that sort of description, just like people have been playing with the, the wiki, the Karpathy wiki implementation, LLM wiki, you can do the same sort of implementation through just creating a really basic SKOS model to start. And then you're starting with RDF without introducing the complexity of ontology. You just see how definitions and, and RDF in general works and, and be able to introduce that. Number two is starting, and I know that we didn't really set this up, but before building a system with agents, if you wanna get started with ontologies, the first thing is to define competency questions.
49:21And it's something that we don't normally use in the data world that's really fundamental and important, is that with ontologies, we do not build ontologies from the semantic web world. We do not build ontologies until we form competency questions, and those competency questions are questions we want our ontology to answer. So we design and build for what we expect the output to deliver, and those competency questions become our evals, and the competency questions become a way for us to validate our ontology build. So I see a lot of communication out on LinkedIn where people are talking about, you know, modeling the universe or having one ontology to rule them all. It's not how it's done.
50:03You have to start small and targeted, and you have to start with understanding what you are designing. And if you're designing your system or your ontology to answer, say, a set of five basic questions, those become the foundations for what you're gonna build. So do not boil the ocean. Be strategic.
Austin Kronz
50:24Yeah. That's really helpful. I, I do think that is a, a big question we hear, which is like, "Okay, so we have to build the entire ontology of everything." And so you're saying— Yeah... It's refreshing to hear that I can start with a use case and have— Yeah... An ontology for that use case— That would be insane... And build from there.
Jessica Talisman
50:40Yeah. It's like one area of the business. Like I, you know... You, you, you decide on a strategic and targeted area, and, and you start to prove it out in, in that capacity, rather than trying to roll something out throughout an entire organization. It's something that I, I truly believe. I mean, it's like having seeds in the ground that you're gonna water and that they're gonna grow because you need— You know, having strategy with your implementation, that's something that seems to have gone out the window with most agentic and agent-based implementations, is the strategy piece.
51:14And that goes hand in hand with having the discipline around what you're structuring, what you're modeling, what's your starting point, what you, what you expect to deliver. Like that normal thing that happened before the wide, you know, availability of these commercial LLMs, we used to have process. And so it's, it's really coming up with that strategic planning and being thoughtful. I, I think that's why my newsletter is called Intentional Arrangement, because that's always gone hand in hand with information science. I don't know how it went out the window, where we have taken the wheels off basically of vendor analysis and really being strategic and, and pointed in how we approach these problems.
51:55So you're not gonna get context overnight. That's the hard reality. And it's not gonna be build fast, break things. It's gonna be intentional, strategic, and based upon desired outcomes.
Austin Kronz
52:10That's... Yeah, I think that's really helpful. When I was at Gartner, I think there were so many pieces of advice that we'd give clients that was very logical, and I think everyone knows, but you sort of get caught up in the realities of an organization and the politics— Absolutely... Of your organization and, like, the demand to deliver yesterday but also be strategic. And so I, I fully empathize with AI and, and data leaders that are going through this right now, because it is challenging to like move fast and break things, but also like, why is our agent not accurate? Well, we didn't invest in the foundations.
52:42We all knew we should have, but we didn't— Yeah, yeah... Kind of thing.
52:48It's growing pains. It's hard. Like, we're all living it in real time is like, okay, if it's not big data and it's not about collection and, and query and storage, then how do we make this uncomfortable transition? And it's just new ways of working, new skill sets, and I think we're all, you know, in this together, and I know it sounds a little cheesy, but, but You know, I, I won't say that what I'm saying today is the entire picture or all of it, but because it requires that cross-team collaboration, but also cross-discipline.
53:22Determining strategically what's represented by ontology and where the semantic layer is enough, right? What's the state of your metadata? Like, I, I haven't heard a lot about that in conversations, and that, and that I feel like is, is an important focal point. When we're talking about process and procedure in terms of workflows, that has everything to do with metadata. So how do you ontologize your metadata?
Austin Kronz
53:44Interesting. Yeah. That connects a lot of dots because I think with the customers that I've been working with, ones that are further along in their kind of AI maturity— Yeah... Were the ones that started investing very intentionally into, call it metadata management— Yeah... Governance. The AI-ready data before it was AI-ready data, it was just well— Yeah... Managed data years ago.
54:07Three to five— Yeah... Years ago kind of thing. So there— And that's where we see those learning, right?
Jessica Talisman
54:13I mean, it's like the advantage in, in that kind in introducing that discipline and, and knowing that it's a muscle that you have to build. And I think that, like, what, what I'm encouraged by is I'm working in, in, in, in investment and finance right now for one of my clients. It's actually a relief to be in a more regulated environment because it shows It basically projects what— You're told what the things you have to do are.
54:41And that context and ontology has become really important in regulated environments. That's why we see it used in, in, you know... If you look across the space, you look at the gene ontology, for example, or biomedical space or pharmacology or finance investment products, those types of things require ontologies to drive accuracy and work reliably with AI.
Austin Kronz
55:05That's really interesting. I think we could talk probably an hour about that.
55:10The, the, the organizations that are probably most ripe for accurate AI use cases are also the ones that are regulated most around AI, which is like— Yeah... This catch 22 of like— Yeah... Well, what can we actually use versus— It's sort of like raising kids, and when you raise kids, like you need boundaries, right?
Jessica Talisman
55:28And, and you need constraints. That's what ontologies offer. If you look through any W3C documentation of ontologies, which there's lots of, like thousands. Look at Steve Hedden's like graph of graphs. He's documented I think over 3,000 taxonomies and ontologies openly available in the ether. So, you know, this is all about constraints. It's all about boundaries. It's all about you know, we're basically regulating our own environments with ontologies. That's the advantage for lack of regulation. And so just like kids need boundaries and, and constraints, so do agents and agentic AI.
Austin Kronz
56:07Makes sense. Okay, I have one last question, then there's a question from Shannon in the Q&A piece that I wanna get to 'cause I think it wraps things up. But so if Once you have an ontology, what kind of problems do you see that might no longer exist, and then what new problems might be created?
Jessica Talisman
56:24Drift. So the I'm gonna go with the new problems is that you'll see drift, but for those that don't invest in that persistence with ontologies is you'll see you know... So a big risk with ontologies is validation errors, creating loops and clashes where you have invalidated relationships. So really it's about maintenance. It comes down to maintenance with ontology work. But benefits, you know, the, it's, it's having to aside from updates, the, the models that work or capture provenance, for example, tend to be the most performant and help you keep your place in space as you continue to build and work with ontologies.
57:13So don't, don't omit your history, for example, or the event side of your ontology work, the provenance side of your ontology work. I think a lot of people miss that, and then you have to backtrack and try to include that, and it's so much harder just build it right from the beginning. And there's an ontology for that. It's called PROV. It's provenance. It's been around since 2013, and it's perfectly beautiful, operational. Use it if you're gonna start anywhere.
Austin Kronz
57:43I feel like the tag line when we repost this is gonna be, "There's an ontology for that."
57:59She's basically asking if I can start with something small and give an example whether I'm using RDF or OWL. I'm building some ontology taxonomy, how do I connect that to my actual agentic development to show, yes, this improves against our evals or accuracy or explainability? What are you seeing with that component?
Jessica Talisman
58:17I mean, if you implement... I, I, I see people starting at the project level. And so like you have project folders and skills. I see some implementations working where you can leverage. I know that Ora Lassila, who is fantastic, he's one of the fathers and founders of RDF in the original semantic web paper, he has a new spec out that I think is really elegant for, for representing these things in RDF. So I don't have the link, but we can do it after the, the show. But starting at the project folder level and then implementing your, no matter how small or how big, your concept graph.
58:58Again, remember that your taxonomy and your ontology is a Your taxonomy and your thesaurus are concept graphs. Not context graphs, not knowledge graphs per se, but they're concept graphs. That defines the entities. And using an implementation, so I don't know your particular organization, but if you were to use RAG, you're creating that persistent not only memory, but reference point, so it becomes your reference set for any sort of implementation. And then you can use SPARQL queries that you can save as RESTful APIs, or you can surface a SPARQL library. But an agent is also very good. Once it knows your ontology, they're very proficient at querying your concept graph.
59:45You can query your concept graph, 'cause again, you have triples, so you can say things like, "Show me all concepts that are about business processes," and it will surface all of those concepts that are about business processes. So you can build in these attention mechanisms using your concept graph with RAG or even the simple RAG, which is using your project folders, for example, if you're using Claude. Can create a Gem in Gemini if you're using Gem. You know, there's different implementations, but I would, I would start at the project folder level and then connect via API to your...
1:00:22Like for example, I have Apache Jena, and so I have that connected with a library of SPARQL queries with my Claude, my Claude agent. And so it becomes a reference point, and we build SPARQL query libraries that are used and leveraged by an agent.
1:00:41And then we have a persistent library, so yeah.
Austin Kronz
1:00:45All right. Well, Jessica, I, I can't thank you enough. I think there's a, there's a comment in the, in the chat by Ehsan who is saying, "Oh, I thought we were gonna talk about context layers. It's all about ontology." So a good way to close, which is this whole series of WTF is the context layer, again, from our perspective, all of these are components of context. And so if you haven't seen the first few episode, please go back and take a look at them where we talk with Prukalpa, who's the co-founder of Atlan, on what is the overall context platform. We've had Sanjiv Mohan to give us kind of the industry perspective.
1:01:16We had Dave Mariani, who is the co-founder and CTO of AtScale, who was talking all about semantic models and semantic layers. We've had Jessica come on and talk all things ontology. In future episodes, we'll have people like Emil from Neo4j. We'll have Jai Gupta from Foundation Capital to talk context graphs. And we're just going deep into all of the components that make up this umbrella that is the context layer for AI. So with that— And to that point, like context layers, just like knowledge graphs, can have various architectures.
Jessica Talisman
1:01:47So I think that that is the great assortment and distribution of different components that you guys are covering. Yeah.
Semantic layers name things. Ontologies define how those things are allowed to relate.
WTF IS THE CONTEXT LAYER
Context lives in the relationships between things, so you have to define the things first.
WTF IS THE CONTEXT LAYER
Your SQL databases don't hold everything your agents need to understand the business.
WTF IS THE CONTEXT LAYER
AI can scale your definitions once they exist. Writing the first ones is your job.
WTF IS THE CONTEXT LAYER
A graph is an architecture, not a definition. No two graphs are built alike.
WTF IS THE CONTEXT LAYER
Write the questions your ontology must answer first. Those questions become your evals.
WTF IS THE CONTEXT LAYER
Shared definitions cut token spend, because agents stop working out your meaning on every run.
WTF IS THE CONTEXT LAYER
An ontology is a muscle you maintain, not a project you finish.
WTF IS THE CONTEXT LAYER
Semantic layers name things. Ontologies define how those things are allowed to relate.
WTF IS THE CONTEXT LAYER
Context lives in the relationships between things, so you have to define the things first.
WTF IS THE CONTEXT LAYER
Your SQL databases don't hold everything your agents need to understand the business.
WTF IS THE CONTEXT LAYER
AI can scale your definitions once they exist. Writing the first ones is your job.
WTF IS THE CONTEXT LAYER
A graph is an architecture, not a definition. No two graphs are built alike.
WTF IS THE CONTEXT LAYER
Write the questions your ontology must answer first. Those questions become your evals.
WTF IS THE CONTEXT LAYER
Shared definitions cut token spend, because agents stop working out your meaning on every run.
WTF IS THE CONTEXT LAYER
An ontology is a muscle you maintain, not a project you finish.
WTF IS THE CONTEXT LAYER
BLOG ARTICLE · EP 04
From Ontology to Context Layer: What Actually Changed With AI?
Austin Kronz opened episode four with an observation. Almost every customer conversation he has now includes some version of the same question: what about ontologies? Vendors are selling them. Buyers are asking for them. Hardly anyone agrees on what the word means. A discipline with thirty years of research behind it has become a line item in AI budgets, and most of the people funding it could not define it.
So start there. An ontology is where a business writes down what its things are and how they are allowed to relate. What a customer is. What a product is. What can connect to what, and what cannot. That work is decades old, and it has mostly been paid for in fields where a wrong definition is expensive, like biomedical research and finance. Inside everyone else it was the project that got shelved, because the strategy was to collect more data rather than describe it better. Then the returns on collecting more data ran out.
Jessica Talisman has spent 25 years building this kind of infrastructure, and created the Ontology Pipeline. Her argument in this episode is that most teams enter that pipeline at the wrong end. They reach for the ontology while their own terms are still undefined, and an ontology built on undefined terms hardens the mess instead of fixing it. Austin pressed on what that means for the question the series keeps circling. Is the ontology the context layer, one component of it, or a rebrand.
Q: Ontologies have existed for decades. Why are enterprises funding them now?
Talisman dates the shift precisely, and it is recent. Through the big data era, roughly the early 2000s until frontier models became available, enterprise attention went to collection, storage, and query. Ontology work was real work, but inside a company it was the project that got shelved.
"The work that was deprioritized was the ontological work."
Then the returns on volume ran out. Adding more data stopped making models measurably better, and models trained on machine-generated content get less performant, not more. That is when attention moved from how much data you have to how well it is described, which is why data definitions, metric layers, and semantic layers all came back into the conversation at once.
RAG gave teams the first live proof. Those early implementations leaned on ontology work to hold their accuracy together, and for most organizations that was the first time careful description visibly changed the behavior of a system they had already shipped.
"What's changed is we're realizing that description is what matters."
Cost is the third driver, and it is the one that moves budget fastest. An ontology is encoded once and reused, so agents stop working out the same meaning on every run. Austin described the version every team recognizes: the invoice arrives, and behind one basic answer sit hundreds of tool calls the agent looped through to figure out what your terms meant.
Q: What has to exist before you build an ontology?
An ontology structures your data as classes, the things that define your domain, then declares rules for how those things relate. Some things can be related to each other. Some cannot. Once definitions and constraints are both in place, a human and a machine can read the description of a thing and arrive at the same answer. Talisman calls that descriptive access.
The failure she sees most often is teams skipping straight to it. They assume the labels and definitions already sitting in their semantic layer are enough, then model on top of them. Her example is a category called "other," which is a junk drawer with no definition. Formalize that as an ontology and you have made the ambiguity permanent.
"An ontology doesn't magically fix things. An ontology requires that hard work of defining and understanding your domain in order to properly structure it as an ontology."
The order she recommends:
Controlled vocabularies: the agreed terms, wherever they currently sit. SharePoint, Confluence, Jira, your catalog.
Taxonomies and thesauri, encoded in SKOS, which expresses that vocabulary as RDF triples.
The ontology, which reuses the definitions your taxonomy already settled.
The knowledge graph, which is an architecture built on all of the above.
SKOS is the training wheels. Teams learn to model and query RDF on something small, and the definitional work carries forward into the ontology instead of being redone. Talisman notes that the World Bank, Getty, Wikidata, and several EU governments publish vocabularies this way, so the format is already well represented in the material these models trained on.
Q: Can an LLM build the ontology for you?
It can expand one. It cannot start one. Give a model a framework that defines the overarching things in your environment, plus some guidance, and it will extend that structure fast. Ask it to build from scratch and you are asking for something it has no way to produce.
"It's a statistical probability machine. It doesn't encode meaning. It doesn't naturally understand the meaning of your organization."
"Digital asset" at a financial institution and "digital asset" at an ed tech company are two different things. Nothing in the model tells it which one is yours. That first definition has to come from your organization, and how you write it matters as much as that you wrote it. Talisman's example: teams routinely define employee as a class, so when that employee leaves they get erased. Define person as the class and employment as a property, and the status changes while the history survives.
Her practical starting point is deliberately small. Take a subset of the terms that matter, structure them in a spreadsheet with definitions, run it through SKOS Play, and get RDF back. Use that vocabulary in a project folder or a RAG setup and check whether the agent improves. Before building anything larger, write competency questions: the specific questions the ontology has to answer. They scope the build, and they become the evals you validate against.
"We do not build ontologies until we form competency questions."
Q: Is the context layer just a new name for the ontology?
Talisman's answer is no, but not because the two are unrelated. The ontology is one component of the context layer, and context layers, like knowledge graphs, can be built in many different architectures.
The word doing the most damage is graph. A graph is an architecture, not a definition. It may include indexing, NLP, a knowledge base, a vector store. A property graph can run schema-less, which leaves nothing holding your descriptions stable over time. An RDF graph works inside declared constraints. Your taxonomy and thesaurus encoded in SKOS are already a concept graph, and Talisman's view is that for plenty of implementations, that is enough.
"A graph itself involves more than an ontology, more than a schema, otherwise we'd just be talking about schemas and ontologies."
What she would push teams to examine instead is metadata. A metadata application profile maps how data moves, which systems are in play, and how meaning is represented across them. That map tells you which capability each requirement actually needs: where a taxonomy is sufficient, where an ontology earns its cost, and how much context a specific job requires. It is also, she noted, the part of the conversation nobody is having.
The claim worth carrying out of the episode is the one she flagged as controversial before she made it. Context exists in the relationship between things. If that holds, the things have to be defined before any of the relationships mean anything.
Episode five takes the graph question head on. Emil Eifrem, CEO and co-founder of Neo4j, joins Prukalpa Sankar on August 19 to argue whether graph databases are the foundation of the context layer or just where the structure gets stored. Register here.
Thu, Sep 17, 12:30 PM ET
Can a Context Graph Alone Make AI Reliable?
Jaya Gupta called the context graph AI's next trillion-dollar opportunity: the reasoning behind decisions that systems of record never stored. Jaya and Austin work through what a context graph must hold.