The more I think about it, the more I think RSS feeds from the OPAC are a waste of time and energy.
What is the appeal of this? I mean, really?
RSS and the OPAC
by
Tags:
Comments
17 responses to “RSS and the OPAC”
-
People like to track new arrivals in their areas of interest. Doing it over RSS means they can track them using modern tools they might already be using anyway. And it should be cheap and easy to implement (especially with something like OpenSearch), so why not?
-
Many of the current RSS feeds from an OPAC are simply a list of the latest titles entered. Not too exciting, and probably too general for most user’s needs. However, I could see some appeal in adding an array of more targeted feeds – for example, about six months ago our reference folks asked for a list of the new reference books that have been added every month. Instead of the current batch report that currently lists titles and call numbers, I’m thinking about adding an RSS feed that shows the books as they trickle into the system.
Likewise, profs from our departments are often interested in knowing what’s new and shaking in their subject disciplines. Currently, these sorts of reports are generated on demand and are about as interactive as dead trees (again, typically the report consists of title, call number, and price). Assuming we have good definitions of what constitutes a discipline (LC classification, subject headings, or which fund paid for the damn thing), it would be relatively easy to set up one feed per discipline to show the latest entities added to the system, and make it a little more interactive by including abstracts and reviews from Amazon or wherever, direct links to the entry in the system…
So yeah. Basically the RSS feed would be a better substitute for today’s batch or on-demand reports that are inspired by dead trees. But I worry a little that our targeted users probably don’t know how to use RSS feeds in the first place. So I could turn the ideas for RSS feeds into Web pages via the same XSL that I used for “Library Geeks (in human form)” and probably increase our readership significantly.
Hmm. Rambling. I should go back to sleep.
-
Dan(s),
I understand the appeal of the ideal of RSS/ATOM in the OPAC, but are Current Awareness searches in the catalog all that common? Maybe I can see this at Yale (maybe) and I don\\\’t really know anything about Laurentian, but I\\\’d be highly surprised if our users cared about functionality like this (as opposed to having it in Web of Science or Compendex, say).
Now, should our new books list have this? Absolutely. Should our subject guides? In fact, they do. Actually, we technically have RSS feeds for searches in our catalog (at least, via our OpenSearch interface), but trying to sync that with searches in Voyager would be problematic.
The problem that I see is that this just seems more like polishing the turd. I would much rather see better layouts; friendly URLs; and elimination of sessions (which would, in turn, make something like hAtom more realistic) rather than the worry about RSS in our current sorry state.
I guess I just don\\\’t see that, in the wide variety of improvements that need to be done, that syndication should be a terribly high priority.
-
Ah, I think I get where you\’re coming from: by \”and the OPAC\” or \”from the OPAC\” did you really mean \”in the OPAC\”?
Yeah, when I get around to implementing the RSS feeds I talked about, it\’s quite unlikely that they will be in the OPAC. The feeds for \”new items by discipline\” would appear in the subject guides, which live outside of the OPAC, and the list of new reference items would also live outside of the OPAC.
Sorry. I missed the emphasis on \”in\”. The feeds I plan to create will simply be fed by the inventory side of the ILS and will have nothing to do with the OPAC proper.
-
“Polishing the turd” — that’s such a great line for our current state of ILS, etc.
I agree — too many more important “improvements that need to be done..”
There is indeed some usefulness to enabling RSS, etc., but I suspect part of it for many of us is just trying to make are systems **look** more up-to-date. What I mean to point to here is that many of us are very much limited to just “polishing the turd” because of the limited openess our ILS provides and sometimes we jump onto certain functionalities (like RSS) in the absence options for other more important innovations.
In our case, we use the III ILS and they just enabled RSS (outbound) **this year** and on top of it, you have to pay for the “Feedbuilder” product to use it. In a more general app environment and you could just build it, but here, you have to buy a product, or find cumbersome workarounds (but why do I always have to workaround the ILS?)
BTW, enjoyed your presentations at Access 2006.
-
Most people that search google probably don’t use their alerting service. Does that mean that their alerting service is like polishing a turd? I’m just continuing in this fine tradition of making up statistics to suit my purposes. Good title though…very provacative, I like the truthiness element.
-
Ed,
The difference between Google’s alerting service (and I agree, probably not a huge percentage of users) and an OPAC alerting service are this:
1) Google’s architecture makes it probably fairly simple to add syndication on top of it (no sessions in the urls, data structures that lend themselves well to syndication formats)
2) Google has a lot of indexed content that grows enormously from week to week.
3) Google’s userbase is in the millions — a small percentage of Google’s user base is probably larger than the largest library’s entire user base.
I actually agree with dchud. If this was totally non-trivial to add, I would endorse it as just an extra something to offer our constituents. Instead, given the awkwardness of the OPAC, this is actually stupidly hard to implement. As such, I don’t see why we would actually pressure our vendors to incorporate a feature like instead of focusing their energies entirely on making our catalogs suck less.
I look at it sort of like adding an alerting service to WAIS, Archie or Veronica.
-
Targetted current awareness RSS feeds from the catalog could be easily included in subject guide pages. That seems like a good idea to me. Depends on being able to get a query that’s actually the right query to translate into RSS of course (resulting in something useful).
RSS feeds of personal circulation information (upcoming due dates; items placed on hold) seem awfully useful. Could be included in university-wide ‘portal’ applications and such.
I’m seeing RSS being more useful for automatic inclusion in other applications (portals, content management systems creating subject pages, etc.), rather than users subscribing to RSS in their own personal RSS readers (how many users even do this? It’s a question on our university wide tech survey, so we’ll find out locally hopefully). Although some users might do that too.
-
But I agree that RSS is not neccesarily the best priority.
The problem with all this is that anythign that requires changes to the practice of cataloging—is really really hard for economic/social/political/organizational/business reasons. (rather than technical reasons).
And most of what should be a priority probably requires such changes.
So I think people are likely to give up on those, and focus on what seems obtainable. (RSS feeds!).
-
Which opac are you talking about? Are you saying all opacs suck in their ability to graft a current awareness RSS feed on top of them?
Back in 1999 I created a current awareness system by having III dump out new records each week into MARC, and then populating a little mysql db with new stuff. It wasn’t that hard at all.
I imagine some OPACs (Evergreen) have this RSS functionality built in now, but I can’t say I follow it close enough to know. I just don’t in general understand why someone who wrote the Umlaut would be complaining about the ability to build an RSS feed from a catalog.
-
Sorry I’m late to the discussion, but I can at least explain why *I* think RSS from the OPAC is important. Naturally, YMMV.
In almost every library I’ve been in, helped, or in which I’ve talked to the librarians, the catalog is walled off on the library’s website, even though the content in it is one of the most popular destinations on the library’s site. Unless you have a programmer on staff or a progressive vendor (see various comments above for how far we’ve gotten with that), libraries (especially public and school libraries) tend to be stuck with having their content behind that wall.
As already mentioned, adding a new titles display to subject guides and feeds of patron data could be compelling for segments of our users. In my previous job, we had a consortial catalog of 77 libraries, many of which tried to show a list of some new titles on their sites. If Innovative offered this functionality, it would have saved my libraries a collective 1000 hours in just one year. Being able to recycle and reuse content you’re already creating as part of your existing workflow would seem like a prudent thing to do, especially when a proper backend should make this relatively easy to implement.
Even better, libraries can then target this type of feed within their communities to display their content *off* of their websites. A public library can display new materials about soccer on the soccer club’s pages, new titles on the community’s site, and relevant items on school library or park district pages. Academic libraries can display new materials on department home pages, in the campus portal, in the learning management system, etc. School libraries can display lists on class project pages, teacher pages, etc. Special libraries can display subject-based feeds on the intranet, pathfinders, news pages, etc.
If you feel that your users are all remembering to come to your catalog (versus Amazon and other materials catalogs), then this might not be applicable to you. However, if you want to try to reach more of your users, especially where they might already be spending time, and keep your content in front of them, then RSS offers a painless way to do this (especially in terms of staff time after the initial setup). It rotates new content automatically without further drain on your staff, which I think is also compelling.
For me personally, it’s a matter of being able to go where the users are, in addition to making resources available on our own sites. Does that mean we shouldn’t keep working to improve our catalog interfaces? Heck no. Some of us would like to see both happen.
Hope this helps explain why I think this is an important topic.
Jenny
-
Jenny,
Ed pointed out to me that I’m not really consistent with my initial argument.
Yes, I think syndication from the OPAC is a worthwhile goal (otherwise I wouldn’t have spent the last week rewriting the OpenSearch interface I made for our catalog to make it 1.1 compliant). That’s not actually the part I’m belittling.
My objection is the fact that adding syndication to an OPAC in a meaningful way– from the OPAC itself — in a means that would make sense; in an interface that would make sense — is amazingly non-trivial. Our catalogs just aren’t set up to easily facilitate this.
The scenarios you mention, I would argue, are, in fact, not something we should push our vendors for. I would much rather see the user communities handle these sorts of services (they could build them, for free, with existing tools — MARC export and scripting libraries of choice, for example), rather than the scenario George mentions: diverting time and resources away from making their products not be an embarrassment and turn around and charge us extra for a slapped on hack on the side. A slapped on hack that could have (and should have) been just as easily made by a member of the vendor’s user’s community.
No, when the vendors stop propping up products that we have to apologize for to our constituencies and make something sustainable, modular and well-engineered, then they can add these sorts of functionality. After all, it should be much less effort on their part if they have a robust, extensible framework to build upon.
The easiest way I can sum this up is: if the next release of Voyager is the exact same piece of shit interface with a couple of RSS feeds in it, that’s going to impress far, far fewer people than introducing a service like NCSU’s Endeca or Casey Bisson’s WP-Opac. The irony is that WP-Opac would inherently come with syndication and Endeca’s framework would make it simple to add (although, interestingly, NCSU doesn’t seem to do this).
-
I mean, why is that we have to push the boundaries of innovation?
-
We’re pretty much in agreement, Ross, except that I keep going back to the problem most of the librarians I know encounter, namely that if the vendor doesn’t do it, it won’t get done. While we have some really great superpatrons out there, many libraries’ user communities won’t build these types of tools for themselves or the library to use. Sure, some will, but for small public libraries, school libraries, and some special libraries, it’s just not going to happen. I would expect a vendor to include a module for email to patrons, and I now expect vendors to provide RSS out of the catalog.
That said, I couldn’t agree more about the interface and search issues you raise. I just equate the opportunities RSS offers as an additional need.
My kingdom for a catalog that does all of this!
-
Jenny, re: “…if the vendor doesn’t do it, it won’t get done…[and]…many libraries’ user communities won’t build these types of tools for themselves or the library to use”
IMHO, this is wrong for at least two reasons:
1) The ILS “castle wall” architecture introduces significant barriers to in-house innovation, and this in turn leads to much less to share with other system users. In a more open environment, once something got built, it could be more easily shared. This is by far the most critical advantage that comes with OSS efforts. But because “castle walls” prevent many good things from getting built in the proprietary big 3 vendor marketplace, less effort can be shared and more of us wait like fools for them to build things for us…
2) Although we are a small shop, I can’t tell you how many times we have wasted effort trying to get around our ILS instead of focusing on building tools to extend and enhance our OPAC.
Check this RSS example from our shop:
– our “Innovative” ILS was on tru64 last year – long story, but tru64 is dead and our ILS finally began supporting Linux. We asked about installing a scripting language (PHP) one year ago today, and back then they said “go ahead.” Fine, I thought, but not on tru64 (too much trouble, no future, etc.). So we put lots of effort into migrating to Linux this Spring/Summer and I thought, great, now we could do some interaction here with our ILS, maybe not have to **wait** or **overpay** for poor implementations of yesterday’s technology – RSS was one simple feature requested by our staff and going to be our first of many scripting tools we envisioned for enhancing interaction with our OPAC.
– I thought to myself, I DON’T NEED THESE JOKERS to do that for me with their idiotic overpriced “RSS Feedbuilder product”, we’ll do it ourself, and now that we’re on Linux, got the latest “release 2006” from ILS, etc. we’re good 2 go with our PHP install…
– so finally, 3 days ago we installed PHP, but noticed some of the usual “what’s going on here TOP SECRET wrappers” and so on, and find that our **basic vanilla** PHP can’t work on our BRAND NEW Millennium Linux server!! On top of that we are a “software only” site, meaning that we own and maintain the hardware and OS, not the vendor.
– So I call up III and here’s a snip of their response, from Oct. 30th, 2006:
“We don’t support PHP on the [new] Millennium server. Nor do we support cgi scripting by the customer, server side includes, Perl (except with the Perl API), or installs of Movable Type, etc.
They should do this sort of stuff on their own web server, rather than the catalog server.”So yes, maybe “..if the vendor doesn’t do it, it won’t get done..” but only because **they’ve designed it that way** and we’re fools enough to keep letting this go on. [I haven’t heard back from them yet, but I’m definitely making some noise about this latest fiasco…].
And yes, I know, there are “workarounds” but damn it, this is almost 2007 and we’re still putting up with this nonsense!! No more workarounds!!!
-
R-e-a-l-l-y late response…. George, I’m not disagreeing with your premise, but the libraries I’ve worked with couldn’t have done most of what you did (migrating to Linux, installing PHP, etc.). Again, academic libraries and large public libraries have resources to devote to changing their setup, but the majority of public and school libraries don’t.
*Should* it be that way? No, of course not. Is it wrong for vendors like Innovative to lock the doors and make the catalog a walled garden? No. I’ve railed against this about Innovative in particular quite a bit. From where I sit, unfortunately most libraries just don’t have the resources to implement RSS themselves. I wish it was different.
Since you feel so strongly about your vendor, are you considering moving to Koha?
-
Jenny,
Re: considering moving — yes, I’m up for a switch to anything outside of the Big Three (III, Sirsi, Endeaver, etc.), but there’s definitely a cultural & technology assessment barrier I am up against. We (librarians) just seem to be too comfortable with the familiar, but many folks are working to change that.
Personally, I think the vendors will not change, and if they do, it will be too late. What Koha & Evergreen need is just one or two more waves of relatively modest investment (compared to the piles of money we give the vendors), and they WILL TAKE OFF. What a lot of administrators / library directors are waiting for is to see some key university (or library network) take the jump, have some success, and then the possibility **to even think about alternatives** will open up.
I had to go through a somewhat painful experience here, but finally broke through and got OSS options on the table. What my directors needed to hear was that it wasn’t just another “crazy George” idea, but rather something others too were seriously looking at as well.
Once the options opened up, I now got approval to go to check out exciting meetings like this one later today: http://infoservices.uwindsor.ca/ils/
Leave a Reply