Skip to main content


We are in the process of rolling out a soft launch of the RDA website, which includes a new member platform. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: Visitors may encounter functionality issues with group pages, navigation, missing content, broken links, etc. As you explore the new site, please provide your feedback using the UserSnap tool on the bottom right corner of each page. Thank you for your understanding and support as we work through all issues as quickly as possible. Stay updated about upcoming features and functionalities:


Tomasz Miksa

Dear Christine, Christine, all,
Thank you very much for starting this discussion. Indeed, DMPs have to describe data at different stages of their life cycle. This means that we have cases like:
* Project has finished, data was published, DMP contains a list of DOIs pointing to data – illustrated by example [3]
* Project starts, NSF in the USA requires researchers to pre-book DOIs for their data, before data exists. Hence, DMP shows that DOI was assigned, but data has not been created yet. The issue date for the dataset is set to the future. This tells that information provided about a dataset are not final. This also implies that the size of the dataset is to be considered as an estimation – illustrated by example [5]
* Example [7] shows that DMP can described both performed and planned actions – some data was already released, some other actions are planned (and can change in a newer version of DMP).
To simplify the model we decided to remove status fields. Now the logic on how to interpret specific information is implicit:
* ‘dmp modification date’ and’ dataset issue date’ allow to distinguish between planned and performed actions
* ‘license start date’ indicates whether there is an embargo period or not
* properties that are not set indicate that information at a given revision of a DMP was not available at a moment when DMP was created, e.g. costs section does not exist
When it comes to the provenance, we believe it is out of scope of a DMP. Current DMPs do not contain it and such information should be collected somewhere else – we only want to point to data (e.g. by DOIs) and do not want to duplicate information.
Furthermore, we received feedback that for many settings in which DMPs are used, there is no need to distinguish between specific datasets, for example, a DMP often states what licenses will be used and which repositories, but does not say that dataset A goes to repository X, and dataset B goes to repository Y. Our model supports both scenarios – a very detailed and a very generic DMP. As a consequence, we focused on a minimal number of fields that are common and necessary in both cases.
Thank you for the link to the paper. You’re the first one bringing it up here – seems very relevant… and similar! Thank you!
From: marie-christine.jacquemot=***@***.*** On Behalf Of jacquemotmc
Sent: Wednesday, March 13, 2019 2:56 PM
To: laaboch ; Tomasz Miksa ; DMP Common Standards WG
Subject: Re: [dmp-common] DMP Common Standards – model your own maDMP
Dear Tomasz, Christine and all,
I understand Christine’s remarks. However It seems to me that maDMP are supposed to describe data (and/or all other outputs of a project) throughout the different stages of their life cycle. We can easily imagine that during the active phase of a project, data is only accessible to the partners of the project, or that it may not be worth sharing all data (raw or derived) and therefore it might not be worth attributing a DOI. DMP is becoming a tool for researchers and also for research organization and services that want to have an inventory of the data that they are responsible of.
Some potentially missing information: the provenance of a dataset; the ontology/vocabulary that is being used to describe the data/output, persons and roles at different stages.
One last point, are you aware of the work done based on DataId ontology : I apologize if it has already been mentioned.
De : christine.laaboudi=***@***.*** [mailto:***@***.***] De la part de laaboch
Envoyé : mercredi 13 mars 2019 10:31
À : ‘tmiksa’ ; DMP Common Standards WG
Objet : Re: [dmp-common] DMP Common Standards – model your own maDMP
Dear Tomasz,
I have revised the examples and would like to give you my feedback about datasets with no DOI (dataset) and no accessURL (distribution).
* In examples 3, the dataset has a DOI and the data are accessible through an accessURL (distribution)
* In example 5, the dataset has a DOI but no accessURL (distribution).
* In example 7, the second dataset has a DOI (source code) and an accessURL (distribution) while the first one (Cool data) has not DOI and no accessURL. As a result, the DMP doesn’t provide any information about how to get the data from the first dataset.
In order to cover this specific case, I would suggest to either (1) changing the cardinality of accessURL [1] in the distribution, or (2) adding a “dcat:landingPage” property in the dataset, pointing to the project page where the data are available.
Best regards,
Knowledge Management Assistant – Data Librarian
[logo signature mail]
Publications Office of the European Union
Directorate C – Access to and reuse of public information
C.4 – EU Open Data and CORDIS
EU Open Data
2, rue Mercier * L-2985 Luxembourg
Tel. +352 292942858 * Fax +352 292944604
Facebook – @EU Bookshop – @EUR-Lex
@CORDIS_EU – @EUTenders
@EULawDataPubs – @EU_opendata
– Show quoted text -From: tmiksa=***@***.*** [mailto:***@***.***] On Behalf Of tmiksa
Sent: Thursday, March 07, 2019 5:11 PM
To: DMP Common Standards WG
Subject: [dmp-common] DMP Common Standards – model your own maDMP
Dear group members,
We have created some JSON examples of maDMPs. You can find them here:
They are based on the model that you have already seen (which continuously undergoes adaptations):
We would like to ask you to:
* Revise the examples and provide feedback
* Create your own maDMPs examples – you can either model your own scenarios to check how (and if) model supports them, or use some of the user stories from the first consultation in case you need inspiration [1]
The goal of this exercise is to collaboratively do the first verification and validation of the model and detect any problems early on. We count on your help!
Please provide your feedback through issues mechanisms on GitHub or drop us a mail – whatever is easier for you. The sooner, the better – the plan is to present the first draft of the model during the P13 in April!
In the meantime we’re working on a documentation that will complement/replace the current diagram, but we believe that existing resources should provide you enough information to work on examples/provide feedback.
We look forward to hearing from you!
Best wishes,
Tomasz, Paul, Peter