Still in the domain of “traditional” dbs: how could you store a knowledge graph in a relational database?
A big reason for the current popularity of knowledge graphs is the greater availability of graph databases. This is why we refer to “knowledge graphs” and not “knowledge tables”.
The “graph” in “knowledge graph” refers to a type of data structure that is different from the tables used by relational databases. With a relational database, you must decide on the types of things you’re going to store data about in advance (for example, inventory items, suppliers) and define a table for each. You’ll also have to decide in advance what you’re going to store about each type of thing in each table–for example, for a supplier table, you might store each supplier’s name, address, contact name, and contact number. If you load up the respective tables with inventory and supplier data and then decide that you want to store new, related types of information, then changing the structure of your tables without causing problems with your existing data can be a big pain.
When data is stored in a graph structure, storing new types of things or storing new pieces of information about existing types (for example, storing each supplier’s home page URL) is just as easy as adding any other new entities and relationships to a graph. This flexibility makes it especially easy to merge two different, independently-developed knowledge graphs when compared with the potential merging of two independently-developed relational databases.
Tools such as D2RQ and Ultrawrap are available to treat relational databases as input to knowledge graphs, which is useful because so much data is stored in relational databases, but these are read-only solutions. With the data ultimately stored in tables, you’ll still have the difficulty described above in modifying data structures to store new kinds of data.
Some developers may implement the modeling of generic entity-relationship structures over relational database storage. This tends to be because relational database management tools have become so common since the 1980s that for specialists who consider these tools to be their hammers, even knowledge graphs look like nails.
Thank you for your answer!
I guess the migration and data integration problems intrigue me most - per experience many companies, especially those whose core business isn’t IT per se, still have relational tables, and personnel trained in their management, while KGs - at least to an untrained eye - are still a novelty.
I’ll have a look into the tools you suggested, I wonder how and if one could think of a tool for “translating”, so in write mode, between the two mechanisms.
FYI Ultrawrap was a Capsenta product, which was acquired by data.world. All this technology is embedded in data.world now.
(Disclaimer: I founded Capsenta and developed Ultrawrap)