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 PARTICIPANT. 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 PARTICIPANT. 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 PARTICIPANT 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 Mittwoch, 16. April 2014 14:09:48 UTC+2 schrieb 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.
