I took the criticism to heart and rewrote the Wiki page once more. I hope the concept is now a little bit easier to grasp. It could however still need an edit by someone other than me. After all, nothing of what is written is fresh for me. I also got rid of the EdgeElements. Niels
> From: [email protected] > To: [email protected] > Date: Fri, 12 Aug 2011 17:09:51 +0200 > Subject: Re: [Neo4j] Enhanced API wiki page > > > Hi Peter, > > I have given your criticism that the API is too heavy to grasp some more > thought. > > I do agree with your assessment that it is heavy to grasp, but don't really > know how to make it simpler. > N-ary edges (Hyperrelationships) are complex beasts compared to Relationships > as defined in the standard Neo4j API. > In another post I already showed how BinaryEdge, as a one-on-one mapping of > Relationship in standard Neo4j API, > is only one of 16 possible two-sided Edges. > > This added complexity automatically translates into having to deal with more > classes. > > Instead of just Nodes, Relationships and RelationshipTypes, we now have to > deal with: > Vertices, Edges, EdgeTypes, Connectors and ConnectorTypes. > > For the n-ary case, there is no other way to deal with this. Of course we > could give things a different name, > as I have done a couple of times now, but no matter how you slice it, when > you want to create an n-ary edge, > you will have to provide the vertices to connect. > Not only do you have to provide these vertices, it is also imperative you > tell where on the edge to place those vertices. > > This is relatively simple in the case of a BinaryEdge, where we use the > method Vertex#createEdgeTo(Vertex, RelationshipType). > We only have two Vertices we want to add to the Edge, one of them connecting > to the StartConnector, > the other connecting to the EndConnector. So in this particular case the > choice of Connector can be made implicitly. > > With arities > 2 no such implicit choice of Connector can be made, and with > that the entire machinery comes into play. > We will need something akin to EdgeType, because that determines the type of > Connectors available to an Edge. > We need something akin to a Connector, otherwise we don't know were on the > Edge to create a connection. > We also need something akin to an EdgeElement, otherwise we can't create an > Edge in a legal state. > I don't think it's smart to allow the user to create a ternary edge, where > only one or two sides are connected, > just like it's not allowed to create a Relationship in the standard API with > one dangling side. > > I am totally open to renaming things, but I don't think it is possible to > really reduce the number of entities involved. > As to the names chosen: Connection, Connector, ConnectorType and > ConnectionMode follows a neat pattern. > There is a Connection, something between a Vertex and an Edge, which is made > to a Connector on that Edge. > That connector has a type, which defines the Mode of that > connector/connection. > Initially Connector was named EdgeRole, but that didn't allow the same naming > pattern. > It's possible to have EdgeRole, EdgeRoleType and EdgeRoleMode, but there is > no proper variation on the word EdgeRole > that can be used for the denotation of the connection between a Vertex and an > Edge. > > Instead of Connection, Connector, ConnectorType, ConnectorMode, > we could use Association, Associator, AssociatorType, AssociatorMode, but I > don't know if that makes things simpler. > > The term EdgeElement is not all the descriptive and I am very much open to > suggestions for a better name. > It's a class we need when creating n-ary edges. There needs to be some method > that creates an Edge, > which should have a signature: createEdge(EdgeType, > SomethingThatAssociatesVerticesWithAConnectorType...); > > I have chosen the name EdgeElement instead of > SomethingThatAssociatesVerticesWithAConnectorType, > but I am not all that happy with that name either. > > Altogether, n-ary edges are more general than Relationships and with that > users of the API > need to get acquainted with a couple of more concepts that are left implicit > with standard Relationships. > It's simply impossible to generalize Relationships to n-ary edges without > revealing the underlying complexity. > > The Wiki page as I have set up now, may need to do more explaining of > concepts. > It may be that I moved too quickly, that's the down-side of a > one-man-project. > Things that have become self-evident to me over time may be difficult to > grasp for someone new to this model. > So, if there are people that see value in having support for n-ary edges in > an API on top of Neo4j, > please help me out with some of the documentation. A fresh look on things may > be helpful to explain things better. > > Niels > > From: [email protected] > > Date: Thu, 11 Aug 2011 20:46:59 +0200 > > To: [email protected] > > Subject: Re: [Neo4j] Enhanced API wiki page > > > > Nils, > > interesting approaches! However, IMHO the API is still too heavy to > > grasp with ConnectorType, EdgeElement, EdgeType and Edge being > > involved in creating connections between facts. Is anyone seeing a > > more fluent/concise approach to this? Also, did you have some ideas > > about how to traverse or query these hyperedges? > > > > 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 Wed, Aug 10, 2011 at 1:19 AM, Niels Hoogeveen > > <[email protected]> wrote: > > > > > > Today I updated the wiki page for Enhanced API. Since the last edit many > > > changes have taken place, so it was to to reflect those changes on the > > > wiki page. > > > > > > See: https://github.com/peterneubauer/graph-collections/wiki/Enhanced-API > > > > > > I also changed what was previously called an "EdgeRole" into a > > > "Connector". > > > > > > Every Edge has a number of Connectors to which Vertices connect. > > > > > > The EdgeType of an Edge defines the ConnectorTypes of the Connectors of > > > an Edge. > > > > > > Each ConnectorType and with that a Connector, has a ConnectionMode, which > > > can be one of these four: > > > > > > Unrestricted: An Edge can connect to an unlimited number of Vertices > > > through a Connector with an unrestricted mode, and a Vertex can have an > > > unlimited number of connected Edges with a ConnectorType with an > > > unrestricted ConnectionMode. > > > Injective: An Edge can connect to only one Vertex through a Connector > > > with injective mode, but a Vertex can have an unlimited number of > > > connected Edges with a ConnectorType with an injective ConnectionMode. > > > Surjective: An Edge can connect to an unlimited number of Vertices > > > through a Connector with a surjective mode, but a Vertex can only have > > > one Edge connected to it with a ConnectorType with a surjective > > > ConnectionMode. > > > Bijective: An Edge can connect to only one Vertex through a Connector > > > with bijective mode, and a Vertex can only have one Edge connected to it > > > with a ConnectorType with a bijective ConnectionMode. > > > All ConnectionModes have been implemented. > > > > > > The switch from EdgeRole to Connector with ConnectionModes has eliminated > > > some of the more annoying type parameters found in the previous > > > incarnation of Enhanced API. > > > > > > > > > _______________________________________________ > > > Neo4j mailing list > > > [email protected] > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
