I simplified the implementation of the enhanced API, mostly removal of code duplication, and added support of a property value associated node. Looking for feedback, especially with regard to the defined interfaces. Use of the enhanced features of the API has consequences for the name/node space: Relationships: an additional property may be created on the relationship.PropertyTypes: may create nodes as a subref of the reference node.RelationshipTypes: may create nodes as a subref of the reference node.Properties: an additional property (per property) may be create on the node.
Niels > From: pd_aficion...@hotmail.com > To: user@lists.neo4j.org > Date: Fri, 22 Jul 2011 04:00:18 +0200 > Subject: Re: [Neo4j] Hyperedges and Objects > > > I uploaded the first edit (still needs to completely be tested - IS-PRE-ALPHA > quality) of the enhanced API. > > See: > https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/graphdb > > The enhanced API has several new features: > > > 1.) A new interface RelationshipContainer, supporting createRelation, > getRelation, and hasRelation methods. > > > 2.) Relationship implements RelationshipContainer so relationships to and > from relationships can be created. > A relationship property is maintained containing the node ID of an associated > node. This node is lazily created (and with that the relationship property is > set). > Relationships are stored on the associated node, while properties are stored > on the relationship itself. > > > 3.) EnhancedRelationshipType implements RelationshipContainer (and with that > PropertyContainer) so RelationshipTypes can have properties and relationships. > > A node associated with a RelationshipType is created lazily. From the > reference node a RELTYPE_SUBREF relation points to a node, containing > properties corresponding to RelationshipType names. The value of this > property is the node ID of the RelationshipType associated node. > > All relationships creation to and from a EnhancedRelationshipType and all > properties setting on a EnhancedRelationshipType are performed on the > associated node. > All retrievals are done from the associated node. > > The associated node is created the first time it is needed. > > 4.) PropertyType implements RelationshipContainer (and with that > PropertyContainer). PropertyTypes can be used in getProperty, setProperty and > hasProperty style operations. > > PropertyTypes are parameterized with the datatype of the property. This makes > it possible to support methods such as: <T> getPropertyValue(PropertyType) > and setProperty(PropertyType<T>, T) that guard property values added conform > to the datatype presumed by the PropertyType and property values are returned > typed. > > A node associated with a PropertyType is created lazily. From the reference > node a PROPTYPE_SUBREF relation points to a node, which points to nodes per > datatype. > These datatype related nodes contain properties corresponding to PropertyType > names. > > All relationships creation to and from a PropertyType and all properties > setting on a PropertyType are performed on the associated node. All > retrievals are done from the associated node. > > The associated node is created the first time it is needed. > > 5.) GraphDatabaseService allows for the lookup of PropertyTypes and > RelationshipTypes and enhanced Nodes and Relationships. > > > 6.) Property implements RelationshipContainer (and with that > PropertyContainer). //TODO > A node associated to a property is created lazily, allowing properties to > have relationships and properties. > The associated node is created the first time it is needed. > > With these enhancements, all elements of Neo4j (Node, Relationship, > RelationshipType, property name and property value) are unified, sharing a > common interface RelationshipContainer (and with that PropertyContainer). > Node and Relationship also extend their original interfaces, so the API is a > drop-in replacement for the original API. > > Both ProperyType and RelatioshipType now provide the necessary methods to > implement a type/class system on top of Neo4j, but nothing imposes a > type/class system. > > Being able to create Relationships to and from Relationships opens the way to > a transparent implementation of n-ary relationships. > > > This is all neat, I believe, but I would be really happy if there could be > some support in core to hide the implementation a bit more. > > Now: > > 1.) Relationships can have a property containing the node ID of the > associated node. This polutes the namespace, so it would be better if there > were a setLong and getLong method on Relationship, where the node ID can be > stored, keeping the property name away from the property namespace. > > 2.) Named persistent maps from String to PropertyContainer. This would > eliminate the REL_SUBREF related node and the PROP_SUBREF related nodes. It > would be nice if these enhancements didn't polute the node space. Named > persistent maps from String to PropetyContainer would also be helpful for > fast lookup of uris and generally for the creation of unique keys. > > Niels > > Date: Thu, 21 Jul 2011 20:38:15 +0200 > > From: matt...@neotechnology.com > > To: user@lists.neo4j.org > > Subject: Re: [Neo4j] Hyperedges and Objects > > > > Niels, > > > > sounds like fun. Looking forward to get a look at this > > > > 2011/7/21 Niels Hoogeveen <pd_aficion...@hotmail.com> > > > > > > > > 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 > > > > > > > > > > > -- > > Mattias Persson, [matt...@neotechnology.com] > > Hacker, Neo Technology > > www.neotechnology.com > > _______________________________________________ > > 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
