RoaDMaP project outputs

University RDM policy

University of Leeds Research Data Management Policy (July 2012)

University of Leeds Research Data Management Policy Background – link to drafts and feedback (archived as word.docx)

Research data website – information to support the RDM Policy and good RDM practice

Requirements analysis

RDM Case Studies

  1. Timescapes Case Study Report (Sociology).Timescapes blog posts by Professor Bren Neale – Timescapes: Archiving and sharing Qualitative Longitudinal data ; Timescapes: Archiving and sharing Qualitative Longitudinal data – Part 2 (response to Simon Hodson)
  2. Music Case Study Report (music of Trevor Jones)
  3. Engineering Case Study Report (SpineFx)

Data management planning

Software systems and metadata

Research data repository functional requirements (working draft)

Virtualised storage

Training / people

    • Pilot Training Session with Engineering Researcherspresentation, handbook and feedback (blogpost)
    • Pilot training with Social Scientists – presentation, handbook and feedback
    • Training with Research Support Staff – presentations and feedback
    • Training with Pre-award Support Staff – presentations and feedback
    • Perspectives on Research Data Management- 24th May 2012 – presentations and blog posts
    • Training Working Group Aims and Membership
    • List of the main training and awareness activities undertaken by RoaDMaP

Project documentation

  • Project bid, Project Plan, Work Packages, Participant Consent Form, Benefits Report, Final Report

Interim Funding (Aug 2013- July 2014)

  • Paper to senior University management to secure post-project funding for further service development
Advertisements

Research data repository requirements

The RoaDMaP repository working group shares and invites comment on our research repository requirements list

Draft repository functional requirements (Licensed under a Creative Commons Attribution 4.0 International License).

The RoaDMaP repository working group (members from RoaDMaP, central and faculty IT and the library) agreed it would be beneficial to have a list of test criteria we could apply to any pilot repository system and which could be put to the University’s Research Data Working and Steering Groups as part of a formal data repository implementation process for University of Leeds.

We reviewed the very useful work of the JISC funded KAPTUR project led by the Visual Arts Data Service. KAPTUR’s review of platform strengths and weaknesses and the list of test criteria were an excellent starting point for RoaDMaP. As we worked through the individual criteria, we found that, not having the full background and context of how each requirement was created, it would be difficult to simply re-use the list. Rather, it emphasised the value of thinking through a set of requirements based on our own experience, which would be understood by the group and could be justified to third parties.

The group scoped the extent of the ‘repository’ we were considering: we agreed we would not address requirements for ‘live’ data or specific storage requirements but would concentrate on the core functionality of a data repository providing access to research data in a fixed form.

We identified data repository stakeholders, brainstormed repository functionality from each stakeholder’s perspective then re-worded these as requirements and grouped under relevant headings.  Each requirement was then classified as Must, Could, Should, Won’t or for Information (MoSCoW); however, the MoSCoW categorisation is being reviewed and is likely to change. We also found is useful to undertake the MoSCoW analysis for the Timescapes Data Archive which is one of our RoaDMaP case studies.

We would welcome any comments or feedback – and are interested in other functional requirements lists. Perhaps these could be consolidated as an overall output from the Jisc Programme?