I'm going to take a slightly different tack here than the responses you've got so far...
First as others have pointed out, this is three entities and two relationships joe - is a - janitor - at the - school This is important, the lighter weight the relationships, the less problem you are going to have with needing some form of meta type for them. You really want to follow the basic OO lead here and stick to "isa" and "hasa". The "at the" is essentially a "hasa" (a school has a janitor). If you can map your relationships to these two simple concepts then you've got a realistic model, otherwise you probably need to refactor / abstract or normalize (take your pick depending on your background, they're essentially the same thing at this level of modelling). That leads to point number two. Modelling is modelling is modelling, and although a graph database might let you get up and running easily it's not going to save you from modelling your domain properly in the long run. The worse job you do up front the more work it's going to be to fix it in the long run. One common pattern is that if you think you have a meta type then use that for your entity and add the details that makes it a specific sub type as instance data: a janitor is a type of job therefore the entity should be "job", not janitor, job type is a property of job school is a type of building (or maybe even more abstractly a type of location), building type is a property of building therefore the entity should be building. Though in this case it may be location depending on exactly what the domain is going to be used for, though most likely a building "hasa" location... As long as your number of subtypes is some reasonably small number then this pattern of abstraction works well. Here, "reasonably small" is in the range of things you don't mind coding up a enum for in your code. (How's that for a non-committal type guild-line? I'll pick 10 as an arbitrary limit if pushed.) Note that this need for abstraction is true for relational or graph databases. A relational database can behave polymorphically with respect to type just as much as a graph database, the difference is that with a relational database, as you make the model more abstract the number of joins needed to fully resolve type goes up (assuming its a fully normalized model). With a graph database you can always be an edge away. However, in this case the cost is the number of relationships that must be examined. There is no free lunch, the space / time trade off will always be there and that is what you have to worry about as you determine whether you want to abstract more and build more of a meta model. This brings us to my third point. Your layers are perfectly realizable in a graph database (or a relational database for that matter). There is no reason why the entity "janitor" can't have an "isa" relationship with "person" and it in turn can have an "isa" relationship with the metatype "mammal" if need be. Same with school, building and even structure if you need to go that far. If you really need this, proceed with caution, the metatypes are going to have many relationships as your instances grow and the cost of maintaining the metadata this way could get expensive, not so much in ways of space (since you've normalized out the metadata) but in terms of the time needed to traverse all the relationships. However, if you have millions of each janitor or school and all of their equivalent sub types then this may be the way to go. IE; if you have M subtypes of job where M is a medium sized number (say 10 < M > 50) then you have can reduce the size of the index on job by instead implementing the M different subtypes (you more-or-less divide the index size for jobs by M). As I said, the cost is that you know have a whole bunch more relationship to the metatype, but if you don't normally have to touch them, or if finding specific instances of a subtype is a common and / or maybe expensive operation for some reason you've got the right model. Last point. What about the case where you have more than 50, or whatever you consider some large number of subtypes? In that case your model is likely wrong. There's hopefully a way to split the subtypes into categories . If some categories overlap then figure out what makes them overlap and split that off as a category (type or metatype) of it's own. In other words, it's time to refactor, which takes us full circle back to point 1 and it's now time to go get some sleep. Hope this helps. Peter Hunsberger On Sat, Sep 24, 2011 at 12:52 AM, loldrup <lold...@gmail.com> wrote: > I'm trying to figure out how to model the world most flexibly (okay, so I'm > sticking to modelling organisations for now, but still). My main problem > seems to occur when I want to allow the model to naturally expand in > complexity. Say we have the following relationship: > > Joe is a janitor at the school. > > This can easily be modelled with two entities and a relationship. Now say I > have some common properties for janitors. I would have to make a link from > the janitor-relation to some node denoting the type 'janitor' which could > then hold information on these common things. Unfortunately, relationships > doesn't support that. > > Long story short: the problem is that sometimes I want my things to act as > things, sometimes as types, sometimes as interfaces, and I cannot know in > advance which of these modalities I'm going to need. > > Therefore, I'm considering going with this model: > > Imagine a graph in three layers. The lower layer represents things, the > middle layer represents types and the upper layer represents interfaces. > Initially i populate only the lowest layer, but as need arise I go back and > promote various things to also be types or interfaces. These then crop up > in > the second and third layer of the graph, respectively. When this happens, a > vertical relationship is added between the element in the lower layer and > its new type/interface in three higher layers. > > Now the question is: how to model this scheme in neo4j? A number of > challenges pops up: > > * Neo4j relationships cannot be n-ary, so every relationship must be > modelled with a hyperrelationship, thus allowing future relations to the > second and third layers. > > * In a modalities-are-a-changing-paradigm it doesn't really make sense to > distinguish between relations and entities; at different points in time, > one > element may have to act in the roles of both. Neo4j however makes a > fundamental destinction between the two things. I could choose too model > all > relationships as nodes, but will that not make graph traversals messy? > > * Neo4j doesn't come with a type strong destinction between such three > layers of modalityy > > -- > View this message in context: > http://neo4j-community-discussions.438527.n3.nabble.com/Modelling-with-neo4j-tp3363823p3363823.html > Sent from the Neo4j Community Discussions mailing list archive at > Nabble.com. > _______________________________________________ > 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