RDA DMP Common Standard for Machine-actionable Data Management Plans
 DMP Common Standards WG |
|
Group co-chairs: Tomasz Miksa, Paul Walk, Peter Neish |
|
Recommendation Title: RDA DMP Common Standard for Machine-actionable Data Management Plans |
|
Authors: Tomasz Miksa, Paul Walk, Peter Neish |
|
Impact: Allows representing Data Management Plans in a machine-actionable way, to enable exchange of information between systems acting on behalf of stakeholders involved in the research life cycle, such as, researchers, funders, repository managers, ICT operators, data stewards, etc. It also helps in automating typical data management tasks, thus contributes to a reduction of workload imposed on the stakeholders. |
|
Recommendation package DOI: 10.15497/rda00039 |
|
Citation: Miksa, T., Walk, P., & Neish, P. (2019). RDA DMP Common Standard for Machine-actionable Data Management Plans. https://doi.org/10.15497/rda00039 |
Abstract
Data Management Plans are free-form text documents describing the data that is used and produced during the course of research activities. They specify where the data will be archived, which licenses and constraints apply, and to whom credit should be given, etc. The workload and bureaucracy often associated with traditional DMPs can be reduced when they become machine-actionable.
The DMP Common Standards WG has developed an application profile that allows to express information from traditional DMPs in a machine-actionable way. It allows for automatic exchange, integration, and validation of information provided in DMPs.
Thus, it facilitates exchange of information between systems acting on behalf of stakeholders involved in the research life cycle, such as, researchers, funders, repository managers, ICT providers, librarians, etc.
This document summarises the application profile. The full specification can be found: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard
Keywords: DMPs, maDMPs, machine-actionable, application profile
License: CC-0
| Attachment | Size |
|---|---|
 Card RDA_DMPCommon_Standard_for_Machine-actionable_Data_Management_Plans_June2020.pdf | 1013.8 KB |
- Log in to post comments
- 22021 reads
Author: Jonathan Petters
Date: 20 Dec, 2019
I’m glad to see this DMP Common Standard model come out. While I haven’t been involved in this working group effort’s directly, it’s great to have this important foundation towards machine-actionable data management plans available for use!
In general I find this standard very reasonable as a whole after a quick review. I have two comments:
1. Regarding the ‘Metadata’ structure: there are many research disciplines for which no metadata standard exists, and will not for the foreseeable future. I recommend this structure (or perhaps the guidance around it) be modified to allow for the incorporation of non-standard metadata as a descriptor of a Dataset (e.g. metadata in a README file or in a spreadsheet).
I agree we want to encourage the use and development of metadata standards whenever we can, but I would also like to encourage the creation of metadata where standards do not yet exist!
2. Are there plans to test this DMP Common Standard by incorporating information into it from existing DMPs and seeing how well the information from those DMPs fits? Such tests could include short DMPs written as requirements of funding proposals or DMPs from more well-funded large research projects(e.g environmental science field campaigns).
I understand that a lot of effort went into gathering user stories towards the development of this standard (https://github.com/RDA-DMP-Common/user-stories/projects/2), but wonder is such an external test could uncover any small blind spots that are left.
-Jonathan Petters
Author: Tomasz Miksa
Date: 06 Feb, 2020
Thank you very much for the interest in the standard. I hope you will find my answers helpful.
Ad. 1
This is a nice suggestion. Indeed, we wanted to promote using metadata standards, but maybe this is too ambitious at the current state. To enable incorporation of non-standard metadata as a descriptor of a Dataset, we can relax the constraint on ‘metadata_standard_id’ and make it optional (change cardinality from 1 to 0…1). All the information can be provided then within ‘Metatada/descirption’. We will discuss this with the community during the plenary in Melborune and will likely issue a minor revision afterwards.
Ad. 2
During the development we also made some mappings between the standard and the templates, e.g. EC Horizon 2020 or Science Europe. Based on that we included fields like ‘preservation_statement’ or ‘data_quality_assurance’. You can find some mappings and tools that use those mappings here [Tools 8-10]:
Please also note that we are not providing a universal model for DMPs, we are providing an information exchange standard. Therefore, the next step is to look to the tool providers to test our standard.
Author: Beth Plale
Date: 25 Mar, 2020
I strongly second Jonathan's first observation above regarding the maturity of research communities with respect to a metadata standard. Most communities in the US research ecosystem do not have a metadata standard, and for the majority of those, none will exist into the foreseeable future.
Author: Yvan Le Bras
Date: 30 Jan, 2020
Thank you so much for this amazing work !
I was not contributing to it, but as a first lover, I am using your sepcifications https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard to test an old idea I had, to populate DMP from metadata standard. So yes, it appears to me important to ask for a metadata standard as this is for me a inital brick really important to build community dedicated products and services, as maDMP!
So THANK YOU !!!! Will use the github space to give feedback / propose things !
Author: Tomasz Miksa
Date: 06 Feb, 2020
Great to hear that you like it!
We also believe that the current specification is the first step to enable building services that actually *do* something with information in DMPs, or feed that information into DMPs.
You may want to check out some of our plenary slides in which we showed ideas we had for automation.