<<Biblioteca Digital del Portal<<INTERAMER<<Serie Educativa<<Digital Libraries and Virtual Workplaces Important Initiatives for Latin America in the Information Age<<Chapter 10
Autor: Johann Van Reenen, Editor
Título: Digital Libraries and Virtual Workplaces. Important Initiatives for Latin America in the Information Age
2. Portals and their development options
A portal is essentially an integration of services and content in a web site. A portal is the next evolutionary step in the use of web browsers. In 1994, it was Mosaic, then came Netscape, now every computer has some web browser. A browser according to the Special Libraries Association (2000) is a “software that displays web pages and helps facilitate a user interacting with the information on the web pages.” But with the tremendous growth on the number of web pages available, a web browser is not enough. We need a tool to work at a higher level of abstraction, where the user is not required to specify too many details to find the information that she needs or where given the profile of the user, the system can “guess” the user needs or can even correct a typo on the user´s specification. Just like this word processor does when the transcriber misspells much as mcuh. In synthesis, the users need more functionality and intelligence in their browsers.
Even though there is consensus on the general definition of a portal, the major confusion begins when defining specific kinds of portals or when trying to build a taxonomy of portals. In addition, authors have been very creative in the introduction of new terms for every particular type of portal.
We want to focus on Enterprise Portals, also known as enterprise information portals (EIP), intranet portals, corporate portals, and cortals. According to the Special Libraries Association (2000) enterprise portals “represent current evolution of corporate intranet and function as a starting point for employees; EIPs tie together multiple, heterogeneous internal repositories and applications as well as external content sources and services into a single browser-based view that is individualized to a particular user’s task or role; can deliver more relevant content in context than a broad (internet) portal.” Roberts-Witt wrote in 1999: “The idea of a corporate portal is less than a year old and already companies are feeling a sense of urgency in getting them going.”
The Delphi Group conducted a survey in February 1999 of 300 corporate managers to find out what they thought a portal could do for their companies. Robert-Witt analyzes the top three responses to this survey; we reproduce excerpts from this analysis below. According to the survey, the top 3 responses were:
1. “Sharing information and work methods, which seems to speak directly to the knowledge management notion of making tacit knowledge explicit.”
2. “Business process support, or workflow, indicating that companies see a huge upside to exchanging electronic files rather than moving hard copy from desk to desk in the business process.”
3. “Customer service, mirroring the growing business interest in managing customer relationships.”
Roberts-Witt (1999) also clusters corporate portals into three general classes. These classes are: data, information and collaborative portals. We use this classification because it is adequate for our approach. Below are the definitions of her portal types:
- Data Portals “deal primarily with structured data… that tend to populate corporate databases.” The main products in this category try to make “reports widely available to users who need them.” Data portals allow dynamic and low-overhead reporting capabilities.
- Information Portals deal “more directly with unstructured data, such as email, text and other documents. The products typically have indexing and cataloging capabilities, as well as some robust search and retrieval functionality. In essence, they organize and deliver information.”
- Collaborative Portals “focussed on tying more group interactive functionality.”
There is a wide range of options for a portal. Beginning with the simplest form of a portal, defined by McCallum et.al.(2000) as “an information gateway that often includes a search engine plus additional organization and content”, to more sophisticated forms of portals. Sophisticated examples include Yahoo and Altavista, (examples of horizontal portals) or high level university campus portals such as described in Eisler (2000) as examples of a vertical portals. The services provided in a portal vary widely with the purpose of it. But some services that are frequently found are: member registration, personalization, search engine, email and discussion boards, organization and indexing of content, from internal and/or external sources. Normally, the users of a portal have to register in it and provide a name and password each time they use it. This allows the system to personalize the services and contents to the specific user. The portal constitutes a single point of entry and a single logon to the services provided. For a thorough coverage of the subject of personalization see the special issue of the Communications of the ACM (Riecken, 2000).
The task of developing a portal is a large and complex one. There are several alternatives for building a portal. We list some of these alternatives here.
- In-house development. An organization can choose to build its portal by hiring a development team and acquiring the right tools. Regarding the tools there is a myriad of options, but none of them is truly complete to provide all the desired functionality in a portal. The main distinction is between proprietary tools and open source software. The proprietary tools for building portals are, in general, expensive and it is not uncommon to find a bundle of software and consulting services in this area. Some examples of this kind of tools and services are: Microsoft Site Server, Vignette and Broadvision (see Ante,2000), Viador E-Portal Framework, Iona Technologies iPortal Suite, and Hummingbird Enterprise Information Portal (see Whiting, 2000, for the last three). There are many separate tools that are open source software, but very few provide an integrated solution. One of these few is MasonHQ (http://www.masonhq.com), which uses Perl and Apache. Hummingbird started offering free copies of its EIP Development Edition.
- Outsourcing. The whole effort of constructing the portal might be delegated to an outside company. This is a reasonable option if the organization who needs the portal does not have a development team. But in any case, after the portal is developed and becomes operative, a maintenance team should be in place so that the portal is available 24 hours a day, 7 days a week. This situation leads to the third alternative.
- Portal in a box. This alternative is available today from many vendors. It provides a basic skeleton for the portal with a fixed set of services from which the user selects the ones she likes. The basic skeleton can be customized to some level. This option is very limited and not very flexible. Many of the vendors in this category offer this option free of charge, but the downside is that usually a significant amount of advertising is pushed through the portal. Another characteristic of this alternative is that the registration data of the users of the portal and some of the content is hosted at the vendor’s site, without any control over the use and maintenance of these data by the “owner” of the portal. In fact, the portal is really owned by two parties, the organization who wants the portal and the vendor who offers the portal-in-a-box solution.
- Automatic construction. There are some attempts to try to build a portal, or at least its main content, automatically. The most recent example of this is the application described by McCallum et.al. (2000) for automatically building an information portal, specifically in the context of scientific and technology libraries. It uses sophisticated tools based on techniques from artificial intelligence to try to automate mostly the content acquisition aspect. This type of portal falls in the category of information portals described in the classification presented earlier in this section.
Some major issues which the builder of a portal needs to be aware of are: permanent availability, up to date content of the portal, intellectual property of the content of the portal (Thurow, 1999), security, privacy, different user levels with access to different functionality, and how to apply the security and privacy constraints at each level.
A portal could be designed from scratch to provide services and data that are specifically constructed for it. Or it can be conceived as a platform for integrating existing systems and data sources. In the latter case, some major issues in the portal construction complicate the task considerably. These issues are heterogeneity and interoperability, or more generally, system integration. But on the other hand, the effort of building a portal is a facilitator of system integration. For a recent review on system integration in some major applications, see Hasselbring (2000).
How can a portal and a database work together? The first use of a database within a portal is to maintain the user profiles and to support the registration and authentication services. But portals and databases can interact beyond this simple use. A database can be used as the main “content provider” for the portal. Furthermore, other techniques that add value to the data can be jointly used with the database to provide additional services. Some examples of these other techniques are: data mining, text mining, and information extraction. The database technology is at the core of maintaining the content of a portal correct and up to date. Also, the portal provides a convenient interface to the database. It constitutes the modern way of building a database application; a web-based application that can be integrated to other services and data sources.