The buzz words for this conference were SOA, SaaS and Cloud computing, for me. SOA Service Oriented Architecture is a technical term similar to “n-tier architecture” touted a couple of years ago. I think the more important thing is that it refers to a very modular framework, rather than a monolithic type of system like “Integrated Library Systems” have been. SaaS, Software as a Service seems to be used for systems where you don’t run the servers locally but run on a server at the vendor’s site. Frequently it does refer to applications running remotely. We run some Atlas Systems apps for ILL, course reserves and Special Collections this way. OCLC has always provided this type of centralized servers and software for cataloging. Cloud computing seems to be used to mean something similar to SaaS in the library world. It seems to mean that you don’t run the servers, etc. on a local machine. Frequently what you are running on central servers may also be proprietary systems owned by that vendor.
Because I was looking to see what people are planning to do to replace or evolve their current “library management” or backend type systems, I attended a number of sessions from which a pattern seemed to emerge. System designs had shared pools of bib and eresource data, with local information for Circulation, Acquisitions, etc. linking in or getting loaded in. So OCLC Worldcat Local is based on the OCLC database. But when Andrew Pace spoke on “OCLC Web scale computing” where he talked about adding Circulation, Acq and ERM, he mentioned a “Knowledgebase” to help with eresource management. That made me wonder, is OCLC going into the Knowledgebase business that I think has been dominated by Ex Libris SFX and Serials Solutions?
Meanwhile, when Oren Beit-Arie of Ex Libris presented their URM Universal Resource Management framework, it also contained a box for a shared data pool of bibliographic and eresource Knowledgebase data. He called this DaaS Data as a Service. My colleague Janet Fox remarked that the whole presentation was done as if OCLC did not exist. That led me to speculate, do they plan to use some separate database and does this become like RLIN as a database of big academic libraries? This was not addressed in the session but made me wonder. Oren did comment that any data in that data store would be owned by the libraries involved and would not be claimed by Ex Libris. OCLC really shot themselves in the foot with the flap over record use policy even though they have stepped back from that.
Another similar database is the Serials Solutions one. Jane Burke demonstrated the 360 Resource Manager that works off their Knowledgebase at a presentation for the CARLI libraries. And I got a demonstration of Summon which is similar to Worldcat Local. You can upload your library’s bibs, combine them with journal article and ebook and other eresource data. A distinguishing feature seems to be that in Summon you can limit to eresources that you own. I assume the Knowledgebase helps with that. Also, Summon indexes full text of articles not just metadata. Worldcat Local plans to do that in the future. But the end result is that Serials Solutions will also have a big data pool of mixed bib and eresource data.
I also had a discussion with Bob Molyneau of Equinox, a company that supports Evergreen open-ils. They have a consortial enhancement for Evergreen called Fulfillment that is being done for some of the State Libraries in the Midwest. Bob speculated there might be other uses for a consortial layer on Evergreen. For instance, instead of complicated automatic prediction to help claim serials issues if they are not received, you might have a consortial layer service that recognized when one library had received the piece and claimed if others had not.
In the Ole presentation by John Little of Duke University, I was not sure if they planned that type of shared data pool of bib and Knowledgebase information. The design document is due out later this month. Certainly one of the first pieces they want to develop is for management of Eresources both owned and licensed. And he mentioned the CUFFS ERM Knowledgebase. OLE is a project to try to produce an open source library management system for academic institutions. The structure of the project is based on other Kuali projects where for the first few years the development agenda will be driven by the “build partner” libraries that invest in the early development cycles. They will contract out the development.
Meanwhile, LibLime, a company that supports the Koha open source library system, got frustrated and put up biblionet, a shared pool of bib data that is separate from OCLC. I haven’t heard that they have any plans for an eresource Knowledgebase at this time, but it is another example of this trend.
The name of my post, “Just say no” vs. “Yes, we can” refers to the different ways of approaching developments and a conflict in the market place right now. For instance, Andrew Pace suggested that libraries would need to standardize some of their processes by moving to a Worldcat Local type of system. He said that everybody hated “circ tables”. He also suggested that for library fund codes libraries need to “work towards homogeneity”. He seemed to be saying give up customization for cost savings of centralization.
On the other hand, at sessions about Open Source in libraries, there is open frustration with vended systems where you pay a lot of annual support only to be told “NO” when you wanted to do something. Another system vendor was explaining that they wanted to reduce the number of options in order to make sure all new features were available to most customers and support was better. That certainly makes some sense. But I think it is the wrong time for vendors to be doing the “just say no” piece and disallowing customization and control by the library. There certainly are opportunities to get rid of unnecessary complexities, on the other hand the library management system is there to support the work of the library. Policy decisions, like circulation policy need to be made so that the library provides the services their customers need, they should not be limited by system limitations. Many libraries may get by with a fund code of just “gift” or something simple. A large library that receives hundreds of thousands of dollars to acquire materials from gifts of endowment money must be able to track that in a way that meets their needs . “yes, we can” is the necessary mantra, not “just say no.”
In the past, vendors limited what could be customized to support lots of libraries. But the technologies involved have changed. I think younger technologists come into the library setting and say, why are you living with all these restrictions? You could do what you want to do. You can do what the vendor is telling you you cannot do. I believe this is why a number of people think Open Source systems will be a better solution for the future.
But what if we end up with a lot of separate pools of data, and not one central database? Well, another buzz word this year is “Linked Data”. The way I think of that is, instead of allowing outside applications to dip into my database of information about my library holdings, I dump the information I want to expose in an XML file and let people harvest, crawl, pull off pieces of it as they like. For instance, a Google Book Search engineer suggested if libraries put out their holdings information that way, it could be crawled by Google and other search engines and would lead people back to libraries from searches on the net. If the libraries want one big central db, we could put out our information and let OCLC or someone else crawl it. You don’t absolutely have to all be making the records on the same system to combine them in useful ways.
One of the most interesting comments I heard was at LITA Top Technology Trends. Clifford Lynch of CNI suggested there is an enormous mass of literature that embodies the past. But for scholarly materials there are very new open collaborative ways to author and communicate. Eventually it will be very problematic to link between scholarly literature of the past and future scholarly production. Now there’s something to think about.
