Suggested enhancements to JorumOPEN user interface

A very thorough post on the JORUM community bay from the C-change in GEES project – http://c-changeproject.org.uk/ – on suggested enhancements to the JorumOPEN user interface:

http://community.jorum.ac.uk/mod/forum/discuss.php?d=98

Unicycle project completed (and some unfinished business)

Our ukoer project Unicycle completed at the end of April 2010 – Simon has now submitted the report to JISC which I shall link to from here when it is published.

The main aim of the project has been to build a ‘unicycle’: a prototype mechanism for the export and import of open educational resources at Leeds Metropolitan University and increase the release of open educational resources (OER) from Leeds Met into the further and higher education communities.

The image below links to a presentation that Simon delivered at OER10 at Clare College Cambridge (22nd – 24th March 2010) (PDF format)

Unicycle, like the JISC ukoer programme as a whole, was very much a pilot project and as Repository Development Officer I was mainly involved with, well, repository development rather than wider institutional policy and process development; technical infrastructure, however, is obviously an integral aspect of ukoer both at an institutional level and, by definition, across the wider information environment so programme and project have certainly informed ongoing repository development here at Leeds Met.

(By no means all ukoer projects use repositories and the variegated technologies across the programme are explored in a series of recent posts by John Robertson of CETIS – http://blogs.cetis.ac.uk/johnr/category/ukoer/.)

…and the unfinished business

It has been particularly interesting working with Jorum – as a national repository service it is a condition of funding that all projects funded under ukoer must also make their resources available via JorumOpen which is an ongoing challenge; it became apparent very early in the programme that folk did not particularly relish the prospect of duplicating their workload by uploading and cataloguing resources in two locations and Jorum has investigated several methods for harvesting institutionally held collections and/or bulk upload of resources.

There are two methods that have so far been implemented:

RSS

RSS was explored quite early in the programme as a potential technology for metadata harvesting and has the benefit that it is relatively simple to implement.   Jorum have incorporated an RSS reader into the modified DSpace repository that is used for JorumOpen and projects are able to submit an RSS feed for harvest as long as that feed meets certain criteria (e.g. Only a RSS version 2 feed is currently supported/the feed should include a UK Eng&Wales v2 CC).

There are also several caveats to harvesting in this way:

• The feed is not continually polled for new content. Normal feed readers, continually poll the feed and any new items are displayed. The current functionality simply reads the feed when it is deposited – if the same feed is submitted again, it will store duplicates.
• The file data of a resource in the feed is not stored in JorumOpen. A link is simply created pointing to the resource as indicated by the RSS feed (the “link” element).
• Items within a feed are not auto classified within Jorum. In other words, every item in a feed is stored within a single collection as chosen by the admin user i.e. a top level JACS or LearnDirect classification. Having individual feed for each classification such as the OpenLearn model would ensure that items are classified correctly as these feeds can be deposited separately.

The default RSS generated by intraLibrary contains just title and description fields and is therefore not suitable for deposit using this method. It may be possible to programmatically generate an appropriate feed containing the required data but bulk upload of IMS content packages represents a much easier method for us that also has the advantage of depositing the resource itself in to JorumOpen rather than just the metadata.

Note:  Some of the issues around using RSS to harvest metadata in this way are explored in more detail in a paper by Jorum Technical manager Gareth Waller

Bulk upload of IMS content packages

It is relatively straightforward in intraLibrary to bulk-export IMS content packages to generate a .zip file up to a maximum of 100MB at a time.  Each .zip in turn contains multiple .zip files for each resource which contains the file (unless it’s a URL) and the IMS manifest with all the metadata, in the format specified by Jorum.

We are not quite home and dry just yet and have run into a few problems associated with the different metadata standards utilised by our own intraLibrary (UK LOM) and Jorum’s DSpace (DC); packages consisting of web resources from intraLibrary are not parsed because the packager implementation expects a web link to be in a certain metadata element in the manifest but intraLibrary places the link in a different element so any web resource exported from intraLibrary will not be ingested successfully (the metadata record will appear in DSpace but the web link is missing.) In addition to this, multiple authors and author VCARD metadata from our packages was not in the format expected by the Jorum packager which can result in resources marked as “Unknown Author”.

All is not lost, however,  and Jorum plan to introduce a code change to programmatically manipulate the packaged metadata before ingest so that the web-link is in the correct field and the author vCARD is in the suitable format for DSpace; Jorum also have an intraLibrary repository from which they may wish to bulk export records in the future.

Other issues and niggles

There are several other issues and niggles that I have become aware of through Unicycle – some relatively easy to fix, others less so.  I’ll just list a few of them here and aim to explore further in future posts:

1. Several formats raise issues for reuse:
   • Flash: we have several Flash resources comprising multiple .swf that can-not easily be linked in intraLibrary so are just uploaded as a zip
   • Respondus: A proprietary WebCT file format that must be exported to WebCT/Blackboard from Respondus software
   • webct.assessment: Another proprietary WebCT file format (as .zip) that simply does not work in WebCT/Blackboard when it is downloaded from intraLibrary (though the original.zip is fine – may be due to a modified imsmanifest.xml)
2. Managing packages:  Currently the majority of our OER are single files; in order to preview SCORM packages etc we may require some major changes to the SRU functionality of Open Search (may want multiple download links for example.)
3. Comments and tags:  IntraLibrary does support user generated tags and comments as well as an Amazon style star rating system; however, it is only possible to access these facilities when logged into the system and not via SRU which means that comments, tags or star-rating cannot be added or retrieved from the Open Search interface.
4. Workflows:  Not terribly satisfactory, especially if we want folk uploading their own OERs rather than the fully mediated process we have followed for Unicycle.  Ideally we would like a very straightforward SWORD tool.

Advertisement