From the very beginning, our work on the MyST Platform (a layered set of services roughly organized, from bottom up, as MyST Information Object Model, MyST Web Services Platform, MySmartChannels Weblog Application Server, MyST Blogsite), has been guided by the topic map research that Bill and I did while we were both at Starbase. Our goal was to design and build an information management platform almost as abstract as topic maps. (While we both remain strong believers in the topic map vision, we also witnessed first hand the practical challenges of commercializing true topic map technologies--and as a small start up in 2002, we needed shorter routes to demonstrable applications.) So, in that mindset, we created the MyST Object Model--a highly abstract information model capable of representing any conceivable thing (motivated by the impressively general definition of subject in topic map speak.) Fundamental building blocks in the MyST Object Model are Resources, Domains, and Associations. (Technically, we could have done without domains, but domains are one of those concessions to pragmatism.) The MyST Web Services Platform builds web services and security around a MyST Object Model persistence layer. Inherent in this platform is the idea of plug-ins that expose new object models which are based on the underlying MyST Object Model but are more specialized--i.e., more naturally suited to solving a specific class of problems. The MySmartChannels object model is one such derived object model and forms the heart of the next layer in the MyST technology stack, the MySmartChannels Weblog Application Server. Central to the MySmartChannels object model are Spaces, Channels, and Items (and various association types). Without getting into details, these object classes are more specialized than the underlying Domain and Resources classes of the MyST Object Model, but are still very abstract. For example, we use channels to represent many differing kinds of collections of information--weblogs, competitive intelligence, site navigation details, various process configurations, public comments, etc. Finally, we can talk about conversations. The term "conversation" generally refers to a communication between two or more people (or more generally, agents.) Conversations do, in fact, take place all over the place, and channels may be suitable mechanism for capturing and representing some conversations. (Other conversations may be more complex--i.e., contain more information--than can be easily represented in an single channel, perhaps suggesting multiple channels, various typed associates, etc.) The point of all this, of course, is that "channel" and "conversation" are useful, related, but different concepts; just as "building" and "home" are useful, related, but different concepts.
|
