Many chatbots have a problem. They can only remember the context of a conversation to a limited extent or only in very complicated ways. Such logic often must be implemented with a lot of programming effort. In my experiments with graph databases, however, I have noticed that a lot of this complex logic can be outsourced to the networked structure of such a database. As a result, users no longer need to write complex code when building their bot. Not even when the conversation becomes more complex. The logic arises from the design of the network-type structure.

The wanderer

In the last posts you have learned what graph traversal is, what it has in common with hiking and how logic can be stored in a graph as simple logic gates. Now I'll show you how this logic can be executed quite simply, as the traversal algorithm walks the paths in the network.

On the way he stops again and again, because many ways are still closed and will only open up gradually. So the hiker follows only the ways that lead away from a question or a suggested answer, if these have already been answered. If he encounters an unanswered question along the way, he will hand it over to the chatbot. These are simple rules that we can already give the hiker up on his way. But how does the wanderer know whether the logic gates that he find along the way suddenly may be passed?

OR conditions

Fortunately, we do not have to program anything for OR conditions. Our hiker solves this problem by himself. If several connections point to one question, it doesn't matter from which direction the hiker was coming. He may either have followed one OR the other way to discover more outgoing ways. We have thus defined a logical OR simply by placing several incoming connections on a question. Experts call this also OR gate. On the following graphic our hiker encounters the question from the right. He just could have come from above as well.


AND conditions

What if a question should not be triggered until several others have been answered? At the OR, you've learned that it doesn't mater which road the hiker originally came from. That would mean that the hiker need to take all incoming routes at the same time to follow the outgoing paths if he discovers an AND junction.

Not quite. The wanderer cannot split up. It would be possible to check for each node whether the conditions have already been fulfilled by following the incoming connections backwards and checking again whether the nodes that have been found are satisfied in turn, and so on. However, this leads to less flexible and cumbersome sub-queries.

But there is a simpler solution: The hiker simply has to check if he has ever been at the intersection and came from another way last time. He just remembers the name of the streets. If he has ever wandered on all the incoming roads, he may go further.

Here, it is possible to implement these AND logic by just setting connections, too. Experts also refer to this as AND gate. All we have to do is to tell the hiker that the current node is an AND node. This information is ideally stored in the node itself so that the hiker finds it there. In the following picture two ways are marked in red. The hiker must have run on both before the third question is triggered.


Coding becomes extensively unnecessary

Coding is no longer required to map complex conversations. By combining different AND and OR intersections and linking them with connections, you can easily create visually very complex logical structures. That's what I mean by logic graph traversal. It also allows the context to be maintained in a long conversation regardless of the size and complexity.


The clarity remains. Do you want to know when a specific question is asked, you only have to look at the direct dependencies.

With that you have managed to shift a first part of the logic to the database level.

In the next article, I'll show you how conditions can be isolated from questions and answers to get a better overview about them.

Here you will find more articles on the topic