Knowledge Graphs a Visual Introduction

Get into the basics of Knowledge Graphs in the most simplest way

Graphs are everywhere — in social networks, recommendation systems, even in how concepts connect in your brain. But what exactly is a knowledge graph and how do we work with one as a developer?

In this guide, we’ll take a visual and code-friendly approach to explore how knowledge graphs work, starting with the absolute basics.

Graph Terminology

Before we start building graphs, let’s get familiar with a few basic terms. These concepts will help you understand how graph data is structured and how relationships work between different entities (nodes).

Meet the Graph Elements

The DNA of a Graph: Nodes, Relationships and Properties

What the Diagram Shows

This diagram is a visual representation of a graph using the Labeled Property Graph (LPG) model. Let’s break it down:

Each circle represents a node — in this case, two people:

• One labeled :Person with a name property "Alice"
• Another labeled :Person with a name property "Bob"

The arrow between them represents a relationship:

• It’s labeled FRIEND, showing the type of connection between the nodes
• The arrow direction tells us that Alice is friends with Bob

Relationship Direction

• Directed graph: Relationships have a direction — like “User Jane follows User Joe”.
• Undirected graph: Relationships go both ways — like “User Joe is friends with User Jane”.

Relationship Weight

• Unweighted graph: Relationships are just present or not — no extra data.
• Weighted graph: Relationships carry a number or score — for example, “User Jane liked 10 of User Joe’s posts”.

Graph Shape

• Simple graph: Only one relationship between any two entities; no self-links.
• Multigraph: Multiple relationships allowed between the same entities — e.g., knows, loves, and visited between the same two users.
• Complete graph: Every node is connected to every other node. Rare in real life, but useful for learning.

Types of Entities (Nodes)

• Monopartite graph: All nodes are the same kind — like a person graph.
• Bipartite graph: Two kinds of nodes — like person and organization. Relationships only happen across the two types.

Representing Graphs in Text: Cypher Basics

Before diving into graph models, it’s helpful to know how to represent a graph in plain text. One popular way to do this is with Cypher, a query language designed specifically for working with graphs. If you’ve never heard of it, think of Cypher as the graph version of SQL — but instead of tables, you work with nodes and relationships.

Cypher uses a simple, intuitive syntax to describe graph patterns using text. It’s also the foundation for the upcoming Graph Query Language (GQL) standard, which aims to unify how we query graph data across systems.

Nodes

Syntax: (:Label {propertyKey: value})

Example: (:Person {name: "Alice"})

Explanation:

• () surrounds a node.
• :Person is the label (type of entity).
• Properties go inside {}, e.g. {name: "Alice"}.

Relationships

Syntax: -[:TYPE {propertyKey: value}]->

Example: -[:FRIEND {since: 2003}]->

Explanation:

• [] wraps the relationship type.
• :FRIEND describes the kind of connection.
• {} holds relationship properties.
• Arrow shows direction.

Full Pattern Example

Syntax:
(:Person {name: "Alice"})-[:FRIEND]->(:Person {name: "Bob"})

Meaning: Alice is friends with Bob

A side-by-side comparison

Text to Graph: What Cypher Actually Describes

The Labeled Property Graph Model (LPG)

The labeled property graph (LPG) model is a flexible and developer-friendly way to represent data as a graph. It structures information in terms of nodes, relationships, labels and properties — and is widely used in graph databases like Neo4j.

What Makes Up a Labeled-Property Graph?

An LPG graph consists of:

Nodes: Represent entities in your data, like people, organizations or tweets.

Labels: Each node can have one or more labels to describe its role or category, such as Person or Company.

Properties: Nodes and relationships can have key–value pairs attached to them, like name: "Alice" or since: "2021".

Relationships: Connect two nodes and always have:

• A direction
• A type (e.g., FRIENDS_WITH, WORKS_FOR)
• Optional properties, such as since: 2020

Your First Graph Example

Let’s model the following simple information:

Alice and Bob are friends. Alice works at a company called Acme Corp.

🧠 As you look at this example, try to ask yourself: What is a node? What’s a label? What should be a property? And what kind of thing deserves to be its own relationship?

We can come to the following conclusions:

• Who are the entities? → Alice, Bob, and Acme Corp → these are nodes
• What kind of things are they? → People and a company → labels
• What connects them? → Friendship and employment → relationships
• What details are relevant? → Names, start dates → properties

Extending the Model: What If We Add More Data?

Now imagine we also want to include phone numbers, social security numbers and addresses.

• In many cases, you might store things like a phone number directly as a property of the Person node.
• But what if your goal is to find people sharing the same phone number or address? Then it’s better to model these as separate nodes connected by relationships.

Modeling Tips: How to Decide What’s a Node, Property, or Label?

There’s no single “correct” way to model a graph. It depends on:

• Your goal
• Your queries
• Your domain

Here are some guiding questions to help you decide:

• Will I search/filter by this value often? If yes, you might want to make it a node or property.
• Can multiple entities share this value? If yes, consider using a shared node.
• Is it a fixed category or type? If yes, using a label could be the way to go.
• Do I need metadata about the connection? If yes, you might want to use a relationship with properties.

Wrapping Up: From Graph Basics to Your First Model

By now, you’ve taken your first visual steps into the world of knowledge graphs — understanding what graphs are, how to describe them using simple terms, and how to model real-world relationships using the Labeled Property Graph (LPG) approach.

You learned how:

• Graphs can represent people, places, and concepts as nodes
• Relationships are directional, can carry meaning and data, and connect entities together
• You can describe graphs visually

And most importantly, you began to see how modeling decisions shape the kinds of questions your graph can answer.

👣 Where to Go Next

As you move forward:

• Think about your own domain or data: Who are the entities? What connects them?
• Try sketching your own graph on paper — labels, arrows, and properties included.
• Explore graph tools like Neo4j, Memgraph or Kuzu and play with sample datasets.
• Start querying graphs using Cypher to see how structure meets logic.

Graphs aren’t just for data scientists — they’re for anyone who wants to connect the dots more intuitively. Whether you’re working with social networks, recommendation systems, customer journeys or even content tagging, knowledge graphs offer a powerful and flexible way to think in connections.