Google Wave opportunities for Institutional Repositories

Institutional Repositories are web based information systems, used in higher education institutions and (digital) libraries to expose valuable content online. In a simplified way, you could consider them content management applications, with very specific usecases for digital preservation, and metadata-editing workflows.

Unique in the landscape of Institutional Repositories (IR's), is the dominance of Open Source platforms, even though these systems have strategic importance for institutions running them (for example DSpace @ MIT).

Can Google Wave solve problems in the area of IR's ?

The current state of the art IR's face important issues. I believe Google Wave offers important opportunities to at least optimize following issues:

Lack of voluntary deposits from (scientific) faculty

If there is a lack of deposits, this often relates to policy (if no one is obligated to deposit) or marketing (if no one knows about the repository) issues. However, it's still also very much related with usability and the required effort from the submitter.
Google Wave can mean a big step forward for deposit-usability.

Let's say a scientist just finishes writing a new pre print, that he'd (or she) like to deposit to the repository of his institution. He opens up a new wave, and adds the institutional repository bot, a bot intended to communicate with the repository on a wave. Because the bot and the scientist have authenticated with each other at some point in the past, this is already a huge leap forward: no more repository specific authentication.

The bot gives him a range of interaction possibilities, and the scientist chooses new submission (in the demo, it was already clear that interaction through forms, would be possible in Wave). When he drags his file into the wave, he can submit it to the repository, and add some metadata. Real clever IR bots will also be able to generate metadata automatically from the document, even maybe extract a full list of references, made in the document.

You probably get the point now about submitters, interacting with the repository bot from within the wave. The information could also come the other way, when a scientist is on a wave, together with the bot, with the sole purpose of knowing what's going on in the repository. Maybe he wants to get notified about new items in the repository, with similar keywords of the ones he used in his submissions ? Or maybe he wants a daily update on the download stats of his items ?

Ok, fair enough, a lot of this last stuff could also be implemented more or less with email, but the fact that the bot can continuously update the same wave, will make it much more efficient to synthesize information, and will make it go a lot FASTER.

Workflow optimization

In the Institutional Repository DSpace, one or more people can be responsible for checking, and extending the (meta)data for new submissions. If a collection receives a lot of submissions, theses metadata editors can become a bottle neck if tasks are piling up. If there are multiple metadata editors for a collection, a new submission arrives in a pool. From this pool, one of the editors has to "claim" the task, and do the editing.

Task pools and claiming will not be required anymore.

Let's say a new submission arrives, in a collection that has two metadata editors, Mary and Jane. The IR bot will start a new wave, and add Mary and Jane. Mary and Jane always have the same view on the data and the current state of the submission. Instead of having to claim the task, they can just work concurrently on the metadata editing, and push it further through the workflow. Jane can check the spelling of the abstract, while Mary checks the copyright status of the journal where the paper is published.

If you are a repository administrator, funder, submitter or visitor ... you've got a reason to be enthusiastic about Google Wave.