SS, Good blog post.
It seems to me that you are recapitulating the object-vs-relational debate that was raging strongly in the DB world in the late 90's. It seems like the RDB's have won that round (at least for the time being) on the server side, but the object world is obviously in the ascendant on the client side. I also think that this debate is mostly about implementation, but doesn't really address the more fundamental issue of what the actual semantic model is. And that's the important question, because that is what is needed to motivate the design of the user interface and tools to present it to the user. To put this more concretely, it would certainly be possible to represent complex features as sets of related tables. But what would the user interface look like on top of this? How would Paul get his view of complex features? What would it mean in terms of UI to have a complex feature with either two geometries at one level, or an attribute which is itself a collection of spatial features? You would still need a way for the user to indicate how he wanted these to be rendered, how sub-features were created and destroyed, etc. Moreover, a table based model in not in fact simpler, it's more complex! This is because it is more general, since relationships between tables can model both association and aggregation. In contrast, a complex hierarchical Feature is generally considered to model an aggregation. A concrete implication of this difference is that in a table-based model, you either have to explicitly define or explicitly manage the life-cycle of related sub-features. In an object-based model, this is controlled by the top-level feature, which is a simple model for the user to understand. (RDBs usually handle this situation by implementing "cascading delete on foreign keys" - but you don't get this for free, you have to have a language to define this and the user has to understand how to model this). To use another metaphor, I sometimes think of tables as the assembly-language of object models. You can represent pretty much any model you want using tables, but *you* have to to all the work of defining and maintaining the model. An object model is presented at a slightly higher level of abstraction, with some reasonable defaults which can make it easier for a user to work with. My main point here is that I think the choice of object-vs-table is orthogonal to the issues of defining the "mental model" that JUMP presents to users via it's UI. *That* is the key thing to design - the rest is just a question of implementation. Martin Sunburned Surveyor wrote: > I put up a post on my OpenJUMP blog about one possible alternative to > a complex feature model. > > I haven't thought the idea through completely, and I don't have any > plans on implementing the alternative described, but if you are > interested in having the benefits of a more complex feature model in > OpenJUMP you might want to read the post. If nothing else, I hope it > presents an interseting concept. > > The post is here: > http://openjump.blogspot.com/ > > The Sunburned Surveyor > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
