Being able to search aggregated RSS feeds is nothing new, but the combination and filter functions offered by Yahoo Pipes is. One obvious early use of this technology is repository searching. Although some but by no means all repositories allow you to subscribe to search results as RSS feeds, the ability to search across multiple repositories in this way could offer considerable benefits. It’ll be interesting to see if this simple front-end approach overtakes repository back-end interoperability.
I’ve created a few example Pipes to try this service out. In the UK the HE community has a national repository called JORUM. Unfortunately, though understandably, you need to sign-in via Athens to access this so apologies for those who can’t access this resource.
JORUM repository search – selected sub-set of MeSH
The first Pipe searches a sub-set of the JORUM repository, the second searches an aggregate of JORUM and another UK repository, Intute, (formerly the Resource Discovery Network).
For all you non-Brits out there unable to log into JORUM, here’s a Pipe for you:
Aggregated public health repository search
Because users can make these kinds of custom searches very easily for themselves it is going to ask some important questions of repository providers. Do you open up your repository systems to allow for user-defined RSS-based search applications? Or do you close these interfaces down because of unforseen use of content stored within? If you were a user, would you look elsewhere if a repository didn’t allow you to access its contents using RSS?
Another cool development are tools like Dapper (http://www.dappit.com/) and Kapow (http://www.kapowtech.com/) which allow users to create creatre scriptable and queryable ‘scrappers’ of search results and then offer these either as RSS or REST interfaces. Very cool – all it takes is a modicum of structure in the html tags and these things can rip out the content and offer them in easily reusable ways.