Nils that sounds interesting do you share the type mapping code for scala somewhere?
Michael Sent from my iBrick4 Am 05.05.2011 um 22:22 schrieb Niels Hoogeveen <pd_aficion...@hotmail.com>: > > 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
