One interesting development in the UKOER programme has been how many projects have chosen to build their own repository/database to manage their content in some form. Normally the phrase ‘we’ve built our own repository’ makes me worry in the same that ‘we’re developing our own standard’ or ‘our own controlled vocabulary’ does. However, these projects have had a wide variety of good reasons for doing so – all of which bear closer examination. Their approach is a reminder that there are circumstances under which ‘build your own’ is both necessary and a good idea. Some projects also make a case for lightweight and disposable approaches.

All the custom developments have used MySQL and all of those taking this option have been subject strand projects.

• CORE Materials
  • they have built a database for the central management of resources prior to uploading to web 2.0 sites; their own solution was required to support interaction with the APIs of web 2.0 tools.
• Medev OOER
  • they have built a database as a staging ground for preparing OERs – JorumOpen is their primary deposit. They are also considering a local repository in the longer term.
  • MySQL was chosen to be able to interact with Subject Centre website.
  • They are also looking at web2.0 api interoperability
• Open Educational Repository in Support of Computer Science
  • built a lightweight disposable solution as management and publishing tool and staging ground for Jorum deposit
  • Jorum as the primary repository and copy of record/ preservation copy.
• Phorus
  • primary cataloguing of OERs is into Intute which is then harvested via OAI-PMH into their local database
  • they then aim to harvest resources into JORUM
  • they may also move resources to host institution’s (Fedora) repository
• Simulation OER
  • developed local repository both as continuation of earlier work and as available repository options did not meet the key requirement of being able to preview simulations.