by The whole 2.0 meme tends to leave a bad taste in my mouth, and when used by the more — shall we say, vociferous — proponents of the principles behind the title it has been known to cause me to suffer a bad case of the dry heaves. That being said, and noting that he is certainly not one of those that cause me convulsions, I think the OpenILS/Evergreen project owes John Blyberg a very big thank you for explaining, if offhandedly and by accident, exactly what we are all about.
I’ll go through all five points John made, which I think are a great starting point for discussing what, after working to build an ILS from the ground up, the virtual face of a library could and indeed should be made of.
- Social Software
This is something that I was initially astonished to find completely non-existent in the existing commercial ILS offerings. Other than handing out books, it’s what libraries are supposed to do, right? Be a hub of the community, a place to find and share ideas, etc?
Our first foray into the world of social software is our book bag sharing feature. Patrons can create an unlimited number of book bags, mark them as “Shared”, and pass html (or RSS or Atom feed) links to others, allowing friends, family or blog readers track what that patron finds interesting or useful.
The very same framework that supports book bags can also be used to build a tagging system. There are many issues to work out with tagging a catalog, but it’s certainly something we want to explore.
- Open Source
- Open Standards
We’ve talked at length about our use of XMPP (the messaging protocol behind both Jabber and the new Google Talk service), as well as our support and use of Open Source software (which, in my opinion, is the cornerstone of open standards — the Apache web server; XML with XUL, XMPP, MARCXML, RSS, Atom, …), but we also want to be involved in helping to create new standards that, while they may start in the library world, could and should be attractive to those outside our specific problem domain, and to foster the use of existing standards from outside the library world that will allow us to interoperate with others “out there.”
To that end, we have been involved with the unAPI spec building process. I’ve also been building SuperCat in order to make exposing our catalog as simple as possible, and in as many ways as possible (today we do OpenSearch, unAPI, Atom/RSS feeds and REST; tomorrow, who knows?). Any other ideas (or patches!) are always welcome!
- Single sign-on
This is one where we came in on the first day and said “Duh!”, and everyone looked at us funny. Thankfully, they stopped looking at us funny and agreed that it’s a good idea.
In OpenILS, every patron and staff member, every user that the system will ever know about, can be looked up and authenticated using either his library card number or a unique user name of his choosing. What’s more, every service provided by the software that requires authentication and authorization is backed by a central session-based authentication mechanism.
As a staff member with appropriate permissions, you can log in to the OPAC to update your “Joe’s recommended reading” book bag, jump over to the reporting system to see how many times the books in that book bag have circulated in the last week, and (after the upcoming rewrite) hop into the MARC editor (assuming you are using a Mozilla based browser) to change the Leader/17 of the record for the new John Grisham book from 8 to blank because you just received the library’s first copy, all without logging in more than once or having to type in a sixteen digit string of numbers.
- Integrated OPAC
This was yet another “duh” moment for us, and I’m proud to say that, because of all the points above, this is where we’re going. Not only can our OPAC be skinned and themed using CSS and simple XML templates (a set of each for every regional library system and branch in our consortium, if they so desire), it’s also the catalog search interface for staff members. Staff will now see what a patron sees (only more), so no more miscommunication at the reference desk!
As I said above, the catalog (of which the OPAC proper is only one user accessible view) can push raw data out to other systems in a myriad of formats, all in real time and in the most appropriate format for the job. In addition, each organizational unit can create local content, such as surveys, categories and, eventually, embeddable content from CMS systems, that is served specifically to the patrons the frequent their buildings, want information on local happenings and want to provide feedback to “their” library.
I apologize if all of that ends up coming across as an advertisement; it isn’t meant to be. There are certainly * 2.0 (bleh) ideas and areas that we’re not covering and many things we haven’t thought of. But it struck me that, while we (all) have a long way to go before we can start working on version 2.1, it’s not all doom-and-gloom, and there is hope yet that we may be able to again insinuate our institutions, public, private and academic, into the lives of those we strive to serve, and in a way that allows them access to all the information we have locked away in our dead trees while they surf their way across the commercial web.