Episode 20 — How Knowledge Graphs Handle Time: Event Graphs, Scene Graphs, and Reification Explained

All opinions expressed are those of the individuals themselves, not necessarily of any company they work for.

Introducing Kurt Cagle

Sunil Baliga: Welcome to Token Drop, episode 20 — I can't quite believe we're at 20 already. It feels like we started this last week, and before you know it we'll be into 2027.

We have a special guest today: Kurt Cagle. He's very well known in the industry — I'd heard his name from Sam and Sajjad, and got to learn a lot more about him over the past couple of days. Kurt is an ontologist, a knowledge graph architect, and generally an AI thought leader. He's editor-in-chief of The Cagle Report and has authored more than 25 books.

Kurt, you and I were talking yesterday. We tend to talk about 3D knowledge graphs — the dimensions being knowledge, context, and action — and you said you thought there could be more dimensions than that. What are the dimensions you were describing? I think you mentioned temporal, among others.

Why Time Breaks Most Knowledge Graphs

Kurt Cagle: This is an issue that's been floating around the knowledge community for a while. There have been a number of different ways of representing information.

When you design a knowledge graph, one of the first things people do is ask: what are the things that matter to my organization? And there's a natural progression — you go from "here's a list of things" to "here's a list of relationships, and how things fit into those relationships."

But things get more problematic once you start talking about time. Because time is change. It isn't a matter of saying "I've got a timestamp I attached to this." It's a reflection of the fact that information, ultimately, is a way of talking about events that act on things over time.

Because of that, a lot of the knowledge graphs you see in action may have temporal aspects, but they aren't really designed from the standpoint of: how do I track time as a mechanism? How do I track change as a mechanism?

Ontology vs. JSON vs. the Relational Model

Kurt: It's a little different when you're talking about an ontology versus something like JSON. With JSON, you're basically saying, "I have a document, and that document has orderings" — and as long as everything can be separated out into distinct entities, that's usually not a problem. The challenge you run into with JSON is that it doesn't handle normalization well. Look at a JSON file and you'll end up with duplicates. You'll end up needing references, and JSON really isn't built around references.

A relational database is the opposite. It's fundamentally built around relationships, with references built in from the beginning — you go back to Ted Codd and the work he did in the early '70s. But the challenge there is that you don't have a good way of encapsulating information. With a relational database, you're thinking in tables, and tables have connections. The more complicated the connections, the higher-order the normalization forms, the more tables you add. So you end up building ever more complicated connections — and if you want to make a change, especially a modification rather than simply adding a new property, that can be an extraordinarily expensive operation. It necessitates literally changing the schema — the way you think about the information — across all the data in the system.

So this migration toward graphs is really the first step in trying to bridge those two. It lets you say: I have the ability to talk referentially. A graph is nothing but a collection of pointers, when you get right down to it.

The Jane Example: Recording Every Transition

Kurt: Taking those in turn, you can talk about a graph representation as being an instance. But once you start adding time, you start saying: I have Jane. Jane starts out as a junior analyst, then becomes a senior analyst, then becomes a chief analyst.

In object-oriented programming, that's usually a substitution — you're taking information and changing it, but you don't necessarily create a record of that. You're essentially always talking about "what's the state now?"

With a graph, on the other hand, you have the potential to say: I'm going to keep a record of every transition that occurs, across all the variables we're talking about, over time.

There have been a lot of different ways of solving that, and it generally gets fairly complex — because you start having to talk about events that are correlated with one another, evolutions of things, and what amounts to an audit system that has to be built out to say "these events happened at these times, and here, then, is the current state of things."

The Event Graph (Also Called a Context Graph)

Kurt: So that dimension of time — you can think of each of those events as part of an event graph.

That event graph is separate from the ontology, from the knowledge graph you've created. The knowledge graph is where you declare things: this exists, these are the properties that are essentially constant. But as you start talking about transient properties, that's when you get this evolutionary graph running alongside — an event graph.

This is also often called a context graph, because it gives you additional information: why did an event occur? When was the event reported? Who was the initiator of the event? What was the event targeting? All of those become very important when you start talking about how things change with respect to an environment.

The Scene Graph: Capturing the Moving "Now"

Kurt: So that's a second graph that gets built up. But at the same time, every time you have a change in the environment, you also want to update something that says: this is the current state of that particular change. That current state — "what is Jane's job title?" — is a right-now thing. It's where the head is. And that state stays the same, with only minor periodic changes.

You can query against the event chain you've created, but that's a fairly complex query — you have to look at all the possible events and ask, "what's the event that hasn't been terminated yet?" But once you've done that, if you save that result in the process of writing the event up, you also say: okay, this is the state now, and the next time we add an event, we'll change that state — in a now graph, or what's sometimes called a scene graph.

That scene graph isn't really a dimension. It's more a reflection of a pointer — think of it as a moving head indicating the present moment. That present moment is what's captured in the scene graph, and it evolves over time, even though the event graph itself simply grows. It's an append-only graph.

So this creates what amounts to a fairly simple accounting system. You're saying: here is a change, here is the result of that change, and here, then, is the new state. Each of those processes gives you, in a graph, much the same thing as an object-oriented approach — except you keep that information available.

The Open World Assumption and Where the Boundary Actually Is

Kurt: Now, the other side of this. I've been working with graph databases, RDF, and the whole semantic stack for about 25 years now. In that time, one of the things I've generally seen is a lot of talk about the open world assumption — the premise that you can create an identifier, and then everyone else out there can uniquely use that identifier to talk about something, or append to it.

The problem is that in practice, that becomes very problematic. First of all, most people are not dealing with an infinitely large graph — they're dealing with a graph in a database. And that distinction matters enormously, because if you have a graph in a database, then that becomes a boundary. If I'm sharing identifiers, it just means I have a bigger boundary.

That changes the nature of the containment of that information — and to a certain extent, it gives you a degree of freedom. Because if you have a container, you don't necessarily need to know what's inside it. It's a lot like REST in web architecture: all you need to know is, if I read from this, this is what comes out. If I have an identifier, this is the information I get back. It may not actually reflect the internal state of the database you're working with. It's only a reflection of what I, as the producer of that data, want you to see.

What Goes in the Graph vs. the Graph Database?

Sunil: Kurt, I want to ask about something you just said — you said you'd have a graph and a database. I don't quite follow. What goes in the graph, and what goes in the database?

Kurt: The graph is basically an abstraction. The graph is what you know — events, people, places, things. The database, in this case, would be a graph database, which is essentially a mechanism for storing that information.

That distinction is important, because I can talk about moving information from one graph to another, either within or outside of the database. But the information itself — that abstraction you started with — stays the same regardless. It's why you want to talk about identifiers as things that provide structure allowing you to talk about that information, but that aren't absolutely dependent on the particular mechanism you're using to store or query it.

DaaX's Six-Tuple Knowledge Unit

Sunil: Sajjad, you look like you have something to add.

Sajjad Khazipura: I agree with Kurt. We've made some effort to model knowledge in that form — we call it a knowledge unit. Let me share a slide.

For us, the knowledge unit is a six-tuple. It comprises the subject, the predicate, and the object. It has a temporal scope — which can be expanded into an event graph if required — telling you the time validity of the event or description we're talking about. That's modeled by tau.

Then we have mu, which speaks to metadata: was this derived information? Was it factual? Was it projected? Or did you hear it from somebody else?

And for us, most importantly, there's the element J — the justification. What's the provenance of this piece of information? Do you have proof to support it? And what is the context in which it's stated?

That's how we're trying to model our graph. Not all of it is in place today — we do J, and tau to some degree, though not extensively. So there are opportunities for us to evolve, but that's the model.

RDF 1.2, Reification, and the Fifth Dimension

Kurt: The idea you're describing there is actually pretty solid. Where it comes into things is RDF 1.2, which is ongoing and crystallizing now — it should become a formal specification by early to mid-2027.

With that, there's a notion they've been working on for a while called reification. Reification basically says: I have an assertion. And then, for that assertion, I have a reification of the statement — of that assertion — which in turn has associated metadata.

So a lot of what you're doing with the temporal aspects and the provenance information can be tied up into what that reification looks like. I do this all the time. You have the context graph, which on the W3C side would be encapsulated as a named graph — and that named graph effectively says these all share some kind of context, whatever that context is.

The named graph is one aspect of it, but you can also talk about these reifications — which gets you to the fifth dimension, if you will. The reification can then contain provenance information, event information, authoring, conditional status, or — the term usually used — confidence. All of that you can associate as a node structure that lets you do the same thing. So what you're doing, I think, is right. On the W3C side it would be articulated slightly differently, but it's basically similar.

Does Information Ever Get Deleted from a Graph?

Sunil: Sam looks like he's chomping at the bit.

Sam Pooni: Reification matters so much for temporal graphs, context graphs, and AI — I'm totally with you there, Kurt. I read a lot of your work, so I do have some questions. You've written extensively about now graphs and historical graphs, and you've gone into bitemporal notions in some of your articles. My question is: when does information get deleted from the graph — and does it even get deleted?

Kurt: Oh, that's a great question. I love it.

It really depends, and I've been asking myself that question for a long time. In general, if you go in with the assumption that you've got, for the most part, an append-only graph — then the answer is never.

If you make an assertion, and you say "I have an event," and at some point later you realize that event is wrong, you essentially have to say: I am now making a correction to the existing graph. But I have to log that correction. I have to make sure the correction stays as a fact that can itself be verified.

You see this with XBRL all the time. You've closed the books, everything has resolved, and then in the next quarter the analysts come back and say this estimate was wrong by this amount, and that changes how we calculate these things. You can't go back and change the original ledger entry. The moment you change that, you've invalidated an entire stream.

What happens instead is that the invalidation comes forward into the current graph — into the now, the present — and says: we recognize that this particular stream is no longer valid. That marks the end of that whole process. You're now into a different container, because you're effectively saying, we will retain that information — it's part of the graph — but it's not part of the computational cycle. It exists there for archival purposes.

Newton vs. Einstein: Superseded Knowledge Is Rescoped, Not Discarded

Sunil: Isn't that how the world works generally? Newton's theories were superseded by Einstein's, but that doesn't mean I throw away Newton's. I still know it's there — I just know it isn't as universally valid as Einstein's.

Kurt: Absolutely. What you're doing with this notion of an append-only graph is the same thing that happens with any kind of discovery: what was known before may actually still be true in the right scope.

But the scope has changed.

Take relativity. If the speed of a particular particle is close to the speed of light, or if I happen to be in orbit around a very massive object like a black hole or a neutron star — at that point you can say, okay, we're now outside the contained scope we were talking about, and we're in a much bigger scope where these new rules apply. And in the simplest case those rules collapse back to the old rules. But you've said something that effectively shifts the focus, so that you can use the old rules for a level of simplification.

Realistically, you don't use relativity to figure out your itinerary moving around a city. You might, if you're talking about moving between planets — at that point you do begin to get relativistic effects.

So these are all models. What you're doing with a model is asking: what are the rules I'm dealing with?

And when those rules change, you either adjust the model, or you say everything we knew up to this point led us to this starting point — and now we either rectify that starting point with changes, or acknowledge that the rules have changed and move to a new one.

I think that holds true regardless. If you're walking around a house, you don't have to worry about the curvature of the Earth. If you're laying out a shopping mall, you do — because that becomes large enough that you suddenly have to account for the fact that the Earth curves.

The Ontology Fight Happening in Boardrooms

Sajjad: Kurt, you recently wrote about the ontology fight happening in boardrooms that nobody knows about. What is that fight?

Kurt: Well — what is an ontology? That's a hard question to answer, because an ontology is several things. It's a way of identifying the resources you're working with. It's a way of talking about the concepts, the people, places, things you're dealing with. And being able to say "these are the things we're talking about" becomes important, because if you don't know what those things are, you can't track them. You can't manage them.

One of the challenges you run into with organizations is that the language you use varies depending on which department you're dealing with. The way a CEO, a CTO, and a CFO look at the world are different ways. They have different metrics, different terminology — and they have to communicate that to one another in order to move forward and strategize.

Up until now, we haven't done a good job of that. There's an implicit assumption that everyone speaks the same language. Anyone who's come in as a consultant notices immediately: how dysfunctional is this organization? And from an ontologist's standpoint, that really comes down to — how bad is the disconnect in language between IT, research, and HR about what's important to them?

Why Enterprise Ontology Initiatives Really Fail

Kurt: That's another challenge, because when you try to model an organization, there's a tendency to say "all businesses are the same." The reality is they're not. There are things in common, things you can structurally work with. But if I'm in the business of creating genetic strains for enzymes, and you're in the business of keeping shareholders happy, the languages you use are going to be vastly different.

And one of the big challenges is that if you try to build these huge ontologies where everyone has to agree, then everyone also ends up with a stake in what the right concepts are that we need to focus on. No one thinks about it in those terms — but that is why most enterprise AI initiatives, or enterprise ontology initiatives, tend to fail. In general, what happens is you can't get people to agree on the definition of what a customer is.

Upper Ontologies Are Frameworks — and Need a Lower Ontology

Sajjad: Do you think that's where upper ontologies could help?

Kurt: Yes, sort of — but the key thing to keep in mind is that an upper ontology is just a framework. It's a way of saying: here is how you can think about very generalized concepts, to express change, to express process, to express organization and complexity.

And most upper ontologies have one fundamental flaw: to be useful, you have to have a lower ontology. You actually need something that talks about the names and the things. This gets back to the frameworks you have with BFO, OBO, UFO, and so forth. They're very good, but they're very general. And they often introduce a methodology of thinking that works very well in an academic setting but may not work well in an organizational setting.

"Reasoning" Is Four or Five Different Processes

Kurt: I did a previous podcast with GraphWise where we were basically asking: what benefit do you get with reasoning — or is reasoning a bad thing? The answer is no, of course not; reasoning is very necessary. But what we call "reasoning" is actually about four or five different processes, each of which does something different. Inductive reasoning is different from deductive reasoning, which is different from abductive reasoning.

And the ontologists you're working with — typically at the level of an upper ontology — tend to be very good at stressing inductive reasoning. But they don't really handle deductive or abductive reasoning at all well. So you have to be careful when you're talking about reasoning. It's a very big bucket, it means a lot of things, and not all of those things are completely coherent with one another.

Becoming a Defensive Philosopher

Sunil: We're almost out of time. Sajjad, Sam — anything you'd like to ask Kurt? Or Kurt, anything you'd like to ask the guys?

Sam: I actually wrote something about reasoning a few days back, and you reflected my thoughts exactly — there are many moving pieces, and I'd written about the different types of reasoning. It was fascinating listening to you; it feels a bit like talking to a myth-like figure. Thank you for being on the show.

Sajjad: This is such a wide topic. What we're trying to do is bridge the gap between what the philosophers think about objects and things and places, and what the engineers need to know to build things. We're on that bridge connecting the two worlds — and it's a pretty dicey place to be, I must say.

Kurt: It really is. I absolutely agree. I didn't set out to become a philosopher — I became a philosopher defensively. I'm a defensive philosopher. Because at some point you have to step back far enough to ask: okay, what is it we're actually trying to do here? And that often comes down to questioning basic assumptions, sometimes uncomfortably. The problem, of course, is that after you've questioned them and torn something down, you say, "well, that's fine, but now I don't have any basic assumptions — I've got to rebuild everything from scratch." And that sucks.

So yes, I agree. You need people who can come in and look at this from the standpoint of: how do you deal with language? How do you deal with structure? For me, the last year has been increasingly focused on — what do we mean by epistemology? A couple of years ago I wouldn't even have been able to say it. Now, all of a sudden, I'm dealing with epistemology every day, because that's the reality we live in.

Epistemology, and Why AI Is an Epistemological Engine

Sunil: And now I have a word to go look up, because I have no idea what you're talking about.

Kurt: I'll give you a quick definition. An epistle is basically a message — the original Greek term usually meant a letter. What you mean when you talk about epistemology is really the underlying assumption that much — not all, but much — of what you know is secondhand knowledge. It's information that comes to you from external sources.

If you're working in a data context, that's almost always the case. The material being passed to you is very seldom material you originated. It's epistemological in nature — or epistemic, which is an easier way to say it. It's epistemic in that you're dealing with artifacts of events that have already occurred, and now you're dealing with how that information gets passed to you so you can form secondary knowledge.

That has a huge impact on things like AI. Because an AI is nothing but an epistemological engine.

Sunil: Right — it's getting its knowledge from something else.

Sam: And that introduces a problem. If you're writing a DSL, and that DSL isn't known to the LLM because it was trained on data that never included it — now you're in trouble. How do you actually train that?

Sunil: That's a topic for the next podcast. We'll have to end it there.

Kurt: That sounds like a good one. Thank you all for inviting me — it's been a pleasure, and a fun conversation.

Sunil: Thank you, Kurt, really appreciate it. If you could hang on for a second after we end the recording, we'd love to chat.