AWS re:Invent 2025 - Symbolic AI in the age of LLMs (DAT443)

OK, so, um, so I'm Ora and um and I'm here to talk about uh symbolic AI. And this

AI. And this may be sort of a Strange topic now that everybody wants to do generative AI but I promise you it's, uh, it's something that everybody needs to understand and learn about, uh, if you don't already.

So, a few words about me, um.

My scenes of my misspent youth, I have a PhD in AI and CS.

Uh, was involved in creating the original vision for the so-called semantic web. Uh, I was

web. Uh, I was co-author of the original RDF specification.

If you don't know what RDF is, I will tell you.

I'm also author of this book and um fun fact, uh my software flew to the asteroid belt uh at some point.

Uh, and it was, uh, uh, symbolic AI, and I will, I will, I will mention those technologies in a minute.

So this is kind of my game plan today. I'll

give a very brief history of, of AI. Um, the

AI. Um, the part of AI that spends more than 3 years like everybody thinks.

Uh, and I'll talk about what are the elements of symbolic AI.

And uh and then I'll talk about.

What is symbolic AI today and why is it relevant and what are the useful technologies uh that you can apply today? And then, uh,

today? And then, uh, I'll conclude with um a little bit of discussion on what this means from the standpoint of uh Uh, non-symbolic AI generative AI, all that new stuff, so to speak.

All right. So,

when I originally wrote this, uh, talk, uh, I had a much bigger section on history, but uh The overlords didn't want that. So, uh,

so I'll, I'll just, uh, give you a very brief, uh, uh, introduction. So this is basically the history of AI.

Uh, what's important to understand is that it spans more than 80 years, and uh it's, it's sort of a pattern of, uh, excitement and disappointment.

We are currently in the middle of the, the, the 3rd AI summer. We call these

AI summer. We call these summers and winters.

Um And uh I, I have been sort of a little bit of a skeptic maybe of the, of the new, new, new AI and uh because I don't wanna see a third AI winter.

I lived through the second one.

And uh uh I continue to work on, uh, work on AI and people were downright hostile uh uh saying, why are you doing this?

AI is the stuff that doesn't work.

Uh, but here we are.

Uh, So, Symbolic AI or as it was originally called just AI um is a collection of all kinds of technologies uh and this is my incomplete list, but I think it's a representative list in the sense that these are the the important core technologies.

In in symbolic AI now of course it's important to understand that the history of symbolic AI also includes successful deployment of systems that made use of these technologies so it wasn't wasn't all just uh just research or anything.

Um, And, and I will, I, I won't talk about all of these, uh, I simply don't have time. This, uh,

we would be here all day.

Um, but you can come and talk to me afterwards if you're particularly curious about something, and I'm happy to, happy to talk at any length, uh, about, uh, any of this.

What's another thing that's really important to understand about the history of AI is that we have this pattern where. Some

where. Some technology comes about, we think it's AI.

Then later on we learn what it's actually about. We, we understand it and then we go like, well, that can't possibly be AI because I understand how it works.

And, uh, and, and so many of these constituent technologies uh um from the past have sort of stopped being AI.

They, they, they are just mainstream. I mean,

a rule-based system. Nobody, nobody

thinks of that as AI anymore.

Heuristic search, no, certainly nobody thinks of that as, uh, as AI but they very much were AI around the time when they were conceived.

And, and then uh at the bottom here, um, what came from, from, from the, the, the long span of uh AI research were two new programming languages.

And, OK, so now you think, you know, ho hum, programming languages come about all the time.

But this is not just languages. These

were two completely new programming paradigms. Uh, functional programming and logic programming that originate originated within, uh, AI research and now we don't really think of them as AI anymore.

OK. So,

throughout this talk, I will have to talk about things like symbolic reasoning, logical reasoning. So, I'll give you just a

logical reasoning. So, I'll give you just a very quick introduction to that.

So, here's Wally.

Wally's a good boy.

Um, Uh, we can represent, uh, so, so in symbolic reasoning, we use mathematical logic and set theory, uh, as a sort of representational language.

And uh so we can represent all dogs as a set, let's call it dogs.

And then we can say that uh Wally is a member of this set.

Which is one way of saying that Wally is a dog.

Um, and so now.

Let me, let me sort of demonstrate a simple kind of inference rule, uh, how we can do symbolic symbolic reasoning. So first, let's say

reasoning. So first, let's say we want something where X.

Belongs to a set, and let's call that set C.

And then we also say that C is a subset of D.

And if those things hold, then we can conclude that X is actually also a member of this.

This larger set, set D.

And this is, this is a, this is an inference rule. So now

rule. So now if we say dogs are a subset of mammals, And we know that Wally belongs to dogs, then we can conclude that WALE also belongs to the set mammals.

Wally is a mammal, so to speak.

Now, this, of course, sounds incredibly trivial, right? But uh

symbolic reasoning is like that, and real-world applications of symbolic reasoning are far more complex than this, but the principle still, still is the same.

So here's just a visual representation. There's a set

visual representation. There's a set of dogs and while he is there and, and then there's the larger set of uh set of mammals.

OK, so now we, now everybody understands what symbolic reasoning is yes?

Nothing?

OK excellent.

Good. Uh, so now we can move on.

So let me talk about uh knowledge graphs and ontologies.

Um Because those are really the prominent manifestations of symbolic AI today. And, and in

today. And, and in a way, sort of, um they are that because uh about 25 years ago, there was in some way, there was like a sort of a resurgence of uh of, of, of symbolic AI techniques that brought about uh uh uh this.

So, a couple of terms first, uh, a graph, when we talk about graphs, we mean the mathematical notion of a graph.

So it's a structure of nodes and edges.

Typically if you want to draw this on your whiteboard, it would be circles and arrows between them. But

between them. But we don't mean a graph in a graphical sense. And

sense. And a knowledge graph is an application of a graph where basically the, the nodes represent or denote some real-world entities.

And the edges then represent the various kinds of relationships between, between these, these entities.

So, we can use knowledge graphs to, to, to link information and orga organize information and, and, and, and this thing that came about 25 years ago, the semantic web, knowledge graphs today are really the modern manifestation of that idea.

The primary purpose For Knowledge craft is really to capture knowledge and, and oftentimes in a sort of collaborative organizational context.

But there are other uses, very good uses of the same technology.

So um something that I've seen many times and, and also build systems, uh, myself. So,

myself. So, just make knowledge accessible.

To people and more recently to To LLMs also.

Um, a sort of a low-level feature of knowledge graphs, it all comes almost like a, like a sort of a bonus benefit is that uh they're very good for data integration.

You can take your, whatever data you have, we'll call that legacy data.

And uh you can map it to a, to a, to a knowledge graph, and if you do this right, the knowledge graph will represent the integration of these different uh data sources.

And then finally, uh, there's something called digital twins.

People build these, they are really uh sort of a complex representations of physical systems in a digital form.

And so we could imagine like um a digital twin of a, of an electrical system and then you could, you could use that to ask questions like, OK, if I throw this switch, what happens? Or if this circuit breaker blows, who's affected?

Um, So to build a knowledge graph, you have to have a model.

Of what the information is in your knowledge graph, and this model is called an ontology.

And I will, I will come back to that, uh, what that means.

Uh, now, when you finally build this knowledge graph, you have to store it somewhere. You

have to be able to manipulate it.

And for that, you need, uh, a graph database.

And um just as a purely random example, Amazon Neptune is such a graph database and uh um. And

um. And a highly scalable one at that. So,

that. So, let's talk a little bit about what an ontology is.

So there is a common definition of what an ontology is, and if you look it up, uh, you always get the same definition and it's completely useless.

So I won't even repeat it here. Um,

this is my definition of what, what an ontology is. So ontology consists first of all,

is. So ontology consists first of all, of concepts that you have identified. You can think of them like classes.

So, you know, to follow our example, uh, a dog would be one of these, these concepts.

And then you define properties for these concepts.

So in the case of a dog, that might be fur color, for example.

You also define relationships between Instances of these concepts.

So a dog typically has an owner.

And that owner typically is a human.

Um You may specify logical constraints that have to hold, so my example here is.

That Dog and cat, the intersection of, of, of dog and, and cat is, is empty, which means that if you think of these as sets, these sets are, are, are, they don't have a, uh, have an intersection, they are disjoined.

Um, and then finally, and this is, this is not every ontology, but ontology sometimes may also contain actual individuals, as we call them.

So, Wally would be an individual, Wally would be an instance of the class dog, if, if, if you wanna think about it that way.

To define an ontology, you need an ontology language.

And uh what we didn't have back in the 90s, what we do now is we have standardized ontology languages and I'll come back to uh uh talk a little, little more about what these, what these standardized uh ontology languages are. But it has really made

are. But it has really made all use of all this stuff a lot easier because, because we have standards, that means people can build tooling and, and all that.

So I mentioned that ontology is something that captures the semantics of a domain. So what is semantics, really? I

domain. So what is semantics, really? I

mean I anybody heard anyone use the word semantics?

Yeah, uh, I think, uh, I think people use it a lot. Most people don't know what it means.

I find that just a tad ironic because ontology, uh, I'm sorry, semantics is really about meaning.

And uh and and I think of uh semantics in a sort of slightly informal way that it's, it's really definitions of how some piece of software can interpret your data.

And so, given that semantics comes from the relationship that your data has with whatever definitions you have in your ontology. Ontologies

are the, the means to kind of capture the semantics and convey those.

But it can also come from the relationship between two pieces of data, that they have some kind of relationship and that gives them meaning.

So, for example, to humans, and we say that uh that uh uh that, that this person is the child of that.

We might be able to conclude that that other person is a parent.

Um, and then things that you can't express this way, then, of course, you have to hardwire the semantics in code. And

historically, of course, everything, all semantics was hardwired in code.

And, and the, the great aspiration is that we can move towards a situation where things are more definition and data-driven and not so much uh uh uh buried in some black box uh that cannot be really uh inspected so easily.

Interesting thing about semantics is that people typically have a very hard time making the distinction between formal semantics and their own interpretation of some data, for example.

And uh This matters because it creates unrealistic expectations of what software systems can actually do.

Uh, and, and as a result, uh, I, I often hear this, uh, people say, Jason is easy to understand.

Who here thinks Jason is easy to understand?

Some, some people, OK. Not everybody, that's good. OK.

good. OK.

Um, so I'll, I'll, I'll give an example, um, what I mean.

So, here's a little snippet of, uh, Jason.

I'll give you a moment to look at it.

Um, When you read it, you think, yep, OK, I understand what this is. I

understand the meaning of this data.

This is a very sort of a human reaction, uh. I'll

uh. I'll give you another snippet of Jason that ostensibly has exactly the same meaning, and you tell me if you still understand.

What it means Um, maybe somebody here actually speaks Finnish, and therefore you can interpret that the same way you interpreted the previous one.

But I think of Finnish as sort of a As a language, it's sort of like a weak crypto mode.

The key is known, but very few people have it.

Um anyway This is the same thing.

I just translated the keys to, to and some of the values to finish.

And in the English version you basically performed.

A grounding of these symbols.

Grounding of symbols like degree or hobbies.

You interpreted what that is based on your experience and your understanding of the English language.

And, and, and now you think that that's the meaning.

Of course, I could say that this data means something completely different and, and has no relation to the English words that are there.

But what, what you see here is how data looks like to all machines, all the time.

And so I don't think Jason is easy to understand. All

understand. All right. So,

right. So, that's kind of still background. Um,

I'll talk a little bit about what it means to work with onthologies and um.

So, let's say you decided you need a knowledge graph and um and, and therefore you need to have an ontology.

So, the first question is really the sort of build or buy.

And, and when I say buy, I don't really mean literally buy cause ontologies tend not to be for sale, they tend to be shared, they tend to be public, but same difference.

So your choices really are, first of all, you could just find some ontology and go like, OK, this is perfect for my use case, I will just use it as it is.

You have to assess the suitability very carefully.

And I'll, I'll, I'll, I'll talk a little bit about what this this assessment actually is. It will be helpful

is. It will be helpful when you, when you start choosing, choosing ontologies.

You could take that existing ontology and go like, yeah, it's almost what I need, but not quite, so I'm going to be extending it.

And ontology languages have been, have been designed in such a way that it's possible to take an existing ontology and extend that uh for, for your own purposes.

There are also a thing called upper ontologies, which can be a good, uh good starting point for this kind of an exercise.

What's important to understand is that every ontology.

Or the designer of that ontology has made some decisions about how to model the world, and you have to understand what these decisions are.

Otherwise Bad things could happen.

Now the third option is that you'll start from scratch, you know, go like, OK, I don't need what others have done.

I'll just define my own. That's perfectly fine.

Just prepare to do some work, um, because er and lately I've heard a lot of people say, oh, you know, I'll just let the LLM write me an anthology.

An LLM can write you an initial draft of an ontology, but after that, it really requires human eyeballs.

Um.

All right, so the, let's now say you found an ontology, you're thinking maybe I'll extend this, but I have to first assess the suitability.

So, what is that? What is that? First of all, consider your use cases.

Not necessarily one use case.

Pick a couple of use cases and be prepared to find more use cases in the future.

The, the knowledge graphs have this interesting characteristic that uh you build something, and you think, OK, this covers my use cases, and then you realize, oh goodness. This knowledge

oh goodness. This knowledge graph can answer questions that I didn't anticipate, and then you may have more use cases and uses for that for that knowledge graph.

When we design an ontology, we usually define what is called competency questions.

So these are really questions you.

Anticipate that if you do this right, your resulting knowledge graph should be able to answer.

So in some ways the competency question should be translatable to graph queries at some point.

And then coverage means that uh you have something you want to model, you, you look at your enterprise or your organization and go like, OK, we deal with these kinds of concepts, make sure those concepts exist in the ontology that you're going to use.

And if they don't, extend the ontology to, to, to, to cover, cover everything.

So that's one.

Then there's this question that I mentioned that People have already made decisions about how to model the world. I call these ontological commitments.

And this is where what I what I like to call the law of unintended consequences comes into play.

So it's like, in other words, it's, it's this seemed like a good idea at the time.

So you take this ontology and later on you realize, oh goodness.

I can't do certain things because some decisions that were made way earlier.

Um That happens all the time.

And then finally, there is a question of expressive power.

So expressive power is really a measure of what are the things you can say. Using your

say. Using your ontology.

And express so for that you need something called a reasoner typically.

Um, and. You will always

and. You will always have this sort of a trade-off between expressive power and the computational burden.

For using a particular ontology that requires that particular level of expressive power.

Um, the more expressive, also more difficult to, to, to compute, generally speaking, as a sort of a gross, uh, generalization.

So what what what what can you use these things for then?

So, A very typical use for ontologies is that you can operationalize or automate the processing of your data.

You basically Have data and have sort of the meaning, the semantics of that data, follow that data.

And the aspirational end goal is that you can have software that can process that data, can interpret that data in some ways.

Without actually that having been coded in there.

You just give it the ontology and the it interprets the ontology and, and, and can do meaningful things uh for that data. And that, that, that's a real thing that, that, that, that can be done.

Um, ontologists can also be used to uncover implicit information. So that whole example where Wally

information. So that whole example where Wally is a dog and now we find out, oh, Wally is also a mammal. We never said that Wally was a

a mammal. We never said that Wally was a mammal. We uncovered

mammal. We uncovered that that was implicit in the data.

Um Ontologies can serve as documentation.

And uh um having said all these things and there's a lot of sharing here um at least to me, the implication is that I really would like to stay away from closed proprietary ontologies.

So they, they can certainly solve certain problems, but they don't give you the full, full benefit of what ontologies can do.

All right, so some examples of uh uh shared public ontologies that you can use. So

first of all, there are these upper onthologies uh that you can start from, uh, basic formal ontology is very, very abstract, and I always feel like you really need like a graduate degree in philosophy to, uh, to use it.

Gist is a much more practical, practical one. both are popular.

one. both are popular.

Uh, then we have domain-specific onthologies.

FIO is, is, is about the financial industry and all the different concepts in the financial industry. Snowmed is a

industry. Snowmed is a medical thing and uh Sydoc is uh is, is an ontology for people who want to capture cultural heritage, um, museums, archives, you know, what have you. Now, in addition to these

have you. Now, in addition to these two categories, we also have these kind of narrow uh ontologies, um, for, for, for like single purpose that you can mix into your, your, your own own definitions.

These are, these are the four of my favorites.

Uh, Dublin Core has been around for a long time.

Provo is an excellent model for capturing, uh provenance.

Um, and, and, and I will later have an example of what SOS does, uh, sort of when you build taxonomies and thesau right.

So, let's, let's build a quick ontology um and see how that works. So, um,

and this uses the, it uses RDF and owl as the, as the ontology languages, and it uses the, a particular syntax of RDF called turtle. RDF has multiple syntaxes depending on your, your, your preferences.

So we define a class called dog, we say it's a subclass of, first of all, mammal, and also a subclass of pet, and then we say it's disjoint with cat. OK,

so this is in line with what we talked about earlier.

Then we define a few more classes, cat, human, mammal pet uh, pretty, pretty clear stuff.

And then let's define a couple of, uh, let's define one property, the fur color property, and we say fur color property is something that belongs to dogs, uh, and the value is some string.

Uh, we don't say what that string can contain.

An owner is a relationship.

That links pets and humans.

So this is our simple, simple ontology, um and uh in all this representation we would call this a T box or terminology box.

These are the definitions of your data.

Then we also typically have this, uh, uh, another thing called a box or assertions box, which is really the instantiations of, uh, of those definitions.

So we say Wally is a dog.

White and black fur has an owner. Coco is another dog

owner. Coco is another dog or as a human.

Things like that, those are individuals, and and those don't have to be part of your ontology, but they will go into your knowledge graph.

And uh um Because we're using RDF.

We have a graph representation of this, so here it is. Wally is

an instance of the class dog.

Or as an instance of a class human.

And uh Wally has an owner called Dora.

So, so simple, simple graph structure, but RDF has this kind of self-similar structure.

So We can actually include the definitions themselves in the graph as well.

So in this case, dog and human would both be instances of a class called class, which now would be sort of a meta-class, obviously.

Yeah um And here's an example of uh me querying uh the data that we saw earlier using Neptune.

Um, we have extended the Jupiter notebook so that you can run queries directly from cells and, and get the results and uh those results can be tabular or they can be visualized as a graph.

So, all this is what I'm talking about is, is absolutely real.

Um, and, and when you wanna start building a knowledge graph, we can help you.

All right, so I mentioned that there are different ontology languages. So first of all,

languages. So first of all, RDF is a very simple.

Ontology language.

Here are some examples. I define pet and I, I, I, I, I define uh uh the owner uh uh relationship.

And then We can use that to infer new data.

So if I say that that owner is a relationship that links pets and humans, And then I say that Wally, who is a dog, And we know dogs are pets.

Has an owner called Aura, but I haven't said anything else about Aura.

We can infer that Aa must be a human.

Now owl is a more expressive ontology language.

Um, and we express, we can express restrictions using the subclass mechanism.

So here we say that a pet.

Must have exactly one owner, and that owner must be a human.

And If we then take an our reasoner and we take your graph, if there are unsatisfied restrictions.

Two possible things can happen.

Either the reasoner reports that there are inconsistencies, or it will add new information to your graph to make it so that those restrictions are satisfied.

So, similarly, it could, it could infer that the owner, if you, if I introduce an owner, but it's not a human, the reasoner could actually uh uh infer that the owner actually is a human.

Uh, Shackle is a, is a language, RDF based language that was originally designed for validating your RDF data.

But you can also, you can use it to express constraints.

Uh, those constraints in shackle are called shapes.

But unlike RDF and Owl, Shackle never infers new data.

So if there are unsatisfied unsatisfied constraints, your shackle engine will simply tell you that your data did not validate.

So why is this?

Why do RDF and work differently from shackles? So we have to talk about something called

from shackles? So we have to talk about something called world assumptions.

So first of all, closed world assumption.

is this thing that we assume that What's in your database?

Is all that there is, there is nothing else.

And so, whatever reasoning you do, can be based on the fact that you have complete knowledge.

And that means that you can use something called negation by failure.

So if you can't prove something to be true, you have to conclude that it's false.

Traditional databases tend to use the closed world assumption.

Open world assumption on the other hand is the idea that We don't know everything.

There could be more information out there, and we can't possibly assume that we have it all.

So that means you can't use negation by failure as an inference rule.

We adopted this for the semantic web.

Because we thought, well, you know, the web, uh, maybe you haven't reached that particular server, you hadn't collected that particular piece of data. There could be more stuff, so

of data. There could be more stuff, so made made perfect sense.

Um, and now, uh, just a quick word about those, those ontological commitments or modeling commitments.

So we defined that pet can have only one owner.

But what if there's like joint ownership of some pet? How do you do that?

So, This is a very common occurrence.

You, you pick an ontology, you do modeling.

Later you find out oops can't do that um so possible solutions if you control those upper definitions you can just go and refactor your code a little bit, the, the, the code of the ontology that is, um, and make it so that, uh, there can be multiple owners or you can introduce a new relationship uh co-owner or something like that.

There are ways to fix this.

Um, and then, When you define your ontology and you have different kinds of concepts, sometimes you have concepts that are really variations of one another, and you can capture this using a class hierarchy.

Um, the alternative is to capture these variations using something we call concept schemes, and I'll, I'll explain this.

So let's say we want to represent dogs in such a way that we also capture the breed of a dog.

OK, so here's some, um, here's some uh uh definitions. A

dog is a class, toy dog is a subclass of dog, Shih Tzu is a, uh, is a, is a subclass of toy dog.

And these are the, I don't know, American Kennel Club classifications of, of, of things.

Um, you know, we, we, we introduced all these definitions and now we, we say that Wally is a Shih-tzu and a poodle.

Yeah.

These are called designer breeds nowadays. I, I would call them mutts, but.

Um, but anyway, here we use the class hierarchy to do that, and it sort of looks like this.

Note that we can have instances that are instances of multiple classes.

So multiple inheritance in RDF is not limited to classes alone.

If you don't like that, You can introduce that designer breed.

Which in this case is actually called shiu.

Real, real thing.

And then you can just say Shiu is a subclass of both shih-tzu and a poodle.

And then Wally is an instance of this class.

All good.

Now, the alternative is to say, all dogs are really much alike. We, I don't want multiple classes.

much alike. We, I don't want multiple classes.

Uh, I don't wanna clutter my ontology with large number of classes.

So let's put a property on dogs called breed.

And then decide what kind of values can that that that that property take. And

take. And for that we need we need that scarce vocabulary that I mentioned earlier.

And we build something that's called a concept scheme.

And we defined all these things that we earlier defined as classes. We now define them as coarse concepts.

Uh, and then we can just say that Wally is a dog and Wally's breed is Shih Tzu and poodle.

But basically you represented the same, same stuff. uh, it's just that you only have

stuff. uh, it's just that you only have one class now.

And again here, if you only want a breed to have one value.

You can again introduce the designer breed as a separate concept and And then do this.

So this is, this is how it works. This is how you, how you define ontologies and work with the classes and the definitions.

So, a couple of quick words about how to, how to actually work with reasoning and this does not require a PhD in math.

Uh, you can do this, um, I mean, maybe some of you do have a PhD in math, that's fine, but uh it's not a requisite here. So

here. So there are many use cases for reasoning.

One is this what we already talked about uncover implicit information. We say Wally is a sheepu.

information. We say Wally is a sheepu.

We can conclude that Wally is a dog. We can

also conclude that Wally is a mammal.

Uh, those can be handy, handy things to know. We can

know. We can discover inconsistencies if I say Wally is a cat and a dog.

Uh, the whole reasoner will tell me that you have a fundamental inconsistency.

One that cannot be fixed by adding more data to the, to the graph.

Uh, Reasoning can also be used to make query authoring easier.

Because You can operate, let's say, just using the, the, the, the, the base classes, for example, and your ontology can evolve.

But the reasoning basically insulates your queries from the changes in the ontology.

You can add more dog breeds, and this query will still work.

I Um, RDF basically more or less just gives you taxonomical reasoning.

But it, in addition to class hierarchies, also properties can have hierarchies, which is a very handy, handy feature when you are extending.

Somebody else's ontology.

You can introduce your own properties, but you can say, well, these are really extensions of those properties that came from that other ontology.

So here I have defined uh uh an owl class called black poodle.

And I have defined it in a way where I say breed must be, must have the value poodle, and fur color must have the value black. Now earlier

black. Now earlier I said that we use subclassing.

To introduce restrictions, but here I've used something called equivalent class, and the difference is this, if you use subclass, that introduces a necessary condition. All black poodles

condition. All black poodles must satisfy those constraints.

But if you use equivalent class, it's Necessary and sufficient condition, which means that if you find something or the reasoner finds something.

Where Breed is poodle and fur color is black, it can actually conclude that this is an instance of the class black poodle, which means that the reasoner can be used for classifying your data.

Um Well, now, of course, there's the question of how and when to do this. Um, some

triple stores or or graph databases for RDF, they have a built-in reasoner. Uh, if not, there are options.

You can even use Sparkle, the query language, as sort of a reasoning engine. Um,

engine. Um, here's an example of, uh, figuring out what the, what the class of an instance is.

Without, without reasoning, um, you can, you can rewrite your query to basically climb the, the, the, the hierarchies in the ontology.

And do the same thing that a real reasoner would do.

This happens at query time. If you want to do this before query.

You can materialize these results of the reasoning beforehand. Results

beforehand. Results of reasoning, by the way, are called entailments.

You will see this word uh pop up every now and then. If

I say entailment, think about results of reasoning.

Um, so this would be a way to, uh, to kind of materialize the entailments in your graph, and the, uh, and and and there is a choice between these two, do it query time or do it beforehand.

If your data changes a lot, it may be more useful to do it at query time.

But if your data is more or less static, you can do it up front and then you don't have to do anything when you're querying.

So when you're materializing, um, you will encounter this problem that we call truth maintenance.

I used to think that truth maintenance could be like a, like uh something uh an, an authoritarian government does, uh, but, uh, but it turns out that truth maintenance is the question of, OK, I've materialized some entailments, and now I've changed the data, which entailments do I have to retract now because they're no longer supported by the original data.

And uh this can be a very costly, costly operation.

Uh, if you use, um, if you use Sparkle, the query language as your reasoning engine, you can do this, what I think of as poor man's truth maintenance.

You materialize, you put them in a separate name graph in your RDF has this feature called name graphs.

And then you can drop that graph and recomput when things have changed. All

changed. All right so That's that. Now a few

That's that. Now a few words about.

The new AI and its relationship to the old AI, so to speak. So can the

to speak. So can the older AI help the new AI is really the question.

All of you must have seen this quote.

What's important about this thing is that Arthur C. Clarke said.

Any sufficiently advanced technology is indistinguishable from magic. He

didn't say it is magic.

And there are a lot of people who think of the new AI as sort of magic, but it isn't magic, and it's really important to, to keep that in mind.

So we have, we have some challenges.

We all know that these are challenges, so hallucinations, obviously. And limbs

obviously. And limbs will make stuff up, and that's a feature that's they're supposed to do that.

Um, but it makes it difficult to, to, to, to build systems. Anthropomorphism.

People start thinking of their chatbot as an actual human.

And um The answers sound convincing.

People will believe them. They won't

check them.

This is a problem.

And then the computational efficiency is definitely a problem in the sense that If you already know how to compute something, Then just compute it. Don't ask the LLM because it's highly inefficient.

And our energy supply is finite.

Related to this are some interesting historical criticisms of AI.

Joseph Weizenbaum in the 1960s built what is the first chatbot.

And it was very crude, obviously compared to what we have today.

You sort of these rules and pattern matching and.

But he noticed that people started having conversations with this chatbot as if it was a real person, and it turned Weinsenbaum into a vocal critic of AI.

He, he didn't like the idea of anthropomorphizing computers. Uh,

computers. Uh, the Chinese room experiment, uh, is a, is a, is an interesting sort of philosophical question that really asks what is consciousness and what is understanding? Can machines

understand something? Can an artificial system be conscious? It's a

be conscious? It's a I used to think it's only a philosophical question, but lately, Maybe it's a more practical question.

Even these are highly relevant today.

Um, the history of AI is about scarcity.

We always had scarcity of something.

We didn't have the right algorithms. We didn't have enough memory. We didn't have a fast enough processor.

Those are more or less solved in many ways. We

have enough of those, but we have other scarcities today.

This is my, my list of the, the, the scarcities we encountered today. So let's

talk about this a little bit.

We want correct answers, right?

We don't want the system to hallucinate some, some, some bullshit.

Um, so, you could pull the answer from a knowledge graph rather than uh have the LLM produce the answer for you.

Accountability trustworthiness same thing.

You wanna know where the answers are coming from.

If they come from your knowledge graph, that knowledge graph can be curated and audited, and you can make sure that it contains.

Um, provably factual information. You

information. You want to be able to explain the answers.

An insurance company will tell uh a policyholder that their claim was denied.

I'm sure the first question that the policyholder has is why was it denied.

You want an explanation and, and, and uh explainability is a, is a, is a prominent feature of symbolic reasoning. And when you do symbolic reasoning,

reasoning. And when you do symbolic reasoning, you can always trace back why you got the answer you, you, you, you have. And

have. And then this, the, this energy question. So getting

an answer from a knowledge graph for a question is literally several orders of magnitude more efficient than getting it from an LLM.

So There's a growing understanding that The future AI systems really are going to be hybrid.

They will combine.

Different kinds of technologies, symbolic and, and, and these newer non-symbolic techniques.

But in cognitive science, there's been this idea of what they call dual process models of cognition.

Um, this is an idea that really was popularized by Daniel Kahneman's book Thinking Fast and Slow.

Um, it wasn't his idea originally, but he made, he made it popular and, um, the idea that there's a fast process that gives you an answer right away, but that answer may be incorrect or biased or something, or the answer can also be deliberated a little more and you get a more trustworthy, trustworthy answer.

And there was also in the 70s, there was a lot of interesting work where people really started thinking about intelligence and consciousness and started drawing like What we now would think are like architecture diagrams, software architecture diagrams. Aaron Sloman, Daniel Dennett did a lot of work like that. Um,

like that. Um, so here's, here's my sort of very trivialized idea of how to use an LLM with a, with a knowledge graph.

Ask a question, the LLM translates the question into a query.

The query runs, answer comes from your knowledge graph, and of course, not just.

Basic query processing, it could include symbolic uh reasoning as well.

Now how does this fast and slow thing work with this, so it could be something like this.

LLM gives you a quick answer.

Or you go the other route, you get a more sort of effortful answer. Um,

other architectures, of course, are possible and make perfect sense, but, uh, I like this as sort of a simple explanation of what these things might look like.

So now you're going to ask, well, this is graph rag, right?

This is not graph rag.

So graph rag Uses a graph, not necessarily a knowledge graph, to basically improve the LLM performance, accuracy, whatever. But I'd like to

whatever. But I'd like to kind of flip this and use an LLM to improve the performance and usability of knowledge graphs. And the

graphs. And the Now with LLMs we finally have a a decent natural language capability.

And um so, taking questions, translating them into something, but having the answers come from a knowledge graph, to me, sounds like a great idea.

And then finally, people talk about neurosymbolic AI, so let me explain what that is.

So, symbolic AI is often seen as kind of unrealistic and, and, and too idealistic.

Everything has to be perfect for things to work.

Now, on the other hand, on the positive side, the representations are completely transparent.

And results can be explained.

Non-symbolic idea, on the other hand, while it can deal with the sort of messy real world data.

The representations are opaque. You can't

really look at them.

And the results cannot be, cannot be explained.

So what we would really like is to get all the green stuff, right?

Um. So,

so here are some examples of what neurosymbolic AI could be.

It is not a single architecture or methodology, even there are many different ways to combine symbolic and non-symbolic processing.

So combining the two, it could be that you have used a heuristic search, but your evaluation function in the search is actually does some neural processing, for example, and obviously this System one and System 2 architecture is an example of that too.

Um, you could take non-symbolic input like a picture.

Photograph, convert that to some symbolic representation, and then use symbolic techniques to.

Reason from that symbolic representation.

Or You could take symbolic data.

But use that with the non-symbolic like machine learning, uh uh uh uh some machine, machine learning algorithm, for example. People have done work on like

example. People have done work on like showing how mathematical equations can be simplified and then fed those as training data.

To a machine learning system and, and come up with the, with the system that, where they claim that, well, now, now I have a machine learning system that can, can, that can do mathematical simplification.

Now, that's still guessing, but results have been remarkably good.

All right, So I suppose I should summarize a little bit.

I hope uh you, you're gonna take some of this with you. So AI has been around for a long time, longer than 3 years, OK?

Uh, and there've been many useful techniques and technologies developed over this period of 80 years or something.

Um, And these technologies, once they're well understood, they really stop being AI.

Now in the early 2000s we saw this dramatic shift from symbolic to non-symbolic AI.

But the, the, the, the symbolic AI techniques are still, are still relevant and uh. Um,

and uh. Um, ontologies.

You can do this, you can use ontologies, you can build knowledge graphs, um, you can operationalize your processing of your data, you can document your data better using an ontology, and you can even use reasoning. This is all

reasoning. This is all quite real.

And then finally, We can mitigate some of the problems that we have with LLMs using symbolic techniques. Not only

ontologies and knowledge crafts, mind you, like planning and autonomous agents that come from symbolic AI.

Those techniques can be very useful. We

didn't have time to talk about that.

But uh I'll hang out here. You can

come and ask me if you're really interested. Um,

the whole idea of planning particularly is uh. Something that

uh. Something that the modern manifestation of agents tend not to do, and I always think that agents have to be able to do planning in order to exhibit autonomy.

We'll see many more of these.

These Hybrid systems going forward.

Um, we have a little bit of time. I'm not gonna answer questions now, but come talk to me afterwards. Um,

uh, uh, it's much easier to, uh, to, to answer questions, questions that way. Um,

way. Um, so, thank you very much. Uh, and if you later on have questions, you can always email me, remind me of this lecture, and, um, my email, so I'm Aura, and my email is super difficult to remember. It's Aura@

Amazon.com.

And uh um Thank you so much.