Sunday, May 8, 2011

Why we are not interested in Portals - 2

From my last post, I have worked up a model of a Portal implementation so we can now compare our model with that of a Portal. Of course, there is a lot more functionality in your average Portal than I have modeled, but the point remains as this model fits the fundamental structure of the vast majority of Portals.



If we look at the Portal model we see that all of the information flow is from the User to the Portal. There is no information moving back to the User, except that they are looking at on the Portal. The control of the presentation, organization and interface is with the Portal and stays with the Portal. Even the comments don't move back to core Institutional database, but remains within the Portal. As the Portal is almost always under the control of the Institution anyway, this means that information not only moves from the Users to the Institution (no change there), but also the control of the way the information is managed, presented, accessed and ordered remains with the Institution as well (again, no change there).







If we look at our model, there are three fundamental differences. First, the information that goes to the hub, is not organized, presented nor ordered there, but simply PuSHed from there to the Subscribers' servers. It is at the Subscribers' servers that the information is organized, presented and ordered many times over, and in the local context. There is also the key difference that comments are not simply attached to a Portal instance, but are available to return into the Institution as part of the object's primary record. Most fundamental of all, though, is that our model is reversible. Any Subscriber in our model can become a Publisher, and any Publisher a Subscriber. Knowledge developed through the local use of Institutional information, can be PuSHed back to the Institution to enhance their documentation of the object. A Portal cannot be reversed as it is not a distribution system, but a broadcast system.

Sunday, May 1, 2011

Why we are not interested in Portals.

I thought we would lay down the gauntlet now, even though we are a bit of a way off demonstrating our work. I have uploaded two models for our systems. The first is a User Model, which is a demonstrative diagram for a general audience that shows what our system will intend to do. The second is an Object Model, using UML, which is more for developers. The two more or less depict the same system, though. I should emphasize, for those developers reading this, that the Object Model is not a full Class Model, but more of a "conceptual" Object Model.

What I want to show, however, is not simply what we intend to do, but to also explain why this is different from a Web Portal. In a recent discussion between the IT Officer for Anthropology at the American Museum of Natural History (New York), Jim and I, it became clear that what we are doing could easily be confused with a Portal. Or, worse in my mind, that it could be assumed that there would be little difference between what we are doing and a Portal. In fact, I think that what we are doing is fundamentally different, and even opposed, to what Portals do. Here is why.

If you will pardon me drawing a definition from Wikipedia, a Web Portal is "a web site that function as a point of access to information on the World Wide Web. A portal presents information from diverse sources in a unified way." (Wikipedia, emphasis added). Wikipedia goes on to say that a Portal "provide[s] a way for enterprises to provide a consistent look and feel with access control and procedures for multiple applications and databases, which otherwise would have been different entities altogether." This is the key difference to what we are trying to do and what Web Portals are trying to do. Whereas a Web Portal takes a diverse set of resources, centralizes them and gives them a single "enterprise" identity, what we are trying to do is the opposite. We are trying to do is to take a diverse set of resources, distribute them as filtered sets to diverse expert communities, so that these filtered sets of resources can be localized and used in completely different ways.

The difference between a Web Portal and our approach is not simply superficial, but goes right down to our understanding of what Knowledge is. Where the assumption about knowledge in a Web Portal, and most "knowledge systems," is that knowledge is an accumulated resource, a set of commodities that gain their power as knowledge through their packaging or their organizing, we accept a different, less colonial, view of knowledge. We see knowledge not as a set of proscriptively ordered and presented resources, but as a personal, local and community achievement. Knowledge, for us, is something you do, and do skillfully, not something you acquire, proffer or stockpile.

So the difference may seem subtle, even trivial, but is in fact fundamental. A Web Portal seeks to share information resources between individuals and communities through a unified, proscribed and centralized system -- an enterprise system much like a museum or archive. However, what we trying to do is to share information resources between individuals and communities by distributing those resources into the diverse local systems so that they can be directly used to build local knowledge. While a Web Portal is, by its very nature, a system that creates a unified identity for information, and information use, through its "enterprise" identity, our system seeks to fundamentally undermine this universalizing and commodifying approach to knowledge by radically replacing unity and centralization with diversity and localization.