“The primary aim of the PORSCHE project is to provide “seamless access to academic and clinical learning resources to healthcare students”… “establishing the basis for a long term national partnership between the NHS and academia by sharing of appropriately licensed content between Jorum and the NeLR”. To achieve this, PORSCHE has been exploring metadata transfer between the two repositories using OAI-PMH. Jorum is currently running on a modified DSpace (v1.5.2) and the NeLR on intraLibrary (3.1) both of which will of course expose an OAI-PMH feed, however, there would be an additional requirement for each repository to ingest each other’s feeds which is functionality that is not currently supported by either platform, though it is supported by the NDLR running on a later version of DSpace (v1.6) while PORSCHE are currently liaising with Intrallect to develop similar functionality in intraLibrary.”
Along with the PORSCHE team I’ve recently been testing a pre-release intraLibrary 3.5 which now includes an OAI-PMH harvest facility so that the metadata from external repositories can appear as a “collection” in intraLibrary. In the context of our own ACErep project, for example, this would also allow us to harvest the ALPS collections from the repositories at the University of Leeds and York St John, thereby offering a form of federated searching as collections are all brought under the standard intraLibrary search mechanism.
Selecting the OER collection from the Leeds Met repository (corresponds to OAI set=23) I am able to select harvested metadata format (dc or lom) and type of harvest (All Records, Since Last Success, From Date), time to run, and select intraLibrary Group/Process and Collection:
…and then, crucially for ACErep, I’m able to search my harvested collection (called mrnick) by SRU:
Not sure yet when we’ll be able to get intraLibrary 3.5 but it should then be straightforward to harvest ALPS collections from the University of Leeds and York St John and search all ALPS resources across the three institutions from an ALPS branded interface.
In the context of PORSCHE, when the NHS is running 3.5 they will be able to harvest relevant collections from Jorum (e.g. HE – Medicine and Dentistry) into the NeLR.
<setName>HE – Medicine and Dentistry</setName>
Work to achieve similar from Jorum is ongoing via liaison with PORSCHE – see also my post on the UKCoRR blog at http://ukcorr.blogspot.com/2011/12/jorum-steering-group.html and this recent post on the Jorum blog on Coming improvements to the Jorum UserExperience
Recently I attended a “hackathon” at the University of Leeds, a day long event which brought together programmers and educators/clinicians/information managers to work together on developing apps to support learning and teaching. It aimed to be an informal, fun day of sharing, learning, meeting new people and exploring the exciting possibilities opened up through the use of mobile technology.
It was decided to set up a wiki to record the event and to serve as a discussion space, see http://alpscetl.pbworks.com/
This was the final meeting of the PORSCHE Executive Board – I attended by telephone and submitted this written update from ACErep:
After initial testing of the EasyDeposit SWORD client with the Jorum development server (see April 6th update) we have now configured the client with a SWORD endpoint for each of the several repository platforms we hope to deposit into. These include a demo install of DSpace – http://demo.dspace.org/ – the NDLR (in lieu of Jorum), the WRRO EPrints repository and our own intraLibrary repository.
We have been able to successfully deposit into http://demo.dspace.org/ and into the NDLR (also DSpace) but the client fails with EPrints with a generic error message. I have not yet established what the problem might be and queries have been raised with ‘email@example.com’ and ‘firstname.lastname@example.org’.
SWORD has now also been implemented at York St John (Archivalware) and is currently being tested – I have not yet been able to test with EasyDeposit.
DSpace, EPrints and Archivalware should all accept METS packages but in order to deposit into intraLibrary it is necessary to extend EasyDeposit to package as IMS – negotiation is currently underway to carry out this work in partnership with Intrallect hopefully in time for the ALPS Showcase on 16th September* (there will still also the requirement to standardise Application Profiles across the repositories).
In terms of repository cross-search it was suggested that we may be able explore doing this via the DSpace (v1.6) API (the version run by the NDLR) though I have not yet seen any documentation though our content has now been successfully harvested into the NDLR (test install) via OAI-PMH.
* This work has now been scheduled for w/c 29th August
I’ve installed Stuart Lewis’ EasyDeposit sword client – http://easydeposit.swordapp.org/ – and configured it with several sword endpoints covering the several repository platforms we hope to deposit into:
http://training1.eprints.org/ (Thanks to Dave Tarrant)
http://www.ndlr.ie/ (Thanks to Phil Franks)
I’ve been able to successfully deposit into http://demo.dspace.org/ and into the NDLR (also DSpace) but the client fails with the EPrints training install with a generic error message – I don’t know EPrints very well so don’t know if it’s a problem with EasyDeposit or the configuration of the EPrints repository I’m trying to deposit into. I can see two collections in the client (see below) and had a quick rummage around in training1.eprints.org but can’t see an obvious way to configure collections [am Training Admin]….any EPrints folk out there able to help?
(It also won’t yet work into IntraLibrary but that’s due to the fact that EasyDeposit packages as METS and IL only accepts IMS-CP.)
Game-Informed Risk Assessment? – A Labyrinth based toolkit for managing a good practice risk assessment workflow and guidance for open educational resources
Just a quick post live from #elhealth2011 – just seen Stewart Cromar from Edinburgh University talking about “labyrinth” as used by the MEDEV toolkit – http://www.medev.ac.uk/ourwork/oer/toolkits/
Also had very brief discussions with Stewart and PORSCHE team about the possibility of implementing a similar system at another institution – I think it has the potential to fulfil our deposit use-case for ACErep (and OER in general) . Basically the toolkit leads a user through the process of file-upload, metadata addition, appropriate licensing and syndication to several destinations – Jorum, other repositories*, Web 2.0 services like You-Tube.
*I’ve also been pestering one of the MEDEV developers about implementing SWORD which would be fulfil this requirement (as I understand, currently syndication to Jorum will be by RSS harvest.) He’s sat behind me so will try to get him to comment here!
As I posted recently over on repositorynews and as ukoer folk will still be aware, from 1st August, Jorum, historically overseen jointly by the national data-centres in Edinburgh (EDINA) and Manchester (Mimas), will be managed exclusively by Mimas and will liaise more closely with the NDLR in Ireland.
Yesterday I took part in a telephone conference organised by the PORSCHE project team with representatives of Mimas, the NDLR and their technical partners Enovation – this post is to summarise the discussion and describe the processes of data transfer required by PORSCHE and ACErep.
Just to emphasise at the outset that Mimas are extremely positive about moving forward with a community driven process for the development of Jorum – informed by the ukoer programme and projects like PORSCHE and ACErep – but it is still very early days and we should be careful not to raise expectations unrealistically – the service does not pass to Mimas until August who are still in the process of appointing a Jorum Technical Coordinator – a role that is obviously central to these discussions.
The primary aim of the PORSCHE project is to provide “seamless access to academic and clinical learning resources to healthcare students”… “establishing the basis for a long term national partnership between the NHS and academia by sharing of appropriately licensed content between Jorum and the NeLR”. To achieve this, PORSCHE has been exploring metadata transfer between the two repositories using OAI-PMH. Jorum is currently running on a modified DSpace (v1.5.2) and the NeLR on intraLibrary (3.1) both of which will of course expose an OAI-PMH feed, however, there would be an additional requirement for each repository to ingest each other’s feeds which is functionality that is not currently supported by either platform, though it is supported by the NDLR running on a later version of DSpace (v1.6) while PORSCHE are currently liaising with Intrallect to develop similar functionality in intraLibrary.
N.B. There may be an additional requirement for PORSCHE to transfer files as well as metadata (i.e. full content packages) between the two systems and it was suggested that OAI-ORE (Open Archives Initiative Object Reuse and Exchange) might meet this requirement – I don’t know enough about this standard to comment. (In intraLibrary I think it is possible to use a custom metadata template to expose the URI for the full content package in the OAI-PMH feed – might this be a possibility for file transfer?)
In lieu of a Jorum software upgrade to match the specification of their Irish counterpart, the NDLR have agreed to test the intraLibrary OAI-PMH feed (both from the NeLR and the Leeds Met repository) into their test-server which should be relatively straightforward (some metadata mapping notwithstanding). Moreover DSpace (v1.6) includes an API that supports search and retrieve and v1.8 due for release in October of this year includes an improved (RESTful) API which may preclude the need for further development of the Jorum API – identified as a pre-requisite for both ACErep and PORSCHE.
In summary, a proof-of concept metadata exchange will be developed between the NHS Repository and the NDLR, future work by Jorum with hopefully mean that this can this concept can then be replicated:
Just a note that the NDLR is already ingesting OAI-PMH from Jorum but I’ve spotted an issue in that the resource URL isn’t necessarily being included in the simple record, appearing only in the full record (unlinked) in a dc:identifier field – see https://dspace.ndlr.ie/jspui/simple-search?query=ukoer for examples including this one from Leeds Met https://dspace.ndlr.ie/jspui/handle/10633/29188
N.B. It looks to me like this has arisen in instances where there are multiple dc:identifier fields where the first isn’t a URL – ours often have an intraLibrary ID in the first field (see below). I don’t expect this will be a major issue to resolve?