The ELOGeo OER Rapid Innovation project (AKA Breaking Down Barriers: Building a GeoKnowledge Community with Open Educational Resources) was proposed by the Landmap team at Mimas shortly after Ben Ryan and I started working at Jorum, and, crucially, just as Jorum was embarking on a big programme of enhancements to make a great leap forward before the end of 2012. This blog post will review how ELOGeo has been a crucial part of Jorum’s emerging plans to provide a JISC-funded shared service, and the journey the Jorum team went on with the Landmap team to make the ELOGeo vision for a repository happen with Jorum as the back end. I should note that, at this moment, due to a number of factors, the ELOGeo repository is not quite ready to launch to the community: more on that further into this blog post. And watch this blog for future announcements re timeline and roll-out for ELOGeo.
Back to the start: early plans
When Gail Millin-Chalabi and Kamie Kitmitto of Landmap approached us with their draft project proposal, we were excited by the possibilities for trialling something that is very important to Jorum: the idea of providing community-specific interfaces, or windows, onto Jorum, tailored for the needs of that community. The two main areas we had been thinking about for this were institutional OER repositories, and subject communities. At the time, we were also in negotiation with the FE community in Scotland, represented by Scotland’s Colleges, about providing them with an OER repository as they moved from a closed model to completely open content. We are now fully engaged in a project to deliver this repository, known as Re:Source, in mid-November; it is our first foray into providing tailored services for a fee, as we move toward a business model of co-funding between JISC and external organisations. Showing that we can offer value to the UK HE and FE community is crucial to us as JISC moves forward into its new structure. And offering added value that communities and organisations will be willing to pay for is part of the vision.
Where we were in early 2012: Jorum and DSpace
As we developed the project proposal with Gail and Kamie, Ben had only just got his hands on Jorum’s DSpace platform, and neither of us were particularly familiar with the technical possibilities. At that point Jorum had been delivered on a very old version of DSpace for a relatively short period of time, with some modifications developed to customise DSpace as a repository for educational resources. None of the developers who had made this happen were in the team when we arrived, so there was some catching up to do. One thing we gathered was that DSpace has READ and WRITE APIs – perfect, you’d have thought, for building a customised front end with Jorum’s main database behind it. Not so, as it turned out.
There were many problems with the old version of DSpace, with the modifications, and with the APIs. In the meantime, we stepped into the middle of a project to deliver an entirely new front end web interface, built on Ruby on Rails, and intended to avoid the DSpace interface altogether and give folk a much more friendly and usable experience of Jorum. This was meant to be built on the READ API and possibly SWORD for ingest, and a good deal of work had already been achieved – but there were things that needed ironing out. Not to mention the requirement that was asserting itself very rapidly: for users and other stakeholders to be able to access stats and other data about the OERs in Jorum and their use. The old Jorum DSpace used an open source stats package that was limited in terms of what we needed to achieve.
New DSpace, new Jorum
With the support of our Jorum Steering Group and some very timely enhancements funding from JISC, we embarked on our Summer of Enhancements 2012. Knowing that we would soon need to deliver really good repository services for Scotland’s Colleges and ELOGeo, and that we needed much better ingest, discoverability, APIs and stats, we set out to take the necessary step of porting DSpace 1.5.2, with the mods needed for OER support, to the most recent version of DSpace – DSpace 1.8.2. We had the funding, but not yet the full team in place, so we packaged up the work and brought in some DSpace expertise from Cottage Labs, Enovation and @Mire to assist Ben. We have monitored the risk associated with the upgrade and kept our programme manager informed throughout; and have not compromised the service to our users at any stage. We know that the resulting service will be a superior offering, and well worth the effort involved.
We have a lot to deliver on this year, and, despite the relatively small size of ELOGeo, this project is absolutely central to our business case to our community:
Jorum can help you meet your subject community’s need to share, promote and access relevant OERs – we can save you the costs of supporting the software and providing the information management expertise in-house – we can give your academics access to the wealth of OERs shared by others via Jorum, while foregrounding your own resources, vocabularies, priorities.
How do we provide these community windows?
When we signed up for ELOGeo, we didn’t yet have a clear set of technical options or services to offer. The really clear use case to us, and to Scotland’s Colleges, Landmap, and other communities and organisations we talk to, is:
* We want a community view onto Jorum that allows access to both the community’s specific resources, and, when required by the user, access to all of Jorum’s resources.
* And we want people using Jorum’s own interface (including searching and browsing, using our APIs and feeds, and harvesting or aggregating from Jorum) to have access to Jorum’s core collection and the OERs provided by the communities that have their own interfaces.
At the start we discussed a few ideas, in varying shades of “lightweightedness”, for providing tailored windows onto content held within Jorum.
1) Lens onto Jorum: This is the simplest concept: putting something specific onto the end of Jorum’s URL and getting a page with the relevant content, e.g.: http://www.jorum.ac.uk/history giving a view on resources tagged or classified ‘history’, or http://www.jorum.ac.uk/universityofstrathclyde showing all Jorum resources submitted by people working at Strathclyde.
2) DSpace Community within Jorum: One of the features of moving to a recent version of Jorum is the ability to set up different Communities, within which you can have Collections. Actually, the old DSpace allowed Communities and Collections too- they just weren’t as configurable. With the new version of DSpace we can customise the DSpace interface for each Community, both in terms of theme and text and in terms of browse and search features and other aspects of the user experience.
3) Customised front end built on an API: This assumes a good working set of APIs and standard interfaces (e.g. SWORD) to allow search and deposit to be presented through a website completely designed from scratch. In theory, the ideal; in practice, a lot more resource intensive.
4) Two DSpace instances sharing content: Still not sure how viable this is, but the ELOGeo content was originally held on another DSpace instance at Nottingham University, so we thought about just having two separate instances, and making sure users could access content from both by regular mutual aggregation of the database contents.
Best laid plans: a change of technical direction mid-project
As can be seen in this blog’s introductory post, we originally went with option 3) Customised front end built on an API:
Building a GeoKnowledge Community at Mimas
Boy, were we wrong! Rest assured, thanks to the Jorum Paradata Enhancement Project with Cottage Labs, Jorum will, when we roll out the results of our Summer of Enhancements, have an excellent API for READ and for stats, and we will be providing some usable ingest interfaces, and we will be eating our own API dogfood in providing our own new front end, but at the start of the ELOGeo project, we quickly determined that we would move forward with implementing ELOGeo as a Community within Jorum, with its own URL, visual identity and interface.
As required, ELOGeo users will be able to:
(a) Deposit content through this interface into the ELOGeo Community collections – but this content will be available to anyone accessing Jorum content also;
(b) Browse and search, using their own community-specific vocabularies etc., the ELOGeo-specific content held in their Community collections; and
(c) Expand any search or browse to include all relevant Jorum content in their search results.
At the time of writing we don’t have a screenshot to show you of the ELOGeo interface, but to give you an idea of what a DSpace Community interface built onto Jorum might look like, here is a screenshot of the current Beta of Scotland’s Colleges’ Re:Source repository, which, as you can see, has sub-communities within this Community in Jorum. NB: this will be a lot more developed with faceted browse vocabularies and so on by the time they launch in November.
Re:Source Beta: screenshot example of customised DSpace Communities interface
But it’s the end of the project: why haven’t we delivered?
Unfortunately, Landmap and hence the Breaking Down Barriers project lost their key developer (and the knowledge she had gained) at the start of the project; this led to overall delay and a project extension. Jorum received word of being funded to July 2013 in June and was able to begin the recruitment process for our own development team – but this was only partially successful and took us right to nearly the end of the project, with our first new developer not starting until mid-September.
Add to this the massive complexity of Jorum’s own in-house development task: pulling together the port to DSpace 1.8.2 with the requirements of Scotland’s Colleges, a few small-scale projects (of which ELOGeo was one), completing our own new front end, and developing and integrating a new stats dashboard, underlying search technology, and APIs, all managed by one Technical Manager. Our new Repository Application Developer started in mid-September, and we still have no Web Application Developer.
Technical lessons learned
To launch ELOGeo, we need to roll Jorum out on DSpace 1.8.2 in order to make the whole ELOGeo window-on-Jorum concept work. Technical complexities (I won’t say “unforeseen” because there are always technical complexities, you just can’t say in advance how onerous they will be) included:
- working out how best to get the ELOGeo DSpace content out of its old repository into Jorum (see Landmap developer Bharti Gupta’s excellent technical post on this);
- difficulties in porting the DSpace modifications needed to support the particular requirements of sharing OERs;
- with some banality: difficulties in implementing different visual design themes into DSpace at the Community level. As you can see from the picture above, it is definitely possible to do- but it breaks stuff that then needs to be followed up and fixed.
We hope to follow up with a more detailed post on, in particular, the technical barriers and solutions to delivering an OER sharing services built on DSpace Communities. Keep an eye out for that one. NB: Landmap developer Will Standring has done some excellent posts on his technical achievements – really useful for anyone working with DSpace.
Meanwhile, I can say that I am thrilled, as Jorum Service Manager, that we have one method trialled and true for providing community and organisational windows onto content with Jorum – certainly the process will be a lot slicker going forward, and the wider HE and FE community will benefit from an increased wealth of open content for education. And we are happy to be openly sharing what we have learned so that others implementing educational content services using DSpace (or indeed, any community doing something similar) can move with ease through some of the barriers we encountered.
We welcome comments, questions and feedback, and would like to encourage you to get in touch with Jorum if you need further information on any of the above.