Output – IRep for NTU – Final Report: Interoperabilty

Title: IRep for NTU – Final Report

Number of pages or page numbers: 15-17, 21

Section: Interoperability and integration with other institutional systems and external systems; Implications and Recommendations

Date Released: 18/07/2008

URI for Output: http://www.ntu.ac.uk/irep/63815.doc

Summary of contents:

Discussion of how the repository integrates with particular existing systems and functions.
‘Integration with eSearch (Metalib): eSearch is the [established NTU] library federated search system
… users [can] perform ‘All Fields’ and ‘Title’ searches directly from the eSearch interface and also allowed thumbnails to be returned for display within this interface where available. … one minor drawback with returning IRep records through eSearch such as if multiple object manifestations are attached to a single record, only a link to the primary object is returned.’

‘Integration with SFX: Our approach with the “Research and Scholarly” collection was to ingest into the repository the totality of the 9000 over records from the Research Publications Database regardless whether or not we had the full text items (or equivalent) to ingest as well.’ Decision based on lack of access to local full text in short term and probable publishers’ restrictions on some pre-prints in longer term. Implemented using ‘using the SFX OpenURL link server from Ex Libris already available at NTU to allow us providing context-sensitive linking to full-text article’ to present ‘ “the most appropriate” location of an object’. This is however DOI dependent and as a result its use is currently limited. [Note full text statistics https://rrtsynthesis.wordpress.com/2008/09/30/output-ntu-irep-for-ntu-final-report-technical-implementation/ ]

‘Integration with NTU Researcher web profiles via X-Server: … IRep [may] completely replace the [Research Publications Database]. One major feature of the RPD is to publish a publications list for each researcher on their NTU profile web pages. This is supporting the RAE requirements.’ This functionality has been demonstrated and tested but is not being implemented before the current RAE review period ends.’

The learning materials system was being replaced during the project so interoperabilty testing was not possible.

Interoperability with OAI-PMH

  • Google and sitemaps

‘However by the time we went live with the repository in early May 2008, Google had released a statement saying that they were retiring support for OAI-PMH in Sitemaps [13]. This was quite a drawback for the project as one of the main pieces of feedback we received from the academics when presenting them about IRep was the clear benefit offered by the repository of having their publications found by search engines.’
Ex Libris are developing a work around (database cloned as static web pages [ functional but !!]).

  • Registry services

Registered with OpenDOAR.

‘We found it was a great advantage to have librarian cataloguers ensuring compliance and monitoring the metadata quality as they were already familiar manipulating such data within other systems. However the cataloguers felt it was a step backward to use Dublin Core as the metadata schema due to its lack of richness in comparison to other schemas they were used to manipulate. However the project team purposely selected the Dublin Core schema in part due to its simplicity for the ease of manipulation by people having no expertise in this kind of data. … Yet the use of the Dublin Core schema brought another issue in terms of interoperability with SFX due to the lack of qualification and the ambiguity in the fields.’ (p21)


No specific details about theses, data, or funding councils mentioned  though they are within scope – so general findings are of some relevance).

There is no mention of any other specific external OAI-PMH based services – harvesters??

Selection of metadata schema based on interoperability/ common ground rather than required (local) functionality?

%d bloggers like this: