Disruptive Library Technology Jester

Are we building the “next generation” catalog for us (librarians) or our users? As a read a report from the Next Generation Summit Search Interface Working Group of the Orbis/Cascade Alliance, I have to wonder. Portions of this report are dated¹ other portions are timeless. In particular, this section from page 2 (emphasis added):

How do we define “next generation”?

The working group has considered what it means to create a “next generation catalog” within the context of the current Summit interface and the current definition of “next generation” as understood within the library community. However, maybe this isn’t the right question. In part, library systems have failed to even keep up with our current generation of users, with neither the library community or vendor community really understanding how a current generation catalog might function. We have ideas from looking at vendor sites and social software tools that provide tagging, faceted browsing, and user reviews, but are these really “next generation”? No, they represent current generation functionality that library systems simply have yet to assimilate into their current service offerings. It’s a dangerous confusion of vocabulary. While these services represent “next generation” services for the library community, they don’t for our users. If a simple makeover of the ILS is to be our aim, then we will continue to fail to provide services for our current generation of users. Our current library information systems are failing our users and inhibiting our users’ attempts to build communities around our services and systems.

Libraries should rectify this problem by seeking to build systems that meet the needs of this current generation, while allowing the library community to plan for and implement functionality that will be necessary within the “next generation”. In part, this is what some libraries are doing — some examples are discussed in this report. North Carolina State University’s utilization of Endeca has been lauded far and wide, but in essence, they’ve simply started to catch up with today’s current generation of users. Yet in just catching up to the current generation, they have distinguished themselves from the rest of the library community. They have placed themselves in a position to look beyond the needs of the current generation of users and focus on the services and needs of the next. At this point, few organizations, including the Alliance, can make such a claim. That, in part, is the challenge facing the Alliance and this working group as it made its assessments.

It would seem helpful to shift terminology, because in doing so we can focus more readily on the needs of our users. They aren’t looking for a “Next Generation” interface. “Next Generation” to us means “Current Generation” to our users. “Next Generation” for our users is “what have you done for me lately?” In order to meet that need, we need a platform that is “developer-friendly.” Again, from the report:

a platform that supports and encourages interaction with the system. This can take many shapes, including OAI harvesting, SRU, OpenSearch or a simple web-services-based API to allow the Alliance to take a more proactive role in developing services.

And, finally, in the report’s recommendations:

Additionally, in researching current and in-development solutions, it became clear that if the Alliance is to continue to meet the needs of its users, it will have to demand greater access to the metadata (holdings, items, bibliographic) found within the catalog. Regardless of who provides the Alliance’s next generation OPAC product, one of the deliverables that must be available as part of any solution is API or web services access to the catalog. Access at this level is important for two reasons:

1. It allows libraries to integrate and share development resources:
   The Alliance members are currently hamstrung by the closed nature of the Summit catalog. The Summit INN- Reach catalog currently only provides two methods of interaction – Z39.50 and HTML access. For developers looking to build services around the Summit catalog, the Z39.50 protocol, as implemented, is currently too limiting and expensive for production development services. All major ILS vendors but III provide their customers a web services or HTTP REST API access to their systems, allowing for continued development around the catalog. Lacking such access, the Summit catalog will continue to be marginalized within the consortium’s academic campuses as tools and services are developed that take advantage of web service friendly applications.
2. Allows for the development of library-created or user-created mashups:
   The Alliance should strive to create a resource that encourages users, libraries, and campuses to develop services around the Summit catalog. The library community has recognized that our patrons want social tools, which we tend to identify as tagging, commenting, etc. However, Web 2.0 applications like Flickr are popular because of the API access that they provide to their users as well. This access has enabled other web services, individuals, and organizations to develop different methods for exporting and utilizing the images placed within the Flickr photo archive. The Alliance should strive to make the Summit catalog open in this way, so that users and members alike are free to enhance Summit to meet individual, campus, or consortial needs.

If it is possible to sum up what we need in “next generation” systems, I haven’t seen more succinctly put than this report.

Footnotes

1. Although the report itself does not contain a date, mention of the report appears in the agenda of a March 2007 meeting of the consortium’s Summit Catalog Committee. [↩]