Practice bipartite projections

Quick recap: Why preserve labels?

In the previous lessons, you learned:

For Node Similarity, preserving labels matters because the algorithm compares nodes within each partition based on their shared connections across the partition. GDS needs to know which nodes belong to which partition.oan

The movies dataset

Your database contains several bipartite structures:

Each of these is naturally bipartite: one node type connects only to the other, never to itself.

Projection 1: User-Movie bipartite

Let’s start with the User-Movie projection from the previous lesson. Run this command to create a labelled bipartite network:

MATCH (source:User)-[r:RATED]->(target:Movie) // (1)
WITH gds.graph.project( // (2)
  'user-movie', // (3)
  source, // (4)
  target, // (5)
  {
    sourceNodeLabels: labels(source), // (6)
    targetNodeLabels: labels(target), // (7)
    relationshipType: type(r) // (8)
  },
  {}
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (9)

What you’ve created:

CALL gds.nodeSimilarity.write( // (1)
  'user-movie', // (2)
  {
    writeRelationshipType: 'SIMILAR_USER', // (3)
    writeProperty: 'score' // (4)
  })
YIELD nodesCompared, relationshipsWritten // (5)

MATCH path = (u1:User)-[:SIMILAR_USER]->(u2:User)-[:RATED]->(m:Movie) // (1)
RETURN path // (2)
LIMIT 10 // (3)

Projection 2: Actor-Movie bipartite

Now create a different bipartite projection: Actors and Movies.

Complete the projection by replacing the ???? placeholders:

MATCH (source:????)-[r:????]->(target:????) // (1)
WITH gds.graph.project( // (2)
  'actor-movie', // (3)
  source, // (4)
  target, // (5)
  {
    sourceNodeLabels: ????, // (6)
    targetNodeLabels: ????, // (7)
    relationshipType: ???? // (8)
  },
  {}
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (9)

MATCH (source:Actor)-[r:ACTED_IN]->(target:Movie) // (1)
WITH gds.graph.project( // (2)
  'actor-movie', // (3)
  source, // (4)
  target, // (5)
  {
    sourceNodeLabels: labels(source), // (6)
    targetNodeLabels: labels(target), // (7)
    relationshipType: type(r) // (8)
  },
  {}
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (9)

What you’ve created:

Now run Node Similarity:

CALL gds.nodeSimilarity.write( // (1)
  'actor-movie', // (2)
  {
    writeRelationshipType: 'SIMILAR_ACTOR', // (3)
    writeProperty: 'score' // (4)
  })
YIELD nodesCompared, relationshipsWritten // (5)

Verify the results:

MATCH (a1:Actor)-[s:SIMILAR_ACTOR]->(a2:Actor) // (1)
RETURN a1.name AS actor1, a2.name AS actor2, s.score AS similarity // (2)
ORDER BY s.score DESC // (3)
LIMIT 10 // (4)

What this reveals: Actors who frequently appear in the same movies—collaboration clusters in the film industry.

Projection 3: Movie-Genre bipartite

Now create a bipartite projection of Movies and Genres, then run Node Similarity. Complete both steps yourself.

Step 1: Create the projection by replacing the ????? placeholders:

MATCH (source:?????)-[r:?????]->(target:?????) // (1)
WITH gds.graph.project( // (2)
  'movie-genre', // (3)
  source, // (4)
  target, // (5)
  {
    sourceNodeLabels: ?????, // (6)
    targetNodeLabels: ?????, // (7)
    relationshipType: ????? // (8)
  },
  {}
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (9)

Step 2: Run Node Similarity on your projection:

CALL gds.nodeSimilarity.write( // (1)
  'movie-genre', // (2)
  {
    writeRelationshipType: '?????', // (3)
    writeProperty: 'score' // (4)
  })
YIELD nodesCompared, relationshipsWritten // (5)

MATCH (source:Movie)-[r:IN_GENRE]->(target:Genre) // (1)
WITH gds.graph.project( // (2)
  'movie-genre', // (3)
  source, // (4)
  target, // (5)
  {
    sourceNodeLabels: labels(source), // (6)
    targetNodeLabels: labels(target), // (7)
    relationshipType: type(r) // (8)
  },
  {}
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (9)

CALL gds.nodeSimilarity.write(
  'movie-genre',
  {
    writeRelationshipType: 'SIMILAR_MOVIE',
    writeProperty: 'score'
  })
YIELD nodesCompared, relationshipsWritten

Verify the results:

MATCH (m1:Movie)-[s:SIMILAR_MOVIE]->(m2:Movie) // (1)
RETURN m1.title AS movie1, m2.title AS movie2, s.score AS similarity // (2)
ORDER BY s.score DESC // (3)
LIMIT 10 // (4)

What this reveals: Movies that share genre classifications—content-based similarity for recommendations.

How bipartite structure determines similarity

Each projection you created uses the same algorithm but produces different results because the bipartite structure determines what "shared neighbours" means:

The key insight: Node Similarity doesn’t define what "similar" means—your projection structure does. The algorithm simply finds nodes that share neighbours across the bipartite divide.

Bipartite projections vs monopartite transformations

In Lesson 4, you created monopartite projections by transforming bipartite structures:

In this lesson, you created labelled bipartite projections that preserve both node types:

When to use each approach:

Both approaches are valid—choose based on your algorithm and analytical goals.

What’s next

You’ve practiced creating labelled bipartite projections and running Node Similarity on each one.

Each projection used the same bipartite-aware algorithm but revealed different insights:

In the next lesson, you’ll put this knowledge to the test with a challenge that requires you to design your own projection and choose the appropriate approach—monopartite transformation or labelled bipartite—based on your analytical goal.