David Groenewegen and Simon Huggard
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.
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:
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.
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.
The aims of the trial were as follows:
FIGURE 1: The login screen. Note the links to a feedback option at left.
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.
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.
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.
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.
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 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.
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.
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:
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.
(1) Lim, E., 'The last book: The delivery of future content', LASIE, Vol 32, No. 1, April 2001, p.48
(6) Stern, David, 'The OpenURL possibilities: automating enhanced discovery and delivery', Online March/April 2001, pp, 41-47.
Digital Resources Librarian
Information Resources Division
Sir Louis Matheson Library
Monash University VIC 3800
ph 03 9905 1593
fx 03 9905 2610
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.
Information Systems Division
Sir Louis Matheson Library
Monash University VIC 3800
ph 03 9905 9138
fx 03 9905 2610
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.