Archive

Posts Tagged ‘Archivalware’

ACErep update for the PORSCHE Executive Board meeting on Wednesday 10th August 2011

August 12, 2011 Leave a comment

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 ‘sword-app-tech@lists.sourceforge.net’ and ‘eprints-tech@ecs.soton.ac.uk’.

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

Project update

March 4, 2011 1 comment

One of the most challenging aspects of ACErep continues to be working across multiple institutions and organisations and recently progress has stalled somewhat as we liaise with our partners and wait for development work essential to the overall infrastructure.

In November last year we were able to build a prototype using Xpert which harvests OAI-PMH from our repository at Leeds Met and which we are then able to selectively search by keyword. We had initially hoped to work with Jorum but at that time there was no Open API, nor were there any plans to harvest by OAI-PMH, so we liaised instead with Pat Lockley of Xpert who was able to help with both requirements.

A lot has happened since November however, both at Xpert and Jorum. Pat is moving on to another (OER related) post which raises questions for us around the sustainability of that service now it has lost its key developer and I have been working with the PORSCHE project at Newcastle University which aims to provide seamless access to academic and clinical learning resources for healthcare students primarily from the respective collections in Jorum and the NHS National eLearning Repository (NeLR). As such, PORSCHE has also requested that Jorum harvest by OAI-PMH and provide an open API; the project team includes the Jorum service manager Hiten Vaghmaria as well as Kate Lomax of the NeLR (which, like Leeds Met’s repository, is also based on intraLibrary.) Jorum have now released a first iteration of an open API and hopefully both projects, and the UKOER community at large, can now work with the national OER service to develop that API to meet our requirements – PORSCHE’s Suzanne Hardy has set up a the Jorum API discussion space (wiki) at http://jorumapi.pbworks.com/w/page/35601929/Jorum-API-discussion-space. I am, in fact, yet to contribute to the discussion myself partly due to a lack of knowledge around API development – I’m far from clear, for example, how we may most effectively use an API to return just a subset of the resources in Jorum (i.e. ALPS/medical resources). In the Xpert prototype we just filtered on keyword but this feels a little unsatisfactory and Pat suggested a custom URL search would be better…

The other pieces of the jigsaw are repository-shaped and variously lacking the dove-tailing standards required to make the model workable. At Leeds University the learning and teaching repository is ExLibris’ DigiTool while York St John have a system called ArchivalWare, both systems are OAI-PMH compliant but do not support SWORD – development work is underway to rectify this at York St John while Jodie has set up an out of the box test install of e-prints to investigate OER object management.

Mike has also made some progress with EasyDeposit which is now working on a Leeds Met server and, after a few teething problems, will now successfully deposit a METS package to Jorum (DSpace), we will still need to test with EPrints (METS should be OK I think) and ArchivalWare when SWORD is integrated with that platform…probably METS again. There is an issue with intraLibrary, however, in that it only accepts IMSCP by SWORD, not METS, so we will also need to write an IMS content packager for EasyDeposit.

We are very grateful to Tamsin Treasure-Jones of ALPs for her continued support with this challenging project and I’m hopeful that all of these pieces can be put together over the Spring and Summer as we move towards a local, regional and national infrastructure for sharing medical teaching, learning and assessment material with an approach that will have the benefit of digital assets being preserved in one location (an institutional repository) while providing several points of access as well as allowing the ALPS branded web-site and the institutional repositories to “piggyback” on Jorum’s Google pagerank and improving discoverability.

A potential infrastructure (2)

June 24, 2010 1 comment

Thanks to Gareth Waller from Jorum who has been in touch to say that there are currently no public APIs available for JorumOpen and no immediate plans to release one.  The only public interfaces at present are:

  • An OAI-PMH target for harvesting metadata records i.e. pulling metadata from JO
  • A SWORD target for depositing METs packages ie pushing content into JO

There is an SRU add on for DSpace but, as Gareth has indicated in his comment on the previous post, it is not enabled due to a bug; it may be enabled in the future if the bug can be fixed.

Rather than SRU, a better way to search JorumOpen will be the new search tool to be launched at the end of the month that will provide a web application to search records from both JorumOpen (DSpace) and JorumUK (intraLibrary) and also provide features such as RSS feeds on search results (I presume this is the tool based on OAI-PMH?)

Wherever possible, Jorum are keen to include the actual resource rather than just metadata record/link to resource in JorumOpen – to allow other users to search on the content of that resource e.g. text in PDF  – which is the approach we have taken with the Unicycle project via bulk upload of IMS.  Whether it will always be appropriate to duplicate resources in this way, however, is still something of a moot point, especially in the context of medical resources where an audit trail/version control might be more of a priority than for Unicycle as flagged up by the MEDEV OOER project.

With this in mind, Gareth has suggested that a better way to integrate with Jorum would be to deposit directly into JorumOpen via SWORD; we could then then use the new search tool for our bespoke portal:

Gareth's suggestion for a modified infrastructure

A potential infrastructure?

June 22, 2010 4 comments

I’ve been giving some thought to a potential infrastructure for ACErep and got to thinking about what APIs might be (or might become) available for JorumOpen; depending on the technology available, it occurred to me that one possible approach might be to bulk upload resources from our three institutional repositories – or just harvest the metadata – into JorumOpen and then search those records via an API (at a pinch a custom RSS feed might do) from a bespoke ALPS CETL portal.  This would mean that resources would be discoverable from a variety of different locations – Google, JorumOpen, our 3 individual institutional repositories, the ALPS CETL portal…

First project meeting

May 5, 2010 Leave a comment

With one thing and another, it has taken a little while for this project to get off the ground but the planets have finally aligned and yesterday we sat down for the inaugural meeting of the ALPS CETL Repository Project – or ACErep for short.

“We” are a cross institutional team from the University of Leeds, York St John University and Leeds Met and the current project has developed from the Assessment and Learning in Practice Settings (ALPS) CETL project, a consortium of five institutions working across 16 professions. ALPS also works closely with placement providers particularly NHS Yorkshire & Humber.

Leeds, YSJ and Leeds Met all have (different) repository systems to manage “Learning Objects”. These are respectively ExLibris’ DigiTool, Archivalware from PTFS Europe and Intrallect’s intraLibrary (NHS Yorkshire & Humber is also developing a repository using intraLibrary).

In outline, the proposal is that stakeholders should be able to:

  • Search across the multiple platforms for resources
  • Download resources from any of the platforms into the working arena of their choice
  • Adapt existing resources to suit local use
  • Deposit either an original or an adapted resource/learning object into one or more of the repositories maintained by the CETL partners

It is very early days and we all have plenty of work to do after yesterday’s meeting but we anticipate that we will need to develop some sort of portal or interface to cross-search the repositories probably using common standards like SRU/SRW; OAI-PMH and RSS; we will also look at (re)deposit into a chosen repository using SWORD.

In the first instance, the scope of the project needs to be clearly defined and we should be wary of being overly ambitious; the project is running until December this year so some of our workpackages are a bit tight, not least recruiting stakeholders before academic staff disappear over the Summer!  It is also important that we begin to develop detailed use-cases and user journeys as soon as possible though these will necessarily evolve in parallel with technical development and will also be informed by stakeholder engagement throughout the project (I hope!)

Watch this space!