Sorry meant Niels of course ;) Sent from my iBrick4
Am 05.05.2011 um 22:35 schrieb Michael Hunger <michael.hun...@neotechnology.com>: > 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
