Repositories vs Learning Object Repositories

I got into a bit of an argument on the JISC-REPOSITORIES list yesterday, about whether general repositories (EPrints, DSpace, Fez etc) could take on the functions of a bespoke learning object repository (e.g. Intralibrary). My position is that a general repository is made to be adapted - you should be able to change the schema and the services to adapt to local requirements, but the contrary position is that a learning object repository is just too different and specialised.

We'll see. The EdSpace project at Southampton is running a learning resources repository based on EPrints, but they are experimenting with the nature of a learning object repository by introducing open access practices and sensibilities rather than keeping learning behind institutional firewalls. They are building something interesting (which shows signs of being effective as well) but they certainly wouldn't claim to be trying to replicate a learning object repository.

However, the discussion got me thinking about the limits of plasticity inherent in an open source repository such as EPrints (or DSpace etc).

The out-of-the-box, vanilla repository provides various services to support certain agendas (say open access, preservation and scholarly collections). However, it comes with lots of configuration options and customisation opportunities to extend that basic functionality. You can change the look and feel of the user interface, or the schema for the metadata or the services that are applied to the repository holdings. There are configuration options, APIs and plugins that you can use to adapt the repository to your local requirements, and every institution has its own list of extras that the repository just has to handle - whether it is journal workflow management, scientific data archiving or RAE evidence gathering. You can do any of these things as long as you have sufficient technical assistance to hand. And sufficient time. Otherwise, you just have to live with the generic experience. The diagram (above and to the left) makes it plain that the more you want to extend the boundary of your repository, the more effort you are going to have to put in.

In theory you can adapt your repository so far in the direction of any particular agenda that you could encompass all the needs and requirements of users concerned with that agenda. However, that may require an awful lot of effort - or just more understanding and insight than you have time to achieve. Bigger institutions will obviously be at an advantage here!

That may be where you turn to the open source community, so that others may help you to add the facilities that you want (see diagram to the left). But what has tended to happen in the repository community is that these out-sourced, open-source developments proceed independently of each other, so that it can be difficult to have a Basic Repository + Education module + Research Management module that work happily together.

It's hardly controversial to conclude that the facilities that you can add to a repository are always going to be constrained by the amount of technical resource available to you. This does put some constraints on the amount of the terrain (agendas and services) that your repository's perimeter can encompass. So perhaps a way forward is to cheat by redefining the problem in terms of something that the repository can already do. I've already mentioned that EdSpace are getting results by making the "educational resources" problem look more like "Open Access + preservation". This approach seems to be working in other areas as well - scientific data (eCrystals), archiving fine arts (KULTUR). Still, there remain interesting challenges for making a single repository "all things to all men" - whether they are physicists, chemists, engineers, social scientists or sculptors.

"Some things to all men" we can obviously do straight out of the box.