Hi Landon, Martin, (as so often) I agree with most points made by Martin. Perhaps a use case that I have in mind for a while is of interest here.
In Germany (sorry...) there is a group of people who developed an object model for urban planning called "XPlanGML" (for those able to understand German, see http://www.xplanung.de). A "Plan" consists of several "layers" that itself consitst of different types of object sometimes having more than one geometry. The model was developed in UML and converted to a GML application schema. We implemented support for this GML application schema with deegree WFS and now a client that is able to display the semantic structure and even able to crate XPlanGML would be a real hit. If OJ would be extended to do this you would have to give it a complex feature model. But the main work would go into the user interface, because object information would have to be displayed in a tree-like structure able to display all connections between the objects. If you want to crate XPlanGML, you would have to define the object type of a newly created geometry, but also the place in the tree that represents the actual plan. Have a nice weekend, Markus Martin Davis schrieb: > 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 >> >> >> > > -- Dr. Markus Müller l a t / l o n GmbH (Hamburg) Gluckstr. 53a 22081 Hamburg, Germany phone ++49 +177 2470742 fax ++49 +228 18496-29 http://www.lat-lon.de http://www.deegree.org -- ------------------------------------------------------------------------- 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
