Probably other people will come up with other constraints for their sites. How to technically accommodate all this, I don’t know. Maybe a single Javascript script is better than individually tweak several feeds. Sites like delicious.com allow users to check some boxes to generate a widget that calls the script with the right parameters. Just a thought, probably not too helpful…

I would run a standard RSS ‘recently added’-ordered feed with a RSS icon button on the site. But also, on some sort of ‘developers’ page, expose a number of other RSS-looking feeds that are really just APIs disguised as RSS.

Returning RSS XML instead of custom XML in APIs gives developers a familiar base that leads to fast hackability. Eventually they would read the documentation that says the publication date is in dc:date not rss:updated and it’s ordered by dc:date, etc., but because it’s RSS they already have half the tools they need.

This is one of OpenSearch’s strengths – that the results are just RSS plus extensions.

Unfortunately, many EPrints in ORO only contain the published year, and the current RSS feeds in EPrints will only embed the pubDate into the item element if a fully RFC compliant date can be constructed (although this can be modified easily if required)

I’d be open to extending the bibliographic metadata to include additional elements or indeed write additional export plugins if there is a need to support other users/systems that we don’t already provide for. All suggestions welcome.

RSS feeds are a transport mechanism. The way many people see them used is for the syndication of recnt contnt on a site but that’s not the only way of using rss.

eg i use “static RSS” feeds all over the place simply to transport links around. The content never changes, the RSS is just moved to move the content from one place to another.

And i don’t think there is anything in the RSS/atom spec that determines what order items in a feed appear in? Although as @ostephens points out, many feed reader clients implement user directed features such as showing unread items in bold title font, hiding read items etc etc

“I would argue not very, and this has long been a concern of mine. The reason is, like RSS, really simple: standard RSS feeds do not deliver repository content in an order which is useful for Faculty pages, i.e. by date of publication.”

So order them a different way?

There is no reason why the whole of an individual’s publications can’t be delivered as RSS in whatever order you like – chronological, reverse chronological, date of submission, alphabetical, grouped by journal etc etc.

IMHO, RSS as a consumer technology is now a minimal play. RSS is/will be used more widely as a lightweight transport mechanism (although here it faces competition from JSON, which can get round cross domain browser security issues)

WRT additional bib data in the feed, Owen is right on it again; there’s no reason not to extend Atom eg using a Dublin Core namespace, although the lack of standards about using feeds to syndicate bibliographic data means that you’ll need a custom handler on the other end.

I thought that chris gutteridge had enabled all sorts of rss’n'json outputs on eprints anyway? Maybe not…?

“I’ve just asked EPrints Services, who maintain our repo, about creating an RSS feed for each EPrint, so that each EPrint item is an RSS item, including MediaRSS info, too.”

I agree that recently published EPrints would be better than recently added EPrints, but hey ho, I’ll take what I can get.

I’ve just asked EPrints Services, who maintain our repo, about creating an RSS feed for each EPrint, so that each EPrint item is an RSS , including MediaRSS info, too. I’d use that for an OER project I’m running. it would allow me to dump the entire course as one EPrint and then grab a feed with all the resources from that course. I could then use it to pull into WordPress, via FeedWordPress or publish to iTunes (in this case, it’s video).