A bipartite graph divides nodes into two sets. Relationships run across the sets, not within either set. A retail graph, for example, can connect User nodes to Item nodes with BOUGHT relationships; it does not need direct User-to-User links to reveal similar purchasing behavior. This shape is useful when the meaningful connection is an interaction: rating a movie, buying a product, voting on a law, or attaching a hashtag to a tweet. section 1.2.3 section 2.1.3
Model node labels and relationship types close to the domain. A user–tweet graph can use User and Tweet nodes with an active-voice PUBLISH relationship. Choose one direction and use it consistently: native graph-database traversal can follow the relationship in either direction, so adding a redundant reverse relationship adds no semantic value. section 2.3.2 section 2.4.2
Bipartite graphs support analysis in two common ways:
- Compare nodes indirectly through their shared neighbors. Customers who buy similar items, or users who listen to similar genres, can be treated as similar without a direct relationship. section 1.2.3 section 7.2.2
- Project either node set into a monopartite graph. Tweets sharing a hashtag can receive SIMILAR relationships; hashtags appearing in the same tweets can receive co-occurrence relationships. section 2.4.2 section 7.0
- Run algorithms that expect connected, single-type networks after projection. PageRank on the original directed tweet–hashtag shape can produce unhelpful results because influence cannot flow through both node types. section 7.0
Projecting hashtag co-occurrence
Start with the indirect pattern `(:Tweet)-[:HAS_TAG]->(:Tag)<-[:HAS_TAG]-(:Tweet)`. For every pair of tags used by the same tweet, create a direct co-occurrence relationship: `MATCH (s:Tag)<-[:HAS_TAG]-(:Tweet)-[:HAS_TAG]->(t:Tag) CREATE (s)-[:CO_OCCURRENCE]->(t);` The resulting tag network makes shared use explicit. Its relationship meaning is domain-specific: CO_OCCURRENCE emphasizes shared tweets, while SIMILAR can emphasize inferred likeness. section 2.4.2 section 7.0
Jaccard similarity provides a weighted version of this projection. For each hashtag, collect the tweets containing it; for each pair of hashtags, divide the size of the shared-tweet set by the size of the combined set. Store that score on an inferred relationship if needed. The same idea applies to baskets with overlapping products or users with overlapping musical genres. section 7.2.1 section 7.2.2
When using Neo4j Graph Data Science node similarity, relationship orientation determines which nodes are compared. With `HAS_TAG` stored from Tweet to Tag, reversing it during graph projection compares tags by their tweet neighborhoods rather than tweets by their tag neighborhoods. Parameters such as `similarityCutoff` and `topK` control which inferred relationships remain in the projected network. section 7.2.2
Follow the visual transformation from tweet–hashtag links to direct tweet similarity relationships; the same projection choice can be made for hashtags instead. section 2.4.2
