I agree it can be valuable to assign a type to a node. In my own work I do that, but we may have very different needs with regards to typing. In the application I have built, I use relationships to make nodes an instance of one or more types, while node types can be subtype of one or more other node type. This does not lead to a singular type, but in fact to a type-forest. Each type can have an associated trait (I am working in Scala) that will be mixed in when creating an instance. On runtime the type-forest is flattened and a signature for the instance is generated based on this list of type names. Based on this signature a class for the instance is dynamically created by means of the Scala interpreter (unless the same class has already been created, in which case it is simply looked up in the classloader), where all defined traits are mixed into the instance. Having a fixed singular type doesn't solve my modeling needs. First of all each instance may be an instance of more than one type, but furthermore, due to the subtyping relations in my type system, a node may have a different type signature, because someone made some modification somewhere in the type hierarchy. It would be most unpleasant if all instances of a type need to be updated because somewhere a super type was added or removed. It is precisely the decoupling of data store and schema that makes neo4j such a powerful platform. My typing needs may be very different from yours, and i can imagine scenarios where one would even prefer the use of an inference engine (using eg. Pellet, Drools, Jena or Prolog) to determine the type of a node based on a possibly complex set of rules. In such a scenario things can become even more complicated because the type of a node may depend on the value of a property, the existence of a relationship or even the value of a property of a related node or a relationship defined on such a node (eg. someone becomes a grand parent when a child begets a child). Having static types would entail updating type information of possibly many nodes, simply because the value of a property changes or a relationship somewhere in the graph is removed or added. It is not possible to accommodate all those needs within the neo4j kernel, so it's better to leave it out altogether. For your application it may be nice to have a type label attached to a node. In my application it would be just ballast, because the only reasonable label I can think of would be "node", something that doesn't add any information.
> From: rick.bullo...@thingworx.com > To: user@lists.neo4j.org > Date: Thu, 5 May 2011 10:25:58 -0700 > Subject: Re: [Neo4j] First-class "type" property on relationships but not > nodes; why? > > Respectfully disagree. In many domains, it is valuable to know the "type" of > the domain object a node represents "in situ" with no knowledge whatsoever of > its place in the graph relative to other nodes. > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On > Behalf Of Niels Hoogeveen > Sent: Thursday, May 05, 2011 1:22 PM > To: user@lists.neo4j.org > Subject: Re: [Neo4j] First-class "type" property on relationships but not > nodes; why? > > > I think the basic confusion surrounding this issue stems from the term > RelationshipType. It is not a type, but just a key to the relationships value > store (resulting in nodes). > When you consider a node as a consisting of two maps, one from property keys > to property values and one from the tuple (RelationshipType, Direction) to a > node, you see there is actually no type there, only keys. From a navigational > point of view there is no need for a name for a node, because each node > already has a name relative to the node pointing to it (the name of the > relationship, unfortunately labeled RelationshipType). > When you work in Java or any other language supporting maps, you can add > entries to map keys to maps (this is essentially what a relationship does, it > maps a key (name + direction) to a list of maps). In those scenarios you > don't care about a name for that map either. It is accessible through the > keys which can be assigned specifically for each entry, making it much more > flexible than using a fixed singular name. > The addition of type labels for nodes doesn't make the implementation more > consistent, since there is no way to directly navigate from a node to another > node (you always need a relationship for that). A property key is there to > find a property relative to a node. A relationship label (unfortunately named > RelationshipType) is there to find a node relative to another node. For > consistency reasons there is no need for additional labels, keys or names. > > From: rick.bullo...@thingworx.com > > To: user@lists.neo4j.org > > Date: Thu, 5 May 2011 08:51:59 -0700 > > Subject: Re: [Neo4j] First-class "type" property on relationships but not > > nodes; why? > > > > I would say that the same is true of a "type" on a node - it could be a > > significant performance optimization, depending on how properties are > > loaded vs the "node itself". If it saves a major step by not having to > > search around in property "stuff", there's an immediate advantage. Also, I > > suspect that many (most) people would store "type" properties as string(s) > > (we don't, but that's only because we've basically implemented node type as > > a special kind of enum, similar to relationship type), the various > > performance issues related to string storage/retrieval exist. > > > > Also, the very essence of a "type" on a node creates a basic sort of > > atomicity in terms of knowing what a node "represents", given only its node > > id, with no dependencies on relationships for facilitating type identity > > (though we use relationships in our model as a form of "implementation > > inheritance" similar to Tobias' comments on the subject). > > > > I really think that there are enough potential benefits to at least > > consider a native "type" concept it for the future, if for no other reason > > that uniformity of implementation, though I suspect there will be inherent > > performance optimizations and new types of traversals made possible and > > faster. > > > > The good (great) news is that the flexibility and capability of Neo4J as it > > already exists allows us to model all of these scenarios today! > > > > > > -----Original Message----- > > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On > > Behalf Of Craig Taverner > > Sent: Thursday, May 05, 2011 10:08 AM > > To: Neo4j user discussions > > Subject: Re: [Neo4j] First-class "type" property on relationships but not > > nodes; why? > > > > Another view of things would be to say that ideally there should be no first > > class type on either relationships or nodes, since that is a domain specific > > concept (as Neils says he wants two types, but Rick wants one, and some > > object models type nodes by relating them to a separate node representing a > > class). > > > > Then the addition of a type to a relationship is, in my opinion, a > > performance optimization for many graph algorithms since the traverser will > > perform well if it has 'first class' access to this information, instead of > > hitting the property store. I guess this is my take on Tobias point that the > > type is a navigational feature. > > > > Now I wonder if the traverser, and many known graph algorithms, would be > > possible to make faster or easier to code if the nodes also had first class > > types? I don't know the answer to this, but assume that if it did really > > help, it would have been done already ;-) > > > > On Thu, May 5, 2011 at 3:52 PM, Niels Hoogeveen > > <pd_aficion...@hotmail.com>wrote: > > > > > > > > The meta model component (though in need of some attention), already > > > allows > > > the typing of a node. An important difference between the typing in the > > > meta > > > model component and the suggestion made in this thread is the fact that a > > > node according to the meta model can have more than one type, while the > > > RelationshipType in kernel only allows one type per relationship. > > > For my modeling need, the ability to assign more than one type per node is > > > essential. Adding a singular type at kernel level would only make things > > > more confusing. > > > I would go further than what Tobias says and would say RelationshipType is > > > nothing but a name, just like various properties have names. Types would > > > require much more information, like cardinality, source/target constraints > > > etc. Those are all part of the meta model where they belong. > > > > > > > From: tobias.ivars...@neotechnology.com > > > > Date: Thu, 5 May 2011 15:33:04 +0200 > > > > To: user@lists.neo4j.org > > > > Subject: Re: [Neo4j] First-class "type" property on relationships but > > > > not > > > nodes; why? > > > > > > > > The RelationshipType isn't a type. It is a navigational feature. > > > > > > > > I've slapped this link around for a few years now, every time this > > > question > > > > has been brought up: > > > > http://lists.neo4j.org/pipermail/user/2008-October/000848.html > > > > > > > > The fact that RelationshipType is a navigational feature and not a type > > > > means that there is in fact already a corresponding thing for nodes: the > > > > Indexes. > > > > > > > > But I agree that there would be things we could gain by adding a Type > > > > concept to Nodes. Such as for example better automatic indexing. But I > > > don't > > > > know what it would look like. And I want it to be clear that such a > > > feature > > > > is very different from what RelationshipType is today. > > > > > > > > Cheers, > > > > Tobias > > > > > > > > On Thu, May 5, 2011 at 10:29 AM, Aseem Kishore <aseem.kish...@gmail.com > > > >wrote: > > > > > > > > > I've found it interesting that Neo4j has a mandatory "type" property > > > > > on > > > > > relationships, but not nodes. Just curious, what's the reasoning > > > > > behind > > > the > > > > > design having this distinction? > > > > > > > > > > If you say "you need to know what type of relationship these two nodes > > > > > have", I would reply, "don't you also need to know what type of nodes > > > they > > > > > are, as well?" > > > > > > > > > > Similarly, if you say "because there can be many different types of > > > > > relationships", I would reply, "there can also be many different types > > > of > > > > > nodes, and in both cases, there doesn't need to be". > > > > > > > > > > A perfect example is in the documentation/tutorial: movies and actors. > > > Just > > > > > the fact that we talk about the nodes in the database as "movies" and > > > > > "actors" -- wouldn't it be helpful for the database to support that > > > > > categorization first-class? > > > > > > > > > > To be precise, it's easy for us to add a "type" property to nodes > > > ourselves > > > > > (we do in our usage), but it's not a first-class property like > > > > > relationships, where queries and traversals can easily and naturally > > > > > specify > > > > > the type or types they expect. > > > > > > > > > > Thanks! > > > > > > > > > > Aseem > > > > > _______________________________________________ > > > > > Neo4j mailing list > > > > > User@lists.neo4j.org > > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > > > > > > > > > > > > > -- > > > > Tobias Ivarsson <tobias.ivars...@neotechnology.com> > > > > Hacker, Neo Technology > > > > www.neotechnology.com > > > > Cellphone: +46 706 534857 > > > > _______________________________________________ > > > > 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
