LIBRARY PORTALS
Prepared by Richard W. Boss
Hundreds of libraries have implemented library portals and as many as half of the RFPs outstanding in early 2005 specified that an automated library system include a "portal," a single user interface for access to a wide variety of electronic resources both within and outside of the library. Portals were initially developed by large companies seeking to provide a single user interface for employees to access corporate information on multiple heterogeneous computer systems. While the first portals were developed by or for a specific company, commercially produced portal software soon became available.
A portal can be mounted either on a dedicated server or on a Web server that supports other applications. The software is generally described as a portal server product. Major vendors include BroadVision, Epicentric, iPlanet, Oracle, Plumtree, and Tibco. Plumtree is the market leader. There are also some smaller vendors which focus on the library market, among them Fretwell-Downing, MuseGlobal and WebFeat.
A portal typically contains the following:
Intuitive and customizable Web interface
A portal provides an easy-to-navigate interface that can be designed to match the look and feel of an organization' s existing applications. While most portals are implemented with Web browsers, it is possible to use another client interface such as a GUI.
Personalized content presentation
A portal can be presonalized using users-profile information to deliver personalized content. Each user can gain a view that is tailored to his or her access privileges. The personalization can be for an individual or for a category of individuals. In most organizations, employees are provided with their own personalized content; customers and suppliers are provided content which has been personalized for a category.
Federated searching
A portal makes it possible to access a wide variety of electronic resources with a single log-on and a single search rather than consecutive log-ons and searaches.
Relevancy ranking
One of the drawbacks of portals is that they can bring too much information to the user. The solution to that problem is "relevancy ranking," filtering for relevancy and ranking the search results according to pre-determined criteria.
Link resolution
Particularly important for libraries, link resolvers bring together information about a cited resource, the user, and the target document. For example, it enables the user to navigate from a reference citation to full-text, from an abstract in a database to a catalog search for materials about the same topic, or from a cited reference search report to an interlibrary loan request.
Security
User profiles can be used to increase the security of the systems being accessed because most portal servers use caching to improve performance. The users access the cache, rather than the back-end server that is the source of the information.
Patron authentication is another security feature, not only to determine rights to access that stored on a local system, but remote resources which require that access be limited to specific individuals or categories of people.
Communications and collaboration
A portal can be used to provide chat, e-mail, shared calendars, Web meetings, etc.
Sources for Library Portals
A majority of the libraries that have implemented portals have relied on a vendor that specializes in the library market because substantial tailoring of the portal is necessary in order for it to work well with an automated library sytems.
Lexis-Nexis was a pioneer in developing portals with content management for use by libraries and law offices. It selected Plumtree's Corporate Portal 4.0 platform and added a structured taxonomy to enhance and simplify navigation across legal resources. Web sites, news feeds, and local documents. Westlaw, Lexis/Nexis' major competitor in the legal market, subsequently developed a similar portal.
Almost all vendors of automated library systems now offer portals. Endeavor and ExLibris, vendors that focus on the academic and special library markets, were among the first in 2001, but it soon became obvious to the industry that public libraries have as great a need as academic libraryies.
Five vendors, including Endeavor, Innovative Interfaces, LIBIT of Germany, Sirsi, and TLC have selected MuseGlobal technology for incorporation into their systems as a portal. MuseGlobal is a "portal server" product specifically designed for retrieval of information by library users. Dynix has an agreement to use WebFeat, a major competitor to MuseGlobal. Fretwell-Downing also offers a special product. Most of these vendors have made their sales only to libraries using their automated library system. The exception is ExLibris, a company that has developed its own portal server product and has sold it to serveral hundred libraries not using its Aleph500 automated library system.
Since the portal product is positioned between the brower and the vendor's patron access catalog, it is necessary to write an interface between the portal product and the patron access catalog so that features such as placing a hold and other patron empowerment features are not lost.
While there are advantages to working with the vendor of the automated library system because it assures easier integration of the portal and the automated library system, it is possible for a library to work directly with the portal developer. The exception is Muse Global, which now licenses its products only to distributors.
The majority of libraries use their portals solely to access the many databases to which they subscribe using the common interface and single log-on, authentication, and federated or single search the portal provides. Only a few libraries offer very broad access to the patron access catalog, special files the library may have created, the catalogs of other libraries, subscription databases, and userful Web sites selected by library staff. Very few libraries facilitate access to specialized search engines.
Features of library portals
Portals are changing too rapidly to describe each vendor's offering. The information would be out of date within a few months. Instead, the following paragraphs describe a generic portal of the type that a library should consider. It can then compare several vendors' latest general release portal offerings against its requirements. References to particular vendors is made only when that vendor appears to have been the first to introduce a new feature.
Not all products that are described as library portals meet all of the definition of a portal. Federated searching - the simultaneous searching of several electronic resources - is only one component of a library portal. Libraries that have adopted it without the other components, should not describe what they offer as a portal.
Patron authication is also an essential component of a portal, both to authorize access to the library portal and to authenticate users for the database providers that require authentication. As many libraries had implemented patron authentication prior to the widespread use of portals, the patron authentication component of a specific vendor's portal may not have been implemented.
The third component of a portal is a link resolver. As previously mentioned, a link resolver brings together information about a citation, the user, and the targeted resource. The link resolver is activated when the user clicks on a link embedded in the user interface. As the various databases to which linkages are made have different interfaces, support different searching techniques, and have other unique features, the OpenURL Framework is the underlying standard.
Link resolution is the least widely implemented portal component because it is the most expensive component. Not only must the software be purchased, but the linkages must be created and kept current. That can be a time-consuming task. Endeavor Information Systems was the first vendor to extend basic portal capabilities by licensing software and a database from a vendor that creates and maintains such links. It adopted JournalSeek in 2002, a knowledge database developed by Openly Informatics, Inc.,to link to over 7,700 electronic journals in the sciences and humanities, and Link.Openly a system for generating links from bibliographi citation data. The offering, known as LinkFinderPlus, provides access to electronic resources with far less time required on the part of library staff to create linkages. All of the other major vendor of automated library system had introduced link resolvers by the end of 2003.
Relevancy Ranking
One of the major problems with portals is that they often return too much information. There is a need to manage the content to make it more relevant. The simplest form of ranking is that which lists the results in order of the percentage of the search terms which are matched. That is why entering multiple terms is far more effective than entering a single term.
Another way of structuring heaps of unorganized information is to maintain a thesaurus to serve as a navigational tool as well as an organizational tool to filter search results. At this time, most vendors of library portals only provide the capability for building and maintaining a thesaurus.
Costs
The cost of a library portal product can range from as little as $7,500 for a small library purchasing software only for mounting on an existing server to more than $100,000 for a large library purchasing a system which includes hardware, software, and third-party database and linking products. A link resolver subscription that keeps the linkages up to date can cost several thousand dollars a year.
Specifying Portal and Content Management
A library interested in purchasing a portal product from the vendor of its automated library system, or from another vendor, should develop requirements and submit them to the vendor(s) for proposals that set forth what is in general release, what is in development, and what is in planning.
- The portal shall be a Web-based common user interface
to information in various electronic formats stored on a variety of systems
- a variety of clients shall be supported including:
- PC-based workstations with Web browsers on the
library’s network
- Mobile computer devices on the library network
(e.g., PDAs, notebooks, sub-notebooks, etc).
- Web browsers accessing via the Internet
- Z39.50 clients
- The portal shall provide access not only to the
patron access catalog on the automated library system, but also the catalogs
of other libraries, archives, and museum systems
- Access shall be provided to item level holdings and
location
- At the library's option, patrons shall be able to
place holds and view their own records through the portal.
- The portal shall provide access to online
reference services to which the library subscribes.
- The portal shall provide access to useful Web sites
selected by library staff.
- There shall be access to records for all material types, including, but not limited to:
- monographs
- serials
- machine-readable data files
- maps
- microforms
- vertical file
- audiovisual formats
- sound recordings
- manuscripts
- journals and diaries
- scores
- computer software
- URLs
- realia
- photographs
- slides
- prints
- paintings
- sculptures
- textiles
- glass
- ceramics
- amulets
- architectural elements
- archaeological artifacts
- ceremonial objects
- domestic objects
- clothing and accessories
- tools
- numismatics
- It shall be possible to access records in the following formats:
10. HTTP, SQL, and Z39.50 clients shall be supported. Vendor to identify any other protocols it supports.
11. It shall be possible to broadcast a search to a number of target systems and bring back a unified search result.
12. When a user begins a session, the system shall present a brief opening message describing the system and providing a menu of beginning search options and further help or information from the system.
13. The portal shall provide user interfaces in languages in addition to English, with the option of switching to English on each screen. [Identify languages supported].
14. Staff shall be able to modify access points available to patrons.
15. All diacritics in the source of information shall be displayed.
16. The system shall support five levels of scoping that can be set by staff so that the initial screen shows:
- all holdings of the location
- all holdings of the library
- all holdings of the library and online reference
services to which it subscribes
- all holdings of the library, online reference
services to which it subscribes and library-selected URLs, including the
patron access catalogs of other libraries.
- everywhere (i.e., including the Internet)
17. It shall be possible to access all related records when accessing any record. [e.g., to access a manuscript that is part of a collection organized about a person or by a collector]
18. It shall be possible to search by at least the following:
- author, maker, or artist
- title
- series
- publisher
- place of publication or production
- date of publication or production
- subject or iconography
- category
- material or object type
- medium
- call number
- accession number
- donor
- any other indexed field
- any of the 500 or so information categories in museum records
19. It shall be possible to limit a search by:
- language
- country of origin
- geographic region
- year of creation
- range of years of creation
20. The system shall allow users to refine a search based on previous search results
21. The system shall display the search strategy and number of hits retrieved by each search
22. The system shall merge and dedupe search results
23. The portal shall provide one or more options for filtering search results to increase the relevancy of the information retrieved
24. Vendor shall describe how it filters citations to determine relevance
25. Search results shall be listed in order of relevancy ranking
26. It shall be possible, but not necessary, to maintain a thesaurus on the portal platform
27. It shall be possible to use an available online thesaurus to obtain synonyms to add to the search statement
28. Vendor shall identify any third-party thesaurus product(s) that it offers
29. Templates and graphical utilities shall be provided for setting up user interfaces and tying them to back-end services
30. The portal shall include a link resolver.
31. The system shall conform to the Open URL standard.
32. Vendor shall indicate whether it can provide a collection of pre-loaded linkages suitable for a library of its type.
33. It shall be possible to add external databases by merely keying the URL into the system.
34. Patron authentication shall be available to meet the requirements of database providers
35. The system shall be capable of suspending a potentially long search at a predetermined point and providing the user with certain options: narrow the search, terminate the search, examine a portion of the hits, continue the search, etc.
36. When the client has been inactive for a specified period of time, it shall clear automatically
37. Help messages shall be available to users at all times; menus or prompts shall continually remind the user how to request these messages
38. The system shall allow the user to retrieve help messages without losing the search in progress
39. The system shall display error messages selected on the basis of the step in the search at which an error occurred
40. Error messages shall briefly remind users of the nature of the error, or of what the system is expected to receive at that point in the search.
41. Error messages shall include instruction for receiving additional information, either by referring the user to the help messages, or by allowing the user to request a follow-up to the error message which contains further detail about the search being attempted
42. If a search retrieves no records, the system shall refer the user to a public service desk
43. Portal use statistics shall be available for each source accessed, including
- number of sessions
- length of sessions
- page views
- documents viewed
44. It shall be possible to aggregate data for all statistical categories
45. It shall be possible to group all statistics by the patron codes maintained in the automated library system
46. Statistics shall be available on the number of patrons
- successfully authenticated
- not successfully authenticated
47. Vendor shall describe the process for adding, editing, and deleting electronic resources
48. Vendor shall build the page layouts for the initial user interface, one which accesses not only all in-house applications, but also external ones identified prior to initial installation
49. Vendor shall indicate what other support services it provides and on what terms
50. Vendor shall indicate whether the portal and content management software can be mounted on the same server as the library’s Web-based patron access catalog or whether it requires a separate server
51. Vendor shall quote all hardware, system software, application software, installation, and training prices for its portal product.
52. If the federated search, patron authentication, and link resolver components are available both bundled and as separately priced components, vendor shall quote prices both ways.
53. Vendor shall quote the annual maintenance and support fees for the portal.
54. Vendor shall quote the annual subscription rate for link resolver updates.
March, 2005.
PLA is a division of the American Library Association. Copyright Statement.
|
