The Coming Merger of Blockchain and Knowledge Graphs

Kurt Cagle
9 min readNov 12, 2019
Blockchain, when you get right down to it, is a graph. Why not use a graph database to represent it?

Graph databases and knowledge graphs, in particular, have seen an uptick in interest among CIOs, digital transformation managers and others in enterprise circles. Some of this has come as data warehousing and data lake technologies have not shown the anticipated bringing together of all data within a company. This is due in part to a number of untenable assumptions, not least of which being that the relational model itself is sufficient to capture the rich, complex metadata that must be associated with properties that need to be in place to be useful. Column headers are often seen as an afterthought, when in fact those column headers are essential to converting data into knowledge.

Graph databases work by using a few basic principles. One of the first is the notion that keys, which identify resources in a data system, are global. In a relational database, this isn’t really true — most identifier keys are integers generated by the system to be unique relative to a table within that database. Typically this might start out as being the same as a row number in a table, though with deletions and insertions there’s no real guarantee that two consecutive rows will consist of successive integers. If you take the data outside of the context of the database, you need additional metadata that may or may not actually be passed to determine what keys actually…

--

--