Since it was made live at the start of January 2011 over thirty OERs have been added to the OSTRICH repository. Use has been growing steadily and we've so far seen 628 visits and 3013 page views. Some of the most often visited pages include:
For those that want to install a distributed repository for Open Educational Resources identical to that used by the OSTRICH project at http://ostrich.bath.ac.uk the files required to build a repository have been made available as an OER that includes the Drupal 7 codebase and database, in the form of a MySQL dump file.
We've now hit the stage in the OSTRICH project here at the University of Bath where our understanding of the OER environment is really taking shape. And with more experience of the processes involved under our belts, the issues and challenges of creating or converting OERs for our institutional context are beginning to show as emerging themes.
- Intellectual property rights and copyright issues
- What makes a reusable OER: an understanding of audience/end-user and of the use and reuse cycle
- The sustainability of the OER creation/conversion process
Many of these themes were echoed in discussions at last month's dissemination event for UKOLN. This talk with an invited audience and live stream online saw myself and Alex Lydiate (Educational Software and Systems Devloper in the e-Learning Team) explaining the context of the OSTRICH OER project, describing the build of the OSTRICH repository and highlighting the emergent themes at this mid-way point in the project.
The audience was a mix of information professionals, research staff and data managers. It made for some interesting discussions that mirrored many of the themes that have been raised both in the Synthesis and Evaluation stage of the pilot JISC programme and in recent conversations at programme level events for Phase Two.
The discoverability of resources was considered of great importance. It was useful to hear an end-user perspective on this in the form of Library Services staff who advise academic staff on locating suitable resources and struggling to find their way through the maze of available OERs.
This was followed by a debate about metadata; the need to get the balance right between adequate metadata to ensure discoverability of resources and the impact that providing this information has on staff time and their willingness to engage with OER. This naturally led on to a technical discussion around the automation of metadata collection and options for the presentation of metadata to enhance discoverability of OERs.
It was really useful to engage with a wider OER audience in this way and the conversations we had will provide a valuable input into our evaluations of the project and the processes we've been developing recently.
The first version of the OSTRICH OER repository is now live at ostrich.bath.ac.uk. At the moment this is just a prototype to give the project team a chance to test functionality and theme the space. The 'content' links currently point mainly to Google pages rather than real files; and the formatting, text and associated documents are in draft form and more than likely to change. However, it does give us an initial draft to work from so that we can get an idea of the look and feel of it...
For those interested in the technical set up, our developer Alex Lydiate has blogged about the initial construction in Drupal 7 and the underlying data structure here.
We've been calling this a distributed repository since it's designed to link out to OER resource files held elsewhere (see the blog post on the initial plan here), but we've since been given the name 'referatory' by John Robertson at JISC and that does a much better job of describing its functionality...
We've referred to the JISC OER Programme Phase 2 Technical Guidelines and the JorumOpen bulk upload deposit options while planning both the repository and the data to be collected for each OER.
The detail of this planning has been set out in the following document, and while this probably raises as many questions as it answers (some of which we still as a team have to answer!) it may be of help to others who are going through a similar planning process.
Following on from the renaming of CORRE as d-CORRE (devolved-CORRE) we now bring you what has been nicknamed d-Repository. D is for 'distributed' since our developer won't let us call our proposed model a repository. Strictly speaking, our resources won't be 'reposing' in it!
Similar to some other Phase One OER projects, concerns about versioning and about our ability to easily update and take-down materials from the repository has led us to consider a model where a central OER record links out to distributed resources. These will potentially be held in a variety of institutional and external services.
Initial planning for OSTRICH d-repository
Whilst we're setting up this repository for the OSTRICH project, we're also thinking ahead and using the experience as a basis for planning functionality we'd need from a OER repository here at the University of Bath in the longer-term.
So, for the OSTRICH d-repository, input from the team at the University of Derby about our proposed model has been sought and a process for adding/removing content will need to be worked out between us.
Looking at the longer-term, Library staff with responsibility for our OPUS e-Prints repository of research publications (opus.bath.ac.uk) and our Web Services team (who provide the Learning Materials Filestore) may be able to offer insight into how the model might fit with current and any future services/systems the University offers.
The content of the JISC OER Phase One Synthesis and Evaluation of Technical and Hosting Issues, particularly those from the Institutional Strand, is proving invaluable. As will any advice that the team at the University of Nottingham might be able to give us about what they've discovered so far about potentially semi-automating the upload of OER records into JorumOpen via RSS.
Other questions and issues we might need to explore shortly include:
- 'Extraction' of Derby's OER records and resources at the end of the project, if required
- How to best organise ownership' of OER records and linked resources/materials to allow for effective update/removal at a later date
- Whether it is possible/desirable to separately theme OER records from each institution
- The collection of metadata: what is appropriate/useful/practical to collect, who will author metadata, can the repository process support joint authoring or follow a draft-version-to-central-sign-off process
- Support mechanisms to put in place for users - including guides on where and how to store materials
- Will comment/feedback on OERs be enabled?
- How to evaluate/track OER usage: Google Analytics? Survey?