Tuesday, 27 January 2009

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.


  1. Right. And you end up considering what the verbs are that the users (any users) want to perform on the content. Your average repository can handle "put in" and "describe" and "manage access rights on" and "look at" reasonably well. As soon as you get to "revise," however, there's a problem, and "comment on" or "rate" takes some pretty serious hacking. Even "remember for later" isn't a common feature, though it's arguable that this function belongs in the cloud.

  2. can ePrints unpack a LO and play it like intralibrary?

  3. I'm with you. In the very early days of the eprints.org software (probably the first version) I modified it to form a simple learning object repository with rudimentary support for IEEE LOM and so on. Unfortunately, I never wrote up what I'd done and a server failure caused me to lose the work I'd done :-(

    No big loss I assure you.

    One of the problems here is that LO repository people will tell you that the content package is very important to them, and that their repositories have to have internal knowledge of usch things in order to bundle and unbundle that content.

    I tend to disagree - because I've never been fully convinced of the value of the package (not just in e-learning but generally as it happens) as a thing that needs to be shipped round the network in the way envisaged by the learning object people.

    I think teachers and learners get far more value out of disaggregated resources (assets), support for which it is much easier to build into a generic repository.

  4. is there a comparative analysis / study done about the different types of Repositories , LO repository available today?