Wellcome DMP Compliance Rubric
A check-list / marking rubric to be used when evaluating Data Management Plans for compliance with Wellcome data retention and sharing requirements
BBSRC—See BBSRC Data Sharing Policy
Purpose of rubric
Providing feedback to researchers
Mary Donaldson [email protected]
Service Coordinator, Research Data Management, University of Glasgow.
This is version 2.0 and has been posted to enable discussion and comments within the research data community.
A PDF can be downloaded from the Zenodo repository - http://doi.org/10.5281/zenodo.247085
BBSRC expects data sharing to take place in the following research areas:
Data arising from high volume experimentation.
Low throughput data arising from long time series or cumulative approaches.
Data sharing is also expected in other areas where there is a strong scientific case and where it is cost effective.
Models generated using systems approaches.
The general expectation for research data is that it will be available at the end research project, and that the DMPs will be used to describe how it will be made
available. If data are not to be shared, there should be a clear case why not, and if a full dataset is not available, why a partial dataset, or restricted dataset might not
be available. (From Michael Ball, BBSRC)
Maximum plan length is one A4 page.
BBSRC Data Sharing Policy v1.2 (March 2016)
BBSRC Data Sharing FAQ v1.4 (March 2016)
BBSRC Data Sharing in the Biosciences Leaflet
BBSRC Data Management Plan Guidance (http://www.bbsrc.ac.uk/funding/apply/application-guidance/data-management/)
Criteria and performance levels
|Detailed||Addressed but incomplete / unsatisfactory||Not addressed|
|What type of data will be collected?||Data types clearly defined. Eg|
experimental measurements, models, recordings, video, images, machine logs etc.
|Data types mentioned for some of project / dataset but not all.||No details included.|
|What scale / volume of data will be collected||Clear estimate of dataset size given for|
each data type.
|Dataset size given but not broken down by data type. Size not give for all data|
types. Dataset size is clearly unrealistic (it will not always be possible to judge this).
|No indication of data volume is given.|
|How will data be manged?||Data management methodology is clearly stated or referenced. eg file|
naming conventions, file architecture etc..
|Methodology is described, but lacks detail or only covers a subset of the data to be collected.||No methodology is mentioned.|
|Which community standards for data collection will be used?||Clear references are made to collection standards eg XXXXX||Some mention of collection standards but not included for all data to be collected.||No community standards are mentioned and no project-specific approach is described.|
|What documentation/metadata will accompany the data?||Clear outline of documentation and metadata strategy with references to existing good practice in the community or detailed project-specific approach where community standards don't exist.||Some mention of documentation or metadata without detail about community standards or a project-specific approach.||No mention of documentation or metadata.|
|How does the data relate to other data available in public repositories?||Clear description of relationship to existing datasets.||Mention of existing datasets without details.||No mention of existing datasets.|
|What are the intended future/foreseeable uses of the dataset(s)?||Clear description of possible future uses of dataset(s) by both researcher an others. Clear indication that dataset(s) would not be suitable for future use with reasons given.||Some mention of future use without details. Statement that data won't be suitable for future use with no reason given. Future use only considered for subset of data generated.||No mention of possible future uses.|
|How will dataset(s) be shared?||Clear consideration of where, how and to whom the data will be made available. Strategy is in line with good practice in the area of research (if able to judge!). Assessment of specific access mechanisms if needed.||Some mention made of how the data will be shared but details missing.||No mention of how dataset will be shared.|
|How long will dataset be retained?||Clear data retention statement (funder requires 10 years, post project)||Clear data retention statement but not in accordance with funder requirement||No mention of period for data retention.|
|Are there any restrictions to data sharing?||Clear assessment of any restrictions which might apply to data sharing, with reasons, eg potental patent application, ethical reasons, commercial co-funding. Clear statement that there would be no restrictions to sharing any of the data.||Mentions a need to restrict access to data/subset of data but without giving reasons why.||No mention of data sharing restrictions.|
|When will the dataset(s) be released publicly?||A clear time-scale is indicated e.g. no later than the publication of the main findings of the research (funder recommendation), at the end of the award, within 3 years of the generation of the dataset (recommendation for fields where there is no community best practice). Where a delay to release is indicated, reasons are given.||Time-scale is mentioned but not clear or not clear for all datasets.|
Time-scale is clearly not in accordance with funder expectations.
|Time-scale for release of data is not mentioned.|
|What formats will the final dataset(s) be in?||Clearly describes the file formats that will be used for storing data and explains the rationale or complicating factors.||Only partially describes data formats that will be used for storing data and/or the rationale or complicating factors.||Does not describe data formats that will be used for storing data and does not provide a rationale or discuss complicating factors.|
Updated less than a minute ago