v29 #2 Optimizing Library Services — The OPAC

by Edward Iglesias  (Web Services Librarian, 204 Mitchell Street, Nacogdoches, TX  75965) 

Column Editors:  Elizabeth Leber  (Promotions Assistant, IGI Global) 

and Lindsay Johnston  (Managing Director, IGI Global) 

Column Editor’s Note:  Promotions Assistant, Elizabeth Leber, joined the IGI Global team in November 2016, and she recently became a column editor for Against the Grain.  Elizabeth earned her BA in English with a focus on secondary education from Penn State University.  She then continued to earn a Master of Arts in Education: Adult Education and Training degree from the University of Phoenix.  Her professional background was primarily focused on enrollment in higher education prior to transitioning to a marketing career in the publishing sector.  Elizabeth currently resides in Palmyra, Pennsylvania.  Most importantly, she is eager to collaborate with the outstanding Against the Grain team for IGI Global’s “Optimizing Library Services” column, which focuses on what services academic libraries can offer in the 21st century. — LJ

 

When attempting to understand the way libraries acquire technology it is important to keep in mind that there was a time when nearly all technology was produced in house.  The helpful Wikipedia article on OPACs (“Online Public Access Catalog.” Wikipedia, the Free Encyclopedia, February 10, 2016. https://en.wikipedia.org/w/index.php?title=Online_public_access_catalog&oldid=704231767) gives a start time to online catalogs around 1975 with in-house systems developed at the Ohio State University.  These were all in-house, locally developed systems since there were no ILS vendors until the 1980s.  The records that went into those systems were developed largely by the Library of Congress in the 1960s (“MARC.”  Accessed April 5, 2016.  http://lili.org/forlibs/ce/able/course8/04marchistory.htm).  The earliest mention of the word OPAC is from around 1976 with OCLC (a library consortium that later became a library vendor) developing the first shared online catalog to be widely used.  Throughout the 20th century, the technology of libraries was very DIY.  Around 1980, all of this changed with the advent of cheap computing and vendors that offered products to libraries that previously only had card catalogs.  Since then, more and more library technology has been purchased as a product from a vendor rather than being developed as a solution by staff.  

Typically the transition from an in-house system to an outsourced system has a specific process:  (1) there are cards that are typed up locally;  (2) eventually this gets outsourced and cards are bought;  (3) this information gets put into a database and is made available electronically;  (4) the online catalog eventually replaces the print card catalog;  (5) librarians who adopted the new platform became experts at searching the in-house system;  (6) the vendor supported system takes its place;  and (7) the in-house system is eventually retired.  The vendor system is not as customizable as the old system, but everyone learns to make do.  These precipitous declines in technology investment, customizability and local control are the hallmarks of outsourcing and will be seen again and again.  As Marshall Breeding reported in 2007:

“New Product Offerings from SirsiDynix” — SirsiDynix Symphony incorporates open, industry-standard technologies, offering the library community features and capabilities including:  a service-oriented architecture (SOA), software-as-a-service (SaaS) options, power library “user experience” portal and search solutions, comprehensive integrated library management and productivity solutions, Java-based staff clients for all modules, fully documented application programming interfaces (APIs), Unicode support, advanced business intelligence and reporting tools, support for SIP2 and NCIP and support for the Oracle relational database management system.  (“New Product Offerings from SirsiDynix: SirsiDynix Introduces SirsiDynix Symphony as New Integrated Library System.”  Library Hi Tech News 24, no. 7 (August 2007): 37–37.)

If this is the state of the art for OPACs, it is helpful to contrast what is gained and lost.  After the first breed of home grown OPACs, the next generation focused on institutions that would largely maintain their own servers and network architecture.  MARC records were loaded locally and were stored on the server.  These records were very similar and had the same access points (author, title and keyword).  Because MARC was designed at a time when memory was very limited, these records were stored in a flat file rather than a relational database.  In order to search these records, there were indexes created at each of the access points.  These records were stored on a system usually designed by information technology specialists at the institution.  All of this meant that while the library had access to its own hardware and software, once a vendor became involved, the control was increasingly out of their hands.  The migration from one OPAC to another requires the vendor’s involvement because it was no longer a matter of just moving records.  They had to be exported with customizations, which may or may not have been supported by the new system.  

A hopeful change to this status quo is the growth of open source systems, which allows much more flexibility and local control.  The tradeoff is the necessity for local expertise, specifically, in house programmers and systems administrators who are comfortable working with documentation and informal online communities as opposed to calling a help desk.  As vendor support costs continue to rise, and the number of experts in open source systems grow, products such as Koha or Evergreen — especially when supported by independent companies such as Bywater Solutions — become much more realistic.

As OPACs became the de-facto inventory control system for libraries, many item types were hammered into place that were never meant to be supported.  Dublin Core records imported from image or document repositories, were the first candidates.  However, the real struggle came as electronic serials grew in prominence.  Library systems and librarians had a great deal of expertise in dealing with paper serials.  With the rise of online database aggregators, content became siloed into various database platforms.  This prompted the need for a tool that would enable users to more easily find and retrieve content, and it would allow users to search across the entire library collection.  Thus, was born the Discovery Layer.  

 

Pin It

Comments are closed.