Closing the ukoer circle?

The titular Unicycle of our phase 1 ukoer project at Leeds Met referred to “a prototype mechanism for the export and import of open educational resources” that would seek to “share OER materials with…HE community via JORUM”.

To recap, under the ukoer programme, it was mandated that all resources released by an institutional project must also be made available from the national repository service Jorum. The method used by most phase 1 projects was harvest of metadata only by RSS, however, in our case, we were unable to produce an RSS feed in the necessary format and in lieu of OAI-PMH which was not supported by Jorum, the requirement was fulfilled by a full IMSCP transfer – I simply uploaded a zip file of all resources that the JORUM tech folk were able to ingest directly into DSpace. At the time this was seen as the ideal solution for Jorum which, as a “repository”, should seek to preserve actual files rather than just URIs pointing to resources elsewhere. However, it meant that our files were duplicated in both repositories and that our repository would inevitably be eclipsed by Jorum in search engine results. I’ve explored these implications elsewhere and they have also cropped up as part of the ACErep project and I have become convinced that a better solution for us would be for metadata only to be harvested (or possibly deposited by SWORD*) including a URI in our institutional repository.

(Our OAI-PMH is already harvested by the Xpert repository at Nottingham University)

As ukoer folk will be aware, the management of Jorum is currently undergoing substantive restructuring; hitherto a joint project between EDINA and MIMAS, from 1st August 2011, the service will be managed exclusively by MIMAS and will liaise more closely with the NDLR – http://www.ndlr.ie/ – in Ireland (also based on DSpace) and utilising a common, Open Source code-base.

One of the likely early developments from this is that Jorum will soon support OAI-PMH – the protocol is already supported by the NDLR running on a more current version of DSpace – allowing us, I hope, to revisit how our resources (metadata only) are ingested into Jorum. In addition, MIMAS will be putting further development efforts into enhancing the Jorum API which has already been identified as a pre-requisite for both our ACErep project and the PORSCHE project at Newcastle University.

* SWORD deposit (metadata only) into Jorum in tandem with file deposit into a local repository should be technically possible I think and would potentially have the benefit of records being available immediately from the API rather than the inevitable delay associated with harvest (Xpert harvests overnight).

This evolving national infrastructure is obviously essential to advocacy around Open Educational Resources; the development, release, use and reuse of OER at an institutional level and will necessarily underpin developing institutional infrastructures. For example, in conjunction with promotional activities here at Leeds Met and technical developments from Intrallect – notably a desktop SWORD client (beta) that can capture core ukoer metadata and deposit to our intraLibrary installation – I hope that we can close the ukoer circle such that teaching staff can source their own OER from Jorum, Xpert or other institutional or subject source – reuse and/or repurpose under the terms of Creative Commons and redeposit back into our local repository and thence automatically to Jorum / Xpert / other syndicated OER services (e.g. Learning Registry) via OAI-PMH and / or SWORD.

Advertisement

Linking from a research paper to associated OER and thoughts on extending the CRIS model to OER

With our “blended” repository comprising research and UKOER, I still feel very much like I have a foot in two camps. A feeling that, ironically, is reinforced, by my role as Technical Officer for UKCoRR – the UK Council of Research Repositories!

I think I’m right in saying that it’s still atypical to manage both types of resource with a single repository platform and there are certainly considerations why it may not necessarily be desirable – both from a technical and political perspective.

The main repositories that have been developed as part of the ukoer programme are modifications to DSpace (Jorum) and EPrints (HumBox, EdShare), the two main open source repository software platforms that were both initially developed to manage research. In contrast, we have worked with intraLibrary, a commercial learning object repository, to manage both OER and research and while this certainly hasn’t been without it’s problems, I’m naturally interested in potential benefits from this approach both in terms of “reward & recognition” for OER by something analogous to peer-review perhaps (a theme that was explored as part of the Unicycle project) and also in terms of work-flow, possibly mediated via a CRIS-type system such as Symplectic Elements or Atira Pure…

intraLibrary has a workflow to link related resources which I can easily use to link a research paper with associated OER, so in the example below I can link…

Coates, C., Smith, S. (2010) Promoting the concept of competency maps to enhance the student learning experience. Assessment, Teaching and Learning Journal (Leeds Met), 10 (Winter), pp.21-25.

…to the three ALPS Common Competency Maps in the OER collection (see Linked Resources at the bottom of the record):

ALPS Common Competency Map – Communication

ALPS Common Competency Map – Ethical Practice

ALPS Common Competency Map – Team Working

These records, in turn, comprise links back to the research paper (and associated conference paper):

With such an approach, is there perhaps an opportunity to tie research and OER more closely together at an institutional level (if this isn’t politically naive!) and contribute to research led teaching?

The next stage might be to develop a common workflow for research and OER…

Workflow, in fact, has long been a bug-bear of mine and, for both types of resource, essentially remains fully mediated by me and administrative colleagues. In all likelihood, however, as are many institutions, we will soon be implementing a CRIS that will make it easier to collate institutional research outputs by harvesting research data from external bibliometric sources, as well as allowing records to be added manually, and integrating with the repository such that academic staff are able to attach an appropriate full-text to a record and upload it along with metadata into the repository directly from a “user-friendly interface” (TM).

At a recent demo of one of these types of system I confirmed that it could transfer a range of file-types to a repository (utilising SWORD) as well as allowing various licences to be configured including (I think) Creative Commons so there seems no fundamental reason why such a system could not be used to support the workflow for both OA research and OER.

Of course I will need to get my hands on one of these systems before I can properly investigate exactly what is achievable…watch this space.

Interviewed at OER Hack Day

Nick Sheppard at DevCSI’s OER Hack Day from UKOLN on Vimeo.

Repository deposit from the desktop

Thinking about repository workflows for staff – put a deposit client where their resources live, on their desktop…

What I have:

A (slightly unwieldy) set of files comprising:

• (an earlier version) of the SWORD client available from http://sourceforge.net/projects/sword-app/ (an Executable Jar and related files)
• a Visual Basic Script
• a Windows Batch file

How it works:

The VB script was written by Boyd Duffy at Keele University and, as a non-developer, I know only that I need to edit  sword_deposit.vbs with my SWORD DEPOSIT_TARGET. It’s then simply* a matter of dragging and dropping a file (or multiple files) onto the VBS icon for them to be uploaded into the repository (workflow can obviously be configured in the repository itself, to be published immediately**, for example, or, more likely, go into a workflow where metadata can be added according to a particular Application Profile).

** I think Keele use it as a quick and dirty method for image files to be transferred from desktop to repository from where they can be immediately accessed via a VLE PowerLink.

Here is a screen capture that I did a while ago: http://www.leedsmet.ac.uk/inn/repository/video/SWORD_drop_from_desktop/

* Re simple – I can, in fact, only make it work from a Leeds Met IP!  Perhaps something to do with PROXY_HOST / wireless?

What I need:

METADATA of course!

The current tool is of limited use as it just pushes a file into the repository. In fact, it will quite happily push a Content Package – a Zip comprising a file and some metadata as XML – either an IMSMANIFEST (which I would need for intraLibrary) or METS for DSpace (i.e. Jorum.)

Though I don’t have the skills myself, I’m hoping someone can tell me how we might develop a desktop app to integrate a way of capturing the metadata associated with a resource, converting it into an IMSMANIFEST and/or METS, zipping the whole lot up and pushing it to a repository (or multiple repositories) via SWORD …

If we were to use our current ukoer AP we would need to capture:

• Title
• Description
• (Uncontrolled) Keyword(s)
• Author / owner / contributor
• Date
• Type of resource
• Technical format
• Licence information
• Subject classification (HEA and JACS)

Click link below for an example IMSCP:

http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary?command=open-package-download&learning_object_key=i3605n162666t.zip

Or link below for METS (with cut-down metadata); this package has been successfully deposited in Jorum (dev) via SWORD:

http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary?command=open-preview&learning_object_key=i3128n92902t

N.B. A practical issue with this approach might be including such an application on an institutional staff build and I have heard rumours that it might be possible to achieve similar drag and drop functionality with a web-based app using HTML5 – browser support still inconsistent though I think.

Xpert vs Jorum?

Xpert – http://www.nottingham.ac.uk/xpert/ – at Nottingham University is a “distributed repository of e-learning resources” and contains metadata and resources for almost 70,000 learning objects from over 3000 providers. Recently the project has released some interesting tools in the form of Xpert labs including APIs to return CC licensed OER in a variety of data formats and a basic SDK (Software Development Kit).  There is also a code snippet to add Xpert search to your site like this – http://www.leedsmet.ac.uk/inn/repository/xpert.html.

As a manager of an OER repository I am chiefly interested in assembling and preserving a collection of high quality assessment, learning and teaching material from my institution that can be discovered and reused effectively by teachers/lecturers in UK HE (and globally) and have been able to work with @Xpert_project to ensure that an OAI-PMH feed from our repository is harvested by the service – this took a little bit of code-tinkering (thanks to @patlockley) as our metadata incorporates multiple <dc:identifier> fields the first of which holds the OAI ID with the second holding the location URL – the end result from Xpert is a nice record of our ukoer including a properly formatted description, the URL for the CC license and, as I’ve just noticed,  related resources – for instance, the search below returns 4 component parts of a SCORM package that I added yesterday (that, in its complete state, would not run in our VLE – a SCORM 1.2 LMS – as the large number of JavaScript variables exceeds what is possible under version 1.2  resulting in an error after slide 6 – it plays fine in intraLibrary though). I also used this opportunity to experiment with intraLibrary’s “linked resources” functionality which Xpert can display from the XML return:

http://www.nottingham.ac.uk/xpert/scoreresults.php?keywords=leedsmet&search_all.x=69&search_all.y=18&search_all=all&ukoer=on

What is missing, however, is any indication that this resource emanates from Leeds Met – think I’ll need to add a <dc:publisher> field to fix this – currently we only provide <dc:creator> which Xpert maps to author; this also means that our institution does not appear in Advanced Search under Institution…

It’s probably too much to ask Pat to add the link URLs using <lom:identifier></lom:identifier> as I hope to do from Open Search (and Xpert labs does include an API specifically to return related objects using the base url http://www.nottingham.ac.uk/xpert/related/ adding a list of comma separated keywords, then a number of results you’d like to return to the end of this URL e.g. http://www.nottingham.ac.uk/xpert/related/ukoer,5.)

As these are SCORM packages, though, I would like to add a link to download the package itself which could then be imported into a VLE…once again this is functionality that we are yet to incorporate into Open Search and they currently just play directly in the browser or they can be linked directly from Blackboard using our PowerLink but the necessary URL to download the package is in the SRU and OAI-PMH returns:

<package:packageType>scorm</package:packageType>
<package:packageTypeVersion>1.2</package:packageTypeVersion>
<package:packageDownloadLocator>http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary?command=open-package-download&learning_object_key=i06n105033t.zip</package:packageDownloadLocator>

These resources then, made live yesterday afternoon, are already available from Xpert; they will also,  eventually, find their way into Jorum Open but this requires further intervention from me – we’re not using the Jorum RSS harvest for technical reasons but I don’t *think* that facility could perform a daily update harvest in the same way as OAI-PMH. I’m still working on the workflow for regularly packaging my IMSCPs and publishing them as a .zip for the kindly folk at Jorum to harvest from Open Search (there has, in any case, not been much new added since the end of the Unicycle project – http://repository.leedsmet.ac.uk/main/view_record.php?identifier=2845&SearchGroup=Open+Educational+Resources).  When our processes are fully embedded in institutional practice I anticipate putting up an archive say every month; of course this will have the “advantage” of preserving the full IMSCP in JorumOpen rather than just the metadata and the link which is all that is harvested by Xpert but I don’t think this is a particular concern for *me* as I am responsible for my own preservation via our own formal repository platform (this building on the discussion from my last post.)

Xpert grew out of JISC Rapid Innovation funding last year which perhaps goes some way to explaining the (arguably) more agile development compared to Jorum (who I really don’t wish to be disparaging towards – I think the @jorumteam have done a fantastic job in the past 12 months and the national service is really taking shape; they obviously have a more formal remit than Xpert and have responded very positively to a wide array of stakeholders as evidenced in their recently published Road-map – they have also been very helpful to me and Unicycle on a personal/project level and this post is more about bigging-up the small guy than doing down the big-guy!)

JorumOpen currently holds an impressive 10 and a half thousand  OERs catalogued as HE – still a fraction of the size of Xpert (is sheer size actually likely to become an issue when searching for suitable OERs in either service?)  In addition, a large proportion of these records (how many?) are likely to be metadata/link only as they have been harvested by RSS which presents potential issues for preservation (see last post)…in any case, all credit to Xpert who have developed a responsive service that goes a long way to it’s stated aim of “delivering and supporting a distributed repository of e-learning resources” and providing real value to the (global) HE community to boot!

OER repositories and preservation – the elephant (not in) the room?

Way back at the beginning of the ukoer programme there were discussions around including a link to a resource in JorumOpen rather than the file itself; Gareth Waller emphasised on my post at the time that “having a chain of URLs does not present any technical problems in the sense that the end resource can still be found, the problems only appear when the link chain breaks (either via a bad URL or a server not responding).” He also emphasised that “if the physical resource is submitted into Jorum, we may be able to offer enhanced searching to the end user for that particular item e.g. full text search on a pdf. If a link is submitted, we can only allow the user to search on the metadata associated with the resource.”

The issue has cropped up again recently on the JISC-REPOSITORIES mailing list where @lescarr makes the point that, of the recently announced six winners in the Jorum Learning and Teaching Competition, which are all discoverable from Jorum, none are actually deposited in the national oer repository – just metadata records with a web link to the location elsewhere on the web.  Les goes on to emphasise that, while this is perfectly useful, “one of the raisons d’etre of repositories is to provide persistent, safe access to valuable material”.

There was a lot of discussion throughout the ukoer programme around the pros and cons of duplicating resources in Jorum as opposed to simply linking to resources held in other repositories/on institutional or third-party websites and also on the development of tools to harvest metadata via RSS and OAI with different projects having different preferences depending on the tools they were using and the types of resources they were releasing (see http://blogs.cetis.ac.uk/lmc/2009/12/09/oer-rss-and-jorumopen/).  Responding to a clear demand from the ukoer community who understandably did not wish to dual deposit both locally and into the national repository, Jorum therefore developed a tool to harvest metadata via RSS (which I presume is why many records are metadata only).

Our Unicycle project, in fact, as one of the ukoer projects using a formal repository platform that makes it straightforward to export resources as IMS content packages,  is one of the few projects, I think, to actually bulk upload our OERs to Jorum – however, many of the resources in our repository are themselves metadata records only that point to an external resource on leedmet.ac.uk, YouTube, joebloggs.com or wherever which clearly carries implications for preservation…Our OERs are also harvested by the xpert repository at Nottingham using OAI-PMH. Xpert is “a JISC funded rapid innovation project (summer 2009) to explore the potential of delivering and supporting a distributed repository of e-learning resources…to progress the vision of a distributed architecture of e-learning resources for sharing and re-use.”  As such, there are no resources in Xpert per se, just links to resources harvested from various feeds – which means, of course, that it cannot have preservation as one of its raisons d’etre (I recently learned during a twitter conversation with the repository itself that xpert use a 404 checker that checks all their links once a week and deletes any that are broken.)

The ukoer programme was necessarily none-proscriptive around technology (apart from mandating “deposit” in Jorum Open) and, as made clear in @kavubob‘s series of posts The use of…in the ukoer programme a wide range of tools and platforms were used including but by no means limited to formal repositories  – Web 2.0 technologies in particular lent themselves to the programme, even for projects like our own that did use a formal repository we were often simply curating resources on external web-sites (Web 2.0 is third party pretty much by definition and a well established source of anxiety for preservationists).  What, then, are the implications for preservation of OERs and is it an elephant that we will struggle to keep in the room?  To what extent does it matter if an individual resource, perhaps poorly curated, disappears from a specific web-location; if it has been “released into the wild” under Creative Commons (and it’s any good) then there is a good chance it has already been reused or duplicated elsewhere – perhaps disaggregated or modified (Lots of Copies Keep Stuff Safe)?

Unicycle final report

The final report for the Unicycle project is now available, along with  supporting documentation, from http://unicycle-leedsmet.ning.com/ (direct link for the report is  http://www.box.net/shared/kk4jisht5e)

The report is also available from the JISC website pages for Unicycle

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.

End of a pipe dream?

I’ve been enjoying exploring Yahoo Pipes and have now managed to generate a feed for OER that also incorporates the author vCard; I’m sure it must also be possible to extract other data including rights information (though I’m not quite sure how!):

http://pipes.yahoo.com/mrnick/build_rss_from_xml

(vCard not visible in the Pipe but is displayed if the Pipe is rendered as RSS)

It also occurred to me that it may be possible to use a similar method to extract the abstract for research RSS feeds (which is in the second description field) and I’ve been grappling with Pipes to this end but am struggling at the moment – tantalisingly I am able to construct a “Path to item list” that returns an individual abstract but for the life of me, can’t figure out how to return abstracts for all records – SRW:records.SRW:record.1.SRW:recordData.lom:lom.lom:general.lom:description.1.lom:string.
content

I’ll certainly continue to use Pipes as it’s a very powerful tool, especially for a non-programmer like me, however, for the time being this mini-project is postponed. Nothing is ever wasted though and I’m sure what I’ve learned will come in useful somewhere down the line….

Pipe dream

This afternoon I’ve been grappling with Yahoo Pipes, trying to generate a feed that incorporates metadata from an SRU query.  I’ve made a modicum of progress and, as I’m now a bit stuck, this is just a quick post to document that modicum before it all leaks away over the weekend.

The Pipe module that seems most appropriate is “Fetch Data”: “This module retrieves any XML, JSON, iCal or KML file and tries to extract a list of elements using the provided path parameter.”

I input an appropriate URL to query “ukoer” which will return all OERs uploaded as part of UniCycle:

http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary-SRU?recordSchema=lom&maximumRecords=50&operation=searchRetrieve&version=1.1&query=ukoer&SearchSubmit.x=18&SearchSubmit.y=24&x-info-2-auth1.0-authenticationToken=oer

And read the instructions here which describe how to use the “Path to item list” field in order to extract just a portion of the data by listing the nested XML elements, separating each with a dot (“.”)

After a bit of trial and error I was able to zero in on the “Description” field for the first record by entering SRW:records.SRW:record.0.SRW:recordData.lom:lom.lom:general.lom:description.lom:string.content into “path to item list”

However, when I attempt to run the pipe, nothing is returned  – though the correct field IS displayed correctly in the debugger panel:

Also, what I would like to do of course, is to return the “Description” field for ALL records but I have no idea how to achieve this…I’ll have another look when I’m nice and fresh on Monday morning!