Honestly, like Rick, I do tend to use a type parameter. One advantage is that other tools (like neoclipse for example) can visualize the generic graph and color code, or add icons, based on that parameters.
For indexing, I tend to only add lucene indexes for identity properties (like a name or id) to help find some key starting points and then traverse from there. Often I use traversers only, since my graphs are always linked in some way to the root node. It all depends on your use case and query. If you only have five trucks, you might as well traverse to them. If you have five hundred, index the name. In general a well structured graph is in fact an index :-) On Fri, Nov 5, 2010 at 7:57 PM, Andrew Serff <li...@serff.net> wrote: > Craig, > > Thank your for you interesting approach. I had not thought of modeling it > so that the actual graph infers type. > > After my second question I sent, I thought of another way to "type" the > nodes and it is by using separate index namespaces for each type. So if I > want to find a truck, i look in the truck index and search it to find a > node > then I can traverse the graph from there. Do you see any downsides to this > approach? > > I've got some thinking to do now. Sounds like I at least need to keep my > type property. Thanks again for your insights. If you (or anyone else) > has > more ideas, please pass them along! > Thanks! > Andrew > > On Fri, Nov 5, 2010 at 12:11 PM, Craig Taverner <cr...@amanzi.com> wrote: > > > I can make a few comments about modeling this kind of data. > > > > While it is an option to use type="trunk" properties to type your nodes, > > and > > in fact I do that a lot myself, another very common approach is to deduce > > the type from the incoming relationships. Then everything is about the > > graph > > structure. Consider this structure: > > > > - You have a model root node from which you have relationships to the > > main data types: > > - PEOPLE to a node from which PERSON relationships point to each > > person node > > - Person nodes can have DRIVES relationships to trucks, or a > PASSENGER > > relationships instead > > - PRODUCTS with PRODUCT relationships to each product. You can type > > the product on the relationship or the node type='banana' > > - TRUCKS to all the trucks > > - etc. > > - This model gives a fully connected graph where the type of the node > is > > obvious from the relationship you took to get there: > > - If you want to know who drive truck A, travers backwards on the > > DRIVES relationship from the truck node > > - If you want to know which trucks carry bananas, traverse from the > > bananas node backwards along all CONTAINS relationships > > - etc. > > - Location is more interesting. > > - If this is only a list of fixed truck-stops, you could model them > as > > nodes in the graph, and keep updating the graph as the truck checks > > into > > each location. > > - More complex possibilities are possible with adding mapping data, > > streets and waypoints to the graph and model the trucks position > more > > dynamically. > > - Perhaps consider using the Neo4j Spatial library for enabling > > spatial indexes and faster geographic queries on the locations and > the > > trucks. > > - To get really advanced, do not keep reconnecting the truck to each > > truck-stop as it moves, but model the routes with a time > > component, so the > > truck is attached to a route which already includes the entire > > path it will > > take in time. Then a query about where the truck is, or was or will > be > > is > > simply a graph traversal. > > > > > > On Fri, Nov 5, 2010 at 5:35 PM, Andrew Serff <li...@serff.net> wrote: > > > > > Hello all, I'm having difficulty trying to decide on the best way to > > model > > > my data in Neo4j. I'm hoping if I describe what I'm trying to do, > maybe > > > you > > > guys can help me figure out the best way to model the data in neo4j. > > > > > > For starters, I'll have something like a document that was written > about > > > one > > > to many topics, say a Truck or Car that travels from place to place. > > > The truck could be carrying something like fruit (bananas, oranges, > > > whatever). It also has a driver. The Car will have passengers/people > in > > > it. The cars/trucks will go from one location to another. > > > So I'll want nodes to represent the document, the truck, the bananas, > the > > > people, the locations, etc > > > When it comes to looking up the data, I'll want to look things up like: > > > - Find all the trucks carrying bananas > > > - Find all the documents about this truck > > > - Find all the trucks that were in this location > > > - Find where this person has been > > > > > > So, should I create nodes and make a property "type" where type = > truck, > > > document, fruit, location, etc. And each node has an ID, like for the > > > truck, the ID could be it's license plate? Or is there a better way to > > > have > > > "typed" nodes? > > > > > > Right now, in the index service, I only see how to look up a node by a > > > single key. I might want to look up by (type=truck && licensePlate = > > > 123456), because there could be a car with that same plate and i don't > > want > > > that node...Or should I not use the index service for this type of > query > > > and > > > look to a SPARQL query (which I have no experience with...)? > > > > > > Let me know what you all think. Any help is greatly appreciated. > > > Thanks! > > > Andrew > > > _______________________________________________ > > > 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
