Perhaps we can also add to this enhanced API: * creation of nodes and rels with a initial map of properties, with optional auto-indexing of some of those properties * a getOrCreate method * fluent, chained API for creating stuff in a readable language * getRelationshipCount() * some more that I forgot :)
Michael, pulling his wishlist Am 21.07.2011 um 20:32 schrieb Niels Hoogeveen: > > i made a start on this. It's not all too difficult to enhance relationships > such that relationships can be created upon them, which is a first step > towards supporting hypergraphs. In fact hypergraphs are more constrained than > an enhanced graph that supports the creation of relationships on > relationships. > As it stands now, the enhanced graph can work as a drop-in replacement of the > standard neo4j API and has enhanced methods that mirror the standard methods. > I also added support for typed properties, such that methods like <T> > getPropertyValue<PropertyType<T>> are possible where <T> is one of the data > types supported by PropertyContainer. > I will upload this within the next few days. > Niels > > > From: pd_aficion...@hotmail.com > To: user@lists.neo4j.org > Subject: RE: [Neo4j] Hyperedges and Objects > Date: Mon, 18 Jul 2011 17:59:08 +0200 > > > > > > > > > I think a hypergraph would be an interesting collection to support in > neo-graph-collections. If I find the time, I will make a start with it this > week, unless there are of course other volunteers :wink: willing to do the > lifting here. > Niels > >> From: michael.hun...@neotechnology.com >> Date: Sat, 16 Jul 2011 23:37:48 +0200 >> To: user@lists.neo4j.org >> Subject: Re: [Neo4j] Hyperedges and Objects >> >> I completely agree, >> >> hyperedges and the accompanying traversers should be handled in a library. >> As you probably know the traversal framework currently also uses the core >> API under the hood to perform the traversals (and no black magic (yet)). >> >> So it should be fairly easy to take that approach/code and create a library >> that abstracts the hyper-edge issues (creation, deletion, traversal). The >> position semantics based approach sounds interesting. >> >> Would love to see that as community contribution. >> >> Cheers >> >> Michael >> >> Am 16.07.2011 um 23:08 schrieb Niels Hoogeveen: >> >>> >>> The question is how much easier a traverser can become when there were >>> dedicated hyper edges. In a binary relation it is fairly easy to define one >>> end of the relation as the source and the other as the target (start and >>> end node), >>> but in n-ary relationships the roles of the attached nodes become more >>> complicated. >>> >>> Suppose we have the GIVES relationship, where one attached node takes the >>> role of subject (the giver), >>> one node takes the role of direct object (the gift), and another node takes >>> the role of indirect object (the recipient). >>> To traverse such a graph, we need to know these different roles, otherwise >>> we may end up traversing the wrong nodes. >>> >>> Suppose we the following statements: >>> >>> John gives Paul a servant. >>> Paul visited Albania. >>> Paul's servant visited Albania. >>> >>> We now want to know all people that received a gift from John and who >>> visited Albania. >>> >>> Without properly denoting the roles in the ternary relationship stated by >>> "John gives Paul a servant", >>> the answer to the query may well be: Paul and Paul's servant. >>> Both are persons, both have visited Albania and both are part of the GIVES >>> relationship defined. >>> >>> When we have to define the exact roles of each part of an n-ary >>> relationship for each traversal, >>> it is just as complicated as defining a traversal based on binary >>> relationships, >>> where different relationship types denote the roles of each part of the >>> n-ary relationship. >>> >>> If hyperedges were to be introduced, either as a library or in core, >>> the entire notion of the graph and how traversals are performed need to be >>> rethought. >>> >>> The concept of an edge as having a start and an end node doesn't translate >>> well into the world of hyper edges. >>> There is not necessarily a start node and an end node, >>> instead there are various nodes that are distinctly attached to the hyper >>> edge. >>> >>> One way to think about an edge in both the graph and in the hypergraph >>> world is as a tuple. >>> >>> A binary relationship can be thought of as the tuple: >>> >>> (node1, node2, RelationshipType, Set(property)) >>> >>> A ternary relationship can be thought of as the tuple: >>> >>> (node1, node2, node3, RelationshipType, Set(property)) >>> >>> etc... >>> >>> Instead of marking a binary relationship as outgoing or incoming, we can >>> use the position in the tuple to denote its role. >>> We can say the first node in the tuple corresponds to the start node, and >>> the second node in the tuple corresponds to the end node. >>> Having two possible permutations relates to the two possible directions an >>> edge can have. >>> >>> Position based definitions of relationships translate well into the domain >>> of n-ary relationships, >>> though the semantics of such relationships can easily become difficult. >>> A ternary relationship already has 6 permutations for the attached nodes, >>> while a 10-ary relationship has 3,628,800 possible permutations. >>> >>> It would be an interesting project to design a tuple-position-based >>> traverser. >>> For binary relationships it should have the exact same features as the >>> current direction based traverser, >>> but it would be possible to generalize that design to n-ary relationships. >>> This can all be done as a libary. >>> >>> Only when perfomance can be really improved in core, does it make sense to >>> request for native support. >>> >>> Niels >>>> Date: Sat, 16 Jul 2011 19:31:22 +0200 >>>> From: ntausc...@gmail.com >>>> To: user@lists.neo4j.org >>>> Subject: Re: [Neo4j] Hyperedges and Objects >>>> >>>> That's clear. Such mappings are more difficult to traverse since the >>>> traverser has to know if there is such a hyper edge vertex. I'm >>>> wondering if there is no need to provide an embedded solution for such a >>>> transformation. Each user who is confronted with hyper edges has to >>>> implement some kind of such mapping. It would be helpful, for example, >>>> if each Neo4j relationship can manage hyper edges automatically and >>>> provide an additional 'isHyper' method pointing out that there are >>>> additional methods allowing to get all further incident nodes. This is >>>> also a matter of performance. I think such a handling is implemented >>>> most efficiently within the Neo4j engine. >>>> >>>> Best regards >>>> >>>> Norbert Tausch >>>> >>>> Am 16.07.2011 00:52, schrieb Niels Hoogeveen: >>>>> Hyper edges can be emulated. >>>>> Suppose you want to store the fact "John gives Pete a book". >>>>> This is indeed a ternary relationship, which would call for an hyper edge. >>>>> This fact can be stored as follows: >>>>> Some act of giving --Giver-->JohnSome act of giving --Recipient--> >>>>> PeteSome act of giving --Gift--> book >>>>> N-ary relationships can generally be decomposed into N binary >>>>> relationships, where a central node is used to used as a placeholder for >>>>> the N-ary relationship. >>>>> Complex types can either be stored into a byte array or if appropriate in >>>>> multiple properties. >>>>> >>>>> >>>>>> Date: Sat, 16 Jul 2011 00:04:15 +0200 >>>>>> From: ntausc...@gmail.com >>>>>> To: user@lists.neo4j.org >>>>>> Subject: [Neo4j] Hyperedges and Objects >>>>>> >>>>>> Hi, >>>>>> >>>>>> is there a possibility to store hyper edges in Neo4j? Is there a plan to >>>>>> implement this? >>>>>> >>>>>> Will Neo4j get the ability to store complex types in addition to >>>>>> primitve data types for properties of nodes and relationships? >>>>>> >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Norbert Tausch >>>>>> >>>>>> _______________________________________________ >>>>>> Neo4j mailing list >>>>>> User@lists.neo4j.org >>>>>> https://lists.neo4j.org/mailman/listinfo/user >>>>> >>>>> _______________________________________________ >>>>> Neo4j mailing list >>>>> User@lists.neo4j.org >>>>> https://lists.neo4j.org/mailman/listinfo/user >>>> _______________________________________________ >>>> Neo4j mailing list >>>> User@lists.neo4j.org >>>> https://lists.neo4j.org/mailman/listinfo/user >>> >>> _______________________________________________ >>> Neo4j mailing list >>> User@lists.neo4j.org >>> https://lists.neo4j.org/mailman/listinfo/user >> >> _______________________________________________ >> Neo4j mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
