I see. I realized that this was what you were after. What I was proposing was that you would know the types for the properties given the type of the node. The types for the nodes in your case would be more abstract, perhaps just defined by the set of properties. I used concrete types in my explanation because it usually helps people understand what I mean with utilizing the navigation context.
I had a suspicion that your particular application might not benefit from this approach, but I wanted to throw it into the mix for the sake of completeness of the discussion, since there are a lot more people reading the list than writing in a particular thread. Cheers, Tobias On Wed, Dec 9, 2009 at 2:02 PM, <rick.bullo...@burningskysoftware.com>wrote: > 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 > -- Tobias Ivarsson <tobias.ivars...@neotechnology.com> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
