We’ve started using the template as part of our main data management workshop for PGRs, and we’ve also had a group of Doctoral Training Centre students complete DMPs using it as well. Feedback from both groups has been very positive.

You can access both documents from our institutional repository:

• Data Management Plan for Postgraduate Researchers
• Data Management Planning Guidance for Postgraduate Researchers

Truth be told, RAIDmap has been up on SourceForge for a little while now, as we’ve been tidying it up for release and making sure everything works as advertised. Not perfectly, you understand, but as advertised: there are a few bugs still lurking in the system, and plenty of scope for improvement. We see the delivery of the tool as the beginning rather than an end to it, and on that note we would like to put out a special plea to any developers out there to have a look at the code and see if this a tool you might like to contribute to. If so, you’ll be interested in the fifth and final part of REDm-MED Deliverable 5, the RAIDmap Application Developer Guide. This explains how to get started compiling and developing RAIDmap, how the installers are generated, and gives an overview of which bits of the code do what. We think RAIDmap has the potential to be a useful data management tool, but it needs just a bit more TLC than we have time or funds to give it, so any help would be greatly appreciated.

With the delivery of the software and the Developer Guide, that pretty much brings us to the end of the REDm-MED project, but in the manner of an album bonus track, there’s one more report to reveal. (Don’t get too excited.) The Minimum Mandatory Metadata Set for RAIDmap specifies the metadata collected by the RAIDmap tool, and explains the reasons why those particular elements were chosen. For those in a hurry, the short version is that we took from PREMIS and the DataCite Metadata Schema those elements which were easiest to supply at the point of record creation (or thereabouts) rather than at the point of ingest into a repository. We hope the report and its approach may be of use to institutions who are also considering what metadata to collect about research datasets.

As Alex said, Deliverable 3, A Research Data Management Plan for Engineering Research, is a generic departmental data management plan based on Deliverable 2.

And then we have the first four parts (yes, really) of Deliverable 5. Parts 1, 2 & 3 are all tools which are associated with, and help project-level implementation of, the ME-RDMP (Deliverable 2) and, incidentally, which should be considered adjuncts also to Deliverable 3. These are:

• The University of Bath Department of Mechanical Engineering DMP Online Template. This has already been uploaded into DMP Online Tool v3.
• Naming Documents for Better Organization, which encourages the creators of documents not only to give them sensible and logically derived context-bearing file names, but also hopes to achieve some rehabilitation of the Document Title as a useful object.
• Project Data Record Manifest Template for Research Projects, which provides the basis for the key project-level document which records the important contextualizing documents created for and by a research activity and where they may be found.

Deliverable 5, part 4 is the RAIDmap Application User Guide, which should whet your appetite for Deliverable 6, the RAIDmap application itself. Sorry you’ll have to be patient just a little longer for this, as you will for the the last part of Deliverable 5.

Happy Reading, folks!

While I am on the subject, I should also point out the remaining deliverables will also arrive in a somewhat eccentric order. You can expect seven deliverables in total, of which the last to arrive will be Deliverable 6 and Deliverable 5 Part 5 (yes, you read that right). But that’s enough spoilers for one post…

The plan has two main sections. The first explains how to use data management plans at the project level: where they should be kept, how ‘public’ they should be, what is expected in terms of review and revision, and so on. The second provides a template to assist principle investigators and researchers in writing a project data management plan. Both sections include recommendations of tools for planning and performing data management, and give pointers to more detailed advice.

The recommendations were probably the hardest part of the plan to write. Despite reviewing the landscape, we did not find suitable tools for all the tasks that required them. Part of the problem was that some infrastructure and guidance needs to be provided at the institutional level, rather than the departmental or national level, so one consequence of writing this plan was a set of recommendations for our sister project, Research360.

• the rationale for the requirement,
• the rôle (principal investigator, researcher, data manager) supported by the requirement,
• the level (institutional, departmental, project) at which the requirement should be met,
• information or resources that could help meet the requirement, and
• validation of the requirement.

As the document explains, the requirements were derived from work conducted by the ERIM Project and the IDMB Project, in consultation with a panel of researchers and academics from the department. The validation for the requirements came from several sources, most notably the checklist underlying the DCC’s DMP Online tool, and Crowston and Qin’s Capability Maturity Model for Scientific Data Management. The latter came to our attention during a review of data management lifecycle models that we conducted.