First, let me preface this post by noting that these are somewhat random thoughts that I’ve been rolling around in my head for the past couple of weeks…so take them for what they are.
Over the past few weeks/months, the library blogshere has been doing quite a bit of chatting on Library 2.0, and ambigous term that means many things to many people. However, two recent developments have spurred this discussion to some degree of late…the new OPAC by NCSU and the continued development of Evergreen, the open-source ILS being developed in Georgia. Both of these projects, for different reasons, are very impressive. NCSU, for thinking out of the box and Evergreen, as a development accomplishment. But I’ve been starting to wondering if the library community really should be spending much time working on our ILS systems at this point in the game. I guess some background is in order…
At OSU, we’ve been thinking a lot about our library infrastructure and where our current components, like the ILS, fit into this architecture. Not very long ago, many libraries would have said that the ILS is their library architecture, and the services built around it simply were ways of enriching or supplementing data found in the ILS system. But I don’t think that this is, or should be, the case any longer. In fact, I’m not sure that the ILS should really be developed at all any longer. In fact, I’m almost to the point where I’d advocate that the patron should never actually have to see or deal with the ILS, outside of circulation transactions. Rather, I think that librarians/developers should be spending much more time looking at how to tie together the now nearly infinite information resources that a library has at their disposal. I’m sure OSU is pretty representative of many libraries today–and when I look at our ILS, I see a tool where patrons can primarily find information on our legacy print collections. Sure, we have an ERM module, have placed serial titles in the catalog — but when it comes down to it, getting users to the information that they actually want or need (i.e., articles, images, data objects), the ILS simply fails to provide this information and users limiting themselves just to searching the library catalog unnecessarily limit their access to the wide variety of licensed resources available within the library.
So what’s the answer…I’m not sure. Currently folks are looking at federated search, but that seems to be more of a stop gap solution…others like Google are moving to work directly with publishers (i.e., Google Scholar) which seems to get closer to the mark — but even here, Google’s reliance on its Search over metadata makes finding information on Google Scholar hopeless. But an answer has to be out there…I’m just hoping that librarians/developers within the library community will continue to take part in the discussions.
Which brings me back to the ILS. As the ILS’s role within a library’s infrastructure moves farther and farther from the center, I’m left to wonder if the current ILS development efforts underway really move the community forward.
Anyway, as I said, some random thoughts that I just wanted to throw out there.
–Terry
Comments
11 responses to “Develop the library’s OPAC? Maybe not…”
I’ve been having these same thoughts lo these past few months, and I’m really glad to see you articulate them so well. I really think this is the next step we have to take – and we seem to have the tools to do it (or the tools to make the tools…), but I don’t know who is going to do it. Should be interesting to be a part of, though.
I think I agree with you. I think, overall, you’re describing the next big revolution in computing – not bigger and faster anymore, but taking the resources we have and making them easy for the average consumer (patron).
Google has a head start on the augmentation of random information, but the library still the reputation and charge of gathering and disseminating quality and/or scholarly material. We are not out of the game yet, but need to get moving.
The problem to me is that there seems to be the need for a lot more cooperation and at a higher level. An open-source ILS for a large college institution is great, and other colleges might be able to implement them as well, but how do you get something that can trickle down to strapped, small public institutions. I think only when we begin formulating solutions that can be realistically implemented by all libraries to do you really start getting serious about restoring the luster to the library profession.
I think they do, for the simple reason that they’re finally opening up the hermetically-sealed can that is our current bibliographic data. No library-data-management system that can’t work with that data is going to fly. That may be a bad thing, but it’s also a true thing.
I agree with you that the ILS will recede into the background; I merely state that it hasn’t done so yet, and cannot be anticipated to do so for some time. Given that, what Evergreen is doing is absolutely the right thing.
I’m actually interested in the last comment that you made Jason regarding the need to trickle down to public institutions. Its true, I think that in general, much of what is created at the research institution level has very little impact on the smaller college/public library community (on a side note — I think that this might be why so many vendors see IR development as one of the next big areas. While Dspace and Fedora offer very viable platforms with large userbases, I find talking to smaller institutions that most don’t see these projects as being viable within their sitution and are tending to gravitate to the vendor community)– which is odd, partically because many of the open source ILS systems are designed specifically with smaller organizations in mind. I think you’d be hard pressed to find many (maybe any) large research libraries running an open source ILS — partly I suspect because of the idea that these are simply “toy” ILSs and partly because organizations like to have support contracts so that they can simply stop worrying about the service since it will be “taken care of”. And I’m at a bit of a loss in how we come up with a solution.
I think the receding is happening and going to happen, faster than most think. To some degree, I firmly believe that vendors have kept their system closed for so long (and for those of us III, continue to suffer this malady) is simply because they seen this day coming. With very little effort, vendors could have added XML gateways, SRU/SRW servers…even custom API to allow users to get at their data, but they traditionally haven’t. Fortunately, some folks like David Walker at Cal. St. San Marcos and the California University system in general, are starting to look at ways to decentralize the ILS system. David Walker posted a presentation this year that shows some of what they are doing with federated search technologies (ExLibris’s MetaLib product…which btw, if you haven’t purchased a federated search product and are going to, I would highly recommend. The product comes with an XML api which is demonstrated in David’s presentation), which are essentially pushing their ILS system into the shadows (where it should be). The presentation can be found at: http://smugnet.org/2005intl/Session-2-David-Walker.ppt for anyone interested.
FRIENDLY DISCLAIMER: I am one of the OpenILS/Evergreen developers.
> I think the receding is happening and going to happen, faster than most think.
Until yesterday I felt the same way. Then we had a meeting with some of our constituent librarians. We were reviewing the progress of our OPAC development and making sure our priority list matched our customers’. The good new is, we’re right on track. The bad news (well, for the purposes of this discussion) is that the ILS is absolutely and completely central in the minds of our public library staff. When talking about e-books their questions centered around how they should be cataloged and how the OPAC should point users to the vendor’s site, and not how we could insinuate the library into the patron’s normal workflow. They liked how we are implementing personal reading lists (or bookbags), but they imediately wanted to use that to add links into the OPAC from the library’s home page. (We’re building a whole infrastucture to support things like staff-recommended reading lists and published/saved searches, etc.)
The truth of the matter is, at least for the 250+ public libraries that we deal with every day, most patrons are not “sophisticated” enough for the investment in online (or any non-traditional) services to really pay off. For many of our patrons, the public terminals in the libraries are their only exposure to the online world. And, most of our public library patrons only want physical items, so we don’t have a digital collection to speak of. For us, the physical collection isn’t legacy, it’s our bread and butter.
Now, having said that, I still agree that the ILS proper needn’t be the only interface to the library as an institution. While that may be the case for PINES today, there’s no good reason why OpenILS/Evergreen can’t (ney, /won’t/ (ney, /doesn’t/!)) supply a simple, consistant interface for all the extentions/alternate UIs/unimagined features one could want to layer on top of a catalog. Or a circulation listing. Or a holdings database … or anything else that’s traditionally locked up in comercial ILSen. 🙂
> To some degree, I firmly believe that vendors have kept their system closed for so long (and for those of us III, continue to suffer this malady) is simply because they seen this day coming.
I’m not sure on this. I tend to follow the “don’t attribute to malice what can be explained away by laziness” rule of thumb. Until recently, there hasn’t been much real (read: market) pressure on vendors to add extra features. Maybe our project has helped to prod vendors a little, maybe not. But, again, that’s just my point of view.
—-
And, finally, as others pointed out in earlier comments, there is still a pretty wide gap between the needs of a large academic library user base and a small academic user base. And it seems to me that the difference between even a small academic user base and a public library user base is within the same order of magnitude as that.
>>FRIENDLY DISCLAIMER: I am one of the OpenILS/Evergreen developers.
Well, welcome to the conversation.
>>Until yesterday I felt the same way. Then we had a meeting with some of our constituent librarians.
You bring up a very good point…I’m obviously in a research library so our print collections are becoming more legacy collections. In fact, we have started digitizing certain serial sets within the library simply to make them more available to our patrons — so I should have prefaced my earlier comment to say that, within a research organization, I believe that the move away from the ILS is happening faster than most may think. You are right, however, within the public library work, this move will take place at a much slower rate.
>>I’m not sure on this. I tend to follow the “don’t attribute
Then you are less cynical than I. Having worked with two vendors as a consultant to help research libraries migrate from one vendor system to another (not to mention working with our own vendor), I don’t believe it was simply laziness. In many cases, vendors have made conscious decisions not to support specific protocals because it would make the ILS (their bread and butter) more marginalized within a libraries infrastructure. I should point out, as a younger librarian, my experience is limited to the past 6 years, but that’s my personal opinion. Are their good vendors where this doesn’t apply — yes. I’ve had very good experiences with some vendors as well, but as I said, experience has made me cynical.
Finally, one last thing…I’ve been thinking lately about the success of Linux as a model — personally, I think that there are specific software applications within the library that should be available as open source, the ILS being one of them. But to that end, why spinter development. Linux has thrived, in part, because all linux distros inherit a common kernal. There are currently a handful of open source ILS projects in the library community — I guess another question that I would ask is why this hasn’t lead to a more cohesive development community. If Evergreen is to be the new “kernal” for the open source ILS, why not move Koha to that kernal than then build custom services around it — or vis versa.
> I’ve been thinking lately about the success of Linux as a model …
And so have we. I’m in the process of writing up a big “‘ILS as Platform’ == Evergreen” entry for http://open-ils.org/blog/, wherein I will lay out the case for, or at least expose the “hows” and “whys”, using OpenILS/Evergreen as the basis of other systems.
> If Evergreen is to be the new “kernalâ€? for the open source ILS …
Heh … I’ll let /you/ bring that up with the Koha team. Seriously, though, Evergreen and Koha have very different design goals and implementation scales. There are some base assumptions inside Koha that (IMHO) can’t scale up to large, complex consortia, just as the implementation requirements of Evergreen would probably be prohibitively heavy for a very small cash and IT strapped library. Both of those may change over time, but it wouldn’t be feasible to toss the investment in either at this point.
Plus, I like having the competition. 😉
[…] Casey Maison has been doing a lot of writing and thinking about how to make ILS systems more social — and as such, has created a testbed application using WordPress to sit ontop of their library opac. His original post can be found here: WPopac: An OPAC 2.0 Testbed. Its an interesting idea and I mention it simply because it falls into my musings of last week regarding the wisedom of dedicating the limited resources in the library community at developing an ILS (Develop the library’s OPAC? Maybe not…) – something that I see as being more and more marginalized in the future library infrastructure. Of course, I’m coming at this from the research library community, where it seems this movement is happenning much faster than in other communities. […]
I catalog and program & have just found your site. The open source catalog projects you mentioned sound interesting–where can I find out more?
thanks,
The Evergreen Project is being produced by the Georgia Public Library Service and is found at: http://open-ils.org/. This ILS development project is in heavy development with a production set of code scheduled for sometime this summer (summer 2006).
Koha has been in production for sometime, and is being developed by a number of folks in New Zealand. The project URL there is: http://www.koha.org/.
–Terry