Data and Analytics Learning Group Discussions
Ask your questions, start a discussion, and connect with other learners.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

SAP Knowledge Graph - what is it and why do we need it?

MarkGreen
Product and Topic Expert
Product and Topic Expert
285

Checkout this great article that positions the knowledge graph in simple terms with very helpful illustrations:

Why SAP Needs a Knowledge Graph: Giving Enterprise... - SAP Community

Checkout this great article that positions the knowledge graph in simple terms with very helpful illustrations:

Why SAP Needs a Knowledge Graph: Giving Enterprise... - SAP Community

1 REPLY 1
Read only

alexandergregor_scivos
Product and Topic Expert
Product and Topic Expert
0 Likes
165

Indeed, this is a well-written article. Comrprehensive and easy-to read with an excellent summary. The example question he starts with ("Which customers are influenced when this supplier slips a delivery?") proves as a good guiding example to explain the benefits of the knowledge graph. 

It also explains very well its potential to derive new insights. 

I really recommend reading Marks comment at the bottom of that blog because it was exactly my first thought:  "defining relationships is what we have always been doing with foreign key relationships in a relational database"'. So, did we not always have a knowledge graph somehow in a database if we outline the foreign key relationships? And, isn't a database just as much prepared for new questions that were not initially intended? Can't we just write a new query with a couple of inner joins?

But, as the blog points out largely:  This is not the main focus of the database's querying language.  We all know that a query with 2 inner joins can become very slow even if we just want a list of affected entities because the database SQL query language by its design looks for individual records with facts. The main focus of the database is the relationship within the table. In contrast, the focus of the knowledge graph (and its querying language) is the relationships between entities / topics. This has several advantages :

1. It is much easyier to query a question with a focus on relationships instead of entities: "how many customers are affected?" "What are the second-level sides effects if this material price changes?" 

2. Such questions can be handled much faster.

3. The relationship design is much more flexible. In a database, it would be really difficult to add a new foreign key between different tables, especially if data types are different. 

4. New relationships can be defined based on existing relationships, e. g. affected customer. This is more dynamic than storing the result of a query.

And, as the blog points out so well, in the current age of agents 😉 we often do not know what are the related entities that give the intended meaning to a word. When talking about suppliers, we do have a world of related topics in our head: products, plants, delivery methods, payment methods, customers. They are represented in our head as associated notions. When we humans answer a question, we rely on a network of significant related entities. A knowledge graph provides exactly this for autonomous agents.