When Graphs Collide: The Coming Merger of Property and Semantic Graphs
For most of us, the word graph brings back memories (not always pleasant) of pencils and rulers and quadrille ruled paper, though a more recent generation may think instead of pie and bar charts produced in Excel from spreadsheets. However, in the last few years, another form of graph, one that goes back to a whole branch of mathematics called graph theory, is beginning to have a huge impact in business, science and the world of artificial intelligence.
A graph data is a class of data store that has been flying under the radar for some time now but increasingly are emerging as some of the hottest trends in data management. It makes use of relationships and connections as much as tables and indexes.
Graph representations are not new. Indeed, graphs figured pretty heavily in early medieval mysticism, including the Hebrew Kaballah:
On the other hand, graphs also play a significant role in contemporary physics, including such areas as the standard model of particle physics:
In the realm of computing, graphs are everywhere. Indeed, it can be argued that, at least for a broad subset of computer programming, graphs underlie almost all databases produced since the introduction of the computer in the 1940s. However, pure graph databases (rather than just ones that can be modeled by graphs) have only been around for the past decade or so, divided primarily into two distinct types: semantic (or triple store) databases, and property graph databases. In order to understand the distinction, a little bit of background on database theory in general is useful.
In a traditional relational database, information is stored in tables, where the rows of each table correspond (roughly) to a particular thing or resource, and the columns correspond to the properties acting on those resources. This distinction is somewhat fuzzy in that tables and classes of objects aren’t completely synonymous but it works to a first approximation. The values where a particular row and column intersect can essentially be of one of three broad types: a scalar value (such as a revenue number or the text contents of an article), a primary key, or a foreign key reference to a primary key.
The primary key is an identifier for the resource itself. Many databases use a mechanism in which every time a new row is created, an integer pointer is incremented and used as the key. Because rows can be deleted or merged, most relational tables do not quite have a one to one correspondence between row and primary key. Sometimes it is possible (though not necessarily wise) to bypass creating a primary key altogether, and the key for the table is a composite key.
A join, in relational parlance, matches a foreign key (or more properly, key reference) in one table with a primary key in another table. By using a particular language syntax (SQL), you can create a join by telling the database what table a given key reference column indicates, then matching the foreign key indexes (the integers) to the primary key indexes in the target table. An Excel user could think of this as creating a lookup table on a separate sheet in a workbook, then using lookup techniques to get detailed data about something without having to repeat the same information over and over in the spreadsheet.
When Tim Berners-Lee (TBL) was first mucking about trying to write an abstracts system (what we’d call a content management system today) at CERN in the late 1980s, he came up with a truly ingenious invention. He built a server on a target machine that would take an address (that famous protocol) and retrieve a document on that server that was referenceable from that address. Put another way, he mimicked the way that a database stored its references, then used as a way of uniquely specifying where that resource was.
