Hi, Tobias.
Thanks for your thoughts and ideas. My requirement is not only to know the "type" of something, but also to store metadata for "types" so that I can catalog the "property type" of each individual property in a node for a given "type". It's a bit complicated, but we are allowing very dynamic declarative "types" that will not have an explicit compiled Java class wrapper for each "type" (we will have a generic wrapper that deals with the "dynamic" type, and some explicit wrapper for pre-defined entities). The main reason is that we need to deal with a few data types beyond the Java primitives and String(s). For example, we want to be able to know contextually that a property is a "timestamp" or a "hyperlink". Thus the need for the extra (but relatively simple) metadata. It might be useful to identify a commonly use subset of addition property types that correspond to, for example, the most common RDBMS data types and XML schema types. This might include date, time, datetime, link, and so on. Since at the persistence level it appears that a property is saved along with an integer enumeration of its "simple type", perhaps there is an extensibility model that could be implemented to allow these application-specific types to be created and managed. I know that would be problematic, though, given that the current implementation is an enumeration. No worries though, since there are perfectly good workarounds/alternatives using relationships. Cheers, Rick -------- Original Message -------- Subject: Re: [Neo] Type metadata in properties/nodes From: Tobias Ivarsson <tobias.ivars...@neotechnology.com> Date: Wed, December 09, 2009 5:39 am To: Neo user discussions <user@lists.neo4j.org> Associating nodes with a type node is a good approach, especially if you want to be able to do queries like "give me all nodes of type X". But for knowing the semantic type of a node when found through a general traversal I prefer to use the navigational context of the node. For example if I have a Person-node I know that the node at the other end of a FRIEND-relationship will be a Person-node as well. Or if I have i Car-node I know that the node at the other end of a OWNER-relationship will be either a Person or a Company, both of which probably have enough in common for me to be able to get an address (for sending them the parking ticket or what ever), if I need to specifically know if it's a Person or a Company, I could use some property for that information (or check the relationship to a type node), but most of the semantic information would be known from how I reached the node. I have added a note about this to the FAQ in the wiki. Cheers, Tobias On Tue, Dec 8, 2009 at 10:22 PM, Rick Bullotta < rick.bullo...@burningskysoftware.com> wrote: > Thanks, Peter. Good info. I think we ended up with a hybrid approach: we > modeled a set of "Type" nodes (related to a master "Types" node), each of > which includes the type metadata (property/type data) for a specific > "type". > "Instance" nodes then maintain a two-way relationship with their associated > "Type" node so that any node can quickly obtain its Type node and so we can > easily traverse all instances of a specific type...and we may end up > extending this such that the properties themselves are each a node of their > own, in some cases, where we need to be able to relate/search/traverse at a > very detailed level. I suppose that depends on the performance > implications > of having lots more nodes and relationships. > > In any case, it definitely seems "do-able" with Neo. > > > > > -----Original Message----- > From: user-boun...@lists.neo4j.org [[1]mailto:user-boun...@lists.neo4j.org] > On > Behalf Of Peter Neubauer > Sent: Tuesday, December 08, 2009 3:25 PM > To: Neo user discussions > Subject: Re: [Neo] Type metadata in properties/nodes > > Hi Rick, > there are a number of interesting approaches to this, involving both > ways to retain the metadata: > > 1. RDF and OWL > - basically, every node will maintain a relationship to its type node > (your shadow node), something like x?--RDF:TYPE-->type_node which > contains info on what the type is, what properties etc. > > 2. Neo4j Meta package ([2]http://components.neo4j.org/neo-meta/) > - this is the concept of describing the type of things in code (Java > in this case) and thus in code enforce the restrictions and type > conversions on properties through the code. This does not capture any > meta info in the graph but is easy to do. > > 3. Annotate the nodes with type info > - in this approach, there is a "type" or "classname" property on any > node that is used to derive the type to deserialize/serialize the > object into, the rest of the meta info is contained in the upper code > layers. Andreas Ronges JRuby bindings are using this approach. > > 4. Encode everything into a String property > - this approach means shuffling everything into a string property, > basically treating properties as BLOBs. Works in some cases, but > certainly locks down your data in these properties. > > What is best depends on your domain, and there might be more > approaches out there. I sense that you are asking even for an > extensible type system especially on properties. That is not in scope > of the core graph engine, but I am not sure if in theory it would be > possible to extend the property type system, we would need to discuss > that separately. > > Cheers, > > /peter neubauer > > COO and Sales, Neo Technology > > GTalk: neubauer.peter > Skype peter.neubauer > Phone +46 704 106975 > LinkedIn [3]http://www.linkedin.com/in/neubauer > Twitter [4]http://twitter.com/peterneubauer > > [5]http://www.neo4j.org - Relationships count. > [6]http://gremlin.tinkerpop.com - PageRank in 2 lines of code. > > > > On Tue, Dec 8, 2009 at 8:43 PM, Rick Bullotta > <rick.bullo...@burningskysoftware.com> wrote: > > I can see how relationships could be used to map "is a duck." typing, but > > I'm struggling with how to infer type from properties. In particular, > while > > anything could be stuffed into a String, it loses important semantics > when > > you do so. I'm not referring to *storage* as a String, which makes > plenty > > of sense - it's that the type identity of the source property is lost if > you > > do so. I could maintain a "shadow node" of the type metadata that could > be > > related to each instance with a property name/property type array, but > that > > seems like something that would be useful within the node model itself. > > > > > > > > Types like DateTime, hyperlinks, and so on, while quite easily storable > in > > Neo4J, lose useful semantics on the way in. I'd welcome your thoughts on > > how others have managed this type of scenario and other techniques for > "meta > > tagging" nodes and properties with type or other semantic info. > > > > > > > > Thanks, > > > > > > > > Rick > > > > _______________________________________________ > > Neo mailing list > > User@lists.neo4j.org > > [7]https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > [8]https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > [9]https://lists.neo4j.org/mailman/listinfo/user > -- Tobias Ivarsson <tobias.ivars...@neotechnology.com> Hacker, Neo Technology [10]www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list User@lists.neo4j.org [11]https://lists.neo4j.org/mailman/listinfo/user References 1. http://email02.secureserver.net/#Compose 2. http://components.neo4j.org/neo-meta/ 3. http://www.linkedin.com/in/neubauer 4. http://twitter.com/peterneubauer 5. http://www.neo4j.org/ 6. http://gremlin.tinkerpop.com/ 7. https://lists.neo4j.org/mailman/listinfo/user 8. https://lists.neo4j.org/mailman/listinfo/user 9. https://lists.neo4j.org/mailman/listinfo/user 10. http://www.neotechnology.com/ 11. https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
