12 July 2009
why is serials recordkeeping so problematic?
The part I’ve been munching through: apparently it’s really, really hard for libraries to keep track of their electronic serials and database usage. If you want to know which of the things you’re subscribed to are actually getting used and how (and what it’s costing you), strap yourself in for a long ride, because ILSes don’t have rich enough functionality to harvest that information for you. Some people buy additional systems on top to help, but even those require a lot of work if you want to extract useful data.
There are some good reasons for this. Libraries frequently subscribe to databases or journals as bundles (and may be required to do so by the publisher), and the usage codes may not disaggregate resources within the bundle. Libraries may subscribe as part of consortia, but need to extract data for their individual institution.
Still, though. This seems like a pretty obvious thing to want to do — keep track of your actual use! So why do the tools not support it? I welcome ideas from people who actually know something (which is not me!), but in the meantime, I’ll brainstorm some possibilities…
- It’s a genuinely hard technical problem. (And there are a lot of problems that need to be solved here — not just capturing the data, from subscription systems that apparently don’t natively provide it, but organizing it into a database that answers users’ questions, has a usable front end, and spits out data in formats useful for budgeters and other decisionmakers. That’s not one system — that’s multiple interacting systems, possibly produced by different organizations — and potentially problems that have to be re-solved for every database vendor and ILS combination. OK, it’s even harder than I realized when I started this bullet point and was just thinking about algorithms.)
- Libraries don’t prioritize recordkeeping and review of their serials and databases enough to exert pressure (market, social, cultural) on companies to develop this feature.
- ILSes offer a tremendous number of features; while libraries might want better serials tracking, they care more about those other features, so it’s those things that ILSes are competing on. (Although this doesn’t answer why an ILS that does well on those things, *and* on serials, doesn’t emerge and stomp on its competitors. But maybe it’s too hard (algorithmically or monetarily) to do that.)
- This is a place where the culture clash between librarians and programmers is showing; maybe they just aren’t talking to one another enough for the user needs to become apparent. Again, you’d think this would be a place where the company (or open source project) that does do a good user needs analysis to eat its competition — and there are niches where librarians and programmers overlap — but all too often they don’t seem to even have a common vocabulary.
Comments are closed.