Cool Nils, where should it live? Some own package or? Cheers,
/peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Thu, Jul 21, 2011 at 8:32 PM, Niels Hoogeveen <pd_aficion...@hotmail.com> wrote: > > 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
