I solved the node typing problem using http://wiki.neo4j.org/content/Design_Guide#Subreferences . This worked out well for starting traversals over all nodes of a particular type. Many of my traversal problems can be solved easily with a Pathfinder initialized with two subreference nodes to get all paths between two types. For cases in which I need a particular node of a particular type, I hit a node index.
~/Bobby On Thu, May 5, 2011 at 3:22 PM, Niels Hoogeveen <pd_aficion...@hotmail.com>wrote: > > 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
