Some stormy weather and delayed flights resulted in some last minute changes to the day-long session, Implementing the Next-Generation Catalogue: Taking it from Talk to Action. In the end, SirsiDynix vice-president Stephen Abram couldn’t attend, and two presenters communicated by phone and remote web access.
Leading off the session was Beth Jefferson of BiblioCommons, the Knowledge Ontario initiative to create a Canada-wide common interface to library catalogues and user accounts. While BiblioCommons would not fully replace HIP, it takes over a number of HIP’s functions. MARC records are loaded into the BiblioCommons system where they are then indexed. Some library-specific functions, like remote patron authentication to e-books and other electronic resources would eventually be done by BiblioCommons.
BiblioCommons should not be compared to HIP. The comparison that needs to be made is between BiblioCommons and other layered-on catalog interfaces like Endeca and Aquabrowser. These new interfaces mix together imported local cataloguing data with data and services from elsewhere, and typically exist outside the organization. I heard from Wayne Jones, head of Technical Services at Queens University (Wayne Jones was my supervisor at a co-op job at the National Library of Canada in 1990). He had previously indicated that Queens was looking at Endeca (McMaster University Library uses this), but Queens has now decided to go with BiblioCommons. Wayne Jones had said that the familiarity and simplicity of Google and Amazon (the AmaGoogle monster, as he called it) are the key drivers for students to shun the catalogue or complain about its current design. He said that current OPACs are based on 10-year old designs that badly need to be updated.
Two primary motivations for BiblioCommons and other next-generation catalogues– fix the catalogue and engage the users.
"Discovery"– the initial online search for books– is increasingly done at Amazon and similar sites first. The library catalogue is checked at the end of the discovery process. This process appears to be OK with users, but it suggests libraries are not doing all they can.
The library has a place– book clubs and book discussion groups are among the most popular activities on the web, but libraries can be there too.
In the library, browsing shelves and checking the just returned books are two popular "discovery" methods. This is a form of social networking, user "data" providing fruitful suggestions for further reading– what web 2.0/library 2.0 is all about. Why shouldn’t the library catalogue be designed to take advantage of this natural behaviour to enhance usage of the library’s resources?
BiblioCommons is currently in beta testing at Oakville Public Library. Many small changes were made based upon user feedback. People can sign-in with a username instead of barcode. When providing tags for books, the data entry box now provides an autosuggest feature. Instead of a feedback link, there are big white boxes at the bottom of screens inviting comments, and a large submit button. The beta testers found many small changes resulted in big improvements to the service.
Adding the BiblioCommons service on top of the catalogue involves several steps. 1) a data dump of MARC records into BiblioCommons. 2) mapping our MARC records and local choices to the BiblioCommons database (this can get hairy as was indicated– an understatement from my own experience). 3) installation of a thin client on the library’s ILS– this thin client connects to the BiblioCommons database (nightly for bib records, real time for item information).
One feature now considered standard in all next generation catalogues is faceted searching. Facets are like limits, except the list of facets are pulled from the result set (so there will be no facet for "DVD" if there are no DVDs in the result set, whereas "DVD" will always appear as a limit option, perhaps misleading users). Again, ALL new library catalogues will include a facet option, and this means a lot of data in MARC records never used before will be made visible (more quality checking of MARC records would likely be required — but this would result in a positive development for patrons since I had heard that faceted searching has been received positively by those who have tried it). As for other ILS vendors: SirsiDynix has partnered with BrainWare to build a faceted interface [now called Enterprise], Innovative Interfaces has developed a faceted interface called Encore, and Ex Libris has a faceted interface called Primo.
Karen Coyle, a digital libraries consultant from California, also gave a presentation. She had started the Next Generation Catalog mailing list, to which I have contributed. Karen Coyle is the one who actually put together the final report of the Working Group on the Future of Bibliographic Control, the report from the Library of Congress written because of the outcry over its decision to stop creating series authorities. She did not take responsibility for the content– in fact, she found the report tough-going and a little contradictory.
She did agree with the basic directions that library catalogues need to go in that were enumerated in the report. Library catalogues need to be "in" the network. When searching a book title on Google, the first results include the book from Google Books or from Amazon (or both). In addition, an ideal catalogue should have no dead ends– the user interface should always be able to take the user to other places (what being "in" the network is all about). The wealth of information on a Wikipedia entry for a book title can be astonishing.
Libraries do produce good bibliographic data, but it’s buried or trapped in information silos. OCLC WorldCat Identities is a good example of what can be done with existing library data. The range of library catalogue data associated with an author can be consolidated on a single web page. WorldCat Identities is an example of what the semantic web is all about. Libraries can take the lead in being holders of trusted, registered data about bibliographic entities on the semantic web that can then be used by anyone on the web.
Gail Richardson of Oakville Public Library gave a presentation on her library’s beta testing efforts with BiblioCommons. She highlighted the "community credits" feature to motivate users to supply social networking data such as tags, ratings, and reviews. Users become eligible for prizes when they enter more social networking data (although many users, such as Gail herself, do it for the fun of it).
Gail’s quote is now the BiblioCommons slogan: "Using the collection to build connections".
A technical overview of BiblioCommons was given next. Most of the catalogue’s user interface would be handled by BiblioCommons but Horizon and HIP libraries would still need their respective servers. Sirsi Unicorn has an API that can be used directly by BiblioCommons (other ILS’s also may not need an OPAC web server with BiblioCommons). When designing BiblioCommons, it was discovered that some existing protocols like NCIP and SIP were not adequate, and so new APIs were written. For an ILS server, even with the addition of the client software, there is no significant incremental hit on traffic when used with BiblioCommons.
BiblioCommons requires no local support and uses a simple locked down port on a library’s firewall. The BiblioCommons servers use the same redundant model as the big data-hungry web players like YouTube and Flickr. BiblioCommons uses 24-hour security, backup diesel generators, redundant Internet connections, and grid computing/virtualization of servers. The software language is the hot new JRuby, which combines the scalability of Java and development agilty of Ruby on Rails.
John Blyberg appeared in teleconference mode. He is responsible for the pioneering catalogue interface work done at Ann Arbor Public Library. Even with all the work done at Ann Arbor, he said that the newer methodology used in BiblioCommons is much better. The earlier work involved too many workarounds– too much effort was spent in not touching the underlying catalog data by using reverse proxies and catalog wrappers. The new methodology is SOA — Service-Oriented Architecture, where functionality is decomposed and separated from the underlying systems and languages. The services then communicate with each other by passing data from one service to another. In the case of library systems, this means separating the database from the application layer and then those two from the presentation layer.
Later on the phone was David Fraser, a legal expert from Halifax, considered one of the most renowned privacy experts in Canada. With the user-supplied data at the centre of BiblioCommons, the legal issues with privacy needed to be worked out. Privacy is not just about confidentiality anymore– it’s about empowering individuals and giving them control as to how their personal information is used now and in the future. BiblioCommons is unique in that it has to comply with public sector laws (because the public library partners are governed by those laws) and with the newer commercial laws like PIPEDA.
In essence BiblioCommons is built around the idea that users’ account information is a key driver to their use of the catalogue. By building in opportunities and incentives when users are checking their accounts, useful data can be built up. For many people, the new social networking data itself will become a driver to the use of the library catalogue. The main take-away point is that libraries are overwhelmingly used and perceived as places where discussions and social data about books should occur. The popularity of those activities elsewhere on the web would likely be dwarfed by the volume of activity generated if public library catalogues embraced these models of user interaction and resource discovery.