A follower network models a social platform as a graph of users and directed follow relationships. It supports questions about network structure and insights discovered through analysis. section 2.3 section 2.3.1
Represent each user as a User node and each follow interaction as a relationship from the follower to the followed user. A Twitter handle can uniquely identify a node; registration dates and follow dates can be stored as properties. section 2.3.1
Use these modeling decisions when designing the graph:
- Keep the relationship direction: one user may follow another without receiving a reciprocal follow. section 5.1
- Treat the focused network as monopartite because it contains one node type, User, and one relationship type, FOLLOWS. section 2.3.1 section 5.1
- Treat it as unweighted when follow relationships have no property measuring their strength. section 5.1
- Clarify node types, properties, identifiers, relationship types, direction, and relationship-qualifying properties before loading data. section 2.3.1
A Cypher follower pattern
(:User{id:"Vanessa", registeredAt:"2019-03-05"})-[:FOLLOWS{since:"2020-01-01"}]->(:User{id:"Thomas", registeredAt:"2011-03-05"}) section 2.3.1
(:User{id:"Vanessa", registeredAt:"2019-03-05"})-[:FOLLOWS{since:"2020-01-01"}]->(:User{id:"Thomas", registeredAt:"2011-03-05"})
Inspect a compact graph pattern showing node labels, unique identifiers, dates, relationship direction, and the FOLLOWS type. section 2.3.1
Once modeled, characterize connectedness and link density with Cypher and Neo4j Graph Data Science algorithms, including community detection and centrality methods. section 5.1
