One hesitates to interpose oneself when giants get to rasslin’. This time, though, I’m going to risk getting squashed, because my usual ox has been gored and I want to talk about it.
Another tidbit in the last Cites and Insights chastised a few librarians for being happy about RSS feeds of catalogue data, since patrons who want online access to new-title lists or whatever don’t know diddly about news aggregators. (This, of course, begs the question of how long that ignorance will continue—but that isn’t where Walt went, and it’s not where his responders went, and so I won’t go there either.)
To which Jenny points out that an RSS feed doesn’t have to go directly to a patron’s news aggregator to be useful. It’s not hard to integrate an RSS feed—say, of newly-purchased titles—directly into a library website, and doing so might save website-updating time for librarians, who apparently put these data on the web by hand at present.
Whoa. Hang on. Hold the phone. By hand? If I may be permitted an emotisound, *facepalm*.
This is a hackable problem. One doesn’t need RSS to solve it, though vendor-provided RSS might well make life easier. Essentially, it boils down to three tasks:
- telling the catalogue what data we want to display;
- figuring out the format the catalogue returns the data in and munging it as necessary; and
- integrating that into the web page.
Well, and maybe a fourth—setting up a cron job or daemon or whatever to poll the catalogue and update the web page automatically.
If the library has already got email alerts for new titles going out automatically, well, even easier—hack those. I would, in a hot minute, because I’m better at text-munging than I am at messing with databases.
It honestly shouldn’t take a whole lot of programming chops to set this up, assuming a minimal amount of transparency in our ILS’s underlying database. (I’m guessing a Z39.50 gateway would be enough and more than enough, and I hope it wouldn’t even get that complicated. Don’t these suckers allow SQL queries?) What it takes is recognizing that it’s a solvable problem and being willing to bash the system with a large rock, cursing the whole time, until it does what you’re asking it to. This is what I personally do to systems. I am not a trained programmer; I just beat things with rocks until they work. It’s not expertise, just bloodyminded determination to build something useful and time-saving.
I believe I have mentioned before how disappointed I am in librarians’ general unwillingness to beat things with rocks until they work? “I’m not a programmer!” doesn’t cut it, sorry. I could solve the problem just outlined with the half-semester’s worth of SQL I have and a wee bit of help with PHP. It’s just not that hard, and an ugly kludgy inexpertly-hacked solution (such as I might come up with) will suffice. No librarian, anywhere, EVER, should be putting up new-title lists by hand. The very idea is an abomination.
Just hack it, folks. Just HACK IT. If I can, you can.
Now, that said, I can think of fascinating wizardly things to do with catalogue and vendor RSS feeds. Imagine a new-titles list with reviews from a reputable review source (as opposed to some random A-a-o-.c-m customer). Imagine such lists by genre, by author, by media type (new DVDs!) or by subject. RSS is a convenient data format to mess around and play with, and if enough entities start putting out their data in it, network effects start coming into play.
So, you know, maybe Walt’s right and it’s not so big a deal that the vendors aren’t RSSing, because we’ve got other ways into the data if we’re only willing to work at it. And maybe Jenny’s right that a little RSS sugar goes a long way.
I still want to know why the hell we’re waiting for the vendors on problems like this. If the problem is data transparency (and it may well be), lean on the vendors for that rather than specific gizmos like RSS feeds, because it’s more versatile in the long run.
More things to just hack. More things to beat with rocks.
