Lorcan Dempsey looks at what is happening with portals – including a growing awareness that the library portal is only one step towards creating an effective network presence.
Portal is one of those unhelpful words that we use in the network environment; unhelpful because we don’t really have a common sense of what we mean by it. You will find many definitions, but they are often so vague as to be useless, or so specific to a particular service or implementation as to be incapable of general application.
A portal spectrum may include a simple collection of links, a database of resource description which can be customised to particular roles or individuals, a metasearch database federation service, or a complex orchestration of network applications within a consistent framework. Recently, in the library community there has been some emphasis on metasearch, or cross-searching, and on MyLibrary-type personalisation systems based on resource metadata. These services are now quite common, and a library has many options to choose from when it comes to implementation.
This interest and progressive deployment have led to considerable discussion and some interesting initiatives. I discuss two recent developments here before noting a wider trend – service recombination in multiple portals.[1] Both these initiatives centre on cross-searching or metasearch, the context of much portal discussion in libraries. I use ‘metasearch’ rather than ‘portal’ for clarity.
The first is the Scholars Portal Initiative created by the Association of Research Libraries. Here, a group of research libraries is experimenting with a portal built using Fretwell-Downing software. ARL defined a portal in this context as an application which provides cross-searching or metasearch and one other service. Rightly, readers might think of the eLib hybrid library projects when they read this. The focus is very similar.
Richer in network services
What has changed is the passage of years and the emergence of an environment which is richer in network services, and one in which it has become clearer that the library portal is only one rendezvous point between services and users. Think for example about the emergence of the course management system, or virtual learning environment, in the last few years which mediates a growing part of the learning and teaching experience.
Another increasingly important venue is the developing portal framework of a library’s home institution, in this case a university, but which may be local government or a firm. There is a growing desire to see library services effectively surfaced in these other environments. A recent Scholars Portal document reports a development path identified by participants as follows: ‘This area includes the ability to move seamlessly between courseware and the Scholars Portal, searching profiles, and accessing reading lists. Participant recommendation for the first round of development is to create a “portlet” that could be included on any web page (including a courseware web page, a course-related web page, a subject page, etc) that would allow the user to conduct a search on an existing Scholars Portal profile.’ [2]
Of course, many other libraries in the US, as in the UK, are investing in such specialist cross-search products. Most library system vendors have a metasearch product of this sort, and several companies specialise in this area. Often, such a product will be associated with an Open-URL resolution application to assist in linking discovered metadata to instances of the discovered resource. We have moved someway along in implementing the Models [3] verbs of discover, locate, request and deliver. Much of the focus of these developments is to save the time of the user by automating and thereby hiding as much of the discover-to-deliver chain as possible.
The progressive deployment of such metasearch library portal products has highlighted several issues in implementation. And this leads to the second initiative I want to discuss. Recently, Niso (National Information Standards Organisation) in the US has identified three important implementation issues, and has established working groups to address them under the broad heading of ‘metasearch’. [4] These are: search and retrieve; collection/service description; and authentication/authorisation.
Briefly, the search group is exploring search interaction with distributed resources. The aim is to do this more gracefully than currently, where quite often the metasearch product interacts with the target resource in less than fully effective or economical ways. Some target resources may use Z39.50, some don’t and may require various custom approaches.
The second group is exploring the configuration data that a metasearch application needs or could usefully use about target resources. Currently, this is an area which is weakly standardised and where practices are still developing. Typically, a metasearch product or resolver will need to be configured with data about the target resources. This might be technical data such as port number, protocols and metadata formats supported, special connection scripts, and so on (this is sometimes called ‘service description’). And then there is data describing the content of the resource itself (this is sometimes called ‘collection description’). A collection may have several services associated with it, which make it available through different channels.
The third group is looking at the broad issues of identity management. It is interesting to consider why after many years these issues remain on the table and to think about what incentives exist or do not exist to implement standards across the various stakeholders involved.
Integrating resources into learning workflows
Stepping back, we can see some trends. A major one is growing awareness that the library portal is only one step towards creating an effective network presence. We are used to thinking about the integration of information resources with each other. However, the real integration to be aimed for is the more effective integration of information resources into the research and learning workflows of the user. The library portal may be a means towards this end, but it should not be confused with that end. This is becoming clearer for two related reasons.
The first is that both available and potential services are growing in volume and variety. Virtual reference (the ‘mortal in the portal’) is one example. Services around reading lists, personal collections of documents or metadata, and editing or analysis tools are others. An interesting area to watch is services which allow teachers to take resources and ‘chunk’ them into appropriate course materials; another is services which allow users to deposit documents or data in repositories, perhaps offering metadata creation, name authority and subject indexing services. Think about services that return bibliographic data in a particular citation format for pasting into a paper or a grant proposal or for downloading into a reference manager. Some of these will require rights clearance services. Offering this range of services effectively is a subtle and unsolved problem which may make us think rather differently about services on the network. I have mentioned learning management systems and institutional portals as venues for such services. However, what about something like the Microsoft research task pane? This allows us to insert search services into Microsoft applications. Would it not be useful to be able to search the catalogue direct from a Microsoft Word document, or get some data back from a search to paste into the document?
This leads into the second reason. We are used to thinking of ‘service’ in monolithic terms: you come to a composite complex service. Think of what is available on the library website, from the metasearch engine, through the Opac. Increasingly, we will begin to think of ‘service’ in more fine-grained ways. ‘Portlets’ were mentioned above. A portlet is a ‘pluggable’ user interface component. Many institutional portals are made up of many of these portlets or ‘channels’, and we can see a definite trend towards making individual library services available as ‘portlets’ in institutional or other portals.
Some individual services were mentioned above. So, the library portal presence may be one aggregation of such portlets, but they may also be available through other portals or in other application environments. How does one position oneself among the densely interconnected RSS feeds, blogs, collaborative interactive environments that populate the network world alongside evolving office and communications environments? This will require flexible thinking about flexible network services.
Behind these trends, there is an important issue looming to which I will return in later columns. There is some evidence that there is a growing disconnection between the net-aware experiences of students and other emerging library users and the experiences that are available to them in networked library and learning environments. What sorts of services does one provide for those for whom the ‘net is oxygen’ or who are ‘always on’? [5]
References and notes
[1] A fuller treatment of these issues may be found in: Lorcan Dempsey. ‘The Recombinant Library: portals and people’. Journal of Library Administration, Vol. 39, No. 4, 2003, pp. 103-136. Pre-print available at www.oclc.org/research/staff/dempsey/
dempsey_recombinant_library/
[2] Scholars Portal Project Report, May 2004 (www.arl.org/access/scholarsportal/
SPupdateMay04.html).
[3] Moving to Distributed Environments for Library Services (www.ukoln.ac.uk/dlis/models/).
[4] Niso Metasearch Initiative (www.niso.org/committees/MetaSearch-info.html).
[5] Diana Oblinger. ‘The next generation of educational engagement.’ Journal of Interactive Media in Education, 2004 (8), 2004. Special issue on the Educational Semantic Web. ISSN: 1365-893X (www.jime.open.ac.uk/2004/8).
Lorcan Dempsey is Vice-president Research and Chief Strategist, OCLC Inc. (DempseyL@oclc.org).
Updated: 20 January 2005