Unit 9: Vewwy, vewwy intewesting

Yesterday’s class session was a lot of fun! With so many things to which I want to respond, I’m splitting this week into two posts. The topic this week focused on Electronic Resource Management Systems: Vendors and Functionalities—sounds like hardly the place for the descriptor “fun,” right? What I enjoyed so much about it was a) the relevancy of the information given certain libraries’ and library types’ trends toward primarily e-resources, b) the demo we did, and c) the connections I was able to make between my semester classes.

The need for ERM systems stems from the sheer volume of electronic resources available in the packages and products to which libraries subscribe, an amount that was simply not manageable by a single ILS. ERMI, or Electronic Resource Management Initiative, is guided by the following principles (Hogarth & Bloom, 2003):

1. Print and e-resource management should be through an integrated environment.
2. Information provided should be consistent regardless of path taken.
3. Each data element should have a single point of maintenance.
4. Electronic resource management systems should be sufficiently flexible to make possible to add new/additional fields and data elements.

In other words, in the coming years, librarians will be working toward ensuring these guidelines are interwoven with the new technologies and software available for managing their electronic resources. I found the list helpful as a sort of checklist against which I could compare different ERMS vendors’ products and consider how the different platforms and modules either enhance or obstruct these characteristics.

One of the major differences between the Hogarth & Bloom (2003) article that we read compared to the Collins’ chapter was that Collins spoke much more about the challenges in implementing the ERMS. Hogarth & Bloom (2003), on the other hand, focused on pushing the envelope in the future rather than stressing out about making them work now. It really illustrated – for me, at least – the tension kind of inherent in libraries and the systems they use to manage their resources, and with technology in general, depending on library type. Perhaps the authors are on different sides of the library field fence, but librarians (or who I think of as being on the use and implementation side of things) are concerned with making things actually work in the here and now, saying “Whoa, slow the heck down, what?” whereas program developers (or who I think of as being on the software design side of things – which sometimes include librarians) are intent on staying one step ahead of the game, pushing forward so not to spend too much time tweaking a possible soon-to-be-outmoded system.

I’m finding evidence of this in my research on mobile devices (more specifically Internet-capable handheld devices) and electronic resources, where there’s a ton of literature available that focuses on all the new tools and apps and opportunities for development. At the same time, however, there is hardly any literature that discusses actually implementing mobile services for licensed materials in a library. Vewy vewy interesting...