Graph database design principles, general principles and granularity issue

In relational database design, there are normal forms to guide the design process. Are there similar prinicples that apply to the design of graph databases like neo4j?

In particular, I'm puzzled by the issue granularity: I could design a graph database where most attributes are stored in the vertices (a contact has attributes name, birth date, ...) or I could store most data i开发者_Python百科n relationships (connecting the contact with a "firtst name" relationship to another vertex holding the actual information) or I could do both (then of course issues of consistency arise, but it may speed up retrieval times).

These issues are similar to my beginner questions when I started SQL design and many of the issues could only be resolved by gaining experience. Still can you recommend a good, practical book on the very basics of this topic or point me to where to find some general principles?

There isn't anything I've seen that is taken as truth quite like normalization in relational databases. However, I'd advocate two things:

1) Model your entities (nodes) as you normally would. The attributes of those entities are things that belong specifically to those entities and exist outside of relations (connections).

2) Model your relationships (edges) as you normally would. Those attributes should not exist except where two entities (nodes) are related (connected).