10 Responses to “Separation Makes the Heart Grow Fonder”

1. Geoff Zeiss Says:
   June 29th, 2007 at 12:58 pm

   I think that it is fair to say that traditionally GIS folks believed in separating the two. But it seems to me that a consensus is developing that storing both content and presentation in the same database makes sense. If I remember, GFIS did this many years ago. GML3 was an important step in this direction and the recent extension of the OGC’s Simple Feature Spec to include text also took this approach. CAD folks have always tended to asociate content and style in the same database. DWG or DGN is a database and every object has a style directly associated with it.

   Another important dimension to this discussion is class, which introduces a level of indirection between an object and its stylization. In database terminology, this means that there are two tables with a foreign key relationship, but stylization can still be stored in the same databae.

2. Dan Shannon Says:
   July 3rd, 2007 at 4:03 pm

   You have a great point. I have always been a big advocate of concerning ourselves with content over presentation from an Enterprise GIS perspective. Let the application layer manage presentation, and let the database manage content.

   However, I have come to admit, reluctantly I confess, that sometimes ( to misquote McLuhan ), “The presentation IS the content”
   Or more simply a text node, as in your example, can itself be considered to be a valuable product. We can think of it a bit like a point address node. It can be inferred by a parcel centroid, but it may be of more value if explicitly placed on a roof top.

   Granted, a street name’s ideal placement varies based on scale, use, etc. However, the same could be said for an address node, as some users would prefer driveway to rooftop. In some cases, with GIS data the ‘medium is the message’?

3. Remi Arnaud Says:
   July 3rd, 2007 at 5:48 pm

   All Good Things Come in Threes !

   The Logic (software), the Platform (hardware) and the Content (data).

   In the early ages, those three parts are blended together and cannot be separated. Example of such systems are the Lunar Orbit and Landing Approach (LOLA) Simulator and Nolan Bushnell Computer Space in 1971.

   But soon it made sense to separate video games in two parts. In 1972 Magnavox released the Odyssey (designed by Ralph Baer). The Hardware was called the video game console, and the logic and content packed into a game cartridge.

   35 years latter this is still the way games are packaged, but now come the age of Games 3.0 as declared by Phil Harrison (SCE) in its GDC’07 keynote, where finally the 3 parts are available separately. The Hardware (Console), the Software (Home virtual world) and the Content (downloadable dynamic content).

   Curiously video games that are usually driving the technology, have been very late in adopting this obvious model. Most applications have been separating Content from Software from Hardware a long time ago. Applications such as word processing (Micropro Wordstar 1979), spreadsheet (Dan Bricklin Visicalc 1979) have been sold as software to be run on a (sold separately) hardware, in order to process (user provided) content.

   Closer to GeoWeb concern, Google Earth is a Software that run on several hardware platform, streaming its content from server. Additional content can be inserted using the COLLADA digital asset exchange format from a large number of Digital Content Creation tools.

   “Separation of Content and Presentation” is obviously the way to go, so that the same Content can be used in different Presentation or Creation applications and be made useful to the end-user. Or that user can provide their own content to the application (mashups)

   “Using a separate style I can ensure I have complete control over text placement, font and colour - and NONE of this is in the content!!”. So here’s the real problem, the content is not rich enough. In order to be useful the content need to have all the information required to be useful to the user. If font, color and control over text placement is needed, then it should be part of the content. And even more important, the content need to be available in an open, royalty free, standard language, in oder to be usable in many applications, even those not even imagined yet.

   COLLADA, a Khronos Group royalty free open standard (www.khronos.org/collada), based upon the Extensible Markup Language (XML) schema specification is based on the 3 parts separation principle. It is always tempting to mix content with logic, such as in VRML or other scene graph based design, where the content is mixed up with information on how to interpret the content, but one of the design principle of COLLADA, and IMHO its strength compared to many other content description language, is to concentrate on the content (3D, material, effects, physic, animation, user data), and not the description of how an application should be using the content.

   In conclusion, it is important to separate the content from the way it should be interpreted, but at the same time make sure that the content is rich enough so that various applications can make a good job at communicating it to the end user.

4. Ron Says:
   July 3rd, 2007 at 10:26 pm

   A comment on Geoff Zeiss’s comment. I don’t think the issue is that of separating the databases so much as having the encodings bound together. If I encode a road as having 3 lanes, gravel surface and styled as a 3 point red line - then HOW do I style it otherwise for another purpose? Perhaps the colour and weight are right for the state transportation department, but is not appropriate for the Department of Sustainable Development. Even more to the point, I might want to have different presentations for both different roles of the road and for different audiences or situations (the road could be used for evacuation in a fire or an earthquake, but is otherwise marked for forest access. I don’t see how this can be accomplished WITHOUT separating presentation and content encodings.

5. Sam Bacharach Says:
   July 6th, 2007 at 12:15 pm

   Geoff does a good job of pointing out that the ground rules that were written to account for hardware, software and user limitations are changing. So I think the the answer is that it can be done sometimes and not others. The challenge from an OGC perspective is to provide a standard to do what we can today without it becoming a hindrance in the future — think DTED that was designed to run on a cpu with a smidgeon of the memory, processor speed and storage of my smartphone. We are still cutting the tops off of mountains and ridges and losing important changes in the terrain to a simple gridded system that was created in the 60s because there is just too much software and data out there to move on. We cannot afford to do the same thing with 3D and CAD/GIS integration and that is going to require us to better define and understand the needs of many more users than we had when GIS was just a desktop tool for professionals. That will be a struggle of monumental proportions.

6. mpg Says:
   July 6th, 2007 at 4:11 pm

   For all the usual reasons they taught me in back in school (some covered by Remi above), we should absolutely strive to separate content from presentation… While being practical enough to recognize that we will likely never reach true complete separation, it is nonetheless a good goal to continue to strive for.

   An interesting angle to consider is perhaps this: what is “special” about the messy cases where we have to “cheat” to make things look pretty? If we could abstract and identify those properties, then perhaps they could be expressed within the realm of the content data (or perhaps the metadata thereof), so that the presentation engine need not “cheat”.

   (What’s a good, canonical example of a cartographic layout problem we could try to break down and think about it?)

7. Rita Turkowski Says:
   July 9th, 2007 at 1:23 pm

   How interesting that many software architectural concepts tend to be cyclical in nature! Per Geoff Zeiss’ comment on CAD systems, and Remi Arnaud’s comment on early games systems, content was intermixed with logic for presentation, so we see the mingling of the two. Why? for one, content was not tied to end-user semantics so much as it is today in our distinct web based application environment and secondly, well, it was just easier to do. Initial designs for new technology seek to solve immediate problems (as in give the user what he needs, now!) whereas later, when technology and systems mature and become more complex, content and logic becomes more sophisticated and the desire arises to separate the two, freeing content presentation to be delivered by a system that knows best how to deal with it. But when software design and development gets a bit too complex for presentation logic on simple end-user systems, it then makes sense to cycle back to the thinking that a more simplistic lumping of the two together is the right way to go. I see this happening in the geo space where the need to address visualization and interactivity based on the content (and a painless end-user experience!) drives the system architecture decisions.

   As Dan Shannon implies, “..with GIS data, the ‘medium is the message’? ” the lumping of the presentation logic and content together make sense for a useful and successful least common denominator approach to GIS, whether, for example, in independent applications such as Google Earth or in perhaps X3D web plug-ins for a standards based approach to GIS. Hence, when the medium is the message, you have to allow for content data to define what the user sees and interacts with in a way that they expect to.

   Supporting Remi’s hypothesis, rich content generally tends to beget even richer content - think mash-ups - so, yes, content really should be kept separate from logic so that it can be quickly and easily repurposed with new content. The mash-up type scenario works best in a content/presentation “separatist” architecture. And, building off Ron Lake’s comment, I think there is a need to add a new layer of “content-awareness” that allows for metadata to provide additional presentation information, to be used on specific end systems. This, however, implies some mixing of logic and content cycling back to my original statement.

   However, I cannot agree more with Sam Bacharach that “We cannot afford to do the same thing with 3D and CAD/GIS integration and that is going to require us to better define and understand the needs of many more users than we had when GIS was just a desktop tool for professionals. That will be a struggle of monumental proportions.” When talking about CAD today - and the markets driving the new CAD/GIS integration, it is worth noting that the requirements of the users have gone far beyond just creating and manipulating 3D design concepts. These new internet-savvy and sophisticated 3D content producers and users will drive the upcoming CAD/GIS efforts. As a multi-disciplined community we need to listen carefully to their needs so we might create an extensible standard that will not hinder unforseen progress! And, as mpg suggests above, if we can abstract and identify the “special” properties in the messy cases and come up with something that can be defined and specified, then perhaps a standard can emerge that is both useful and even extensible.

8. Dan shannon Says:
   July 12th, 2007 at 5:08 pm

   Some great insights here. Rita’s summary echoing Sam’s comments make me think that to some extent there is a little irony here in that in the process of coming up with new forms and structures for representing spatial concepts, in the very act of being creative, we are often guilty of thinking a little too ’small’, not anticipating what will come next that will need to build upon or extend what we’ve done. But as mentioned above, it is a monumental challenge precisely because we don’t know what we don’t know….yet. All the more reason for us to become literate in thinking, working and creating with ‘Open’ structures in mind.

9. Eddie Curtis Says:
   July 13th, 2007 at 2:34 am

   Separating content and presentation allows the content to be presented in different ways. This allows re-use of the content in different contexts or applications which need different presentation. This is a good thing, but only if there is more than one application which wants to make use of the content.

   Refactoring models from a combined, to a separated (or at least, separable) content and presentation model is a common activity. It happens when a wider community gets interested in the content (probably as a result of the nice presentation they have seen) and the value of re-using the content becomes apparent. As Rita points out, with increased data sharing and web based appications the demands on CAD data are becoming more diverse, so the drive to separate the content is becoming stronger.

   I don’t see the mixing of content and presentation in models as a fault or oversight by the modellers. Decoupling parts of the model takes time and effort. When there is only one application this overhead does not deliver any benefit. It is only when the second application comes along that this effort can pay dividends. I see the re-factoring of models to separate content and presentation as a natural, healthy maturing of the model.

10. Julian Says:
    July 27th, 2007 at 4:20 pm

    I was just at the Spark Session about this at Geoweb 2007, and I was kicking myself in the elevator afterwards for not asking the following question: Why does no-one mention performance? For example, I typically have some data which I want to publish in a service. In general, a service cannot respond quickly enough. If you have a service which responds after 500 milliseconds, 100 milliseconds would be better. If you have a service which responds after 100 milliseconds, you want it to do so for 100 simultaneous requests. If my data is in a database, it generally gives better performance to combine presentation and content in one table, so I dont have to join a table containing content with one containing presentation. To relate to the debate at Geoweb 2007, I’d say that whether I want to do the separation depends on the application, but there are three cases: In the beginning, where I don’t know exactly to draw the line between content and presentation, I keep them together. As the application matures, I’m able to draw the line, so I do. Further on, I discover that 90% would like me to supply a default presentation, so I provide a separate service where I optimize performance by merging content and presentation.