Following the Connections¶

Part 3: Exploring Your Knowledge Graph | Chapter 3 of 6

Prerequisites: Chapters 3.1 ("What Do I Actually Have?") and 3.2 ("Counting and Grouping")

Estimated time: ~20 minutes

Recap¶

In 3.2, you counted your edges. You know REQUIRES dominates (35 edges), IMPLEMENTS is a solid second (18), and CONTRADICTS barely shows up (4). You also grouped concepts by domain and sorted the results. Numbers on a page.

But counting edges is like counting roads on a map without ever driving on one. You know there are 83 roads. Great. Where do they go?

The Scenario¶

You found a concept called Dangerous Setters back in 3.1. It showed up when you searched descriptions for "setter." In 3.2, you counted how many edges it has. Now the real question: what does it actually connect to?

Not "how many connections." Which connections. In what direction. And how far can you follow them before you end up somewhere unexpected?

Time to stop counting arrows and start following them.

Outgoing Connections: Where Does DangerousSetters Point?¶

Let's start with the most direct question: what does DangerousSetters point TO?

MATCH (ds:Concept {name: 'Dangerous Setters'})-[r]->(target)
RETURN ds.name, type(r), target.name

Expected output:

Two outgoing edges. Two very different stories.

DangerousSetters challenges Encapsulation. That's a tension relationship: setters that expose internal state undermine the whole point of hiding it. And DangerousSetters enables InvalidState. That's a causal relationship: if you let anyone set fields directly, objects can end up in states that shouldn't exist.

Incoming Connections: What Points TO DangerousSetters?¶

Flip the arrow. What concepts point at DangerousSetters?

MATCH (source)-[r]->(ds:Concept {name: 'Dangerous Setters'})
RETURN source.name, type(r)

Expected output:

One incoming edge. Immutability contradicts DangerousSetters. Makes sense: if your objects are immutable, dangerous setters can't exist. Problem solved (well, different problems created, but that's Chapter 6's business).

The Three Relationship Patterns¶

You've now used two of the three ways to match relationships. Here they all are, side by side:

That third one, the undirected pattern, is the "I don't care about direction" version. Useful when you want to see the full neighborhood:

MATCH (ds:Concept {name: 'Dangerous Setters'})-[r]-(neighbor)
RETURN ds.name, type(r), neighbor.name

This returns all three connections: Encapsulation, InvalidState, AND Immutability. Outgoing and incoming, all in one query.

In Memgraph Lab, the graph visualization shows the same structure:

Zooming in reveals the concept names and relationship types:

That's the full 1-hop neighborhood of DangerousSetters. Three concepts, three relationships, three different stories.

Relationship Properties: What the Edge Knows¶

Edges aren't just labels. They carry data. Let's see what's hiding on those relationships:

MATCH (ds:Concept {name: 'Dangerous Setters'})-[r]->(target)
RETURN type(r), target.name, r.confidence, r.source_text

Expected output:

r.confidence tells you how certain the extraction was that this relationship exists. r.source_text gives you the passage it was derived from. These properties are your provenance trail: when someone asks "why does the graph say DangerousSetters challenges Encapsulation?", you can point directly to the source text.

Going Deeper: Variable-Length Paths¶

One hop is fine for immediate neighbors. But the interesting stuff lives further out.

Here's the question: starting from DangerousSetters, what can you reach in two hops?

MATCH path = (ds:Concept {name: 'Dangerous Setters'})-[*1..2]->(target)
RETURN [n IN nodes(path) | n.name] AS chain,
       [r IN relationships(path) | type(r)] AS edges,
       length(path) AS hops

That [*1..2] is the magic syntax. It means "follow 1 to 2 edges."

Expected output:

Wait. Look at that last row.

DangerousSetters ENABLES InvalidState, and InvalidState CAUSES ProductionBug. Two hops. A direct causal chain from "I used a naive setter" to "something broke in production."

That chain is invisible if you only look one hop out. You'd see DangerousSetters connects to InvalidState and shrug. Two hops reveals the consequence.

The 2-Hop Neighborhood¶

Here's the full picture of everything within 2 hops of DangerousSetters, in any direction:

DangerousSetters is the red node at the center. Follow two hops out and you reach Properties, ProductionBug, Class Invariant. Follow the incoming edge and you find Immutability. The graph tells a story that no single concept tells alone.

Path Objects: Storing and Inspecting¶

When you write MATCH path = ..., you're capturing the entire trail in a variable. That variable holds the nodes, the relationships, and the order they appeared. You can pull it apart:

MATCH path = (ds:Concept {name: 'Dangerous Setters'})-[*1..2]->(target)
RETURN path,
       nodes(path) AS all_nodes,
       relationships(path) AS all_rels,
       length(path) AS hops

This is where we earn the word "path." You've been following arrows this whole chapter, tracing connections hop by hop. A path is just the formal name for that trail: an ordered sequence of nodes and relationships from start to finish.

Finding a Path to a Specific Target¶

Sometimes you know where you want to end up. You just don't know how to get there.

Is there a connection between DangerousSetters and ClassInvariant? Let's find out:

MATCH path = shortestPath(
  (ds:Concept {name: 'Dangerous Setters'})-[*]-(inv:Concept {name: 'Class Invariant'})
)
RETURN [n IN nodes(path) | n.name] AS chain,
       [r IN relationships(path) | type(r)] AS edges,
       length(path) AS hops

Expected output:

Two hops. DangerousSetters enables InvalidState, which violates ClassInvariant. The setter isn't directly connected to the invariant, but the path through InvalidState makes the relationship crystal clear.

Falsifiable claim: The path from DangerousSetters to ClassInvariant exists in 3 hops or fewer. You just verified it: 2 hops. Even shorter than claimed.

And now, the longer chain. Remember the hint from the 2-hop neighborhood?

MATCH path = (ds:Concept {name: 'Dangerous Setters'})-[*1..5]->(pb:Concept {name: 'Production Bug'})
RETURN [n IN nodes(path) | n.name] AS chain,
       [r IN relationships(path) | type(r)] AS edges,
       length(path) AS hops
ORDER BY hops

Expected output:

There it is. DangerousSetters to ProductionBug in 2 hops. A naive setter method, through the intermediate concept of InvalidState, leads straight to a production incident. The graph made the causal chain explicit.

The Three Aha Moments¶

Let's name what just happened:

1. DangerousSetters CHALLENGES Encapsulation but ENABLES InvalidState. One concept, two outgoing edges, two completely different stories. The relationship type changes everything.

2. The path from DangerousSetters to ClassInvariant is only 2 hops. They're not directly connected, but the chain through InvalidState makes the link obvious. This is exactly the kind of implicit connection that flat search misses.

3. There's a path from DangerousSetters to ProductionBug through InvalidState. A junior dev adds a setter. The graph already knows where that leads. Two hops to a production incident.

Path Visualization: The Causal Chain¶

Here's the full trail, laid out as a chain:

Dangerous Setters ──ENABLES──> InvalidState ──CAUSES──> ProductionBug
                                    │
                                    └──VIOLATES──> Class Invariant

One starting point. Two consequences. The graph doesn't just store concepts: it stores the implications of concepts.

What You Learned¶

• Relationship direction matters. (a)-[r]->(b) and (a)<-[r]-(b) are different questions with different answers.
• Edges carry properties. r.confidence and r.source_text give you provenance, not just labels.
• Variable-length paths ([*1..N]) reveal chains that single-hop queries can't see.
• Path objects store the full trail: nodes, relationships, and order. Use nodes(path), relationships(path), and length(path) to inspect them.
• shortestPath() finds the most direct route between two concepts you already know about.

Exercises¶

Exercise 1: The Full 2-Hop Neighborhood¶

Problem: Find all concepts that DangerousSetters connects to within 2 hops, in either direction. Return the concept name and how many hops away it is.

MATCH path = (ds:Concept {name: 'Dangerous Setters'})-[*1..2]-(target:Concept)
WHERE ds <> target
RETURN DISTINCT target.name, min(length(path)) AS hops
ORDER BY hops, target.name

Exercise 2: Shortest Path Between Properties and Encapsulation¶

Problem: Find the shortest path between Properties and Encapsulation. Return the concept chain and relationship types.

MATCH path = shortestPath(
  (p:Concept {name: 'Properties'})-[*]-(e:Concept {name: 'Encapsulation'})
)
RETURN [n IN nodes(path) | n.name] AS chain,
       [r IN relationships(path) | type(r)] AS edges,
       length(path) AS hops

Exercise 3: Relationship Types from DangerousSetters¶

Problem: List all distinct relationship types that appear in paths starting from DangerousSetters, up to 3 hops out (outgoing direction only).

MATCH path = (ds:Concept {name: 'Dangerous Setters'})-[*1..3]->(target)
UNWIND [r IN relationships(path) | type(r)] AS rel_type
RETURN DISTINCT rel_type, count(*) AS appearances
ORDER BY appearances DESC

Next Up¶

You can follow paths now. You can trace connections forward, backward, and through multiple hops. But what about the concepts that don't have connections? What if you want to find the gaps, the orphans, the concepts that should be connected but aren't?

That's filtering by pattern. Chapter 3.4.