Customizing an Open Source Discovery Layer at East Carolina University Libraries

The Cataloger’s Role in Developing a Replacement for a Traditional Online Catalog

Marlena Barber (barberm@ecu.edu) is Collection Services & Metadata Librarian at Laupus Health Sciences Library, East Carolina University. Christopher Holden (holdenc@ecu.edu) is Assistant Music Librarian, Joyner Library, East Carolina University. Janet L. Mayo (mayoj@ecu.edu) is Head, General Cataloging, Joyner Library, East Carolina University.

Manuscript submitted July 17, 2015; returned to authors for revision October 9, 2015; revised manuscript submitted December 7, 2015; accepted for publication March 16, 2016.

Open source discovery layers offer the ability to extensively customize every aspect of the search experience for a local user population. However, discovery layers have primarily been discussed in the professional literature in terms of the installation or configuration process. In this paper, three catalogers present a case study of an open source discovery layer implementation with a focus on the problems and solutions from the cataloging perspective.

East Carolina University (ECU) is the third largest school in the North Carolina system, with almost 27,000 students.1 As of January 27, 2015, the university “employs nearly 2,050 full-time, part-time, and temporary faculty.”2 These faculty and students are supported by more than 3,500 staff members.3 In fall of 2014, 27,511 students were served by ECU Libraries, a system that consists of a main library (Joyner Library), Laupus Health Sciences Library (Laupus), and the music library.4 These three very different libraries have a wide range of discovery challenges, from multiple classification schemes and subject vocabularies to differences in desired MARC fields in a brief record display to varying requirements for metadata granularity depending on the subject areas or collections. Such a wide array of needs requires a sophisticated and robust discovery tool that offers maximum potential for users to find and access the information they seek.

ECU Libraries has been using the e-Library software from SirsiDynix’s Symphony line of products for its OPAC since 2009. A 2013 internal assessment of e-Library identified problems that fell into three broad areas: poor relevancy ranking, an inflexible user interface, and cumbersome functionality.5 Because of the proprietary software’s limitations, local customization and improvement of the relevancy of search results ranged from difficult to impossible to implement. Desired features, such as customized bibliographic displays for each library or highlighting search terms in record displays, could not be accommodated. The e-Library interface also failed to consistently index certain MARC elements; for example, the music library found that uniform titles in the 240 field were indexed differently from the same uniform titles found in the 700 field.

To supplement the traditional OPAC, the libraries were tasked in 2009 with reviewing and recommending a discovery tool.6 The decision was made to implement ProQuest’s Summon product. While e-Library is used for traditional OPAC tasks such as title or call number browsing, placing holds, and tracking course reserves, Summon serves as a broader, web-scale discovery tool, allowing users to receive results from all of the ECU Libraries’ resources through a single search.

However, because of the product’s proprietary nature, it was often difficult to understand why certain search results were elevated to the top. In particular, Summon’s interface tended to rank electronic resources higher than physical items, a trait that did not work very well for certain types of searches. Additionally, while Summon’s MARC mapping and faceting was customizable to a certain extent, some desired features remained unavailable. For example, because Summon allowed only a one-to-one mapping between an item and a format facet, librarians were frustrated that certain items, such as digital audio files, could be mapped only as an “electronic resource” or as a “sound recording,” but not both. Summon’s display included several undesirable features that were impossible to suppress, such as the display of foreign language subject headings for faceted searches.

Because both e-Library and Summon are proprietary software, customization was limited. ECU Libraries needed an interface with fewer constraints and increased indexing flexibility to meet user needs for all three campus libraries. The libraries decided to pursue open source discovery layer options as a solution to this problem. Initially, planning and development for a new discovery layer began with VuFind, one such open source option, but the libraries later opted to develop another open source catalog, Blacklight.7

Literature Review

Because discovery layers are a relatively recent phenomenon, the literature about them focuses on certain definitions of what constitutes a “discovery layer,” and discuss libraries’ experiences in setting them up. Moore and Greene point out that many terms have been used interchangeably to discuss these new catalog interfaces, including “next-generation catalog,” or NGC, “discovery layer,” and “web-scale discovery tool.” They differentiate between the three terms as follows:

  1. Next-generation catalogs are public search interfaces that integrate Web 2.0 technologies such as RSS feeds and social media;
  2. Discovery layers are search interfaces that specifically exist apart from the traditional ILS, and may incorporate other discoverable content beyond MARC records, such as digital collections and institutional repositories;
  3. Web-scale discovery tools draw from a central index of vendor and publisher databases of scholarly articles, and the local institution’s MARC records. This allows a user to search across practically every resource to which the library has access.8

A few papers have discussed the failings of the traditional OPAC interface and the problems that discovery layers are intended to solve. Ballard and Blaine note that most OPAC interfaces are “often not intuitive and are inconsistent with well-established user interface conventions” and lack good relevancy rankings.9 Sadler points out that relying on an OPAC interface for discovery purposes removes the development of the interface from the feedback of local users, leading to a lack of customization for individual libraries.10 Ho and Horne-Poppe posit that traditional OPACs frustrate users with their “un-intuitive library catalog interfaces that can’t handle searches that start with articles, that don’t enable easy discovery of similar items, and that don’t allow for interaction with the library records.”11

Open source discovery layers have been developed partially as a way to resolve these problems with the OPAC, and partially as a means to provide an alternative to the proprietary commercial products that are so difficult to customize. Open source products allow a library to extensively customize the search experience while avoiding upfront costs, though programming such software does involve an extensive amount of manpower and technical skills. Two such products, VuFind and Blacklight, are open source discovery interfaces meant to overlay a traditional OPAC. VuFind was developed by Villanova University as an open source alternative to the Endeca discovery layer, a commercial product implemented at North Carolina State University.12 Blacklight development was initiated by the University of Virginia. While both VuFind and Blacklight use SolrMarc, a version of the search utility Apache Solr that specifically works with MARC, to index MARC fields, VuFind uses the PHP scripting language to structure and present the web interface, and Blacklight uses an application framework known as Ruby on Rails for the same purpose.13 Nagy and Katz wrote that VuFind emphasizes easy installation and an “out-of-the-box” approach, while Blacklight allows for more extensive customization for those working in a Ruby on Rails environment, giving libraries the ability to provide a diversity of displays for different items, facets, and branch libraries.14 Nagy and Katz assert that Google and other search engines have changed the discovery landscape and user expectations, and the relational database structure of the OPAC does not allow for the speed or relevancy that Solr indexes can provide.15 They make the case that VuFind’s capability to offer post-search faceting, synonym matching, stemmed searches, and spelling correction position it as a marked improvement over the traditional OPAC.

Ballard and Blaine also believe that faceting is a major advantage of discovery layers, pointing out that users were fifteen times more likely to refine their search in a faceted environment than a traditional OPAC in which all refinements had to be entered at the time of the search.16 Sadler appreciated the “tremendous advantages in terms of flexibility in defining what is indexed and how it is searched” within Blacklight and points out that discovery layers can be customized even for branch libraries within a single institution.17 She mentions a customized interface for the University of Virginia music library, which included an index of instrumentation, and the ability to search for musical works by “date of composition.” La Barre mentions the importance of analyzing and customizing facets before the implementation of a discovery layer.18 Leebaw reports that feedback from users on their VuFind implementation revealed that users are very interested in accessing specific collections such as films, sound recordings, and reference materials, using facets.19

Many authors praised the flexibility of open source discovery layers, which provide the ability to devise customized solutions to local problems. Leebaw writes, “Being able to immediately incorporate feedback is one of the best advantages of implementing an open source overlay.”20 This kind of customization can create local solutions for specific groups of researchers and library users. For example, Sadler points out that the University of Virginia created a music controller in Blacklight that incorporates slightly different relevancy rankings and facets than the standard search controller.21 She writes that this is a significant departure from the traditional OPAC, “which assumes that there can be a single interface that will be good enough for most users, and that this interface must be managed centrally.”22

Several papers discussed the impact that discovery layers can have on music materials in particular. Snyder conducted a survey of School of Music faculty and graduate students at the University of Chicago following that institution’s implementation of the AquaBrowser faceted catalog. Survey respondents appreciated the format facet in particular but that faceting for categories such as “genre,” “geographic region,” and “era” was inconsistent and confusing.23 The Music Library Association’s report on discovery requirements indicated that some data, such as the “date of composition,” have been used inconsistently and would be difficult to take advantage of in a discovery environment.24 The report touches on several important requirements for the discovery of musical materials, such as the ability to map multiple formats to a single item, the continued use of text strings for subject headings and uniform titles, and the ability to implement authority control and take advantage of the data in authority records.

There are many comparisons of discovery layers to the Google search engine, with writers pointing out that Google’s ubiquity in the discovery landscape has led to a major shift in expectations among users. Katz and Nagy note that users now prefer a “self-service-oriented approach to searching.”25 However, Ballard and Blaine worry that the “Google-esque” single keyword search query box may not be enough for many academic libraries, and a link to a more advanced search page may still be necessary.26 Leebaw agrees that the “Googlization” of library resources does not always advance the library’s discovery goals and points out that reference librarians raised some concerns about discovery overlays.27 This relates to the trend noted by Moore and Greene that public services librarians are often involved in the process of setting up the discovery layer, which makes them more likely to buy into the completed product.28

A recurring caveat throughout the literature is that developing a local open source discovery layer requires significant amounts of time and in-house programming knowledge. While both VuFind and Blacklight have basic default configuration settings, taking advantage of local customizations and other flexibilities requires a great deal of technical skill. Skinner summarizes GIL-Find, a Georgia-wide implementation of VuFind, and notes that “it would be unlikely for more than a few of the largest universities in the Georgia system to have the staffing or the expertise to adapt an open source product such as VuFind at the local level.”29 Emanuel goes so far as to wonder if next-generation catalogs will create a new “digital divide” between those libraries that can afford to implement an open source product and those that cannot.30

As detailed later in this paper, the university’s Blacklight implementation was contingent on the presence of strong, knowledgeable programmers working for the libraries. Throughout the literature, there is extensive scholarship on the history of next-generation catalogs and aspects to consider when choosing one. However, there is little to no scholarship on the process of setting up local customizations for a next-generation catalog. The intellectual effort to set up the indexing and display of various MARC fields is a significant investment; additionally, the programming knowledge needed to implement these customizations is also important. Each library’s open source installation will differ according to local needs, and perhaps this factor has led to a lack of scholarship describing the process.

Mapping

From the beginning of the project, it was agreed by all parties at the ECU Libraries that intense customization of the discovery layer was needed to specifically address research issues unique to ECU and to fix problems that had been identified with previous search tools. Initially, planning and development for a new discovery layer began with VuFind, an open source option. Throughout the development of VuFind, comments from the university libraries’ Discovery Advisory Board (DAB) were considered and addressed by the catalogers and members of the Application and Discovery Services (ADS) department. The DAB is a library-wide committee that considers all the libraries’ discovery initiatives and includes both public services and technical services faculty and staff from all three libraries. The catalogers and members of the ADS department began to reconfigure the out-of-the-box VuFind product to meet the needs of all the libraries’ user groups, and a working group was assembled to customize the public interface. Using a wiki, they assembled a list of “canned search suggestions” for search testing, and provided ongoing suggestions and feedback. Meanwhile, a cataloging subcommittee consisting of all catalogers and the ILS administrator, met to discuss which MARC fields needed to be indexed and displayed to meet the needs of the larger working group. Despite the default MARC mappings included with the initial VuFind download, the catalogers thought it best to spend a considerable amount of time refining these defaults to maximize discoverability and address the unique needs of specialized researchers at the university. Over the course of their meetings, they discussed indexing for keyword and browse capabilities of various searches (title, author, subject, etc.) and the display of specific fields and subfields in the item-level view. The library staff tasked with customizing the discovery layer used the PBworks wiki, a collaborative online editing system already being used by the library for other projects, as a working space.31 Meeting minutes and documentation including test search terms, mapping decisions, and comments on the current OPAC, were all included.

During the customization process, Joyner’s Discovery Services Librarian, in consultation with her team, made the decision to switch from VuFind to Blacklight. She shared with the DAB that there were performance issues with VuFind for which she and her team were unable to secure satisfactory solutions from other adopters or the VuFind development community. Other reasons cited for the switch were stronger partnerships with other universities that had implemented Blacklight, a more robust development community, the complex customizations offered by Blacklight’s Ruby on Rails environment, and the University of Virginia, also a SirsiDynix Symphony institution, was a Blacklight development partner. All of the MARC mapping work initially done for VuFind was directly transferrable to Blacklight.

The process of mapping MARC fields for a discovery layer was not unfamiliar to the libraries, as the catalogers had previously engaged in reviewing and replacing the default MARC mappings for the libraries’ instance of ProQuest’s Summon. Initially, the catalogers reviewed the default VuFind mappings, and then customized them to meet the needs of differing user populations across all the libraries, drawing on knowledge of these populations gained from direct interactions with the users or from discussions with public services personnel. Specific user communities, such as Laupus’s users, the music library’s users, and the Teaching Resources Center’s users, were discussed in detail, along with specific material formats (musical scores, media, kits, and government documents).

While the default MARC mapping settings provided a good starting point for discussion, it was agreed that these settings were inadequate for the libraries’ catalog. Many important subfields were initially not mapped or completely ignored in the defaults, and the catalogers had to identify these and add them as necessary. For example, the default “author” keyword search did not consider such fields as the 245 $c (the transcribed statement of responsibility), or any entities in 8xx fields (which include author and title information of series). These were deemed extremely important to include in the author index, and promptly added; without them, any author keyword search would be missing vital information such as the name of the author as transcribed from the title page.

As another example, many subfields for uniform titles were ignored; VuFind’s default settings included only the 240 $a and 700 $t subfields in the title index. This ignored the multiple subfields used extensively by the music library for musical uniform titles, and their use in other formats. The 240 field was customized so that the discovery layer took into account subfields $a, $d, $f, $j, $k, $l, $m, $n, $o, $p, $r, and $s for a title search, plus subfield 700 $k, $l, $m, $n, $o, $p, $r, $s, and $t. The addition of these fields allowed searches to take into account more than simply the first few words in a musical uniform title. For example, the uniform title for Mozart’s Clarinet Concerto is Mozart, Wolfgang Amadeus, $o 1756–1791. $t Concertos, $m clarinet, orchestra, $n K. 622, $r A major. Adding these subfields now allowed keywords like “clarinet,” “A major,” or the thematic catalog number “K. 622” to come up in searches, allowing keyword searches such as “Mozart clarinet concerto” or “Mozart concerto K. 622” to function. These new fields were given a specific relevancy “weight,” so that the 245 field would still function as the title field with the highest relevancy, but other title information in the 240 and 700 fields would be considered. These omissions from the default settings indicate the importance of a thorough review by trained catalogers before implementing any open source discovery layer.

The MARC mapping for e-Library’s alphabetical browse search was compared to the default alphabetical browse settings for Blacklight. Changes were made to Blacklight’s browse search to correct deficiencies in e-Library’s browse indexes and to ensure that each index corresponded with its search function. The general material designation (GMD) was considered outdated and removed from display. While this may be considered a radical step, the catalogers thought that with RDA’s elimination of the GMD and Blacklight’s ability to facet based on material format, it was no longer needed. Other changes included tweaking mapping so that uniform titles in the 7XX fields would be treated in the same way as their counterparts in the 240 field. Care was taken to separate the subfields specific to personal names from the subfields specific to uniform titles, with the idea that uniform titles could be displayed in a dropdown menu next to the author’s name in the index. Subfields considered important to identifying titles in the 245 field, such as $n and $p (number and name of a part or section of a work), were added to display.

The classification facet was another aspect of the discovery layer that provided additional functionality lacking in the older OPAC. Users could choose a facet that represented a specific section of call numbers, allowing post-search browsing for specific subject areas. The default set up was only for Library of Congress Classification (LCC); however, for the health science library users, National Library of Medicine (NLM) classification was included (highlighted in figure 1) to interweave seamlessly with LCC. Joyner’s Teaching Resources Center includes books classed using Dewey Decimal Classification, and the music library classifies all media holdings using a non-subject-based alphanumeric model. These were not included in the call number facet; however, all call numbers remain searchable using a call number keyword index.

With previous search tools, many users and librarians at the university expressed frustration with the “format” search limiter in e-Library. This format function was limited to a one-to-one mapping between a system-specific format type and a bibliographic record, meaning that some types of items had to be filed under “format” labels that did not adequately describe them. For example, streaming audio recordings could be filed under the “e-resource” format or the “audio recording” format, but not both. Because of this, a decision was made to use only MARC bibliographic data to map the format facet in the discovery layer, rather than relying on the OPAC’s proprietary “item type” information. The libraries began with the format values that existed within e-Library before adding their own additional formats that were not previously available. For example, under the new list, one could differentiate between “maps,” “globes,” and “atlases,” whereas before each of these was available only under “maps” (see figure 2). Additional facets for “print” and “electronic” were developed to allow users to limit their searches according these terms. Each format was assigned a mapping using MARC fixed field data. By mapping MARC values to the format facet in this manner, the catalogers could now ensure that a resource encompassing multiple formats was discoverable under all applicable formats. However, this required a great deal of time and effort refining the format facet to account for all the fixed field data in MARC records, and led to the discovery of certain errors within the university libraries’ bibliographic data.

Errors

Errors were found in many records at the beginning of the Blacklight testing phase. The aforementioned “format” function proved to be one of the most difficult to develop. Because the university libraries had relied on proprietary item types for format mapping, rather than using MARC bibliographic data, there were many gaps and issues in format fields such as the 006 field, the 007 field, and numerous fixed fields.

Blacklight did not initially recognize the hand puppets held by Joyner, categorizing them as “unknown”; the format mapping was updated to correlate the material type “r” (for realia) with the format facet “physical object.” The music library found that preliminary format mappings had marked long-playing (LP) records as globes. This was not due to poor mapping, but rather due to extensive cataloging errors in the bibliographic records themselves. Graduate assistants were trained to edit the 007 fields of over 600 LPs to make sure they were assigned to the correct format. A similar problem occurred for several hundred monographs. The presence of “t” in the Leader/06 byte is primarily for manuscripts; however, the Libraries uncovered many non-manuscript books with the “t” in this byte. Many were manually investigated and changed to prevent their inclusion in the “Archival and Manuscript Materials” facet. Through updating the faulty data in hundreds of catalog records and refining the format mapping based on a more intimate knowledge of the fixed fields, catalogers resolved all “unknown” and incorrect formats in the Blacklight results. Another example of format-related errors were items that were included in both the “print” and “electronic” facets. While some of these were correct (such as a book with an accompanying CD-ROM), a large number of records had elements of both the print and electronic manifestation in their fixed fields. Many of these were vendor records that had been improperly coded; others were records with fixed fields that had not been appropriately updated when they were derived from existing records and contained faulty data that were generating inaccurate mapping.

Though labor-intensive, fine-tuning the format facet eventually proved to be beneficial to the libraries. By incorporating such fields as the 006 and 007 fields into format mapping, the discovery layer could now take into account records representing multiple formats, whereas previously only the “dominant” format could be mapped to the record. Rather than mapping items to an “electronic resources” format, users can now select “electronic” and “book,” or “electronic” and “video” to fine-tune their search by both medium and physical carrier.

An additional class of non-format errors involved previously undetected irregularities in subfield assignment. For instance, Blacklight flagged many instances of repetitive or incorrect usages of the subfield b in the 245 in many records with AACR cataloging, which required correction. These errors appeared in reports generated by Blacklight as files of records were imported because the MARC 21 standards are integrated in the Blacklight software.

Another problem that became evident soon after the beta phase began was that items with copyright dates for years beyond the current one were not populating to the top of the results list when a user chose to sort by most recent publication date. A customization was quickly added so that the dates up to 9999 in the 260 or 264 date fields would display at the top of the “most recent” results list; this solved the problem for those books with future publication and copyright dates.

The errors uncovered showed the importance of clean, correct, and consistent MARC data in all fields. Many were the result of varying cataloging practices over several decades. The fixed fields in particular received a lot of attention; while many of these had not been used by the previous OPAC, they quickly became important with the new discovery layer. The tremendous workload involved in fixing problems was a useful reminder to curate good MARC data, regardless of which fields are used by the current software.

Relevance

The Libraries found that the ability to customize the relevance ranking was crucial. Blacklight allows librarians to customize the relevancy “weight” given to each MARC subfield, ensuring that certain fields (e.g., 100, 700, 245 $c) are weighted highly for certain methods of searching (e.g., author search). Unlike proprietary OPACs, with a “black box” relevancy system that remains mysterious and unknown, librarians can see the nuts and bolts in Blacklight and customize accordingly. For example, the music library ensured that the specialized music MARC fields were given proper weight in the relevancy engine; it is unclear and difficult to tell if this was the case in the previous proprietary OPAC.

Using e-Library, a keyword search for the famous nursing theorist “Virginia Henderson” failed to retrieve any of the works written by her or with her name in the title until the second page of results, even with the “sort by relevance” option selected. In contrast, a search for “Virginia Henderson” using Blacklight’s search box provides truly relevant results with works written by her and with her name in the title populating within the first results. The university libraries fine-tuned the relevancy to the point that a search for the Beatles’ album Help! and Kathryn Stockett’s novel The Help each yielded the correct result in the first hit, even with only a one word difference between the two generic-sounding titles. This was done by creating a separate index with stopwords such as “the,” “and,” and “a” that was given a slightly lower relevancy weight than the main keyword index with all non-stopwords. By manipulating the relevancy of stopwords in this way, it ensured that they were taken into account when there were two records with a close match, separated by only a stopword (such as Help! and The Help) but also that a search without stopwords included would still bring up the relevant records.

Unique Customization

The libraries used fixed field data to represent a particular format held in the e-Library catalog: the Electronic Theses and Dissertations (ETD) collection. In e-Library, the decision had been made to create a specific format for these that could be used to find institution-specific theses and dissertations. However, these ETDs provided nothing within the MARC bibliographic record to indicate their status, so their format functionality was lost within both Summon and the default Blacklight discovery layer. To solve this problem, the libraries developed a facet that searches for the words “East Carolina University” in the 502 field, and looks for local item data from the ILS output in the 999 field. This allowed for the creation of a “Local theses and dissertations” format.

In an open source discovery layer, it is possible to customize the indexing of fields that are displayed on the basis of MARC indicators. This function had been problematic in e-Library. The ability to refine by indicator is very helpful to differentiate between each 856 field that displays. In ECU’s current e-Library setup, if a record contains an 856 field, a customized “Online Content” button is generated. However, this button can be misleading, as “Online Content” can refer to any manner of supplemental content, such as an online table of contents for a print book. In their Blacklight discovery layer, however, the libraries were ensured that such a button appeared only for those items with full-text content available online. This was done by using the 856 field’s second indicator, which indicates the kind of online content available. An 856 with a second indicator 2, for example, indicates a “related resource” is available online; these did not receive an “Online Content” button, but instead were displayed as “Supplemental Content.”

In some cases, uneven cataloging practices limited what could be done with indexing customizations. An 856 with a second indicator 1 means a version of the resource is available. This often includes tables of contents and not the full text, which can be problematic for users. However, identifying all 856 41 fields as “Supplemental Content” would have excluded thousands of PURLs (Persistent Uniform Resource Locators) on federal document records that link to full text from displaying as “Online Content.” Because PURLs are not the actual resource, but rather a version of the resource, many have been appropriately coded as 856 41, making it difficult to correctly identify which 856 41 links feature full-text content, and which feature supplemental material.

The Libraries also customized the MARC fields that are displayed when a results list is generated after a search. There had been problems with e-Library, which allowed only a finite number of MARC fields to display in a search results list. The various campus libraries each valued different fields in this brief display, depending on their users’ needs. Laupus, for example, felt the display of the 250 field (edition statement) was of great importance for a user selecting the proper item (see figure 3) In contrast, the music library preferred the display of the 300 field (physical description), so that users could distinguish between different kinds of published scores (see figure 4). While e-Library could not accommodate multiple displays for items from different libraries, it was relatively easy to program an open-source discovery layer to do this. Now, items display in a search results list with an edition statement if housed in Laupus, and with a physical description statement if housed in the music library. This customization allowed the discovery layer to specifically serve each library’s user base.

Future Considerations

While many of the developments of open source discovery layers focus on enhanced relevancy and accuracy for keyword searching, long-standing practices in information organization, along with the looming future of BIBFRAME and linked data models, mean that authority control practices remain relevant for facilitating discovery. From the beginning, librarians at the university have been committed to retaining all functionalities of the older OPAC, including browse lists, authority links, and utilization of see and see also references in authority records. Other libraries have expressed the desire to implement these features, such as the plan to implement cross-references in the University of Georgia’s GIL-FIND.32 In the short term, the university libraries plan to create browse lists that take advantage of authority records in the same way as most OPACs. While Blacklight lacks a default function that allows this, programmers remain optimistic about its implementation. VuFind documentation has recently been updated with instructions for implementing alphabetical browse lists, showing the possibility of creating such lists within a Solr system.33

The future holds bigger aspirations for using authority records in discovery layers. Katz and his colleagues make the case that “the value of rich authority data should be shared with everyone, not just catalogers.”34 One idea is to harvest the cross-references in subject thesauri such as LCSH and MeSH for keyword searching, with a keyword term simultaneously querying all related terms. This has been proposed by Pace and other developers, and PubMed has created a system like this using MeSH terminology.35 Another possibility for using authority data is to use the recently added RDA-compliant MARC fields in authority records. The 37X fields, for example, contain a wealth of robust information; to cite one specific example, the 373 field could perhaps be used to allow one to search for works by faculty members associated with the university (see figure 5).

It remains to be seen what the future holds for authority records, and how authorities will be administered in new schema such as BIBFRAME. Regardless of future developments, open source discovery layers will allow libraries to customize their setup and experiment with different methods of taking advantage of this data.

Conclusion

Through customizing an open source catalog, the university libraries gained an understanding of the inner workings of how the data could be manipulated in a way that best meets the users’ needs. An important lesson learned was not simply to accept an open source product’s default settings. While VuFind or Blacklight can be a powerful tool, implementation is not simple. Many hours of work were necessary to clean up errors and set up the indexing and display functions that were present in the older OPAC, and additional hours were needed to establish added features. The implementation also revealed previously unaddressed cataloging errors that required significant clean-up. This process requires the time and staffing to perform a systematic review of MARC mappings for indexing and display, and a working knowledge of the features desired by users and other stakeholders.

Such an understanding should help catalogers to more easily comprehend how data will be manipulated in other item description environments. Additionally, the collaboration between public and technical service departments from the three university libraries has led to continued cooperation and increased efficiencies. Finally, all three libraries, with their unique materials, classification and subject schemas, and user groups were able to customize a product that effectively takes all of those areas into account.

References and Notes

  1. East Carolina University, “Measures of Success,” last modified February 2, 2015, www.ecu.edu/cs-admin/news/measuresofsuccess2014.cfm.
  2. East Carolina University, “ECU at a Glance,” last modified September 22, 2014, www.ecu.edu/cs-admin/mktg/points_east_facts.cfm.
  3. Ibid.
  4. East Carolina University, “Fact Book 2014-2015,” accessed January 27, 2015, www.ecu.edu/cs-acad/ipar/customcf/DL/FB/FactBook14-15.pdf.
  5. An Assessment of the Integrated Library System Currently Shared by the Libraries of East Carolina University and Elizabeth City State University (working paper, East Carolina University, Greenville, NC, 2013).
  6. Elizabeth Ketterman, Megan E. Besaw, and Michael Tucker, “Rethinking How Patrons Discover Information: Implementing a Discovery Tool,” accessed July 14, 2015, http://thescholarship.ecu.edu/handle/10342/3506.
  7. SirsiDynix offers next-generation catalog products such as Enterprise or BlueCloud PAC; however, these were still in the early stages of development when ECU Libraries began to look for other discovery options, and were not considered a viable replacement at the time.
  8. Kate B. Moore and Courtney Greene, “Choosing Discovery: A Literature Review on the Selection and Evaluation of Discovery Layers,” Journal of Web Librarianship 6, no. 3 (2012): 146.
  9. Terry Ballard and Anna Blaine, “User Search-Limiting Behavior in Online Catalogs: Comparing Classic Catalog Use to Search Behavior in Next-Generation Catalogs,” New Library World 112, no. 5–6 (2011): 262.
  10. Elizabeth Sadler, “Project Blacklight: A Next Generation Library Catalog at a First Generation University,” Library Hi Tech 27, no. 1 (2009): 58.
  11. Birong Ho and Laura Horne-Poppe, “VuFind—An OPAC 2.0?” in New Directions in Information Organization, edited by Jung-Ran Park and Lynne C. Howarth (Bingley, UK: Emerald, ٢٠١٣), ١٥٩–٧١.
  12. John Houser, “The VuFind Implementation at Villanova University,” Library Hi-Tech 27, no. 1 (2009): 95.
  13. Demian Katz and Andrew Nagy, “VuFind: Solr Power in the Library” in Library Automation & OPAC 2.0: Information Access and Services in the 2.0 Landscape, edited by Jesus Tramullas and Piedad Garrido (Hershey, PA: Information Science Reference, 2012), 93.
  14. Ibid.; Kate B. Moore and Courtney Greene, “The Search for a New OPAC: Selecting an Open Source Discovery Layer,” Serials Review 38, no. 1 (2012): 28.
  15. Katz and Nagy, 74.
  16. Ballard, 267.
  17. Sadler, 58.
  18. Kathryn La Barre, “Faceted Navigation and Browsing Features in New OPACs: Robust Support for Scholarly Information Seeking?,” Knowledge Organization 34, no. 2 (2007): 86.
  19. Dayna Leebaw et al., “Improving Library Resource Discovery: Exploring the Possibilities of VuFind and Web-Scale Discovery,” Journal of Web Librarianship 7, no. 2 (2013): 178.
  20. Leebaw, 175.
  21. Sadler, 59.
  22. Ibid., 58
  23. Tracey Snyder, “Music Materials in a Faceted Catalog: Interviews with Faculty and Graduate Students,” Music Reference Services Quarterly 13, no. 3-4 (2010): 71–72.
  24. Nara L. Newcomer et al., “Music Discovery Requirements: A Guide to Optimizing Interfaces,” Notes 69, no. 3 (2013): 503.
  25. Katz and Nagy, 73.
  26. Ballard, 265.
  27. Leebaw, 165.
  28. Moore and Greene, “Choosing Discovery,” 155.
  29. Debra G. Skinner, “A Comparison of Searching Functionality of a VuFind Catalogue Implementation and a Traditional Catalogue,” Library Trends 61, no. 1 (2012): 209.
  30. Jenny Emanuel, “Next Generation Catalogs: What Do They Do and Why Should We Care?,” Reference & User Services Quarterly 49, no. 2 (2009): 118.
  31. “PBworks Overview,” CrunchBase website, accessed December 1, 2015, https://www.crunchbase.com/organization/pbworks#/entity.
  32. Skinner.
  33. Demian Katz, “Alphabetical Heading Browse,” VuFind website, last modified January 26, 2015, https://vufind.org/wiki/alphabetical_heading_browse.
  34. Demian Katz, Ralph LeVan, and Ya’aqov Ziso, “Using Authority Data in VuFind,” Code4lib Journal 14 (2011), http://journal.code4lib.org/articles/5354.
  35. Kristen Antelman, Emily Lynema and Andrew K. Pace, “Toward a Twenty-First Century Library Catalog,” Information Technology & Libraries 25, no. 3 (2006): 128; National Center for Biotechnology Information, “Entrez Help,” last modified April 9, 2014, https://www.ncbi.nlm.nih.gov/books/NBK3837/.
Example of Classification Facet Mapping

Figure 1. Example of Classification Facet Mapping

Example of Format Fact Mapping

Figure 2. Example of Format Fact Mapping

Example of Search Result for Health Sciences Library Item

Figure 3. Example of Search Result for Health Sciences Library Item

Example of Search Result for Music Library Item

Figure 4. Example of Search Result for Music Library Item

Example of MARC Authority Record with 373 Field

Figure 5. Example of MARC Authority Record with 373 Field

Refbacks

  • There are currently no refbacks.


ALA Privacy Policy

© 2024 Core