Practice monopartite projections

The movies dataset

Your database contains:

Projection 1: Actor collaboration network

Remember this projection you created in the previous lesson, connecting actors to actors.

Run it again to create an actor-to-actor network:

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

This projection creates:

What this reveals: Actor communities, collaboration patterns, degrees of separation between actors.

MATCH (source:?????)<-[:ACTED_IN]-(:????)-[:ACTED_IN]->(target:?????) // (1)
WITH gds.graph.project( // (2)
  'movies-only', // (3)
  ????, // (4)
  ???? // (5)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (6)

MATCH (source:Movie)<-[:ACTED_IN]-(:Actor)-[:ACTED_IN]->(target:Movie) // (1)
WITH gds.graph.project( // (2)
  'movies-only', // (3)
  source, // (4)
  target, // (5)
  {}, // (6)
  {} // (7)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (8)

Projection 2: User network through shared ratings

In the graph, you have User nodes with RATED relationships to Movie nodes. See if you can create a monopartite graph of only Users and their relationships to each other.

Remember, you need the Movie nodes to get users' shared connections. However, you do not want to include Movie nodes in the projection

Replace ???? with the appropriate Cypher query to complete the projection.

MATCH ???? // (1)
WITH gds.graph.project( // (2)
  'user-interaction-network', // (3)
  source, // (4)
  target, // (5)
  {}, // (6)
  {} // (7)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (8)

MATCH (source:User)-[:RATED]->(:Movie)<-[:RATED]-(target:User) // (1)
WITH gds.graph.project( // (2)
  'user-interaction-network', // (3)
  source, // (4)
  target, // (5)
  {}, // (6)
  {} // (7)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (8)

This projection creates:

What this reveals: User communities with similar tastes, recommendation opportunities.

MATCH ???? // (1)
WHERE ???? // (2)
WITH gds.graph.project( // (3)
  '?????', // (4)
  ?????, // (5)
  ????? // (6)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (7)

MATCH (source:Genre)<-[:IN_GENRE]-(:Movie)-[:IN_GENRE]->(target:Genre) // (1)
WITH gds.graph.project( // (2)
  'genre-cooccurrence', // (3)
  source, // (4)
  target // (5)
) AS g
RETURN g.graphName AS graph, g.nodeCount AS nodes, g.relationshipCount AS rels // (6)

Understanding algorithm results

Each of the graphs you just projected continues to exist in memory.

You can run mutliple algorithms on each one to compare results.

Run the command below to see how degree centrality ranks the Movies in the 'movies-only' graph.

CALL gds.degree.stream('movies-only') // (1)
YIELD nodeId, score // (2)
RETURN gds.util.asNode(nodeId).title AS movie, score AS collaborations // (3)
ORDER BY score DESC // (4)
LIMIT 10 // (5)

The first movie returned is called "Backdraft". There’s a good chance you have never heard of that movie. So, you may wonder why degree centrality ranks it as 'most important'.

Up to now, we have used 'most important' to explain the intention of centrality algorithms — and it’s not entirely incorrect. It is, however, missing context.

It is the most important movie in terms of its relationships' intent. In this case, that intent is actor collaborations.

So, we could predict perhaps that, although 'Backdraft' may not be as famous as, say, 'The Matrix', it should contain a lot more famous faces.

It’s true, we have some high degree centrality actors in there, including:

There are many more, who may have lesser start power, but whose connections to movies which do are more numerous than most.

Take a look for yourself on IMDb.

The key takeaway here is that 'importance' or 'centrality' only matter in terms of the relationships analyzed. In this case, we have not returned the most important or central movies in terms of user ratings, or cultural influence.

Instead, its result is more relevant to the movie business itself. It answers 'Which movies contained the most important actor-to-actor collaborations overall'.

If you had asked someone on the street, they are very unlikely to have guessed 'Backdraft'.

Remember, degree centrality measures the number of outgoing relationships each node has.

PageRank does the same, except it weights each node’s score relative to the score of its neighbors. Run PageRank on this graph, and you might be less surprised by the result.

CALL gds.pageRank.stream('movies-only') // (1)
YIELD nodeId, score // (2)
RETURN gds.util.asNode(nodeId).title AS movie, score AS collaborations // (3)
ORDER BY score DESC // (4)
LIMIT 10 // (5)

You have another graph waiting in memory: 'user-interaction-network'.

It is composed of User to User relationships through Movie nodes.

Replace the graph name below to run the PageRank algorithm on this graph:

CALL gds.pageRank.stream( // (1)
  '?????' // (2)
)
YIELD nodeId, score // (3)
RETURN gds.util.asNode(nodeId).name AS user, score AS centrality // (4)
ORDER BY score DESC // (5)
LIMIT 10 // (6)

The resulting table provides you with a breakdown of the most 'important' users in terms of their movie ratings.

This is also a great example of the difference between PageRank and degree centrality.

Run degree centrality on the same graph to compare the results—the algorithm syntax is provided, just add the graph name:

CALL gds.degree.stream( // (1)
  '?????' // (2)
)
YIELD nodeId, score // (3)
RETURN gds.util.asNode(nodeId).name AS user, score AS centrality // (4)
ORDER BY score DESC // (5)
LIMIT 10 // (6)

Remember, degree centrality merely counts the outgoing relationships of the nodes — PageRank weights those relationships in terms of other nodes in the graph.

So, while 'Angela Garcia' may have rated the most movies overall, 'Zacahry Carey' is the most important user when weighted in terms of other important users.

What’s next

You’ve now practiced creating multiple monopartite projections from the Movies dataset — simply by modifying the initial Cypher query used to generate the graph.

Each projection transforms multipartite data (Actor-Movie, User-Movie, Movie-Genre) into monopartite networks for specific analyses.

In the next lesson, you’ll put this knowledge to the test with a challenge that requires you to create your own monopartite projection.