In an era defined by data, making sense of complex relationships and vast information repositories has become critical for organizations. are emerging as a powerful tool to tackle these challenges. By organizing data into a network of interconnected entities and relationships, knowledge graphs provide a structured way to represent information and extract insights.

In traditional data systems, information is often stored in siloed databases, making it difficult to extract meaningful insights. For instance:

• Disconnected Data: Systems that store data independently struggle to provide a unified view.
• Poor Relationship Representation: Conventional databases often fall short in modeling complex interconnections between entities.
• Search Limitations: Searching across structured and unstructured data seamlessly is challenging.

A knowledge graph addresses these problems by integrating data from various sources into a unified graph structure. It represents as nodes that connect to each other through various relationships (edges) in a format that is both human-readable and machine-interpretable. This framework acts as a database, enabling complex queries by understanding the context and connections between various pieces of information. Knowledge graphs enhance AI applications by improving information retrieval and reasoning capabilities across multiple data sources powering tasks like semantic search, recommendation systems, and more.

What is a Knowledge Graph (KG)?

The term knowledge graph has been used frequently in research and business, usually in close association with Semantic Web technologies, linked data, large-scale data analytics and cloud computing. The term "knowledge graph" is often mistakenly thought to have originated in 2012, when Google adopted it to describe its structured entity-attribute information, prominently featured on its search results pages. While Google's use of the term has significantly boosted its visibility and marketing appeal, the concept dates back much further. The phrase "knowledge graph" itself can be traced to the 1970s, and the underlying ideas go back even earlier.

There have been many efforts to clearly define . For now, a couple of sentences will do: a knowledge graph organizes data from multiple sources into a network of entities (nodes) and relationships (edges), with the meaning of the data encoded in an ontology so that both humans and machines can interpret it. Well-known examples include the and . The table below collects the most cited definitions from the literature, and I come back with a fuller synthesis at the end of the post once the underlying data models are on the table.

Different Types of Information Management Systems

To appreciate the uniqueness of knowledge graphs, it’s helpful to understand how they compare to other :

• : stores data in a row-based table structure which connects related data elements. An RDBMS includes functions that maintain the security, accuracy, integrity and consistency of the data.
• : de-normalised data stores that allow for analytical activities like count, aggregation, etc.
• : data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a dictionary or hash table.
• : stores data tables by column rather than by row. Benefits include more efficient access to data when only querying a subset of columns (by eliminating the need to read columns that are not relevant), and more options for data compression
• : uses graph structures for semantic queries with nodes, edges, and properties to represent and store data
• : data storage system designed for storing, retrieving and managing document-oriented information, also known as semi-structured data
• : optimized for handling time series data, i.e., data points indexed in time order
• : supports multiple data models against a single, integrated backend

Under the hood

The key difference between a graph and relational database is that relational databases work with sets while graph databases work with paths. This manifests itself in unexpected and unhelpful ways for a Relational Database Management System (RDBMS) user.

For example when trying to emulate path operations (e.g. friends of friends) by recursively joining in a relational database, query latency grows unpredictably and massively as does memory usage, not to mention that it tortures SQL to express those kinds of operations. More data means slower in a set-based database, even if you can delay the pain through judicious indexing.

Most graph databases don't suffer this kind of join pain because they express relationships at a fundamental level. That is, relationships physically exist on disk and they are named, directed, and can be themselves decorated with properties (the property graph model). This means if you chose to, you could look at the relationships on disk and see how they "join" entities. Relationships are therefore first-class entities in a graph database and are semantically far stronger than those implied relationships reified at runtime in a relational store.

tldr;

1. Graph databases are much faster than relational databases for connected data, a strength of the underlying model. A consequence of this is that query latency in a graph database is proportional to how much of the graph you choose to explore in a query, and is not proportional to the amount of data stored, thus defusing the .
2. Graph databases make modelling and querying much more pleasant meaning faster development

How to determine if Knowledge Graphs are what you need?

1. Is your Data Highly-Connected?

Graph solutions are focused on highly-connected data that comes with an intrinsic need for relationship analysis. If the connections within the data are not the primary focus and the data is of a transactional nature, then a graph database is probably not the best fit.

2. Is Retrieving the Data more Important than Storing it?

Graph databases are optimized for data retrieval and you should go with the graph database if you intend to retrieve data often. If your focus is on writing to the database and you’re not concerned with analyzing the data, then a graph database wouldn’t be an appropriate solution. A good rule of thumb is, if you don’t intend to use JOIN operations in your queries, then a graph is not a must-have.

3. Does your Data Model Change Often?

If your data model is inconsistent and demands frequent changes, then using a graph database might be the way to go. Because graph databases are more about the data itself than the schema structure, they allow a degree of flexibility.

On the other hand, there are often benefits in having a predefined and consistent table that’s easy to understand. Developers are comfortable and used to relational databases and that fact cannot be downplayed.

For example, if you are storing personal information such as names, dates of birth, locations… and don’t expect many new fields or a change in data types, relational databases are the go-to solution. On the other hand, a graph database could be useful if:

• Additional attributes could be added at some point,
• Not all entities will have all the attributes in the table and
• The attribute types are not strictly defined.

Graphs as data structures

A Graph is a non-linear data structure consisting of vertices and edges. The vertices are sometimes also referred to as nodes and the edges are lines or arcs that connect any two nodes in the graph. More formally, a knowledge graph as a directed labeled graph is a 4-tuple $G = (N, E, L, f)$, where $N$ is a set of nodes, $E \subseteq N \times N$ is a set of edges, $L$ is a set of labels, and $f: E \to L$ is an assignment function from edges to labels. An assignment of a label $B$ to an edge $E = (A, C)$ can be viewed as a triple $(A, B, C)$.

Types of Graphs

Graph theory distinguishes many kinds of graphs; the ones that matter for the rest of this post are:

• Undirected Graph: A graph in which edges do not have any direction. That is the nodes are unordered pairs in the definition of every edge.
• Directed Graph: A graph in which each edge has a direction. That is the nodes are ordered pairs in the definition of every edge.
• Labeled Graph: A graph where edges are labelled (they can carry properties for the relationships).
• Cyclic Graph: A graph containing at least one cycle.

You can also mix these types e.g., Directed Cyclic Graphs, Directed Labeled Cyclic Graphs, Directed Labeled Cyclic Multigraphs, etc. It is exactly such combinations, directed graphs with labelled edges, that the knowledge graph data models below build on.

Graphs as data models

Directed edge-labelled graphs

A directed edge-labelled graph (or multi-relational graph ⁷⁸⁹) is a set of nodes connected by directed, labelled edges. In knowledge graphs, nodes represent entities, and edges represent relationships between them.

Key Features

• Flexible Data Representation: Graphs allow for integrating new data sources more flexibly than relational databases, which require predefined schemas. Unlike hierarchical data models (e.g., XML, JSON), graphs allow cycles and avoid rigid hierarchical structuring.
• Bidirectional Edges: For clarity, bidirectional edges can represent two directed edges.
• Incomplete Data: Missing information can simply be omitted, such as when the graph lacks start/end dates for an event.

A standardised data model based on directed edge-labelled graphs is the which has been recommended by the for representing knowledge graphs on the web. The model defines different types of nodes, including which allow for global identification of entities on the Web; literals, which allow for representing strings (with or without language tags) and other datatype values (integers, dates, etc.); and blank nodes, which are anonymous nodes that are not assigned an identifier.

Everything in an graph is called a resource. “Edge” and “Node” are just the roles played by a resource in a given statement. Fundamentally in , there is no difference between resources playing an edge role and resources playing a node role. An edge in one statement can be a node in another.

There is a standard query language for Graphs called . It is both, a full featured query language and an HTTP protocol making it possible to send query requests to endpoints over HTTP. A key part of the standard is the definition of serializations. The most commonly used serialization format is called Turtle. There is also a JSON serialization called as well as an XML serialization. All databases are able to export and import graph content in standard serializations making it easy and seamless to interchange data.

Heterogeneous Graphs

A heterogeneous graph ¹⁰¹¹¹² (or heterogeneous information network ¹³¹⁴) is a directed graph where each node and edge is assigned one type. Heterogeneous graphs are similar to directed edge-labelled graphs, with edge labels corresponding to edge types, but they also include node types as part of the graph model.

An edge is called homogeneous if it connects two nodes of the same type and heterogeneous if it connects nodes of different types. Heterogeneous graphs allow partitioning nodes by their type, which is useful for machine learning tasks ^{10 11 12}.

In contrast, directed edge-labelled graphs support a more flexible model where nodes can have zero or multiple types.

Property Graphs

While there are core commonalities in property graph implementations, there is no true standard property graph data model. Each implementation of a Property Graph is, therefore, somewhat different. The following discusses the characteristics that are common for any property graph database.

Generally, the property graph data model consists of three elements:

• Nodes: The entities in the graph. Nodes can be tagged with zero to many text labels representing their type. Nodes are also called vertices.
• Edges: The directed links between nodes. Edges are also called relationships. The “from node” of a relationship is called the source node. The “to node” is called the target node. Each edge has a type. While edges are directed, they can be navigated and queried in either direction.
• Properties: The key-value pairs associated with a node or with an edge.

Property values can have data types. Supported data types depend on the vendor. For example, Neo4j data types are similar, but not identical, to Java language data types.

A key part of any data model is having a query language available for working with it. After all, users need to have a way to access and manipulate the data in the graph. For most of their history, property graphs had no industry standard query language. That finally changed in April 2024 when ISO published , the first new ISO database language since SQL. Vendor adoption is still uneven though, and in practice each database still offers its own query language that is incompatible with others:

• offers , also known as CQL: its own query language that, to some extent, took SQL as an inspiration.
• offers GSQL, its own query language that also took SQL as an inspiration.
• MS SQL Graph has their own extension to SQL to support graph query.
• Some vendors, in addition to their own query language, also implement some subset of Cypher. For example, SAP Hana offers its own extensions to SQL and its own GraphScript language plus they support a subset of Cypher.

There is also ; which is an open source graph computing framework that is integrated with some property graph and graph databases. It offers the Gremlin language which is more of an API language than a query language.

A key requirement for working with any data model is the ability to reference nodes, properties and relationships (edges). In the case of property graphs, internally, nodes and edges have IDs. IDs are assigned by a database and are internal to a database. Referencing is done by using text strings: node labels, relationship types, and property names.

RDF vs. Property Graph

In short: The main advantages of RDF

• The Data Model provides a richer, semantically consistent foundation over property graphs.

• Text values can also have language tags to support internationalisation of data. For example, instead of a single value for rdfs:label for New York City we could have multiple values such as:

  "New York City"@en

  "Nueva York"@es

• A key differentiator is how the underlying model (schema) is represented in the same way as the data. Just to serve as a primer, rdf:type is a predicate used to connect a resource with a class it belongs to; rdfs:label is used to provide a display name for a resource. The uniformity of the data model makes Graphs more easily evolvable and gives them more flexibility compared to Property Graphs.

• Enrichment Through Composition: With the inherent composability of Graphs, when two nodes have the same URI, they are automatically merged. This means that you can load different files and their content will be joined together forming a larger and more interesting graph.

• Having data in standard format allows for the ease of integration with the wealth of Open Data available e.g. DBpedia, Geonames, Open Corporates, etc.

• No vendor lock in, it's all open source and W3C Standards

So, in the end, what is a Knowledge Graph?

A Knowledge Graph is a connected data structure of data and associated metadata applied to model, integrate and access information assets. The knowledge graph represents real-world entities, facts, concepts, and events as well as the relationships between them. Knowledge graphs yield a more accurate and comprehensive representation of data.

Knowledge Graphs (KGs) have emerged as a compelling abstraction for organising the world’s structured knowledge, and as a way to integrate information extracted from multiple data sources. Knowledge graphs have started to play a central role in representing the information extracted using natural language processing and computer vision. Domain knowledge expressed in KGs is being input into machine learning models to produce better predictions.

The heart of the knowledge graph is a knowledge model: a collection of interlinked descriptions of concepts, entities, relationships and events where:

• Descriptions have formal semantics that allow both people and computers to process them in an efficient and unambiguous manner;
• Descriptions contribute to one another, forming a network, where each entity represents part of the description of the entities related to it;
• Diverse data is connected and described by semantic metadata according to the knowledge model.

Knowledge graphs combine characteristics of several data management paradigms:

• Database, because the data can be explored via structured queries;
• Graph, because they can be analysed as any other network data structure;
• Knowledge base, because they bear formal semantics, which can be used to interpret the data and infer new facts.

Knowledge graphs have a number of benefits over conventional relational databases and document stores. Specifically:

• A unified, single source of truth
• Flexible and highly adaptable data structure
• Can represent knowledge in any domain
• Wide range of tooling for data model definition and control
• Ability to link and enrich data
• Huge open source library of linked data
• The perfect playground for virtually all ML tasks

Knowledge graphs, represented in RDF, provide the best framework for data integration, unification, linking and reuse, because they combine:

• Expressivity: The standards in the Semantic Web stack (, and ) allow for a fluent representation of various types of data and content: data schema, taxonomies and vocabularies, all sorts of metadata, reference and master data. The  extension makes it easy to model provenance and other structured metadata.
• Performance: All the specifications have been thought out, and proven in practice, to allow for efficient management of graphs of billions of facts and properties.
• Interoperability: There is a range of specifications for data serialization, access ( Protocol for end-points), management ( Graph Store) and federation. The use of globally unique identifiers facilitates data integration and publishing.
• Standardization: All the above is standardized through the W3C community process, to make sure that the requirements of different actors are satisfied, all the way from logicians to enterprise data management professionals and system operations teams.

What is NOT a Knowledge Graph?

Not every graph is a knowledge graph. For instance, a set of statistical data, e.g. the GDP data for countries, represented in is not a KG. A graph representation of data is often useful, but it might be unnecessary to capture the semantic knowledge of the data. It might be sufficient for an application to just have a string ‘Italy’ associated with the string ‘GDP’ and a number ‘1.95 trillion’ without needing to define what countries are or what the ‘Gross Domestic Product’ of a country is. It’s the connections and the graph that make the KG, not the language used to represent the data.

Not every knowledge base is a knowledge graph. A key feature of a KG is that entity descriptions should be interlinked to one another. The definition of one entity includes another entity. This linking is how the graph forms. (e.g. A is B. B is C. C has D. A has D). Knowledge bases without formal structure and semantics, e.g. Q&A “knowledge base” about a software product, also do not represent a KG. It is possible to have an expert system that has a collection of data organized in a format that is not a graph but uses automated deductive processes such as a set of ‘if-then’ rules to facilitate analysis.

Why Knowledge Graphs are very exciting for ML?

Bringing knowledge graphs and machine learning together will systematically improve the accuracy of the systems and extend the range of machine learning capabilities. We are particularly interested in their applications in:

Data Insufficiency

Having a sufficient amount of data to train a machine learning model is very important. In the case of sparse data, Knowledge Graph can be used to augment the training data, e.g., replacing the entity name from original training data with an entity name of a similar type. This way a huge number of both positive and negative examples can be created using Knowledge Graph.

Zero-Shot Learning

Today, the main challenge with a Machine Learning model is that without a properly trained data it can not distinguish between two data points. In Machine Learning, this is considered as Zero-Shot Learning problem. This is where knowledge graphs can play a very big role. The induction from the Machine Learning model can be complemented with a deduction from the Knowledge Graph, e.g., where the type of situation did not appear in the training data.

Explainability

One of the major problems in machine learning industry is explaining the predictions made by machine learning systems. One issue is the implicit representations causing the predictions from the machine learning models. Knowledge Graph can alleviate this problem by mapping the explanations to some proper nodes in the graph and summarizing the decision-taking process.

Appendix

Graph DBMS vendors

The table below summarizes a point-in-time Gartner market guide from around 2021. This market moves fast, so treat it as a snapshot: products, licensing and pricing models change frequently, vendors get acquired and some products get retired altogether. Notable examples since the snapshot: RedisGraph reached end-of-life and was succeeded by , and Cambridge Semantics was acquired by Altair.