Neo4j Relationship Naming Conventions for Similar Actions in Cypher

Question

I am aware of the absence of a constraint for naming relationships, though it is tough to get one guideline and work with it over all the relationships that we might encounter.

Would you go with something like this:

(u:User)-[:LIKES]->(p:Post)
(u:User)-[:LIKES]->(c:Comment)

and then query based on the label; Or something like this:

(u:User)-[:LIKES_POST]->(p:Post)
(u:User)-[:LIKES_COMMENT]->(c:Comment)

Another case is a threaded chat application where a User can start a thread with multiple other users, here's the structure I have in mind:

# the thread
CREATE (ct:ChatThread {created_at: timestamp()})

# the thread starter
(u:User {user: 1})<-[:IN_THREAD {type: 'owner'}]-(ct)

# members of the thread
(u:User {user: 2})<-[:IN_THREAD {type: 'member'}]-(ct)
(u:User {user: 3})<-[:IN_THREAD {type: 'member'}]-(ct)

Answer 1

I'll address the first example you posted:

(u:User)-[:LIKES]->(p:Post)
(u:User)-[:LIKES]->(c:Comment)

vs

(u:User)-[:LIKES_POST]->(p:Post)
(u:User)-[:LIKES_COMMENT]->(c:Comment)

This is essentially fine-grain vs. coarse-grain relationship ,as described in the Graph Databases book (ch. 4 - Building a Graph Database Application). Think about your usage:

• If you always want to query what a user likes, regardless whether it's Post or Comment, then LIKES works great.
• If you want to search specifically for a user's Posts, or a user's Likes, then fine-grain relationship types such as LIKES_POST work great. If you stayed with the more generic LIKES, you'd need to pay attention to the entity types in your filtering. And... if this list grows over time, you'll need to modify your queries to include the new types (and if this type list is unbounded, it could get a bit cumbersome).
• If you often mix it up, you may want to consider having both fine- and coarse-grain relationships between these nodes.