Context lives in the relationships

VivekHey everyone, welcome back to another episode of ContextOps. Today I have with me Jessica. Hi Jessica, good morning.

JessicaThank you for having me.

VivekVery excited about this specific episode, because I think Jessica is one of the most passionate advocates of knowledge management and knowledge architecture out there today. She's one of the few people who have actually been doing this way before it was cool. For the longest time ever. Jessica, I know you currently have your consulting practice, you obviously have an amazing Substack, and your book is coming up, and maybe you should talk about that as well at some point. But I would love to hear: how did you end up doing what you're doing today?

JessicaThis part of my career started in 1997. I was hired by Steven Spielberg: I worked as a visual history cataloger. Off of his movie Schindler's List, he started a nonprofit to capture everyone's narratives and stories about the Holocaust and Holocaust survivors. That's really where it started. We built one of the largest visual history catalogs of its time, which made two-to-six-minute segments of any video recording clip, so it was sort of the beginning of clips. We were still working with VHS tapes, but using machine systems. I was an employee on that project, and that's how my entire career kicked off.

I worked in the GLAM space, so galleries, libraries, arts and museums, and really stayed in the cultural heritage space, which that project was considered part of, and worked a little bit here and there for businesses and enterprises. So I sort of flip-flopped between enterprise work and cultural heritage work, and then come 2018 I fully migrated over into the enterprise space. Along the way I did get a master's in information and library science with a specialization in informatics, well before the current ontology and knowledge graph craze. Informatics in the library science space was things like the semantic web and ontologies and taxonomies. That's really what I studied during my master's, and that's how I ended up where I am today.

VivekA lot of conversation today in the mainstream media is about how things are changing so fast. People will be out of their jobs, software will be completely automated, and so on. But then there's an alternative school of thought from folks in the knowledge management space, folks who have spent some time in symbolic systems and expert systems. They have a very contrarian answer to that question, which is: what has changed? So back to you. What according to you has really changed, and what has not?

JessicaWhat has changed? Interest, and that when you say ontology, people don't look at you like you're crazy. So that's a good thing. The requirements of AI, the cost of tokens. As soon as money comes into the picture, it becomes a big motivator and attention getter, or attention mechanism. So those two things for sure. And then of course people not being able to find things within systems, which actually existed before the current AI craze. When I was hired back then, it was usually because systems were a mess and organizations were having difficulty with information retrieval, just simple information retrieval.

But people are realizing, maybe more slowly than I personally would like. There's more learning to do in this space in terms of ontologies and knowledge graphs and symbolic AI, because most people think the current AI as we know it now, that's AI, there's no other form of AI. Which obviously is not true. There's a long history to artificial intelligence. It was a word created coming out of the Dartmouth summer of 1956, and part of automation and replacement theory. There are a couple of main tracks or schools or philosophies related to artificial intelligence as we know it: one's augmentation and one's automation. So there's a lot of education that's necessary. But the fact that people are now realizing there's a better way to describe and make sense of information, in order to leverage that to optimize LLM-type implementations, is fantastic. I feel like we're just getting started, so it's the tip of the iceberg. As my friend Tony Seale says, it's like the boulder at the top of the hill: are you going to let it roll and cut it loose? One of the problems is that now that the word ontology is in play, it gives opportunity for marketing folks to take hold of it and define it in their own terms and their own ways. In the semantic web community, the symbolic AI community, we're all just sitting there with bated breath to see what direction this turns.

VivekI know. We also had Tony on the podcast a few weeks back, and this came out: everybody has a very convenient interpretation of the word ontology, of the word context. Tony's take was that the marketing of a specific word has an inverse ratio to its actual relevance in the practical enterprise AI world.

JessicaWell, and it does a disservice. That's the sad thing. We saw context graphs and what happened with that. We grab on to whatever comes along. There's a certain desperation in the industry right now, and it's a human reaction, I guess, but at the same time it's misleading, because it is a discipline. The discipline around building symbolic systems, it's not like this came out of nowhere. I was just talking to a pretty big leader in the space, and he asked me: where did this come from? There must be only a handful of ontologists in the world. I imagine there's only what, 10, 12 ontologists in the world? That was truly the perspective, and this is a big leader in technology. I mean, there are thousands of us. We've had conferences ongoing for fifty-plus years. We have our own journals, we have our own research cycles. There are entire academic programs built around this worldwide. A new domain is coming into play, but it doesn't mean it's a new domain. There's science, there's research, there's expertise. It's not something that all of a sudden you can grab hold of and redefine and override.

VivekVery true. Now, because you brought that out, let's do a bunch of myth busting along the way. One reason we chose to name the show ContextOps is that our thesis has been it's not a once-and-done thing, it's a discipline, one that people will understand eventually as they try to operationalize it, as they bring symbolic angles into their AI implementations. But one very poorly understood word, and hence it impacts actual implementations, is this whole thing around context engineering. You wrote about this in your Substack as well. The first interpretation of context engineering was: how much can we stuff in? We have a one-million-token context window, let's stuff in whatever we can. Which is really just a marketing spin on prompt engineering, which now feels like eons ago.

JessicaWe forget how excited everyone got when the context window got bigger. People celebrating: I get to stuff more in. Perfect.

VivekYes. And finally there is acknowledgement that it actually does not work better. But I do want to go back to something you mentioned: you refer to context as a property and not as an object. Could you elaborate on that a bit more?

JessicaWe think of context as a paragraph or a sentence. If I give it a document, that's context. If I give it a paragraph or a sentence or a list of words, that's context. But in fact, it's: how do we describe that document? What does that document or that paragraph have to do with other documents or paragraphs within a space, if we're talking about content, for example? The idea of it being a property is that we have to describe these things. In ontology world, the classes are more or less immutable, defined things within our space, and within ontologies we model property relations and properties to apply descriptors to these things, to define the relationships between things. And the truth is, and you can look back through the literature and research from the beginning of time: context exists in the relationship between things. Context can vary widely when you change the relationship, and the type of relationship, between things.

Because context is such an ambiguous, nebulous word, it could mean anything. It's worked its way into our vernacular to the point where I almost catch myself and try not to use the word anymore. My business, by the way, and I know you guys are ContextOps, but my business, well before any of this, is called Contextually. So I kind of cringe every time I have to write that. When we overuse a term to where it can really mean anything, that definition is wide open. When we talk about context as a property, it's really: okay, great, you have documents. Sure, that's context. But where does context live? It's the relationships between these things, which then would make it a property.

VivekAnd the unfortunate extrapolation of that has been: it's now MD files. Let's just store everything into an MD file, and maybe that qualifies as context, unfortunately.

JessicaThe thing is, with MD files, there's a lot of research going on right now. Is HTML better than Markdown? Really, no one knows per se, and there's a lot of research pointing to the fact that Markdown becomes very noisy at scale for LLMs. So it really depends, and the word depends is also very common within AI, because none of this has really been exacted into a science yet. I don't know if many of the listeners remember when, for SEO plays, GEO or AEO, there was the idea of llms.txt.

VivekYes. llms.txt files.

JessicaThere have been so many attempts, and none of it has ever been codified into science. If anything, the challenge is to prove or disprove these rumors. I think it speaks to the desperation in the marketplace, because the truth is, if you're going to define things ontologically, it's hard. It's not easy, it's a process, it's not fast, it's not immediate. Build-fast-break-things with an ontology doesn't really vibe. It doesn't work. What I watch in organizations is these sort of false attempts, and that's when we end up with derivative plans or architectures that are kind of ontology-ish, but not quite all the way there in terms of that descriptive context. I think we're all sitting in this kind of uncomfortable transition right now. And of course, then there's the marketing machine.

JoshuaJessica, I was just thinking about what you said: relationships are everything. The viewers might not come from an ontological background, so I'm trying to grapple with loading something into context windows versus structured descriptions of meaning. What's the boundary there? How do we distinguish between a well-defined relationship versus nothing? Some people might say: hey, I put this text in, I defined it, I did it. How do you distinguish between that?

JessicaThere are different types of just supplying text within a context window. The world of AI is changing, that landscape is changing so quickly. If you use Claude, now you can build skills to help guide some accuracy, hopefully, around the text you're supplying in the context window. But then there's the question: are you giving text to an LLM in the context window in an ephemeral way, meaning you copy-paste and it's a one-shot? And you're in an organization where 300 people are doing the exact same thing, so everyone's paragraphs and documents vastly vary. The results are very non-scientific, because everyone's working within their own context. It gets wildly unruly. Then you have things like RAG implementations, you can leverage project folders, so if you're working with prompts you can have more stable versions of context with persistence over time. So now we have all these nuanced architectures.

But when we talk about relationships: relationships may be as simple as a thesaurus or a taxonomy encoded with the Resource Description Framework, as triples, RDF, which is the same serialization format that makes ontologies ontologies. Those are W3C specifications, the World Wide Web Consortium. It's all within the same family of standards and documentation, all open, all part of the same discipline: knowledge graphs, ontologies, taxonomies. Those types of implementations give way to things like memory, persistence over time, stability, everyone referring to the same context, where you have structured things. You could even have documents structured within a graph database, with graph embeddings that tell us document A has this type of relationship to document B. You can create this really elegant knowledge infrastructure that acts as persistent memory and reference for an LLM, so that everyone's using the same source of truth, or context, in an organization. Versus the cowboy deployment methodology, which is everyone just throwing things into the window, some people using skills, some people not.

JoshuaSo what I'm hearing you say is: spend more time associating meaning, and you would naturally be on the same page with at least your team, possibly other teams in the same organization.

JessicaYeah. And many people think: okay, we need one canonical definition and one canonical word. Well, the SKOS data model, the RDF SKOS data model, is built to handle a preferred term and as many alternate labels as you want, all rolled up to the same identifier. So where you think there may not be a solution, you would be surprised. There are really elegant solutions to handle almost every nuanced problem an organization faces. I think the bigger problem is that we spend too much time trying to figure out how to cram this back into our Postgres and relational databases. There's still this underlying mental model that everything needs to be oriented and pushed back into these databases. And the truth is, it's really hard to maintain the structure of an ontology and the depth of the relationships that way, because ontologies don't roll up to primary keys and foreign keys. They don't have the same requirements. It's a different type of model, a different type of architecture, a different thing entirely.

I'll give you an example. I'm working right now with an organization, and it was refreshing to hear them say: yeah, mostly what's in our Databricks is finance and accounting. We care about money, right? In our database, we care about money. So where does the other context live? Is marketing and branding in the database? Nope. Are all those different influences in the system? Is the SharePoint in the database, all of the documents? Is the Confluence in the database? Nope. If you operate from that data-only perspective, you are missing context. Most people's operating model is still: let's lift and shift what's in the database and those schemas and reflect that. Well, guess what? You're going to be missing probably three quarters of your organization's context.

JoshuaThat's a really depressing take. A lot of us, when building a software system, think of some kind of database that you're going to be modeling things in, that entity and relationship, but you're not going to think about the rest of the world and the larger context. I think we had someone else on talking about something similar with accounting, and it was the inverse of what you're saying: initially it would have been an RDBMS, but then they said, let's just get all the context, and that was refreshing, because then they could really think from first principles. I had one question. You said: spend time doing the hard work of defining things in an ontology. We've seen a lot of people struggle with that. They wonder if that time is worth spending, even if everybody says it is. But one interesting thing I heard you say was SKOS. What if you spent time on a vocabulary, or a taxonomy? Would that be a good first step?

JessicaMy gosh, that's what my Ontology Pipeline is all about. And I get a lot of pushback from purist ontologists on that. There's a reason, and it is more of a library science approach, an information science approach, because a lot of ontologists and ontology engineers come from spaces where they don't have that same discipline of organizing that comes with library and information science. It's really important: how can you model what you have not defined? The act of organizing your vocabularies, which is why the semantic layer is so popular right now... remember, we're working with language models. The biggest problems in organizations right now are labels and definitions. Meaning. That is the first step.

If you define your vocabularies and structure them with SKOS, which is a data model in RDF, it's your first step into the land of RDF. You have to understand and learn how to write RDF, what it looks like, what is valid, what is not valid. That's the technical component. The organizational component is definitions, breaking down silos, labels. That very basic thing, the same thing the semantic layer is looking to address. The reason ontologies are hard is this: if you try to model ontologies on your existing data and your existing taxonomies, vocabularies, and labels, you're going to harden and project those silos and that confusion up into your ontologies, and it will be reflected there. You're going to end up with duplicates. The ambiguity is going to persist because you haven't defined it. You risk representing relationships incorrectly for lack of definitions.

I'm working on another job right now where we were reviewing, with subject matter experts, the taxonomy we were building for them, a SKOS model. One of their top-level categories was called Other. And I said, we're not going to have Other in the taxonomy. And they said, no, no, but we can define it. It's still not okay. Imagine if every team has Other, with their things organized and categorized under it.

JoshuaWas there a different definition of Other? I'm sorry, I just had to know.

JessicaIt's freestyle. Anyone can define it. I've been in organizations where there's Other, Miscellaneous, Misc, four or five different labels. Does that give you context?

JoshuaIt's the same thing. It's what we thought Aadhaar was, right? There's nothing different about Aadhaar.

JessicaIt's your junk drawer. If you can categorize things under it, then you can name it. I'm not going to say it's lazy, but if you're really serious about context, you need to take the time to define things. I think it's very hard for people because it's not fun work for some. I find it fun, I like it. But it helps to inform. It's necessary discovery for building ontologies. I can't model an ontology unless I understand the meaning of things.

JoshuaSo what I'm hearing you say is: if you invest in the vocabulary, which is at least a starting point, you almost naturally progress. You progress to defining the relationships, and you eventually come up with some kind of an ontology which works for you.

JessicaYes. And the thing I love about that process: when you go through the work of defining your taxonomy, which is hierarchical, you naturally get to the point where your users are basically jumping out of their skin because they want to create relationships outside of the hierarchy. That's a natural, organic indicator that you're ready to progress, that you've reached the bounds and limits of defining things as a hierarchy, parent-child, and now you want to stretch outside of that box. That's the way it should happen.

JoshuaThat's the problem with inertia, it's getting started. Thanks. Over to you, Vivek.

VivekSo my question then becomes: you work with large enterprises who have possibly gone through their own painful implementation cycles which have not given them a lot of results. And there comes one more person, saying one more new thing. How do people respond? Somebody who has been burned a bunch of times by Accenture, McKinsey, Deloitte, one of these consulting firms, or some RAG implementation here and there. And then you tell them: we will do boring foundational work for weeks or months, which you can't even see, by the way. It won't be tangible, because you're building foundational stuff. How do people respond to that? I'm just trying to imagine a CFO hearing this.

JessicaI think that's why the Ontology Pipeline type of workflow has worked for me. You get done with controlled vocabularies, where you've defined your terms in a flat list. Use it with your LLM, and that will derive value. The way I manage it is: yes, it's boring, rigorous work for months and months, but it's iterative. You start with controlled vocabularies and then you have an artifact, or multiple, that you can leverage. And you want to test that, because you might need to restructure, or include more or less terminology in that controlled vocabulary. You have output and you have the ability to test. Then you move on to taxonomy, same thing, in your SKOS model. You have an artifact, a taxonomy or taxonomies. Use them with your LLMs, test them, iterate. Then you move on to metadata schemas, and you start to imbue structure into those using just lightweight ontologies. And wow, you can test that. The idea is to come up with a plan and a process that actually delivers artifacts of value along the way.

When we say symbolic AI, it doesn't mean ontologies alone. If you look at Yann LeCun's world models, for example, he relies heavily on taxonomies, mostly. We become really myopic and think ontologies are it. Everyone wants an ontology, but there's work and process along the way, and there are other formats that drive value, that are necessary to accompany ontologies, that are part of knowledge graphs. Knowledge graphs, after all, are architecture. Really what we're working towards is building a knowledge infrastructure. And that's what's missing. I've been saying it for three years now: we need knowledge infrastructure. We're kind of skirting around, dancing and playing with the idea of knowledge management, but ultimately this is a new architecture and infrastructure.

VivekWe use that word very cautiously when we go into some of our meetings, because it's difficult to wrap your head around the depth of it, how critical that asset could be, and how easily somebody could hand-wave: yeah, we have knowledge infrastructure, some version of that. But thanks, very helpful. So what I'm hearing is: the taxonomy is potentially your first Goldilocks, in the sense that you operationalize it into a specific implementation or agent or AI application, that's where you start realizing real value, and then you go on from there.

JessicaNot only that. This is a discovery, because I'm writing a piece right now reflecting on pre-AI and post-AI: how am I operating differently, how is it different generally in the marketplace, and people's appetite for incorporating these things into their architectures. What I realized was: if an organization struggles to implement and maintain the shape of, for example, an RDF hierarchy, parent-child relations, say a three-level hierarchy in SKOS RDF, you'd better find out early. Because once you get to ontology, where you're introducing real complexity, it's not any easier. It's like the training wheels. That's part of the iterative process. And a lot of organizations get stuck at taxonomy, because their systems are not oriented, nor is the discipline there, to maintain and proliferate the complexity of ontological systems.

JoshuaSo these organizations: when you come with this asset, this final artifact, you put it on the table. What is their role in retaining it? Where's the human's role once this is done?

JessicaThat's a great question, and it's so nuanced for different organizations. I'm working right now at an organization where we got the first iteration done, and then you have to hold the line and immediately get your governance and your style guides and your guidance and your Confluence pages and your SharePoint and your feedback forms, because ultimately you have to involve people. It is very much human-in-the-loop. That process of implementing your first SKOS taxonomy or thesaurus is your first dip of the toe in that symbolic water. So you have to have ways to communicate. It's a two-way communication. And at first, it's very much augmentation before automating any processes. Governance and augmentation, because you're trying to solidify feedback loops and communication: incorporating new terminology, how do we deprecate things, how do we change definitions, how do we run a program where these taxonomies are widely available, like an internal app people can navigate and interact with. The governance piece is core. You can't move forward without it.

VivekNow that you have said that: for those who are new to this whole world of symbolic approaches and knowledge infrastructure as a long-term asset, in some consulting gigs there's a vibe that it's a once-and-done thing, a lift and shift, or the marketing hype triggers that feeling: once you get the ontology, once you have some of this stuff in place, you're done. But the fact remains that knowledge is a dynamic asset. Knowledge evolves, knowledge sunsets, knowledge gets deprecated. And note the point from the leader you spoke about earlier in the conversation, that ontologists are like dinosaurs, how many of them are even left in this world? The worldview is very, very limited today, and the worldview on this asset's relevance and longevity is fairly challenged right now. And on top of that they have to build, maintain, and add layers to it. It just sounds like a new function or a new org. Maybe it's AI-powered, I think it will be AI-powered, that will exist eventually in companies that want to actually go to production with their agents. What would that org look like? What have you seen out there in reality? Are people open to the idea of building this?

JessicaFinance and biosciences, I think, have the most rigorous and mature versions of this, as does cultural heritage: libraries, museums, archives. Across all of those organizations, taxonomies are fundamental. You have to have that muscle. You have teams at Capital One and Bloomberg and JP Morgan where there's a VP of taxonomy and ontology, an entire team or several teams organized around this. Cramming this type of work into your data science team or throwing it at machine engineers is not the solution. It does take hiring the talent that will drive the program. Now, with Tony Seale and Katariina Kari, we have the Knowledge Graph Academy. We've graduated over a hundred students, and it teaches the fundamentals of knowledge graphs, including taxonomy and ontology. So there is some upskilling that has to happen as well.

There's also the thing about knowledge itself: it's ever contracting and expanding. That's the nature of knowledge. Which means that muscle has to be woven into your entire organization. That comes with maturity: having tools in place for knowledge elicitation and capture, having consistency in how you record and store things in a way that's structured and can be represented by ontologies or taxonomies, whether through an ontology-driven tagging system or more nuanced approaches. But it really comes with the maturity of the organization, and the realization that this is not a data problem. I think that's the biggest blocker: organizations that think this is a data problem. It's not a data problem. Databases are not going away. We still need to collect and store and query data. We still need dashboards, finance, accounting, supply chain, all of that goodness. But when we're talking about structuring these things to have meaning, the first thing people go for is automation. And that hunger is so insatiable that it gets in the way of best practices and actually doing the work to build a program that's sustainable.

VivekThat's so apt. I'm wondering: most mid-market companies, not enterprises, who don't have knowledge management functions as formalized as finance or pharma, what would their path look like?

JessicaYou have to hire some people. That's the thing. For a while I said: it just takes upskilling. But it really is like any other function. You have data engineers, you hire data scientists, you hire content strategists. There has been this reluctance to actually hire the skill sets necessary, because there's this misunderstanding that ontologies can just be automated and deployed. That it's not a discipline. It's a prompt.

VivekIt's a prompt. It's just a prompt.

JessicaIf you take your data science team and your data analytics team and your data engineering teams and your content strategy teams seriously, all of those functions throughout your organization, if you take your product management seriously, then why aren't you taking your knowledge seriously? I'm at the point where: if you're not willing to invest in it, that shows me you're not serious.

VivekYou know, Dilip, who is our third co-founder, he is sixty-five, so he carries the wisdom. And we often joke that maybe knowledge is too boomer of a word. It's not Gen Z enough, not millennial enough. Maybe that's why it's not landing in these AI sales cycles today, unfortunately.

JessicaI mean, that's education and critical thinking. It goes along with AI literacy. It depends on your willingness to dive into the domain and really want to understand the origin of context. Context was a word that proliferated throughout semantic web and ontology-based systems for decades. Then this word launched onto the stage, became associated with a lot of functions and features and AI tools, and emerged as a verb, a noun, an adjective. It operates across all those planes now. I think context was an attempt to rebrand knowledge. The problem is that we took the word context and it became, like I said before, nebulous. It lost its meaning. If context was meant to mean knowledge, then it lost its meaning.

VivekI can so relate to that. To the point that we're now sick of that word. In our Slack, we don't even use it. It's borderline dangerous. And I feel guilty that we have spoken about it so many times, but that's just how bad the situation out there really is.

JoshuaI totally relate. I try not to use it, because there are so many ways I could use it, and now I can't use it at all. It's like one of those words that you didn't know was a bad word, and now it's a bad word.

JessicaNo, it's a bad word. It's so bad. I actually went through, I Command-F'd my ANSI/NISO Z39.19 standard, the controlled vocabulary guidelines, and asked: how many times is context mentioned in here? That's a 2004 document. It was a hundred and twenty plus times. And it makes sense, because there it was relative to exactly that domain space of building SKOS taxonomies and thesauri. And then here we are. It's sad that the word has lost its heft and its original intent and meaning. So now we're moving into the space of: okay, if we can't use the word context, can we use knowledge, so that we can be more specific about what we're implementing and what we're trying to build?

JoshuaYou said something interesting about product managers, data science teams, tech people: you expect people to be controlling this. There's a school of thought looking ahead and expecting that people won't be controlling this. How do you decide between what goes to the human and what goes to the machine? Is there a rule we can use?

JessicaI recently wrote a piece called Augmentation, Automation and the Neurosymbolic Loop that spoke exactly to this. If people don't understand historically how we ended up with the version of AI we're playing with right now, generative AI, they're missing the context of what we're doing here. There was a split in the road: the automation school of AI, and augmentation. Our display systems, our mouses, our keyboards are all forms of augmentation, very simplistic forms that come out of that school going back to the 1950s and 60s, using algorithms and statistical predictive systems combined with some symbolism. The really interesting thing is that automation has largely followed human replacement theory. This is an actual thing people participate in, human replacement theory, the original school of thought coming out of the Dartmouth summer, where the term artificial intelligence was coined, with Minsky and these different characters, Claude Shannon. The original hypothesis was: if we describe a problem or a process well enough, it can be automated. And that has failed in loops throughout time, from 1956 to where we are now.

So when we decide what gets automated, it's based off research and proof. There is a general philosophy in AI as a discipline, whether you sit in augmentation or automation, that you augment before automating anything. If you are comfortable automating a task without even testing it, without bringing scientific process into the conversation, then I'm worried for you, I'm worried for your program, I'm worried for your automation. That augmentation phase could be short, because you're so certain it's going to work. But the neurosymbolic loop is something you can introduce, where you have a human in the loop with some symbolic structure alongside the generative AI, so you're combining and fine-tuning these processes until you can be absolutely confident a machine can operate a certain process autonomously. To think you can just free something into the ether without any scientific process defies best practices. For most people, AI is completely new, so it becomes a magical oracle that will manifest like a genie out of a bottle and glitter all over your environments. There actually is practice and science here, and throwing everything at an LLM to see what sticks is pretty darn expensive.

JoshuaSo it could be that they can do it autonomously, but there's no way you just get there. You have to do something augmented first, and then decide if you're going to let go.

JessicaYeah. And perhaps it means RLHF, doing reinforcement with humans in the loop. Maybe that's your form of augmentation. Maybe it's codifying a knowledge elicitation program. We hear a lot coming out of context graphs about tacit knowledge. Okay, so how are you recording that, and what does that look like? Are you going to automate that? Because that could be pretty risky, given legal and finance. It's actual strategy. There's a general panic in organizations, and it has everything to do with board members and stock prices, this desperation, this throwing everything into LLMs and YOLOing it. The problem is there's no strategy there. A lot of companies, including really big companies, are operating with zero strategy. When you actually develop strategy, you can structure these things appropriately: reinforcement learning programs, knowledge elicitation programs, roadmaps where you go from augmentation to automation. That's strategy.

VivekThere is a lot of FOMO right now, unfortunately. But it's also a lot of opportunity.

JessicaIt's opportunity. Yeah.

VivekI know we are on time, but one last question for you, Jessica. I'm sure you've heard the words context engineer, GTM engineer. Should we officially coin the word ontology engineer as well, or is that redundant fundamentally?

JessicaThat already exists. And an ontologist is different from an ontology engineer. An ontologist is someone who builds and structures: they do the domain research, they define the meanings, they build the ontologies and the schemas. That's their role. An ontology engineer helps implement things like SPARQL and SHACL, shape constraint language, to elicit the indexing and retrieval and to operationalize the ontology. Those are defined roles, and they're not new roles. I was actually looking last night, because I got a notification for a job, and it was an ontology analyst. First time I'd seen ontology analyst come up, and I of course clicked on it, because I was a little confused. In the same way we're redefining the word ontology for marketing purposes, we're seeing these really interesting job listings come up. Ontologists at Amazon, and I used to work at Amazon, are generally what the outside world would call taxonomists. There's some mismatch, so it's really about the job description. A lot of these roles are what we call in the library world copy cataloging, where job listings copy other people's job listings, same requirements. And because organizations don't really know what they're hiring for and they're just copying and pasting, there's a lot of mismatch between the actual job to be done and the job listing. There's just a lot of education that needs to happen.

VivekWe've busted so many myths today. I'm really excited about this. Jessica, thank you so much for your time today. Really glad we were able to do this.

JessicaThank you guys. I know it's been a few months.

VivekBut a super fun conversation. I think a lot of people who don't live and breathe these terms will get a sense of calm more than anything else. The world is not ending tomorrow, and jobs are not getting automated.

JessicaIt's a lot. Change management in orgs is hard. Change management in the world is even harder. We're all in the flux of change, and I think we all just want stability. That's the larger social construct I see: everyone wanting stability. And humans need disambiguation. We don't do well without it. Part of human happiness is built on knowing your place, knowing your job, and having a purpose. I think that's the larger situation we're all struggling with.

VivekSo true, so beautifully said. Once again, thank you so much, Jessica. Appreciate your time.

JessicaThank you guys.