ESRC scenarios

ESRC: open access deposit of research outputs

How to populate a local institutional repository and a funder repository through a single deposit: in this case, White Rose Research Online (WRRO) and ESRC's Awards and Outputs database?

Aims - Research Workflow - Possible Scenarios - Progress to date

Aims

Researcher workflow

Ideally, the depositing researcher should have ready access to relevant grant information: perhaps from a list of relevant grants linked to their authentication details or a list of grants associated with their school or faculty.

It should be straightforward to associate individual research outputs with a specific grant.

The researcher may wish to deposit the details of the work - and possibly the work itself - into a number of different places. For example, a subject repository external to their organisation (PubMed Central, arXiv); a repository associated with their research funder (PubMed Central; ESRC). Ideally, the researcher should be able to choose from a list of external deposit locations supported by the repository.

Possible Scenarios

Comments? We're interested. Please email eprints@whiterose.ac.uk

Scenario 1:
Local (institutional) deposit into WRRO; "post" into ESRC's awards and outputs repository using SWORD protocol

An author deposits a journal article and descriptive metadata into WRRO. The metadata includes the ESRC Grant Name and Grant Number. The author indicates on a drop down menu that the work should be deposited with ESRC's Awards and Outputs Repository. When the item is made live in WRRO the data is also pushed out to ESRC using the SWORD protocol (format to be defined by ESRC's SWORD service document but could be a METS file plus full text(s) in a zip file). The returned identifier is added to the item's record in WRRO.

Comment: This scenario is readily achievable. ESRC will be supporting SWORD. There is further work to do (for any adopted scenario) in clarifying the requirements for a "trusted" relationship between two repositories. See Investigating ESRC deposit for further comment.

Scenario 2:
Local (institutional) deposit; data harvested by ESRC's awards and outputs repository

An author deposits a journal article and descriptive metadata into WRRO. The metadata includes the ESRC Grant Name and Grant Number. Data is exposed so that it is harvestable using OAI-PMH.

ESRC regularly harvests from WRRO and identifies new additions from their date stamp. The ESRC grant name and number metadata indicates that this is an ESRC relevant work. (Perhaps there is a different way to indicate locally which records should be harvested - particularly if ESRC will be harvesting relevant outputs which are non-ESRC funded).

Comment: OAI-PMH services are supported by ESRC, but for the immediate scope of this project it would have required additional funding to be identified in order to explore this scenario more fully. In addition, repositories may wish to share compound digital objects; OAI-ORE may be a more suitable standard to investigate in this context.

Scenario 3:
Remote deposit (into ESRC's repository); "post" into WRRO using SWORD protocol

An author deposits their work into ESRC's Awards and Outputs Repository. The metadata indicates that the author has an affiliation with Leeds, Sheffield or York Universities. This invokes a SWORD alert to push the metadata and files to WRRO (format defined by White Rose's SWORD service document). The work is put into WRRO (probably via the editorial buffer rather than directly live?). ESRC receives a receipt from WRRO.

Comment:Not feasible at this time. At the time of investigation, there was very little SWORD support available for .net based systems - and this would be required to implement this scenario. (See Investigating ESRC deposit for further comment.) Funding would therefore need to be identified to allow the development work to progress this scenario.

Scenario 4:
Remote deposit (into ESRC's repository); harvest / bulk import by WRRO

An author deposits a journal article and descriptive metadata into ESRC's Awards and Outputs repository. The metadata indicates that the author has an affiliation with Leeds, Sheffield or York Universities. Data is exposed so that it is harvestable using OAI-PMH.

WRRO regularly harvests from ESRC's repository using OAI-PMH - or imports a set of records using another protocol - identifying new additions from their date stamp. The WRRO affiliation metadata indicates that this is a WRRO relevant work.

Comment: ESRC has an active OAI-PMH service. If the researcher informed Leeds/Sheffield/York of their grant number, the University could harvest the records using OAI-PMH. This solution in technically feasible - though OAI-PMH harvesting is not currently implemented in WRRO.

About SWORD

SWORD (Simple Web-service Offering Repository Deposit) is a profile of the Atom Publishing Protocol. SWORD offers a standard mechanism for deposit into repositories and other systems. Investigation of its utility in assisting repository population is being promoted by the JISC.

Copies of the work

Should both repositories hold a copy of the work or should each repository hold metadata about the work but only one hold the copy with the other providing a link to it?

Scenario 5:
Desktop Deposit

Another possible workflow would see research deposited from the author's desktop. For example, there are some interesting developments coming from Microsoft which could allow repository deposit from within Microsoft Word and other common programmes. This may be a longer term solution, potentially supplying content to multiple destinations from within the creation software. (See Microsoft Research Unveils Free Software Tools to Help Scholars and Researchers Share Knowledge.) To work, the deposit destinations would have to have defined what metadata is required from the supplier and what type of authenitcation and verification mechanisms may be needed in order for the remote system to accept the deposit. As with the other scenarios, there is the question of the quality of metadata (whether generated automatically or created specifically by the depositor) and the extent to which processes can be automated. Would desktop deposit still require mediation? If so, would the mediation lie at the local level (the depositor's institution) or be performed remotely by those services accepting deposit?

Comment: Investigating this scenario was out of scope for the project.