OCLC WorldCat Local case study report

OCLC WorldCat Local: case study of implementation and usability at York St John University

Background

York St John University is a small institution of approx. 6,000 students, over 70% of whom are following full-time programmes of study and the remainder on part-time programmes. York St John University Library and Information Services (LIS) currently shares its SirsiDynix Symphony Library Management System with the City of York Council, under a partnership arrangement set up in 2001.  For some time the University has been aware that the current catalogue interface does not fit with user expectations for a search interface and has been looking at commercial options for replacing the interface to give users a more contemporary experience.  This included all of the key players in the current market for resource discovery interfaces.  Being a small institution finance is an issue and many of the available options have proved too costly to implement.  In August last year LIS decided to buy into OCLC’s WorldCat Local, a resource discovery interface only recently introduced to the UK and Europe, although successfully marketed in North America where there are currently over 600 installations.  The case study follows this, the first implementation of OCLC WorldCat Local in a UK academic institution.

 OCLC WorldCat Local

Apart from cost, reasons for choosing OCLC WorldCat Local were the reputation of OCLC in the library world as a provider of cataloguing and database products and services.  Indeed due to necessary budget cuts elsewhere in library services there was a danger that LIS would lose access to WorldCat as a database resource, were it not for the decision to implement WorldCat Local.  As part of moving to WorldCat Local we were also able to change to OCLC as our provider of catalogue records and consolidate our link resolver which was provided by OCLC through a 3rd party supplier.  It also gave us the means to implement federated searching, something we had been wanting to do for some time.

OCLC WorldCat Local is marketed as “the one search box that does it all”, providing an interface to local, group and worldwide resources from a single search, searching across all resources both physical and electronic, and across all item types simplifying the search and discovery experience.  It provides a tiered approach to searching, using facets to limit to particular item types or databases. 

OCLC WorldCat Local operates on an annual subscription basis with an implementation fee.  It is necessary to be members of WorldCat to catalogue and upload resources so that they are searchable by WorldCat libraries worldwide.  Cataloguing is carried out via the OCLC Connexions cataloguing interface which has both web and client software, the latter being the most robust in practice although both options are largely interchangeable.  Technical implementation involves setting up Z39.50 access to the underlying Library Management System (LMS), although a screen-scrape approach is also available.  The LMS will also need to be configured to allow Z39.50 searching by WorldCat.  Catalogue records have to be exported, loaded into WorldCat, usually in a batchload process, and then re-imported into the LMS, now including the OCLC number, so that the Z39.50 search will work.  A service configuration is set up by OCLC to allow libraries to set user interface options, search display, allowing OPAC statuses to display, setting up of licensed content and databases and link resolvers amongst other options.  A web interface is also configured by OCLC and the search box can be adapted to fit into any web page using the API.  Once the web interface is set up we intended to run both the OPAC and the WorldCat Local interface side by side in order to give access to all local resources, and gain user feedback on WorldCat Local.

 Usability testing

This usability evaluation explored the suitability of OCLC’s WorldCat Local as a replacement resource discovery interface for iBistro. During the evaluation, participants were asked to complete five tasks using WorldCat Local. The tasks were presented in the same order for each participant, but none of the tasks depended on another for success. Our intention was to try to improve our understanding of how returning students will approach using WorldCat Local given what they have already learned of iBistro, and then to use that improved understanding to inform the development of information skills sessions for new and returning students. We also wanted to base any configuration changes made to WorldCat Local on evidence rather than instinct.  The usability report is included as a separate report.

 The project story

The whole project began with a trip to OCLC offices in Sheffield for a demonstration of WorldCat Local and the possibilities it offers as a resource discovery interface.  Once we were assured that the product would give us what we wanted from a resource discovery interface, and had the added advantage of providing us with downloaded records from OCLC, as well as the potential to save money on our current link resolver arrangements and be an affordable option for us, we were ready to proceed.

First steps
The first step was to fill out a lot of forms. OCLC are very keen on forms and you have to fill out forms for becoming cataloguing members, for batchload operations and for setting up Link Manager and e-serials holdings.  If a process is involved, then a form is necessary!  Linked with the batchload forms is a webinar for guidance on how to fill them out and how the process works so early in the project we attended one of these.  Timings for these was an issue, since when we were going through the process, most of the webinars for this and other processes were aimed at the US market and were consequently held at times that were unsuitable for the UK market.  OCLC responded by setting up webinars specifically for us.  However, as the market grows webinars will need to be scheduled at times to suit the UK and Europe.

Data extraction
The process for extracting the data from the system was relatively easy using the MARC Export utility in SirsiDynix Symphony, selecting on the required libraries and excluding discarded and other items by location.  It is important not to delete anything totally from the system during this phase as this could compromise the data being re-imported once it has been matched with WorldCat data and a number assigned.  This initial load matched approximately 100, 000 records from a total of about 130,000, meaning that a large number of records did not match on a first pass.  It was thought that we would have to upgrade these records ourselves in order to produce a match, a task that would have been impossible for a library of our size with limited staff resource.  Fortunately OCLC were able to help with further matching based on format and MARC tags, eventually leaving us with only 1100 non-matched records that are in the process of being resolved.  Many of these have MARC data missing so for anyone else implementing WorldCat Local it is important to ensure data is as accurate and complete as possible.  This can have repercussions at the searching stage in WorldCat Local since many errors in returning location data via the Z39.50 search are caused by lack of data in the 008 field.

Data import
Re-importing data into the LMS is a much more complex process, at least when the LMS system in question is SirsiDynix Symphony.  OCLC returned the data to us as cross-ref files.  Other formats can be chosen when filling out the batchload order form but we opted for this one. The MARC import utility would only match on items with an ISBN and so was unsuitable for the large number of records that did not have an ISBN.  At the time OCLC were unable to help us with the problem so advice was sought from a WorldCat Local reference site in North America, the University of New Brunswick in Canada.  Systems staff there sent us Perl scripts that could be used to extract the relevant data from the cross-ref files sent to us by OCLC.  They also sent details of how to use the Symphony API to insert the data into the records, since we had not had API training in doing this ourselves.  We tested the process on our test server, itself a difficult process since we do not have direct access to the server, being on a shared system with the City of York Council, and having to rely on CYC staff to download additional MARC:PM and MARC:BATCH software to complete the process.  Once this was proved to work effectively, the repetitive task of loading the data back in in relatively small batches to avoid complications began on the live server, and took approximately 2 weeks on and off to achieve.  Thankfully, depending on the method chosen to upload further items to WorldCat Local, this was for us a one-off operation.
     

Deletions
The process for removing items from WorldCat is again a batchload one, either through Batchload Services or via Connexion.  For us the process was not as simple as it appeared.  There is a report in Symphony to Extract deletions for OCLC but it relies on manual removal of items and accesses the transaction logs for data, reporting on the last copy of a title to be removed.  Our deletions process is a batch one whereby items are issued to a Discard user, and then after a period of time converted to a current discard status prior to complete removal from the system.  This process enables us to keep track of deletions for statistical reporting and audit purposes.  Since deletions had also not been tackled consistently for some time we had to review the processes, working out a new workflow so that WorldCat is kept up-to-date.  At the time of writing this is ongoing.  We experimented with reports to find a suitable one that would provide data on items with OCLC numbers and the last copy in a Discard status, and then further edited the information in a spreadsheet.  A list of OCLC numbers was submitted to OCLC and our first batchload has now been processed.  We have yet to investigate batchload processing via Connexion.

Z39.50 connection
Whilst the data export and re-import was ongoing OCLC technical staff were busy getting the Z39.50 connection to work.  There are two options for accessing local information from the LMS – a screen-scrape or Z39.50 access, and it was deemed that the latter would be the most appropriate interface for us.  As we share the system there were some firewall issues, but thankfully problems there were resolved by OCLC working with the City of York Council IT staff.  In order for the process to work correctly there was some setting up to be done in SirsiDynix Symphony, and quite by chance the discovery that there was a FAQ on the SirsiDynix customer care site on implementing WorldCat Local helped enormously.  All did not go smoothly however, and required some input from SirsiDynix support, plus some rebuilding of indexes so the required holdings data would be retrieved in a Z39.50 search.   Configuration
The next stage in the process was the configuration and customization of the web interface.  The interface to WorldCat Local itself was set up for us by OCLC, and then we tweaked the interface through the service configuration that allows changes to be made to user interface options, search results, full-text open url resolvers, place hold/request buttons, OPAC statuses, locations and circulation policies, licensed content and databases and ILS support and maintenance.  Of these perhaps one of the most important and potentially difficult to manage, at least if your underlying LMS is SirsiDynix Symphony, is the OPAC statuses, locations and circulation policies.  A problem with an interface to SirsiDynix Symphony is that the holdings configuration is taken from Location description policies rather than item types as we had at first surmised.  These are transmitted to OCLC so they can be included as part of the Z search script.  As with previous processes, configuration webinars are available, but only at times to suit the US market, so OCLC responded by providing webinars just for us.  We were able to see how the configuration worked, and play around with it.   A second webinar helped us to get our heads around the configuration a little more clearly.   It should not be the same for other library management systems using WorldCat Local. 
Regular monthly conference calls were held with OCLC staff both in the US and UK, sometimes with OCLC UK staff coming on site to take part in the calls.  In March we had a visit from one of the technical team in the US which helped greatly with understanding how things worked and with the configuration set-ups.  To help with configuration issues we also have a “sandbox” so that we can play around and experiment with the configuration once the system is fully live.
Workflows
As part of the process of implementing WorldCat Local it became necessary to review our Acquisitions and Cataloguing processes, and to introduce a new workflow that would take account of the different ways of doing things.  We had been reviewing processes generally, since we needed a more streamlined approach in both areas, so this formalised what we were aiming to do.  As mentioned above cataloguing in WorldCat is carried out via Connexion, available as either a client or web version.  We currently use both versions since they are largely interchangeable but the client version is quicker in practice so we are loading it on all our PCs.  Connexion training is carried out via webinar and we took part in the basic introductory training that allowed us to get going on the system.  Further training is available depending on individual user requirements, but it is chargeable. 

One of the significant changes for us in the workflow has been the point at which we download the catalogue record.  Previously this had been done at the order stage and the record tidied up by our acquisitions assistants when the item arrived, followed by more in depth cataloguing if required by our Database Librarian.  The record is now downloaded when we have the physical item in our hands so that we can be sure we are assigning the correct OCLC number.  There can be many variations in number and detail of records so it is important to select the record that correctly matches the item and this can also affect display in WorldCat Local.  One problem with the display has been that the configuration relies on location and copy details acquired from the SirsiDynix system.  The way in which the SirsiDynix database is constructed means that at the order level no copy record is created so there is nothing for WorldCat Local to link to.  On order items can therefore no longer be seen via the new catalogue interface.  We have thought about creating a dummy copy record, but as the process would also involve downloading the WorldCat record at the order stage in order for it to display in WorldCat Local we would be simply duplicating effort when it came to cataloguing.  It would also require a more senior member of library staff to download the record, hence the reason for creating a simple record at the order stage so that the task of putting orders on the system can be carried out by other acquisitions staff.  The process of cataloguing in Connexion is fairly easy to do, and involves choosing a suitable record and attaching our holding symbol to it.  We have done some original cataloguing for items where we have been unable to find a match.  Once cataloguing in Connexion is complete the record is downloaded into Symphony using SmartPort.Federated searching
One of the reasons for choosing WorldCat Local was that it would give us a federated search interface to allow searching across our licensed databases from one search box.  The next part of our implementation will be to set up more databases in the service configuration, as well as provide links to searching our digital archive.  Although the feature is there we have held off implementing it fully until we have a clearer impression of how the interface is working and being received by users.  We have set up Academic Onefile, currently the only database we subscribe to that is centrally-indexed, which makes searching more responsive.  Other databases that we subscribe to are remotely indexed, and this can slow up the searching process.  OCLC inform us that more databases are being centrally-indexed and there is a list of those that are currently centrally indexed at  
http://www.oclc.org/worldcatlocal/overview/metasearch/dblist/centralindex.htm
Linked to database access is authentication.  WorldCat is authenticating via Shibboleth.  We authenticate via Athens DA mostly for remote users but also for one or two databases used on-site.   We are looking to implement EZProxy as a means of authentication, and are currently testing its implementation.

Link resolver
As part of our move to WorldCat and WorldCat Local we reviewed our link resolver arrangements.  The link resolver we were using was in fact the WorldCat Local Link Manager although it was acquired through a third party.  We negotiated a cheaper arrangement with OCLC and a new  interface was designed and knowledge base transferred in the middle of June, with appropriate changes being made to the 856 field in the underlying LMS.  This proved to be one of the easiest elements of the project and proceeded without any problems.Issues
As WorldCat Local is a new resource discovery interface system in the UK we think it fair to say that both OCLC UK and ourselves were feeling our way with the implementation, and consequently issues have arisen for us that may not or should not occur for later implementers, or indeed for those institutions with better technical knowledge and support or a different LMS.  Implementation issues are mentioned above in the project story.  The following issues are largely to do with how the interface between WorldCat Local and the Symphony system works, and also the WorldCat Local product itself.
One issue that has been identified by other users in usability tests is the display of multiple editions of books.  Currently when WorldCat Local includes records for multiple editions of books (editions, volumes etc) it displays the earliest edition and not the newest in the search results. The OCLC search algorithm in place is displaying the edition that is most widely held, which is not necessarily the newest. FRBR-ised sets came up in previous usability testing for OCLC and end users would prefer the latest edition to be displayed. This is an existing issue for both WorldCat.org and WorldCat Local  and an enhancement request has already been made, to which our name has also been attached.  Details of how the FRBR algorithm works and how this relates to multiple editions was provided by OCLC and is also available on their website –
http://www.oclc.org/uk/en/support/questions/worldcatlocal/search.htm

Related to this was the display of e book and print copies of the same title.  These were displaying separately whereas we preferred for them to display on the same record.  This was achieved by including the OCLC number for both e-book and print on the same record, i.e. each record has 2 OCLC numbers.  A knock-on effect that we did not foresee with this solution was that when users attempted to place holds on a print record that also had an e-book OCLC number in it, they were presented with a blank screen.  This was because the underlying Symphony system could not decipher from the search string that was parsed through which item it should place the hold on.  A solution was eventually found by contacting the wider community and the phrase “not electronic resource” was added to the search string transmitted to the LMS.

A problem with how some holdings displays were appearing is still to be resolved.  Duplicate holdings records were displaying for a number of records so the problem was reported to the development team, who have not yet responded.   It is a similar issue to the place holds where WCL finds 2 records and the de-dupe process in WCL de-duplicates too much information because the information included is exact.  The solution may require a change to the script to make the response more unique.

We had intended to use the ‘List functionality’ in WorldCat Local for reading lists. However this is not working properly currently, possibly due to local caching problems. These will be investigated further and if local caching is ruled out this issue will be raised with OCLC again.

There were a substantial number of records where WorldCat Local was unable to display copy details for approximately 3-5% of total records. We were not sure why this was happening and discovered that simply accessing a record in the LMS and saving it would then display the copy details in WorldCat Local.  A rebuild of the indexes in the LMS solved the problem for us. 

A recent issue for us has been the way changes to the holdings or location information are handled.  Because they are part of the Z search script, any changes made cannot be simply handled by changes made in the underlying LMS.  Instead a support log has to be created for the changes to be made by OCLC, and this can take up to 2 weeks to happen.  Whilst our locations do not change on a frequent basis it is important to us that changes that are made are reflected within as short a time as possible in WorldCat Local.Project completionElements of the project are still ongoing, e.g. federated searching and lists, since we see the implementation of WorldCat Local as a developing service.  We intend to carry out further usability testing with library staff and users to identify areas that could be improved. Now we have reached the end of the main project phase, we have been passed over to OCLC Support UK for any new problems that might arise, although the existing OCLC Project team are following up on continuing problems.  OCLC has asked us to take part in their roadshows taking place throughout the country during October and November 2010, and we shall be presenting a case study on our implementation.

Summary and Recommendations

When we began this project, now more than a year ago, we did not anticipate the steep learning curve necessary to make the implementation successful.  Being a small library with a very small technical team meant that some issues were more difficult for us to resolve.  It has also taken time to work through some of the acquisitions and cataloguing changes, and to resolve issues as they arose.  Many are still outstanding.  Federated searching and the lists feature are yet to be properly addressed and implemented, and they form part of the ongoing project.  Usability testing to date has produced largely positive responses in comparison to the previous catalogue interface.  We have identified some areas where OCLC should adapt to the UK market, rather than being US-centric, e.g. timing of webinars
Our recommendations for institutions considering adopting WorldCat Local as their resource discovery interface are:

  1. Ensure your current catalogue data is as accurate as possible if you are not already cataloguing to WorldCat standards
  2. Be familiar with your Library Management System’s method for exporting and reimporting data and check for instructions on interfacing with WorldCat Local
  3. Accept that your cataloguing and other workflows may need to be adapted to fit in with cataloguing with WorldCat
  4. Ensure all staff are fully aware of the implications of working with a new catalogue interface, particularly those involved with induction processes

This first implementation in an academic institution has been a learning curve also for OCLC staff, particularly those in the UK.  Recommendations for OCLC are: 

  1. Ensure training etc. that needs to be handled from the US is scheduled at times to suit the UK market
  2. Processes, particularly batchload and form completion should be explained in more detail at the outset, probably via a face-to-face project meeting

 For the wider community OCLC WorldCat Local is recommended as a product that sits well beside the other resource discovery interfaces currently on the market.  As a subscription model with an implementation fee it is attractive for those organisations that do not have large capital amounts to spend, but are able to commit some resource from their recurring budget.  For those libraries that catalogue through WorldCat or are considering doing so, and value WorldCat as a database, it is a logical next step if they also require a more user friendly interface than their existing one.  From a student experience viewpoint it makes the searching process easier, and once federated searching and central indexing of databases is set up, will provide access to several million records.  Usability tests carried out as part of this project indicate that it has been well received by most students, particularly when compared with the previous catalogue interface.  For further information on the project see our blog at https://yocalcat.wordpress.com/

Helen Westmancoat
Lauren Shipley
York St John University
October 2010

 

 

 

Advertisements

3 Comments »

RSS feed for comments on this post. TrackBack URI

  1. […] OCLC WorldCat Local case study report […]

  2. Thank you for comprehensive report which makes interesting reading. I’m wondering how many records you needed to migrate in the first place?

    • Thank you for your interest. We migrated approximately 130,000 records out of a database of 250,000 records (some shared with York City Council) and others that we did not want to migrate for various reasons.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: