Open Access News

News from the open access movement


Wednesday, April 25, 2007

Making IR deposits easier

Dorothea Salo, Repository middleware, Caveat Lector, April 24, 2007.  Excerpt:

I did a lot of IR marketing this week, despite my perfect awareness that IR marketing doesn’t work. For a tactic that doesn’t work, I did manage to come away with some contacts, and it appears that the IR made its way into some heads, and that’s all good.

But if marketing doesn’t work, what does?

Here’s the problem I’ve got: there’s a ton of material that’s IR-ready floating around, but I can’t get at it. My nose is mashed up to the window of other people’s hard drives, web servers, workflow silos, and collaboration tools. I want the stuff that comes out of those arenas. I just have no way to grab it.

Here’s the problem everybody else has got: they need the curation, preservation, and “put this important content somewhere safe (but otherwise out of my hair)” tools that an IR theoretically provides, but they don’t need the hassle of extra deposit steps. They need an “Archive It!” button....

I need middleware, and I need it badly....

[F]aculty want and need these tools, and IT is finally listening....

What DSpace and EPrints developers should be considering is how to hook IRs up to the firehose of research products those other tools are producing....[T]hat means an ingest API (no, not a command-line batch import tool, an API!) that is configurable enough to authorize certain tools for unmediated deposit and then prepopulate metadata fields with what those tools “know” about their content and the people who use them.

It’s a tall order, but I dearly hope it’s not impossible, because I want to get my IR’s ingest pipe connected to that firehose.