Hi Lundin, thanks for your suggestion and the linked article.
You're right, the example I posted is relatively easy and I guess, different relationship types are meaningful for this example. To give you an example of a more complex ontology, have a look at BioPAX (http://www.biopax.org/owldoc/Level3/). Let me explain a little bit more: BioPAX is an ontology - normally used to exchange biological network data - which consists of several biological Interaction classes like Conversion, TemplateReaction, Catalysis, BiochemicalReaction, Transport, and so on and so forth. Based on the Interaction class, entities (a protein, gene) are attached by different relationship types, e.g. in a Conversion by "left" and "right", in a TemplateReaction by "template" and "product" or in a Catalysis by "controller", "controlled", and "cofactor". Let's suppose you want to find a path between two biological entities (e.g. a protein or gene). Since you don't know if the path consists of BiochemicalReactions or Transports or Conversions etc., you have to allow all relationship types mentioned above, which is a list of at least 8 different types. At this stage, I thought about hierarchies for relationship types. For example the relationship superclass could be the type "participates". The first subclasses might be "educt", which has itself the two subclasses "left" (in case of a conversion) and "template" (in case of a TemplateReaction), and product (Conversion: right, TemplateReaction: product). This would allow to find paths between entities allowing to traverse all relationship of type "participates". It is not possible to say "allow all directions and types" since there are a lot of other relationship (types) that should not be traversed not mentioned here. I think for this case it might be easier to have only the relationship type "participates" and use the property map for the subclasses in case you wan to specify the path more precisely. But my question is, is there a more elegant way to do this? I heard of an approach, storing the relationship types as nodes in the graph itself. The queries will be of two steps: first get all relationship types that are subclasses and second, use this retrieved list as input for the query. It would be nice if you (or someone else) can comment this. Thanks, Benny Am Samstag, 19. April 2014 18:18:49 UTC+2 schrieb Lundin: > > Hi Benny, > > In your examples, which seems to have an very finite numbers of > relationships types, i would go for adding relationship vs properties. Thus > the traversal can be done cheap rather than involve properties that would > be needed in the look-up. This is the best design performance wise. But of > course if your domain-model involves nodes that becomes dense with millions > of outgoing relationship and the number of relationship cant so easily be > forseen and you want query from that node i would think adding a properties > make sense. > > Here is actually a good blog post on the topic: > http://graphaware.com/neo4j/2013/10/24/neo4j-qualifying-relationships.html > > It is very hard without further insight to say exactly how to model your > domain. > > And dont fortget that you can also limit the serach result by a type as > well, as in > > (x)-[r]->(y) where type(r)="IS_DAUGHETR_OF" > > Mabey you could test some CSV data of a known domain, import it and try > some models and find out ? I would be happy to read such a report. > > Den onsdagen den 16:e april 2014 kl. 14:09:48 UTC+2 skrev Benny Kneissl: >> >> Hi, >> >> as far as I know the smartest way to store hierarchies for node entities >> is to use the new label feature. Lets's suppose an entity is of type B >> where B is a subclass of A. Then the node is labeled by both A and B, right? >> >> But what about hierarchies for relationships? Should several >> relationships be stored between two entities to model hierarchies for >> relationships? Should the type of the relationship differ or is it more >> meaningful to have the same type but different properties? >> >> A possible example is that "isDaughterOf", "isSonOf" are subtypes of >> "isChildOf" when modeling a family tree. Or from biology when having a >> BiochemicalReaction you might want to model "isParticipantOf", "isEductOf", >> "isProductOf". >> >> In this simple hierarchy I think it is sufficient when asking for all >> children to traverse both relationship types, but the hierarchy might >> become more complex and then, it is likely that you forget one relationship >> type in Cypher ( (x)-[r:IS_DAUGHTER_OF | IS_SON_OF]->(y) ). If you use >> only one type ((x)-[r:IS_CHILD_OF]->(y)) you have to add a property >> daughter / son to ask only for daughter/son. So what is a good way >> (performance, complexity in formulating a query) to do it in Neo4j? Adding >> more relationships, or adding more properties? >> >> Currently I don't know what are the advantages for the different >> approaches, in particular, with respect to formulate queries afterwards. >> >> Thank you for some ideas you have in mind, >> >> Benny >> > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
