Archive

Posts Tagged ‘NDLR’

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

Advertisements

OER infrastructure – discussions with Mimas and NDLR

June 21, 2011 2 comments

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:

OAI-PMH transfer between DSpace and intraLibrary

OAI-PMH transfer between DSpace and intraLibrary

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?

Unlinked Jorum handle in full metadata record

Unlinked Jorum handle in full metadata record
https://acerep.wordpress.com/tag/ndlr/
acerep.wordpress.com
crawl=CC-MAIN-2018-22
44539
application/http; msgtype=response
sha1:ML4VAATWYBRT7DTSEKRLIFGPUT5NDBYJ
<urn:uuid:63d9dfb6-7a61-419d-82cc-ae2cd4b042a6>
2018-05-23T10:52:22Z
192.0.78.13
application/xhtml+xml
sha1:PUPQVVVNV74LRYOZKSJT6RJ6NYHNP3HS
<urn:uuid:4d8cdf1e-e758-4b0f-88ae-f9b3a3329207>
https://acerep.wordpress.com/tag/ndlr/
length
response
<urn:uuid:11041611-9e71-4ca9-95b2-b0452c305797>
robots: classic
hostname: ip-10-180-188-198.ec2.internal
software: Nutch 1.6 (CC)
isPartOf: CC-MAIN-2018-22
operator: Common Crawl Admin
description: Wide crawl of the web for May 2018
publisher: Common Crawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf