Functional Checklist for Digital Repositories in the Research Quality Framework (RQF)

Abstract

From the institutional perspective the planned introduction of a Research Quality Framework will have wide ranging ramifications for research, research administration, and research information infrastructure. This document concentrates on the likely issues for the third area, research information infrastructure. Other issues, such as the role of the research office, the formation of research groupings, institutional research strategies, etc, are out of scope for this paper. All we can currently say about the RQF must be carefully qualified because the details have not yet been finalised. This may work in our favour; it may still be possible to effect the nature of the final RQF implementation. At this point it would be sanguine to acknowledge that the we don't know how centralised the RQF will be. Will the RQF be running its own mega repository of "submitted" items? Or will "submitted" mean submitted to the institution's repository and the reference submitted to RQF? The latter one would think, but then will part of the RQF process involve DEST harvesting directly from the repository or will the university's research office mediate? We take as a given the importance of an institutional repository in the process of information management of the RQF process. The introduction of the RQF is a strategic opportunity for institutional repository managers and developers. It is a chance to make the IR even more relevant to the critical mission of the university. That said, it is still possible that the initial RQF will not involve digital repositories at all and will run on hard copy submissions. Assuming that most universities choose to manage their assessable research information through institutional repositories, the repository software and the accompanying repository services will be called upon to support the institution's response to the RQF. The required functionality for such support is discussed herein. This paper only tries to propose an indicative checklist of the functional requirements of a repository wanting to support RQF. Further discussion will elaborate upon this list, which is offered at this stage to stimulate discussion. Show more