Key components

• Graph Database: Used for storing the knowledge graph as related nodes and edges.
• Ontology Builder: A tool used to describe what the knowledge is about.
• Graph Mapper: A tool used to synchronize the existing data and map it to graph storage.
• A conversational user interface (“ConvUI”): that allows anyone to search for information in the knowledge domain.

The Knowledge Graph

We assume that an employee asking for information is working on a specific business domain. For example, “sales and marketing” in sales, “flight operations” for an airline company, or “well operations” in oil and gas.

We leverage the efficiency of a graph database to store this information. A graph database stores information in the form of properties on entities (‘nodes’) and relations (‘edges’). Not precisely a new idea, as entity–relationship (ER) modeling was developed for database design in the 1970s.

Entities/relations (nodes/edges) is a natural and effective way to model a knowledge domain. The key point here is that a graph database does not translate an ER model into a relational database management system (RDBMS) where the relations are stored in the data themselves (in the RDBMS, relations are kind of lost in translation), but directly uses a graph structure and treats relationships as first-class information.

The data is stored differently from a RDBMS but most importantly, data can be foraged and retrieved efficiently in many more useful ways, allowing queries and analytics of associative and contextual nature.

Ontology builder

Business people know the vocabulary used in the company and understand how all the notions fit together. As part of Cloud Conversations, there is a specific tool to help build the vocabulary and the description of the relations.

Graph Mapper

The graph mapper offers a way to connect to existing data sources (e.g. CSV, relational data), retrieve the data, and populate our knowledge graph.

ConvUI

The visible component of the solution is a simple AngularJS application hosted on the cloud. It sends the queries expressed in natural language to a backend implemented as serverless functions in cloud architecture. After analyzing the question using an English grammar and the domain ontology, the system translates it to a query into the graph database. It then decides on the best way to display the result. Some questions will result in a number or simple text while others may lead to visual responses like bar graphs or maps.

The components of the solutions in action: