Categories: Home | General | Requirements Report | Design
|The I-WIRE Project - A Repository Enhancement Project|
This is the final in a series of blog entries that has summarised the findings of the I-WIRE project's User Needs Analysis phase, ending with this summary of the requirements captured during the Future State modelling group session, and during interviews with Research Administrators.
1 Guiding Principles
Considering the I-WIRE project’s objectives, the following guiding principles were applied when analysing the User Needs and assessing whether or not they should be accepted into the project’s scope and taken forward into the design phase.
The deposit process should be author centric. Authors are the best equipped people to provide all the metadata associated with their publications. The further removed the depositor is from the author themself, the bigger the overhead associated with populating the required metadata.
The deposit process must be as simple as possible, require minimal entry from the depositor and auto-complete as much of the data as possible on behalf of the depositor. Auto-completion will not only save time for the depositor, but also help improve the quality of the data captured.
Full text deposit is desirable, however, should not stand in the way of metadata deposit as a minimum in order for the repository to support the REF in parallel to its role as an Open Access repository.
Deposits should be made as early in the publication lifecycle as is reasonable, making the item available to as wide an audience as possible. This can be a lot earlier than the item appearing in one of the subject repositories or commercial databases, however, depends on the publisher’s copyright policy and can dictate which version of the item is deposited (pre-print, post-print or publisher’s final version).
Data should be re-usable for as many different purposes – by as many different processes and systems – as possible. Therefore, the data should be made available in a standard format that can be processed by its consumers.
With the above points in mind, the project team worked through each requirement (grouped into themes), and produced User Stories for the requirements that can be delivered in the project's timescales. The User Stories express the requirements in a neutral manner, written from the end users point of view to ensure the requirements are linked to genuine value, and written with Acceptance Criteria that can be used when it comes to testing the solution and piloting it with the partner Schools.
2 Summary of Requirements
This section summarises the User Needs identified during the interviews and sessions, along with the outcome of the analysis that has been carried out and an indication of which User Needs are being taken forward to the Design phase.
This has been an objective from the inception of the I-WIRE project and is essential for its successful outcome. Integration means surfacing the deposit process, and the browse / search functions, in the MWE portal, enabling data and process integration. Including the more specialised admin and review EPrints functions in the portal is not feasible in the project’s timescales and is seen as lower value as it does not contribute to the primary objective of an enhanced deposit process.
All Research Administrators and authors have stated that the deposit process must be as simple as possible and require minimal effort from the depositor, as authors do not have the time to spend on this activity. If possible, metadata should be automatically retrieved from the dOI entered by the depositor when available.
Being able to upload publication data from other repositories and databases is seen as valuable in saving the authors from having to enter it themselves. Importing data into ORCA - Cardiff's repository - is the responsibility of a separate Retrospective project, and the I-WIRE project is focusing on enhancing the deposit process for authors to be able to deposit as early as permissible and not have to wait for publication data to appear on various databases. However, the project will explore the opportunities for an enhanced deposit process that this type of system integration may provide.
This function would need considerable changes to EPrints and cannot be achieved in the I-WIRE project timescales. However, Research Administrators will be able to identify new deposits for their School using the ORCA data feed that will be implemented by the project.
Research Administrators would like to be able to export publication data into their own databases (MS Access and Excel have been mentioned) for analysis and to use in various other processes such as reports, performance management and funding applications. Due to the supplementary data and rules that will vary by School, the data should be useable in a variety of different processes and systems.
Every School interviewed raised automatic web page updates as a priority need or agreed that it would provide value. The Schools have varying different processes and systems for this currently, ranging from manually intensive to maintaining their own databases. The structure of the Schools research organisations varies too, with data having to be re-used across a variety of pages that serve different Research Groups, Research Centres and Themes.
While discussing this user need, it emerged that authors and Schools will want to be selective over which publications are included in their web pages, as complete publication lists can be too exhaustive. This would require giving users the facility to manage deposits that are already live.
Authors have listed many different processes and systems that require re-use of their publication data, including CVs, web pages, performance management documents and funding applications. The design phase will explore providing an author’s top or most recent publications in the default Portal view, supported by an export facility that could allow check-box selection of individual items.
The I-WIRE project will explore ways that the Cardiff University unique person identifier can be added to ORCA during the deposit process in order to facilitate integration between ORCA and other MWE systems that want to access publication lists. Use of this identifier will be transparent to users as they will not generally be aware of it, using instead items such as email address and name for browsing and searching ORCA
ORCA has very limited metadata for funding and is likely to be a component in the overall solution for management of funding data (and other research data), with links between each component system. Note that ORCA’s role in CRIS (Current Research Information Systems) is being looked at outside the I-WIRE project.
There are issues with including citation data in repositories that I-WIRE will not have time to resolve. The DSpace repository team attempted to include citation counts but encountered licensing constraints. However, the I-WIRE project will explore the various EPrints plugins that have been produced for this purpose. Note that citation data and other metrics are available from established databases (there are more than one) and are under consideration for REF support but usage of these has not been clarified yet.
One Research Administrator would be happy to review the author’s deposits for completion, accuracy and copyright, before promoting them to the live archive, as long as there is confidence that authors are actually depositing their publications on a regular basis. The project will explore this. However, the ‘reviewer’ role is currently carried out within the Libraries Cataloguing team, and will remain in that team for the majority of Schools.
There was also a view that some Schools would want to vet all deposits before they became available in ORCA, and indeed be responsible for the deposit process on behalf of authors, however, this contradicts one of the guiding principles of an enhanced author deposit process.
Many Schools are already using their Staff Appraisal processes to capture and update publication data. The I-WIRE project will look at providing a standard data feed that can be used in this process.
ARCCA would like the deposit process to ask a mandatory question that identifies outputs of research that have made use of ARCCA facilities. This would save the ARCCA team from having to identify these themselves directly with the Schools when producing the annual report. While useful to ARCCA, this is not crucial to the deposit workflow and in fact could be seen as contradictory to the simplified deposit, particularly if the user is presented with a question about ARCCA when they are not familiar with it. However, this will be explored during design.
The School of Medicine have invested in the Symplectic publication management system and are currently integrating it with their School web pages. Symplectic harvests publication data from Web of Science and presents it to authors for validation, minimising the amount of effort required for deposit. However, Symplectic is not a repository of full texts, for which a connector is being produced by the Symplectic team to integrate Symplectic with EPrints. The I-WIRE project will explore the integration between Symplectic and EPrints with a view to identifying opportunities for enhanced deposit, bearing in mind that early deposit into the repository is one of the guiding principles.
It is noted also that the Business School is in the process of implementing Digital Measures which manually captures and stores publication data, alongside other School data such as performance metrics.
The varying copyright policies of different publishers, and the terminology around different versions of articles, are seen as confusing and blockers to the deposit of full text and subsequently use of the repository. Sherpa’s RoMEO database goes some way to helping identify publisher’s copyright policies, and will be looked at in the design phase, but the wider issue of understanding and negotiating copyright will be looked at outside the I-WIRE project.
Various types of links have been requested, including between web page publication lists and the full text articles, and from articles in the repository to the School’s web page. The standard data feed will provide enough data for the consuming system to be able to construct links to the article in the repository (and to highlight Cardiff authors). However, linking from the repository to elsewhere would require a complex configuration feature if it were to satisfy the many different and conflicting requirements that Schools would have, and would therefore not be achievable in the I-WIRE project’s timescales.
Some publishers allow embargos. There would be value in system storing these publications and automatically making them available at the embargo expiry date. The project will explore the current embargo function but believe it to be limited and therefore more effective for depositors to submit metadata ahead of the full text in these scenarios.
Data that is related to the repository but is not within its scope includes funding bodies and sources, and the impacts of research needed by the REF. Note that ORCA will be just one component in the overall solution required to support the various calls for this type of data, but the I-WIRE project is not looking at solutions for identifying, modelling or storing this data.
3 User Stories
The User Needs that are being taken forward to the Design phase have been written as a set of User Stories, an example of which is shown below for illustrative purposes.
The full set of User Stories is available from the I-WIRE project team on request.
There is no guarantee that a particular User Story or Acceptance Criteria within the story will be fully delivered by the project, as the Design work package itself will have to conduct a deeper level of analysis in order to design a solution that is feasible to deliver within the project’s timescales. Each User Story has been prioritised with this in mind, to allow the project to continue with flexibility, and also to adapt to changes that are beyond the control of the project.
© Tracey Andrews. Powered by Apache Roller 4.0.1-dev.
|« May 2013|