online logo

The answer to all our problems?

David Groenewegen and Simon Huggard

Abstract

In semester 1, 2002 Monash University Library trialed Fretwell-Downing's ZPortal software. This software was designed to create seamless access to all the library's electronic online resources. Monash was one of the first libraries in the world to use the ZPortal software. The paper will discuss the reasons for adopting a portal, what was expected of the software, and the aims of the trial. In addition some outcomes of the trial will be discussed, as well as the practical maintenance issues that a system of this nature creates.

Why have a portal?

A portal offers the potential to solve many of the problems that have arisen for libraries in the last decade. As electronic resources have proliferated, a variety of new challenges for our users have proliferated with them, many of which can be made simpler through the use of a portal. These include:

  1. Multiple logins: Although Monash University maintains an LDAP database of student and staff details (which means that most users need know only one username and password for access to most resources), there was some concern among users that logins were required so frequently as to be annoying, especially if they were searching multiple databases. A portal would allow for a single log in for access to all of Monash's resources via the university's LDAP-based 'AuthCate' password.
  2. Multiple interfaces: The large number of interfaces used by electronic resource providers is bewildering to our users. Monash University Library offers access to over 300 electronic resources (such as databases and full text journal sites) which have over 100 different search and retrieval interfaces between them. A portal offered the potential for reducing this to one standard interface, through which all of our resources could be searched, and in which all results were returned in a standard format. This standard interface could also be used for searching multiple databases, thus saving the user the time otherwise spent to move from one resource to another, an important consideration if the user is working from home.
  3. Resource discovery: There are three elements to this problem:
    1. Knowing which resource is most appropriate for your needs: To the average user the names of many resources are unclear. What sort of information does ABI/Inform contain? What about ERIC? Or CINAHL, Compendex or Inspec? Which is more appropriate: Academic Research Library or Expanded Academic ASAP? A portal would allow us to give more detailed explanations of what type of material resources contained; target our resources, so that particular users are directed to particular resources based on their studies/teaching; and then allow them to search a variety of relevant resources at the same time.
    2. Knowing how to get to full text: When Monash surveyed its users in 2001 a large number of them complained of a lack of full text material, despite the fact that they have access to over 15 000 journals. Our conclusion was that users were not able to locate the full text that Monash holds, even though it is listed in the library catalogue. Use of the OpenURL protocol in the portal would allow for connections between index records and Monash's full text holdings.
    3. Maximising use of print holdings: The Library retains a substantial print collection, and most databases index older material that is not available electronically. By making the catalogue a searchable OpenURL target, we hoped to direct users to our print holdings where appropriate. The Library's Intercampus Loan system would have been used to deliver material to the appropriate location.

These were the most immediate needs that a portal could address. In the longer term, the Library had a vision of using the portal as a gateway to all of the Library's services, including Document Delivery, online help and library created subject material (1). With this in mind, the Library chose a name that encompassed more than just searching: myLibrary@monash.

Expectations

For the initial stage of the portal the Library wanted a piece of software that could do the following, with the underlying assumption that other functionality might be added at a later date.

Firstly, the portal needed to be able to use the Monash Directory Service (MDS) to log users in (with their AuthCate password) and to present them with a set of resources based on their teaching/studies as recorded within the MDS. This facility was considered to be crucial 'pushing' the most relevant resources to users. However, it was not intended that users be limited to those resources chosen for them - all users were to be given access to all resources so that they could pursue any research interests they might have.

The MDS connection would also be used to make a link between the Library portal and the University portal (my.monash(2)) . This would allow users to start within my.monash, but to go to the Library's resources when they desired. Using an existing, well patronised service would also help raise awareness of the Library's portal.

Next, the portal needed to perform satisfactorily as a single interface, cross resource searching tool. It should be able to search any single web based resource or combination of resources, including library catalogues, databases and academic websites, and return identical results to those returned by the native interface. It was considered to be critical that the results be identical, in order to give the portal credibility in the eyes of users.

Once a search was complete the software would need to use the OpenURL protocol (3) to create links to Monash's full text holdings. The user would need to be able to access this seamlessly, without re-entering their MDS details.

Finally, all the standard requirements of any new piece of software needed to be met - it had to be robust, efficient, conform to relevant standards and work on a variety of browsers including the Monash standard Netscape 4.7.

In order to gauge which portal software on the market might best achieve these goals the Library sent out an RFP in February 2001. After presentations from vendors the product chosen was ZPortal, made by Fretwell-Downing Informatics of Sheffield, UK (4). A contract was signed in November 2001 to begin a trial of the software in semester 1 2002. This trial allowed for Monash's withdrawal from the contract should certain requirements, such as those listed above, not be met. Due to a change in Monash's security requirements for the MDS, the public was not given access to the portal until May 2002, although Library staff had access from the beginning of March. The trial then ran until the end of August.

Aims of the trial

The aims of the trial were as follows:

  1. To ensure that the software chosen for the portal met the specified technical requirements.
  2. Market the portal in specific areas of the University community, and elicit feedback on its usefulness, to ensure that this was a product that our users would find useful.
  3. Test ease of use - while the Library intended to offer classes in future years, past experience has shown that most users don't attend library classes, so for the portal to succeed it needed to be reasonably intuitive to use.
  4. Ascertain what maintenance and support issues a portal might create, so that the production version could be properly resourced.

myLibrary@monash

FIGURE 1: The login screen. Note the links to a feedback option at left.

image1

FIGURE 2: The Standard search screen. The initial default search was a Z39.50 'Title' search (as shown below) to try and keep the number of hits returned manageable. This was later changed to 'Any' as some users were not getting any hits. The drop down 'Current Profile' box allowed for changing between sets of resources.

image2

FIGURE 3: A results screen. The 'Get it!' link activates the OpenURL resolver. Sorting options were available from the left hand menu bar, or by selecting the title of the resource a user wanted to bring to the top of the list.

image3

FIGURE 4: A record. Note that 'Get it!' can also be activated from this screen. The amount of information displayed varied depending on the quality of the database that was searched.

image4

Outcomes of the trial

At the conclusion of the trial the decision of the Library was that the software was not yet developed to a state where we would be able to recommend it to our users. That said, there were a number of interesting results of the trial.

Meeting technical requirements

As mentioned previously, we expected that a cross-database searching tool would have the ability to search all of the library's databases, regardless of location and format. From a technical point of view, the work required to write search scripts to access resources, does not appear too difficult, as the resources are usually well defined and the http, Z39.50 and MARC standards are clearly defined and well established.

As a multiple database search engine ZPortal performed as expected. ZPortal uses scripts called Z2Webs to make non Z39.50 databases searchable. In most cases some modification of the Z2Webs needed to be made to ensure that all options searched exactly as they did in the native interface, but once this was done the searching worked well. When Z39.50 was used the results could be more inconsistent - the standard of records was often limited, and the search options severely proscribed compared to the normal web interface. Some vendors had such poor Z39.50 implementations that Monash was forced to use Z2Webs instead.

The key to being able to search, retrieve and display these results is the existence of well structured metadata. The problem was not that the metadata didn't exist in the target databases, but the placement of a large amount of key citation information in unexpected fields such as note fields (e.g. 500 MARC tags), without defining any MARC subfields between each piece of information. For example, it was quite common for journal titles, volumes numbers, ISSNs, page numbers and dates to be placed in a single field, separated only by textual information. More frustrating was the use of SUTRS (Simple Unstructured Text Record Syntax) format, where most information is very poorly defined and inconsistent in its output.

We believe that the reason for the relatively poor standard of records can be attributed to database vendors justifiably concentrating their efforts on receiving or converting data into SGML and HTML format for searching, retrieving and displaying via their own web search engines. These search engines mostly use keyword indexing for retrieval of data from any field, rather than relying on structured, indexed fields and subfields. Therefore, the need to standardise, reformat and restructure that data has been less important, with the result that complete Z39.50 support has been neglected.

Once the security issues were worked out, the MDS database was drawn on by ZPortal to create reliable sets of relevant profiles. Survey results and testing showed that most users were presented with resources relevant to their studies/teaching. It was also possible to combine areas of study - a student enrolled in both Business and Economics and Engineering was given the option of searching resources in either field. Users were also able to change profiles, and create their own.

More problematic was the issue of OpenLinking using OpenURL. Getting this to work effectively turned out to be more complicated than was initially expected, largely due to the wide variety of formats various database vendors used for records. The OpenURL standard specifies a standard syntax, which is put together from the journal article metadata, to send to a journal publisher or aggregator site. This query is formatted so that the journal site is provided with all of the information it needs to retrieve the desired article and display it to the user. In the trial OpenURL linking worked well when the required article metadata was in an identified format, however, as discussed above, this was often not the case which made linking almost impossible. To solve this problem Fretwell-Downing made numerous changes to the individual search scripts to ensure better quality data was returned, or to their OpenURL templates to try and get effective results when a journal website was sent a poorly formatted OpenURL query.

Access was further complicated by the need to include Monash's Ezproxy (5) URL in front of any link to a journal article from within ZPortal. Off campus users use EZproxy for access to IP authenticated resources. Because the portal server had a Monash IP address any OpenURL query sent to the publisher or aggregator site was already authenticated. However, the full text was displayed in a new browser window, which meant that access depended on the user's IP address. This problem was solved by adding the EZproxy URL to the OpenURL templates.

Related to this was the need for EZproxy authentication to be seamless to avoid the problem of making a user who already logged in to myLibrary log in again. In Monash's case, this was achieved by setting up the EZproxy server to automatically authenticate any user whose referring URL was the portal server. While this solved the often-complained about problem of having to login multiple times, it did pose a problem in that the EZproxy log files no longer included AuthCate user codes, which are used to tie usage of databases back to the user's Faculty and area of study. We felt that this could be solved using an automatic login script for EZproxy, so that the user's details could be recorded when they logged into myLibrary, or with better usage logs on the portal server.

This situation solved the 'appropriate copy' about which much has been written in relation to the OpenURL standard (6). In Monash's case, it was assumed that all copies were appropriate, because the user could be authenticated with EZproxy from any location. Monash policy is that wherever possible all of our resources should be available to all of our users.

Marketing and feedback

Marketing was deliberately kept relatively low key, as the trial was primarily aimed at the faculties of Engineering and Business and Economics, in order to keep the implementation manageable. These faculties were sent e-mails advertising the service, and staff and postgraduate students were invited to hands-on sessions at various Monash campuses. In order to get a wide range of feedback however, links to myLibrary were also added to various library web pages, including the home page and the databases pages. A note on the front page of myLibrary indicated that the portal was not intended to specifically cater to all users during the trial. Nevertheless, 6922 individual user sessions were undertaken during the trial period.

Each page of the myLibrary site contained a link to a feedback form. Around 30 messages were received using this form, some of them comments, others notification about various problems. In July a survey was conducted using the e-mail addresses of staff and students who had registered to use the portal at that stage. This received 138 responses (12 per cent of the sample group). Comments received in this survey indicated that a high proportion of users appreciated the ease and convenience of a multi-database search tool. However, many users reported problems with time-outs or failed searches, some of which were due to unanticipated set up problems.

Ease of use

Many survey respondents reported that the service needed more online help - there was only limited help available during the trial, as it was not written in time. However an equal number indicated that it was easy to use. The usability might have been improved by changes to wording and on screen instruction, had the trial continued.

One area that was not sufficiently transparent was the ability to change and create sets of resources or 'profiles'. By the end of the trial over 2700 users had registered with myLibrary, but only 15 new profiles had been created. The survey showed that many users were unaware that this was possible. This was particularly worrying, as the assumption going in to the project was that this would be a reasonably popular feature, which would give users a certain degree of flexibility.

Maintenance issues

During the course of the trial it became clear that there would be two main areas of difficulty in maintaining a service of this type:

  1. Keeping track of journal holdings: Monash chose to load aggregator and publisher site journal holdings to the OpenLinking database. During the trial this amounted to around 10 000 items. We were able to extract appropriate fields such as title, ISSN and holdings data from the Monash Voyager catalogue due to the enormous amount of cataloguing work already done on electronic journal holdings at Monash. Because journal publisher or aggregator information was already held in the 'Z' subfield of the 856 MARC tag, this information was used in the OpenLinking database to connect the journal with the service that provided that title in full text. This is an essential component of any portal software, as a relationship must be made between the journals returned in search results and the aggregator or journal sites at which the full text is held. In the case of ZPortal, this meant linking each title with a journal service. If this journal or aggregator information had not already been included in a structured format in the Monash Voyager catalogue, it would have been an enormous amount of extra work to do this. The fluid nature of modern electronic journal holdings, especially those in aggregator databases, has meant that the library has struggled in recent years to keep this information up to date in the catalogue, so maintaining an identical list in a second location would pose a substantial challenge. Recently, commercial companies (such as Serials Solutions, Journal Web Cite and TDNet) have emerged to provide these types of services for libraries, and this may be a viable alternative, particularly if they can maintain journal data on a website, provide updated MARC records, as well as provide structured data to portal vendor.
  2. Changes to target databases: It became clear over the course of the trial that many websites tinker with the workings of their search mechanisms far more often than most users suspect - the Z2Web for ScienceDirect, for instance, needed to be updated four or five times during the course of the trial, although there were no visible changes on the ScienceDirect site. This highlighted the need for vigilance in the way the software was performing. A search that worked perfectly on one day could disappear on the next, through no fault of Monash or ZPortal.

Conclusions

While Monash University Library decided not to proceed with the use of ZPortal, the trial process did prove that there is demand for a portal in this format, and that we need to think very carefully about how this can be managed when we do eventually fully implement software of this nature. The library was also made aware of the limitations of the Z39.50 standard - it only works as well as the implementations of it will allow. In the end the Library was very conscious of the fact that introducing a potentially good piece of software too early would only negatively impact upon its ultimate acceptance - our decision to wait until the technology is more manageable and more capable before introducing was influenced by this realisation.

Endnotes

(1) Lim, E., 'The last book: The delivery of future content', LASIE, Vol 32, No. 1, April 2001, p.48

(2) http://my.monash.edu.au/

(3) http://www.sfxit.com/OpenURL/

(4) http://www.fdgroup.com/fdi/welcome/index.html

(5) http://www.usefulutilities.com/ezproxy/

(6) Stern, David, 'The OpenURL possibilities: automating enhanced discovery and delivery', Online March/April 2001, pp, 41-47.

About the Authors

David Groenewegen
Digital Resources Librarian
Information Resources Division
Sir Louis Matheson Library
Box 4
Monash University VIC 3800
ph 03 9905 1593
fx 03 9905 2610
david.groenewegen@lib.monash.edu.au

David Groenewegen spent 2002 on secondment to the Library Portal Project as Library Portal Administrator. His primary role since July 2000 has been as Digital Resources Librarian at Monash University, in which he co-ordinates access to electronic resources. He has worked at Monash since 1991, in lending services and online information literacy.

Simon Huggard
Systems Librarian
Information Systems Division
Sir Louis Matheson Library
Box 4
Monash University VIC 3800
ph 03 9905 9138
fx 03 9905 2610
simon.huggard@lib.monash.edu.au

Simon Huggard was appointed Systems Librarian in April 2000 and has worked with purchasing and providing access to Monash Library's electronic journals and databases for a number of years. Simon has worked for Monash University Library since 1992 where he has had experience in both the reference and technical service areas of the library.


Warning: Unknown(): open(/tmp/sess_65615a41b62b278240fe48d1b6adaad7, O_RDWR) failed: No space left on device (28) in Unknown on line 0

Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0