Personally I think that since the direction is built into the relationship, and the concept of a relationship is already a 'verb', I think both the 'IS' (or 'HAS') and the 'OF') are redundant. I vote for: father --(CHILD)--> son or alternatively father <--(PARENT)-- son
Clean, simple, consistent :-) Since I use a lot of tree structures, I use this pattern a lot. I also find that the choice of direction is a very meaningful concept, and should be chosen carefully, based on your 'whiteboard' view of the data (which is correlated to your most likely queries of the data). In my case a common query is getting 'children' of nodes for a dynamic tree view, and so the parent--(CHILD)-->node pattern is a natural fit. By the way, the issue of redundancy is visible in both the Java API, and even more so in the Ruby API: father.getRelationships(CHILD,Direction.OUTGOING) father.relationships.outgoing(:CHILD) (Note that the direction is very explicit in the API, so no need to repeat it in the relationship type) On Fri, Nov 20, 2009 at 10:10 AM, Mattias Persson <matt...@neotechnology.com > wrote: > The names IS_PARENT and IS_SON doesn't really explain which direction > it is, right? A better naming would be IS_PARENT_OF or IS_SON_OF. Then > you would immediately see which direction they have. But if you choose > to go with the father or son naming is up to you, whatever feels more > natural. > > 2009/11/19 Anders Nawroth <and...@neotechnology.com>: > > Hi and welcome Matt! > > > >> What is the best way to design this type of relationship? What direction > is > >> best to use? > >> > > > > The one that makes the most sense to you in your code, I think! Or > > rather: how would you draw this on a whiteboard when explaining the > > application domain to someone?! In my case I'd go with HAS_CHILD > > relationships as this direction feels more natural to me. > > > > There's no need to add relationships twice to cover the directions, as > > Neo4j can traverse both incoming and outgoing relationships or simply > > ignore their direction (that is use Direction.BOTH or leave the > > direction unspecified). > > > >> I noticed in the matrix example, relationships point from Neo to the > other > >> characters. > > > > Even if Neo4j relationships always have a start node and an end node > > (and a direction) it's up to the application to decide what semantics > > goes with this. In the Matrix example the KNOWS relationship likely > > should count as undirected, as someone you know also knows you. The > > CODED_BY relationship is different, as the direction of it is really > > significant. > > > >> Is there also a relationship from the reference node to Neo, or > >> does Neo point to the reference node? > >> > > > > There are different variations of this example, both with and without a > > relationship from the reference node to the Thomas Andersson/Neo node. > > This one has such a relationship: > > http://wiki.neo4j.org/content/The_Matrix > > > > For real applications it often a good idea to add a few nodes that are > > used as "subreference nodes" - have a look here: > > http://wiki.neo4j.org/content/Design_Guide#Organizing_your_Nodespace > > > > > > /anders > > > > > > -- > > Anders Nawroth [and...@neotechnology.com] > > GTalk, Skype: anders.nawroth > > Phone: +46 737 894 163 > > http://twitter.com/nawroth > > http://blog.nawroth.com/ > > > > _______________________________________________ > > Neo mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > -- > Mattias Persson, [matt...@neotechnology.com] > Neo Technology, www.neotechnology.com > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user