Andrew K. Pace: September 2008 Archives
About 3 or 4 years ago, I stood before a panel of library automation CEOs at the annual RMG session hosted by Rob McGee. The discussion had taken a typical turn--why do we pay so much for these systems? I've never really accepted that premise. I always thought that libraries were paying what was required of them for vendors to do what was being asked--incremental changes to legacy systems are expensive and time-consuming. I have put this in another more pejorative and accusatory way: vendors squandered our money doing exactly what libraries asked them to do. But in that RMG session, I stood up to counter the "we pay too much argument." I suggested that I had a blank check, and that the CEOs need only tell me what new and exciting things they were working on and I would gladly subsidize the effort. Crickets chirped.
Of course, this was before all the next-gen online catalog arms race (it was those crickets chirping that really convinced me back then that it might take looking outside the typical library automation market to raise the bar). We are improving the lot for patrons with great rapidity, faithful investment, and thoughtfulness. But what are we doing for library staff?
I've said it before and I will say it again. Choosing a library system is a lot like choosing a rental car off the lot. We can quibble over features, keystrokes, and usability heuristics, but library inventory management is largely state of the art across the board. So what should we do next for back office operations? Surely open sourcing state-of-the-art software can't be all we can do! Surely API access to data is only a first step in a longer journey to improving back-office systems.
This is in no way meant as a slight to my brethren in the open source arena. First, the newest of ventures have re-built old things with new technology. Like the legacy OPAC and the ERM system that just won't fit in the ILS, new technologies were required to improve our plight. One must be wary, however, because just as 'open' does not equal 'free', nor does it mean 'new' or 'better'. Secondly, the philosophy of open source has now permeated the library space--it's champions have done a nice job of aligning the OSS (aka FLOSS) philosophy with the ethos of librarianship. For the most part, I think library administrations and technologists are doing a good job of answering the question: am I doing this for technological reasons, or philosophical ones, or both?
"Just because yours is better than everyone else's does not mean it is any good."
But whether it's an open code base, an API, or a change in corporate ownership, we must continually ask, "so what?" Am I reducing my total cost of ownership of the systems I run? Am I making my staff more efficient? Am I innovating the state of library automation? Am I getting what I paid for?
As we enter what I think could be a real renaissance for library systems and services, I would argue for a new set of criteria that determines whether libraries stay with the system they have or make a change to something truly new, not just something different. It may be years before we can kill off the traditional tender and RFP, but we can certainly write a new appendix to one. If someone were to ask me, "what have you done for me lately?" Rather than scramble for an answer while crickets chirp, I would quickly ask back, "what are you expecting?"
I've been doing a great deal of thinking about "network-level" applications for the last several months. Â Some people call it "cloud computing," others "grid computing"...whatever. Â Suffice it to say that it is more than software as a service (SaaS), which is sometimes as far as libraries will go in trusting the network to their applications.
Now the Gen-X in me wants to be an ageist about this and say that older people just don't get the power of cloud computing or SaaS. Â The former head-banger in me (yes, you heard me) recalls the words of Rob Halford, the Beast of Judas Priest, who said "you don't have to be old to be wise." Â The placater in search of middle ground in me says this all boils down to trust and control. Â As Microsoft, who is light on the former and criticized for its love of the latter, put it:
Trust, or the lack thereof, is the number one factor blocking the adoption of software as a service (SaaS). A case could be made that data is the most important asset of any business--data about products, customers, employees, suppliers, and more. And data, of course, is at the heart of SaaS. SaaS applications provide customers with centralized, network-based access to data with less overhead than is possible when using a locally-installed application. But in order to take advantage of the benefits of SaaS, an organization must surrender a level of control over its own data, trusting the SaaS vendor to keep it safe and away from prying eyes.
But now some new information has come to my attention...maybe I was right to be an ageist. According to Pew, younger Internet users are more inclined to store data online and use web-based applications and services that require storage of personal data.
Trusting the network and relinquishing control.  Are libraries ready for that?  Relinquishing control seems an anathema to most people because it usually means forfeiting functionality.  But think about GoogleDocs for a moment.  How much functionality is really lost when converting from Excel?  Not to mention what is gained--the ability to easily share data and editing responsibility across established groups and domains.
How old will librarians be when the benefits outweigh the fears?
In case you're wondering how many cows are in this pasture, I started
counting and figured I could keep this series going for at least the
rest of the calendar year. How long can I milk this one? After a
while, though, it begins to look whiny and tired, so I thought I would
end with a cow for which it might make sense to make more hay. (there,
have I...ahem...butchered that metaphor enough?).
Some of last week's work had me thinking about notes fields in bibliographic and item records. Boy, do we love notes. We didn't quite have the guts to call them what they really are--miscellaneous fodder that doesn't really fit in a real MARC field. No, we went one further, and created 48 different kinds of notes and put them in the 5XX fields. Was that enough? Of course not. Let's throw in ten more (590-599) for local notes. Anyone else think we could have just scanned the whole book in the time that it took to write all those notes?
If social tagging in library catalogs is library 2.0, then notes were our 1.0 effort. We fret over their protection, their proper migration, where they display, their impact on keyword indexes, and the new relevance algorithms required to make sure they get just enough weight as we migrate MARC records to new bolt-on catalogs. Notes run the gamut from arcane impossible to interpret codes and numbers to the invaluable characteristic that distinguish one book from another.
Putting my OCLC hat on, I can't help but argue that at least the local notes belong with the item record, not the bibliographic one. The MARC Holdings record (MFHL, MFHD, LHR...whatever you want to call it) makes a place for both local and staff notes, and if it's truly local in nature, shouldn't it go there? This is mostly a rhetorical question...believe me when I say that I have no intention of getting into an argument with catalogers on this one--a fight that would leave me beaten and bloodied.
What if all those notes--like social tags--were put in a great big pile, used semantically, indexed accordingly? What if all the little localized changes to OCLC bibliographic records were put in a pile and "localized" for local purposes. We might end up with 80% chaff in the pile, but the results could be interesting. Our notes are somehow sacred, but are they as useful as they could be?
Some of last week's work had me thinking about notes fields in bibliographic and item records. Boy, do we love notes. We didn't quite have the guts to call them what they really are--miscellaneous fodder that doesn't really fit in a real MARC field. No, we went one further, and created 48 different kinds of notes and put them in the 5XX fields. Was that enough? Of course not. Let's throw in ten more (590-599) for local notes. Anyone else think we could have just scanned the whole book in the time that it took to write all those notes?
If social tagging in library catalogs is library 2.0, then notes were our 1.0 effort. We fret over their protection, their proper migration, where they display, their impact on keyword indexes, and the new relevance algorithms required to make sure they get just enough weight as we migrate MARC records to new bolt-on catalogs. Notes run the gamut from arcane impossible to interpret codes and numbers to the invaluable characteristic that distinguish one book from another.
Putting my OCLC hat on, I can't help but argue that at least the local notes belong with the item record, not the bibliographic one. The MARC Holdings record (MFHL, MFHD, LHR...whatever you want to call it) makes a place for both local and staff notes, and if it's truly local in nature, shouldn't it go there? This is mostly a rhetorical question...believe me when I say that I have no intention of getting into an argument with catalogers on this one--a fight that would leave me beaten and bloodied.
What if all those notes--like social tags--were put in a great big pile, used semantically, indexed accordingly? What if all the little localized changes to OCLC bibliographic records were put in a pile and "localized" for local purposes. We might end up with 80% chaff in the pile, but the results could be interesting. Our notes are somehow sacred, but are they as useful as they could be?
About the Author
