ltr: Vol. 44 Issue 6: p. 26
Chapter 5: Planning and Implementation
Jennifer L Ward
Steve Shadle
Pam Mofjeld


The University of Washington Libraries, in collaboration with OCLC, began a pilot project that resulted in the creation and launch of a new discovery and delivery platform called WorldCat Local. It enables users to search what were previously three separate catalogs as well as five article databases. The search interface is simple, which research has shown that users prefer.1 WorldCat Local also integrates what were previously separate delivery systems, resulting in a seamless, easier-to-use service. WorldCat Local debuted on April 30, 2007, when the University of Washington Libraries made it the default search box on its home page. The impact on delivery has been impressive, with users requesting and getting far more materials than when we had separate “silos” for discovery and delivery. WorldCat Local provides a new service environment to the library user. Because WorldCat Local integrates a number of data sources (local library catalog, consortial library catalog, digital collections, article databases) and library services (local and consortial catalog requesting, interlibrary loan, link resolving, direct full-text linking, and online reference services), it is important to have the functional experts in all of these areas involved in planning and implementation. This article explores why such a tool was desirable; describes various aspects of the implementation, the effect of usability on development, and the impact on discovery and delivery; and discusses future plans.

WorldCat Local provides a new service environment to the library user. Because WorldCat Local integrates a number of data sources (local library catalog, consortial library catalog, digital collections, article databases) and library services (local and consortial catalog requesting, interlibrary loan, link resolving, direct full-text linking, and online reference services), it is important to have the functional experts in all of these areas involved in planning and implementation. It is critical to have public service staff involvement from day one to support marketing and training, to provide user feedback, and to provide reference support for the new service. Because these sources and services typically cut across a number of departments, it is useful to have a senior administrator on the implementation group to facilitate any cross-departmental changes in policies and/or local practices that might be required to best implement WorldCat Local (examples of such practices will be discussed later). OCLC requires the library to identify one person as the official contact, so in addition to the functional areas previously listed, the library should identify a well-organized project coordinator in order to assure timely communication between OCLC and the library and between various members of the implementation team. In smaller libraries, one person might be responsible for a number of these activities, and the planning and implementation group might be relatively small. If WorldCat Local is being implemented as a consortial catalog, different aspects of planning and implementation will happen at the consortial level and within the individual library.

Our approach was to identify the following functional areas and identify an individual responsible for policy and/or management in each of these areas:

  • public services
  • library systems, including
    • – link resolver/knowledge base local manager
    • – ILS manager/coordinator
    • – consortial/union catalog coordinator
    • – Web services manager/coordinator
  • circulation and resource sharing (interlibrary loan and consortial borrowing)
  • cataloging/MARC data, including
    • – local library's OCLC coordinator and/or service contacts
    • – local cataloging policy
  • project coordinator/liaison

It is important to identify individuals who have the time to dedicate to this activity. In our case, the project coordinator is a production cataloger with other duties. During implementation, it was made clear to staff that her materials would be cataloged at a greatly reduced rate. Depending on the specific implementation issues encountered by a library, temporary shifting and/or delay of work might be necessary so that individual team members have the time available to support WorldCat Local implementation.

It is very important to establish a group e-mail address, discussion list, wiki, message board, or some other form of rapid group communication that requires the participation of all team members and allows team members to be responsive. Considering the crossfunctional nature of WorldCat Local and corresponding interdepartmental support staffing, it is crucial for all team members to support problem solving, create best practices, and develop new processes (and change existing ones) to best support service provision within the WorldCat Local environment. We found it very useful for all WorldCat Local–related reference queries to be distributed to all members of the team. The result was a more responsive service (as the query was distributed to a number of qualified staff) and a greater awareness of the user experience and system problems on the part of all team members.

Working with OCLC

As UW Libraries staff discuss our WorldCat Local implementation with others in the library community, one of the questions asked most frequently is “How long does it take to implement?” As a development partner, our experience was very different from what new subscribers will experience. In the words of Rob Ross, one of the OCLC WorldCat Local implementation managers, they are prepared “to work at the pace at which libraries can make decisions about how their instances of WorldCat Local will look and work.” 1 Libraries that meet OCLC's criteria (have their holdings current in WorldCat, have indexed OCLC numbers in their local catalog, etc.) and are prepared to make decisions quickly can go live in approximately one month; others may initiate the process and then choose to wait for a particular feature to be implemented before moving forward.

Generally speaking, once a library signs a contract for WorldCat Local, they are assigned an implementation manager—someone who works with the library to ensure success of the implementation. As part of the process, the following general steps are worked through:

  1. Assess catalog records and, if necessary, perform a batch load project.
  2. Analyze other records in the OPAC that are not in WorldCat to determine if they can be loaded (e.g., third-party records/sets).
  3. Analyze other collections not currently in the OPAC that might be available in WorldCat Local (e.g., institutional repository).
  4. Meet via phone with the OCLC implementation team to begin mapping out work flows and discuss configuration information.
  5. Configure system and make available for testing.
  6. Go live!

Some of the key activities as part of the steps above include

  1. OCLC conducts a brief introductory meeting with the library to discuss overall library objectives, schedule, key activities, and responsibilities. This meeting includes the project manager/key library contact, OCLC implementation manager, and other OCLC staff.
  2. OCLC conducts project kickoff with key library staff (representatives from cataloging, reference, information technology, etc.).
    • Review project time line and key activities.
    • Review configuration questionnaire/work flows used to collect information about the local library environment/systems and how WorldCat Local should be configured.
  3. Library completes configuration questionnaire and reviews it with the implementation manager. This online questionnaire contains setup questions related to:
    • branding WorldCat Local to match the library's look and feel
    • interoperability with the library's local system, resource sharing system, and URL resolvers
    • relevancy ranking of search results
    • fulfillment options
  4. OCLC tests library's WorldCat Local implementation.
  5. Library tests its WorldCat Local implementation.
  6. Library conducts library staff training.
  7. Library promotes WorldCat Local to end users.
  8. Library reviews statistical reports provided by OCLC about WorldCat Local usage.
  9. Go live!
    • WorldCat Local search box is placed on library Web site and other appropriate places.
    • Additional services, such as the Google gadget and Facebook widget, are made available to end users.

The above is a simplified view of the process, as the local systems in place at each institution are unique. The next section provides details on what is required in each of the functional areas defined earlier.

Implementation Team: Public Services

Implementing WorldCat local requires the expertise of staff familiar with technical and cataloging issues. Although these issues are complex and are the focus of much of the process, OCLC recommends that the project team include public services staff. As part of the initial development and implementation work, their perspective can keep the rest of the group focused on the reason why WorldCat Local is needed: the user.

Experience with the WorldCat Local pilot libraries taught OCLC that one of the keys to a successful implementation lies in the marketing and rollout phase. Public services staff with experience in instruction and outreach play a primary role in organizing training sessions and creating a marketing plan. It is particularly important to provide background, context, and training for library staff so that they understand how the service works and are familiar with WorldCat Local features prior to assisting users. This increases staff comfort with the system and enables them to respond to questions that might arise at a service desk. As with any new system or service, discomfort is inherent when there is a perceived loss of expertise. If staff do not accept or trust the new system, they will be less likely to use it and recommend it to users. Offering a second series of sessions to staff a few months into the implementation reinforces the initial training and allows staff to learn about changes, ask questions, and exchange information about best practices. Staff should be encouraged to share success stories, since those illustrate the benefits of WorldCat Local for users.

In early 2008, electronic training materials and tutorials were created by OCLC to aid with the staff training process. As with WorldCat Local itself, these materials are constantly improved based on feedback from library staff and should reduce the overall time that staff have to spend developing their own local training materials. In mid-2008, online help within WorldCat Local itself (accessed through the “Help” link at the bottom of every page) was greatly enhanced to provide additional detail about the system. Much of the content was driven by user questions and queries.

WorldCat Local includes features that many library catalogs do not, such as faceted browsing, FRBR-ized results sets, searching and delivery integration, and myriad social features. Faceted browsing has become a standard feature in many databases and is thus familiar to public services staff, but it is entirely possible that staff have little experience with such social features as RSS feeds, bookmarking, and tagging, and may question the need for these. As part of the training, it might be worthwhile to review some of the Web 2.0 technologies and perhaps invite a student to talk about why these features are important to them. 2

WorldCat Local was unveiled at the University of Washington on April 30, 2007, almost halfway through the spring quarter. OCLC developed customizable marketing materials, including posters, pencils, bookmarks, and pads of paper, and these were posted and distributed around the campus. Librarians promoted the service in instruction and consultation sessions, demonstrating the search, discover, and request features, as well as highlighting the availability of articles. Subject librarians also sent e-mail about WorldCat Local to their departments. Other than that, we chose to implement the system with little fanfare or advance notice because users were preparing to leave for the summer and would not be able to provide much structured feedback. We intentionally replaced the UW Libraries Catalog search box on our home page with the WorldCat Local search box as a way of promoting its use and obtaining initial user reaction.

Public services staff perform a primary function in establishing a mechanism for user inquiries, ensuring that questions are handled by appropriate staff in a timely manner. The University of Washington has used OCLC's QuestionPoint since 2002 to manage information and reference questions, making it easy to incorporate WorldCat Local into this stream. A link to the service was provided on WorldCat Local pages. An electronic mailing list was created for the WorldCat Local team, and staff monitoring QuestionPoint knew to assign questions about the service to that list. The appropriate team member could then respond to the query. At times, the team engaged in prolonged discussion prior to formulating an answer, particularly when multiple issues were involved. Additionally, a “from page” field in our QuestionPoint Web form captures where the user was when encountering a problem. Often the questions posed had nothing to do with WorldCat Local per se, but with next steps, and that helped to point out where information needed to be more clearly presented. Finally, public services staff were able to collect questions and anecdotes at service desks and send those to the team.

Implementation Team: Library Systems

As mentioned earlier in this chapter, it is important to have the following individuals involved in WorldCat Local implementation:

  • link resolver/knowledge base local manager
  • ILS manager/coordinator
  • consortial/union catalog coordinator
  • Web services manager/coordinator

In this section, we focus on the systems aspects in each of these areas.

Link Resolver/Knowledge Base

One of WorldCat Local's unique advantages is that it incorporates delivery of full-text online content into the user's discovery environment. In order to take advantage of this feature, a library must

  • use OCLC as its sole (or primary) full-text provider, and/or
  • have links in its local catalog records, and/or
  • have a link resolver and knowledge base/coverage database.

Libraries that subscribe to NetLibrary and Electronic Collections Online as their primary online full-text providers will work with their implementation manager to identify the appropriate services and linking in WorldCat Local. Additionally, links that appear in your local catalog record displays (typically in the MARC 856 field of a bibliographic record) will be identified and included in any corresponding WorldCat Local displays.

However, libraries that don't use primarily OCLC for full-text services must have a link resolver and a knowledge base in place to provide access to their full-text e-serial content. At the University of Washington, we use Innovative Interface's WebBridge link resolver in conjunction with e-serial coverage data we obtain from Serial Solutions. Libraries using integrated stand-alone link resolvers (such as SFX) or other hosted solutions (such as Serials Solutions 360Link or Innovative Interfaces CASE) can also take advantage of the OpenURL linking generated by WorldCat Local. To provide access to article full text, WorldCat Local passes an OpenURL to the library's link resolver. The link resolver parses the citation elements of the OpenURL, tests those elements against the library's knowledge base, and provides links to appropriate services (typically online full text) as identified by a library.

Knowledge base scope and link resolution can vary greatly from library to library. In addition to e-serial coverage, the knowledge base may also include e-book holdings or print serial coverage, or it may describe other resources in the collection. Resolution rules (e.g., data tests and corresponding elements) and services provided by the link resolver also vary from library to library. OCLC recognizes this diversity and provides for local customization in identifying when WorldCat Local provides a link that sends an OpenURL to the library's link resolver. In WorldCat Local, the link resolver button (typically labeled “Check for Electronic Resources”) appears in the detailed display. Thus the information necessary to determine whether or not to display the button must be in the WorldCat record and possibly in related holdings records.

At the UW Libraries, we profiled our e-serial coverage and our print serial titles (title and ISSN) in our knowledge base. Given this scope, it was obvious we would want all displays of article citations to include a link resolver button, just as we do with other article citation databases, such as our Proquest and Ebsco databases. Figure 18 illustrates a typical article citation display.

First, notice that because the resource is an article, the Check for Electronic Resources button is displayed. Clicking on this link will send the session over to our link resolver, where full-text links are correctly served. In addition, notice that WorldCat Local has also retrieved and displayed our print holdings for the journal title. However, our print holdings only go to 1998, and the article was published in 2001. Until we load MARC-formatted detailed holdings data for this journal and OCLC checks article date against holdings date (a planned enhancement), article citations will always include a display of our print holdings, whether or not we own the specific issue in which the article appears. In future, print holdings will appear only in article displays where both ISSN and date match.

We determined that there were other times when it was appropriate to send the user to our link resolver. As previously mentioned, we decided to take advantage of OCLC's eSerials Holdings service so that OCLC (working with Serials Solutions) could attach holdings to appropriate WorldCat e-serial records. Great! Now WorldCat users know what e-serials we subscribe to. However, the records we receive from Serials Solutions (our primary source for aggregator e-serial records) lack OCLC record numbers. Because the WorldCat Local default practice for retrieving local availability/status information is based on an OCLC record number search, WorldCat Local is unable to retrieve coverage and linking information from the local catalog. Because e-serial data is also stored in our knowledge base, we asked OCLC to include the link resolver button in any e-serial record display where WorldCat Local was unable to identify a local record as a source for availability/status data. So for e-serial records, when WorldCat Local can't identify a local catalog record that can be used as a source for the link, it will display a Check for Electronic Resources button, which will send a title-level OpenURL to our link resolver. This adds one additional click (through the link resolver display) to the user experience but assures that the user can access the e-serial even without the corresponding OCLC numbers in the local record.

The same practice could be extended to a library's e-book holdings. If a library doesn't have its e-book holdings in OCLC or if its local records lack OCLC record numbers, and if the library profiles e-books in its knowledge base, then OCLC can potentially send an OpenURL (with an ISBN) to a library's link resolver in order to provide WorldCat Local access. Again, this is completely dependent on the library's local cataloging practices as well as the scope and elements available in the library's knowledge base. Depending on the cataloging and linking policies of a particular library, WorldCat Local may be used to provide secondary access for additional types of material. Identifying appropriate situations in which to take advantage of the local resolver will involve work on the part of both the local link resolver expert and the OCLC activation manager (who can identify common types of records or materials where WorldCat Local linking is problematic).

One other note on link resolution: OpenURLs typically include date information. Unfortunately, WorldCat Local–generated OpenURLs include a date, whether appropriate or not, for e-serials as well as for articles. In the case of e-serials, the date appearing in the OpenURL is the beginning year of publication (e.g., Typically, link resolver rules check for both ISSN and date, as both are necessary to identify article coverage. However, if the same data test is used for e-serials, the only links that will be served are those where the e-serial coverage begins with the first year of publication. Note that in order to have all e-serial links served, the library may need to adjust the data tests based both on source (rfr_id=info:sid/ and the format (rft.genre=journal) so that date is not included in the test for WorldCat Local journal-level URLs.

Integrated Library System/Consortial Catalog

This section focuses on system issues related to the local catalog and (if applicable) the consortial catalog. In cases where both exist (the library has a local catalog, and there is a union catalog to which local catalog records are somehow related), there are some questions of which local system should interact with WorldCat Local for any particular operation.

As mentioned earlier, the UW Libraries belong to the Orbis Cascade Alliance, a consortium of 35 academic libraries in Oregon and Washington. The consortial catalog (Summit) is an Innovative Interfaces Inn-Reach system. Inn-Reach catalogs have a number of nice features, including request load balancing, support for local requesting (i.e., filling UW requests with UW materials first), pickup/return anywhere, local customization of pickup locations, and (for Innovative local catalogs) integration with the local catalog circulation module so that Summit circulation happens within the local circulation system. Summit is also supported by a good courier system (with average delivery time across the two-state region of 1.4 days and with fewer than 1% of requests taking more than two days). With this requesting and fulfillment system in place, we decided it didn't make sense to route requests by UW users for UW Libraries materials in a separate work flow through the local catalog (as we had previously when the local catalog was the default catalog). Instead, WorldCat Local would send requests for UW materials and for materials held at other Summit libraries through the Summit system. In doing so, we hoped to make WorldCat Local development a little simpler, as requesting of “returnables” needed to go through only one of two systems, either Summit (if held by Summit libraries, including University of Washington) or ILLiad (for WorldCat resources not held by Summit libraries).

The other choice we needed to make was which system (Summit or University of Washington) would be queried for item availability/status information. WorldCat Local could use a library's attached holdings to identify which system to query (so that WorldCat Local could query the local catalog for UW-held items and Summit for Summit-held items). However, we decided to have all queries sent to Summit for several reasons:

  • Just as with requesting, we hoped that having one destination for item lookup would make for a simpler development process.
  • We were interested in always displaying Summit availability so that if all UW copies were in use, users could identify other copies within the consortium (including those that might be physically close).
  • We were working with a (mostly) correct assumption that the UW catalog was basically a subset of Summit, so whatever was in the UW catalog was also in Summit (remember Inn-Reach systems are closely tied to the local circulation systems, so Summit always shows real-time availability/status).

Some consequences worth discussing resulted from this decision. Differences between local and consortial records can potentially cause matching problems; in our case, such differences resulted in hiding some of our content. Depending on the situation, either we needed to resend our version of the record, talk with other consortium members about retrospective conversion and/or reclamation, and in one case, ask a library to expose its holdings to (this library was a FirstSearch subscriber but had profiled its holdings to not appear in And as will be discussed, differences in loan policies and display terms can also create opportunities for coordination.

Another system-related consideration that needs to be taken into account in a consortial environment is usage. When a library offers WorldCat Local as its default search (and what's the point of subscribing to it if you don't offer it?), local catalog usage changes. The local catalog is searched only when WorldCat Local needs to retrieve item/status information, so your local catalog usage (number and types of searches) will change. In our case, when we decided to use Summit as our WorldCat Local source for item/status information (rather than the local catalog), there were dramatic changes in system usage. Nearly all the searches that had been going to the local catalog were now going to the union catalog, and because they were all coming from one IP (the WorldCat Local server), there was concern expressed by Summit administrators that the Summit server was being attacked in some way. In addition, there were some system performance issues because the union catalog system administration wasn't prepared for what were previously all local UW Library catalog searches to be instead searches on the Summit catalog. In implementing WorldCat Local, the library brings an additional system into the its information environment, so communication is critical. Planning for outages and routine maintenance is also critical. (Who is the contact and what do we do when WorldCat Local goes down or when the consortial or local catalog goes down?) System outage contingency plans should already be in place, but WorldCat Local implementation provides an opportunity to revisit and revise them.

Displays are a critical component of any library service. Because WorldCat Local is built on the platform, displays, navigation, and the general look and feel of the two services are similar, and OCLC has tried to limit the amount of site customization to what is crucial for the library. Thus colors, branding, and a small number of local links appearing in the banner are customizable. Figures 19 and 20 show displays from the University of Washington and State Library of Ohio installations respectively. Other than the banner area of the display, the only other customizable features are the holdings statements and the library scoping (which appear here as the drop-down menu labeled “Libraries Worldwide”). Because the default sort order is by institution (University of Washington/Summit/WorldCat), we decided to leave WorldCat as the default scope, but some libraries may decide to default to their local catalog scope.

Everything else about the WorldCat Local display (i.e., facets on the left, tabs on the title display, record display and placement) are standard across all installations. However, there are some local aspects to the platform (such as order of libraries appearing under the Libraries tab) that are customized based on the user's location.

One other consideration for libraries implementing WorldCat Local is in the area of troubleshooting unexpected system behavior. We have identified significant problem areas (many of which have been discussed in this article), but after a year, we still occasionally run across a problem that we don't remember encountering before. Troubleshooting these problems can sometimes be time consuming. On request, OCLC can provide the data flow diagrams for the display logic used by WorldCat Local. We would highly recommend that implementing libraries get copies of these diagrams to help in troubleshooting problems. More than once, we've been able use these diagrams to identify the reason for a particular WorldCat Local display, and often the problem is not a WorldCat Local problem per se, but might be a loan policy issue or a data problem.

Web Services

It is useful for the library's Web services manager to be part of the implementation effort. WorldCat Local introduces many Web 2.0 features, which may or may not have been included in the library's catalog or Web presence. The Web services manager likely has the most knowledge of these features and is the one to best advise the implementation group in this area. This person can troubleshoot problems that come up regarding browser- and hardware-related issues and is typically also responsible for the look and feel of the library's Web site (and so will provide logos, colors, and other customized display elements). This person will also likely be responsible for integrating WorldCat Local with the library's other Web services. As will be discussed below in the section on cataloging/MARC data, WorldCat Local may not necessarily surface all of your library's resources. We made the decision to retain our local catalog (an Innovative WebPAC) as it provides some search functionality and catalog records that are not currently available in WorldCat Local. But we've made WorldCat Local the default user search experience because of the obvious benefits resulting from integration of discovery and delivery services. Your Web services manager will likely be the one to decide (coordinating with other staff) the best placement and integration of WorldCat Local into your library user's search experience.

Circulation and Interlibrary Loan

WorldCat Local has to be viewed as a delivery tool as well as a discovery tool. Thus, it is important to have someone with knowledge of circulation and interlibrary loan policies and practices on the implementation team. The lines between circulation and interlibrary loan, which are often seen as separate, need to be blurred to bring about seamless integration of delivery for users.

As noted in the section above, we decided to route all requests for UW or Summit materials through the Summit requesting system. All requests for materials not held at University of Washington or Summit would be routed to ILLiad. In thinking about how to integrate delivery into discovery with WorldCat Local, we had to think through the various scenarios and work flows in all three areas: local circulation, Summit borrowing, and ILL borrowing. During implementation, we worked with OCLC staff to develop detailed work flow scenarios and determine at each juncture whether requesting was allowed and what kind of link should be offered to the user.

In order to maximize the full capabilities, it is best if delivery services such as local paging, scanning, and interlibrary loan be robust and well supported. The UW Libraries have long had a program that allowed for local requesting, or paging, of UW materials. Users could request many materials through the local catalog and pick them up at any UW library. We also wanted UW users to be able to request UW materials through Summit borrowing, not only to reduce complexity, but also to support remote users. Over the years, we have worked hard to make sure that local requesting policies aligned with Summit requesting policies as much as possible. However, in implementing WorldCat Local we discovered disconnects, some based on system issues and others on policy.

We had some materials (such as books that circulated for 14 days) that could be requested through the local catalog but not through Summit. There had been local concern about these materials circulating to non-UW sites. This was a policy issue and was resolved by changing our policy and allowing any user at any Summit library to request these materials.

Summit requesting is based upon two factors: the item type and whether requesting is allowed. In WorldCat Local, requesting is based upon the system's being able to determine that materials had the status “Available” when checking Summit for information. This difference in determining availability for requesting also caused a disconnect. We discovered that while we allowed older bound periodicals in storage units to be requested through Summit, they couldn't be requested through WorldCat Local. Some careful investigation was needed to determine the problem. Initially the problem was caused by our WorldCat Local work flows having a “don't allow requests” choice for serials since generally the University of Washington and most Summit libraries did not allow requesting of bound journals. We had OCLC reset the work flows to allow requests of serials if it was determined there were copies available for requesting in Summit. After the change, however, we were puzzled because we couldn't request volumes from storage even though they were coded as available in Summit. We determined that the problem was caused by the serial display in Summit showing only the first 30 volumes of a serial; additional volumes are displayed on a secondary screen. The volumes in storage showed on the secondary screen, but WorldCat Local “pinging” of Summit for availability checked only the first screen. In order to solve this problem, the UW Libraries decided to allow requesting of all bound journal volumes through Summit. This expanded the range of materials available not only to UW users but to users across the consortium.

Cataloging/MARC Data

One of the strengths of WorldCat Local is that it provides appropriate services to the user depending on both the data in the WorldCat record and any corresponding local data in the library's catalog, the consortial catalog, and/or the library's link resolver. In addition, a library can use OCLC services, products, and profiling that will result in an improved WorldCat Local user experience.

One obvious person to be on the implementation team is the person responsible for library catalog (MARC) record policies and practices. This is typically a head of cataloging/metadata, although in some places it might be an associate/assistant director or a (principal) cataloger (whether librarian or staff member). This person (or possibly several people) should be responsible for policy for and/or management of:

  • local cataloging work flow (including identifying where OCLC contribution appears in the local work flow)
  • local library cataloging policies (e.g., use of single vs. separate records in the library catalog, provision of access to online content/links from the library catalog)
  • cataloging projects (retrospective conversion/reclamation) and cataloging priorities

Because the OCLC record number is one of the crucial elements in linking the WorldCat database with the local or consortial catalog, this person (or one of these people) must be able to identify classes of materials that lack OCLC record numbers and should also have the knowledge to develop projects or work flows to improve OCLC record number coverage in the local or consortial catalog.

In addition to having the cataloging expert, it is important to also have the primary OCLC local contact on the implementation team. OCLC provides a number of services, products, and profiling that support or improve WorldCat Local services. These include eSerials Holdings, NetLibrary/Electronic Collections Online, PromptCat, ContentDM, Resource Sharing, WorldCat Link Manager, and QuestionPoint. It is not necessary to have every local contact on an implementation team responsible for each of these services, but it is crucial to at least have the primary local contact know which local experts are needed for consultation.

As previously mentioned, the OCLC record number is a crucial element in linking between WorldCat Local and the local ILS. Thus the OCLC record number must be indexed in your local and/or consortial system. In addition, populating your local records with OCLC record numbers will be one of the major pieces of data preparation any library must undertake. With the exception of some services already discussed, an OCLC record number in the local record is required in order to surface local data (including URLs) in WorldCat Local.

In our experience, several types of local catalog records may lack OCLC numbers:

  • records created prior to a library's use of OCLC (including records that have never been through retrospective conversion).
  • records for which OCLC doesn't lend itself to bibliographic control (such as archival collections), or resources that didn't merit cataloging in OCLC (such as a disposable paperback recreational reading collection)
  • third-party record sets lacking OCLC record numbers (In our case, these consist primarily of Serials Solutions e-serial sets and other microform and electronic sets, such as Early English Books Online or Eighteenth Century Collection Online.)
  • In-process or on-order records that have not yet been through cataloging.

Depending on the library's environment, there may be other classes of records that don't include OCLC record numbers.

The implementation team should be able to identify these classes of materials and come up with strategies to supply OCLC record number or provide alternative access. At the University of Washington, we've had a number of projects to get OCLC record numbers into our local records that lack these numbers. Records still requiring retrospective conversion are a significant portion of those. At the beginning of project planning, we had approximately 18,000 serial records and 1,400 monograph records that have not been through retrospective conversion. For the serials, we contracted with OCLC RetroCon to provide retrospective conversion and batch creation of original records as necessary. Because there are many fewer monograph records needing retrospective conversion, these are being processed by local staff as time permits. We also have some collections that have never been cataloged (including 1,000 environmental impact statements and 2,000 sound recordings). As time permits, we will locally identify and process records for these collections so that they will be surfaced in WorldCat Local.

Libraries that haven't maintained their holdings in WorldCat also have the option of undergoing a reclamation (synchronization) project. In this process, OCLC basically deletes all holdings for a library and reloads the holdings by loading their current catalog records. We decided not to pursue this option because our processes have been pretty closely tied to OCLC and our database is much too large to easily process as a reclamation project.

Vendor set records also may not contain OCLC record numbers. One approach to handle these is to batch load them into OCLC to get record numbers and then to reload them (with OCLC record numbers) back into the local catalog. Record sets that are not allowed to be redistributed (e.g., Early English Books Online) cannot go through this process by the terms of the record set licenses. OCLC is currently in negotiation with record set vendors to allow these records to appear in WorldCat Local (for access purposes) but not to allow catalogers to use these records in the Connexion system.

As previously mentioned, it is important to have your OCLC services contact involved in WorldCat Local implementation as there are a number of OCLC services and products that affect or improve any particular implementation of WorldCat Local. For example, having a PromptCat subscription (or having a local order work flow that includes exporting an OCLC record) may integrate your on-order/in-process materials into WorldCat Local displays. Libraries that use ContentDM can have OCLC harvest their ContentDM metadata. In doing so, OCLC will create MARC records based on library-developed crosswalks, and these records will appear in WorldCat Local. With crosswalks in place, OCLC can provide machine-generated “cataloging” of these digital objects with no additional effort on the part of the library (aside from the original metadata creation).

Other OCLC services can affect a library's WorldCat Local implementation. For example, if a QuestionPoint-subscribing library includes a link to QuestionPoint from all its WorldCat Local pages, additional staff training and QP profiling may be involved. We had several reports of QP requests from our users being picked up by partner libraries whose reference staff would insist, “Articles do not appear in the library catalog” (even though our users had found article citations in WorldCat Local). Of course, resource-sharing services are crucial to the operation of WorldCat Local, and the person responsible for resource sharing should be included in any implementation effort.

Electronic books and electronic serials in WorldCat Local can be particularly problematic. OCLC encourages libraries to subscribe to NetLibrary and Electronic Collections Online as titles profiled in these services will appear in WorldCat Local with no additional effort on the part of the library (beyond having to locally load MARC records provided by OCLC). Other e-book sources are more problematic. Depending on your local cataloging practices (single/separate records and batchload sets vs. individual cataloging on WorldCat), some e-book content may not surface in WorldCat Local. Situations to troubleshoot:

  • If you follow the single-record approach, do the links to your e-books appear in the display for the print book?
  • Are your holdings set in WorldCat on e-book records (and if they are set, do you actually get access to the e-book)?

Providing WorldCat Local access to your electronic serials can be difficult to implement due to data considerations. In the first six months of product development, OCLC implemented some workarounds to help libraries surface their e-serials (and corresponding links). Because libraries often rely on third parties to provide e-serial bibliographic records and different libraries follow different cataloging approaches (single vs. separate records) for e-serials, implementation will require a thorough analysis to determine how best to surface as many e-serial records and links as possible. What follows is based on the analysis and decisions we made to best surface e-serials in our version of WorldCat Local.

First ask yourself: For my library's e-serials, which are represented by WorldCat holdings? For most libraries, the answer to that question likely will be some, but not all. Every library incorporates e-serials into its cataloging work flow in a slightly different way. For which e-serials do you attach holdings in OCLC? When you answer that question, then you know which WorldCat e-serial records will (and won't) surface in search results as held by your library. Libraries that follow the single-record approach (i.e., attaching e-serial holdings locally to print version records) have probably not attached their holdings to the WorldCat e-serial record, but only to the print version record. Because users often prefer online versions, they may retrieve the WorldCat Local e-serial record or use the Internet Resource facet to limit search results to online resources only to determine that (apparently) your library doesn't have access to a particular e-serial. If you have created separate records for all your e-serials and attached OCLC holdings for these, then you are in better shape than those libraries following the single-record approach. At the University of Washington, we follow the single-record approach as much as we can within our local work flows. Thus the only e-serial WorldCat holdings that we have manually attached holdings for in OCLC are those e-serials that we don't already hold in print. For those e-serials that we already hold in print, the only place where the user will see online access is from the print version record.

In addition to e-serials that you process locally, there is likely another class of e-serials that won't surface in WorldCat Local: those that are held in full-text aggregated databases. It is very unlikely that a library will locally process and catalog every serial title in every full-text database. So these will also not appear in WorldCat as being held by the library. If the library believes it is important to surface the records in WorldCat Local, then holdings will need to be attached through alternative means. That alternative is the OCLC eSerial Holdings Service.

eSerial Holdings is a freely available service provided by OCLC that takes data either from your e-serial service provider (the companies OCLC currently works with are Ebsco, Serials Solutions, TDNet, and WorldCat Link Manager) or data that you provide to OCLC and attaches your holdings to the corresponding e-serial records. The eSerials Holdings service is relatively conservative about attaching holdings from this data, so you can be assured that if a record indicates that an e-serial is held by your library, it really is held by your library. E-serial holdings are maintained on a monthly basis. Because OCLC identifies whether a holding is attached directly by the library or through this service, there are very few accidental attachments or deletions of holdings. One of the results of using the eSerials Holdings service is that additional e-serial records will surface in WorldCat Local displays with an indication that you hold the e-serial. More information about the service is available from OCLC.

The next question to ask yourself is this: Are there WorldCat e-serial records to which I have my holdings attached for which my local record lacks an OCLC record number? (Read this question through several times until you are sure you understand it.) Remember, the OCLC record number is the data element that WorldCat Local uses to identify the corresponding local record and to retrieve status and availability information. E-serial records in your local library system may lack e-serial OCLC record numbers. This is true when following the single-record approach, as the local record will be for the print version, not the e-serial. Without the e-serial record in your local system, WorldCat Local will fail when it is unable to retrieve a record based on the e-serial OCLC record number. Ideally, when the library has attached its electronic holdings to the print version record, the library would like WorldCat Local to display the electronic holdings from the local print version record.

OCLC developers created a workaround for this. Knowing that the OCLC record number for the print version record is typically in the MARC 776 (Additional Physical Form) field of the electronic version record, WorldCat Local sends over not only the record number appearing in the MARC 001 field (the OCLC record number) but also any OCLC record numbers appearing in 776$w. If WorldCat Local doesn't match a record in the local system on record number in 001, it then tries record number in 776. The result is that WorldCat Local will identify a print version record to display status/availability information for if it does not match specifically on the e-serial record. Basically what this does is that for serials where we locally follow the single-record approach, both the print and e-serial holdings will display from both the WorldCat print version and e-serial records.

Are there any other e-serial records in your local system that lack OCLC e-serial record numbers? If you load vendor records that lack OCLC record numbers (such as from Serials Solutions, TDNet, or MarcIT), then the answer is yes. Because vendor records typically contain no OCLC record number, it is not possible for WorldCat Local to retrieve the locally loaded record in order to display status/availability information. So in this case (and for all cases where holdings are attached to an e-serial record but WorldCat Local fails to identify a corresponding local system record), WorldCat Local will offer a link to the link resolver (behind a Check for Electronic Resources button). If the e-serial title is included in your knowledge base, then you should be able to provide some form of title-level link (or at least a link to your local catalog) when WorldCat Local linking fails.

One other area where local cataloging policies and practices comes into play is in a consortial catalog. Our WorldCat Local implementation was developed to serve data from an Inn-Reach (Innovative Interfaces) catalog. That catalog has a very specific way of handling record matching and overlay. If WorldCat Local is serving data from a consortial catalog, the implementation team should include someone who understands these processes well. In our case, many WorldCat Local discrepancies could be traced back to problems with the consortial catalog record. One common problem was that the consortial catalog record didn't contain an OCLC record number (even though our local copy of the record does). An understanding of these processes and contribution policies is critical for WorldCat Local to work well within a consortial environment.

Although not critical, there are some additional data projects that will improve WorldCat Local service. Local holdings records (even summary level) will improve identification of holdings statements for articles. In the future, when a serial record has your local holdings record with holdings coded following the MARC Format for Holdings Data, WorldCat Local will be able to identify whether your library holds a particular article that is being presented to the user. Without the local holdings record, WorldCat Local will assume that your library holds any article from a journal to which you've attached holdings. The ability to scope to the branch level (a future enhancement) will also be dependent on having local holdings records that include a branch location.

1. Rob Ross, telephone conversation with Jennifer Ward, April 23, 2008
2. Gibbons, Susan. , . The Academic Library and the Net Gen Student. Chicago: American Library Association; 2007.


[Figure ID: fig1]
Figure 18 

Screen shot of article citation. Accessed May 2008.

[Figure ID: fig2]
Figure 19 

University of Washington's WorldCat Local implementation. Accessed May 2008.

[Figure ID: fig3]
Figure 20 

State Library of ohio's WorldCat Local implementation. Accessed May 2008.

Article Categories:
  • Information Science
  • Library Science


  • There are currently no refbacks.

Published by ALA TechSource, an imprint of the American Library Association.
Copyright Statement | ALA Privacy Policy