CASRAI Dictionary

Tag: DMP

  • Reading the RDA DMP Common Standard v2 changelog

    The Research Data Alliance’s DMP Common Standard, originally published as v1 in 2019, has been the canonical machine-readable schema for machine-actionable data management plans. The v2 revision, released early in 2026 after a two-year community consultation, reorganises the schema, tightens validation, and adds explicit support for software, samples, and instruments alongside data. This post is a field-by-field walkthrough for integrators.

    Why v2 was needed

    v1 was designed in the FAIR-data heyday and is fit for that purpose. Three forces produced the v2 revision. First, the scope of “things to be managed” expanded: software is increasingly part of the planning conversation, samples are increasingly recognised as research outputs that need governance, instruments have their own management lifecycle. v1 could be coaxed into representing these but the structure was uncomfortable. Second, validation: v1 was permissive in the ways that mature standards usually tighten over time. Optional fields proliferated, the meaning of several fields was under-specified, and tools produced incompatible serialisations within nominal compliance. Third, FAIR-implementation maturity: v2 needed to carry the metadata that the FAIR data-assessment frameworks (FAIRsharing, F-UJI, FAIR Implementation Profiles) had converged on requiring.

    Structural changes

    The top-level structure of v2 is reorganised. v1 had dmp as the root with sub-resources for dataset, contact, contributor, project, cost. v2 keeps dmp as the root but moves to a managed_resources array that contains heterogeneous resource types: dataset, software, sample, instrument, other. Each resource type has its own schema with shared common fields (identifier, title, description, distribution, license, contributors with CRediT roles) and type-specific fields.

    This is the biggest structural change and the one that will require migration effort. v1 DMPs with only datasets can be projected into v2 cleanly; v1 DMPs that used the dataset structure to represent software or samples (the common workaround) will need restructuring on migration.

    Identifier requirements

    v2 tightens identifier requirements. Every managed resource must declare its identifier with a type (DOI, Handle, URL, ARK, IGSN for samples, RAiD for projects); the identifier validation runs against the type. The contributor structure requires ORCID iDs for individuals; the affiliation structure requires ROR IDs for organisations. The project structure requires either a RAiD or a Funder Registry grant identifier or both.

    The validation tightening is the integration-relevant change. v1 tools that accepted strings in identifier fields will produce DMPs that fail v2 validation. Integrators should review their PID-handling logic before migrating.

    The CRediT integration

    v2 carries CRediT roles natively in the contributor structure. Each contributor on a DMP can be assigned one or more CRediT roles with the degree-of-contribution qualifier. The expected pattern is that DMP contributors (the people who will manage the data) get roles like Data curation, Resources, Project administration, Supervision, with the actual research contributors getting their roles assigned later via the publication or dataset metadata. The DMP captures the data-management contributorship, not the research contributorship.

    FAIR alignment

    v2 includes a fair_assessment structure that aligns with the FAIR Implementation Profile framework. Each managed resource can carry an FIP reference, and the DMP-level fair_assessment can declare which FAIRsharing-registered standards, identifiers, and policies the resources conform to. This is the bridge between DMP-as-planning-document and DMP-as-FAIR-compliance-record.

    The cost structure

    v2 reworks the cost structure. v1 had a flat cost array with title, description, value, currency. v2 categorises costs by phase (acquisition, processing, storage-active, storage-preservation, dissemination, decommissioning) and by recurrence (one-off versus annual), which lets a DMP integrate with funder budget structures and institutional cost-recovery models. The cost structure is optional but recommended.

    Lifecycle status

    v2 introduces an explicit lifecycle field on each managed resource, with controlled values covering planning, acquisition, processing, analysis, dissemination, preservation, decommissioning. A DMP can describe resources at different lifecycle stages, which lets the same DMP serve as both a project-launch plan and a project-completion record. This addresses a v1 friction where DMPs were either pre-project plans or post-project records and the same document could not serve both purposes cleanly.

    Migration path

    RDA’s recommendation is that v1 DMPs remain valid through 2027 and that v2 DMPs become the preferred format from 2026. Tools producing or consuming DMPs should support both formats during the transition window. The official RDA migration guide covers the field mappings; the CASRAI maDMP domain tracks tool-vendor support as it rolls out.

    Specific migration considerations: v1 datasets representing software should be re-categorised as v2 software resources; v1 datasets representing samples should be re-categorised as v2 sample resources; v1 contributors without ORCID iDs need ORCID iDs added before v2 validation will pass; v1 organisational affiliations need ROR IDs.

    Tool support

    By the v2 release, the major DMP tools (DMPonline, DMPTool, easyDMP, ARGOS) had announced support timelines. DMPonline and DMPTool committed to v2 export support in mid-2026 with import support later in the year. easyDMP shipped v2 support at the v2 release. ARGOS has v2 support in beta. Institutional and funder DMP services built on these tools inherit their support timelines.

    The funder side of the integration is also moving. Several major funders had been ingesting v1 DMPs in machine-readable form for compliance tracking; the v2 transition gives them an opportunity to tighten ingestion validation and to use the richer FAIR-assessment structure. The CASRAI funder maDMP guide walks through the funder-side migration.

    What this enables

    The longer-term value of v2 is in the queries it enables across machine-readable DMPs at scale. A funder can ask: across all funded projects starting in 2026, which fraction declared FAIR-compliant deposit plans for their datasets, software, and samples? — and get a structured answer. An institution can ask: which projects on our books have DMPs that declare preservation costs, and what is our aggregate preservation-cost commitment? — and get a structured answer. v1 made these queries notionally possible; v2 makes them reliable.

    For research administration, the practical posture in 2026 is to follow the funder migration. Where funders require v2, migrate; where they still accept v1, produce both. The migration is one-way (a v2 DMP cannot be cleanly downgraded to v1 if the new resource types are used) but the v1-to-v2 path is well-supported.

    Related dictionary entries

  • Research data management plans go machine-actionable: the maDMP transition

    The Data Management Plan has been an awkward artefact of the funded-research workflow since the 2010 NSF mandate. For a decade it was a few-page PDF, written at proposal stage, signed off by a librarian, and largely forgotten until the next proposal. In 2026 the picture is different. The machine-actionable DMP (maDMP) has matured from a Research Data Alliance working-group concept into operational infrastructure at major funders, repositories, and institutions. This post walks through what changed, what the tooling actually does, and what the corresponding software-management-plan turn means for funded projects in 2026.

    The maDMP idea

    The traditional DMP described what the project would do with its data: which formats, which repositories, what metadata, what retention. The information was useful but was locked in prose; downstream systems could not consume it, so the same information was re-entered in each new context (the repository deposit form, the funder report, the institutional CRIS).

    The maDMP idea, formalised by the RDA DMP Common Standard, is to express the DMP as structured machine-readable data (a JSON document conforming to the Common Standard schema) that downstream systems can consume directly. The same information that is human-readable in the PDF is also available as queryable structured data, with PIDs (ORCID for people, ROR for organisations, DOI for repositories, RAiD for the project).

    The Common Standard, finalised by the RDA Active DMPs working group, defines the JSON schema, the controlled vocabularies, and the core required fields. Version 1.1 was the working release through 2022-2024; the 1.2 update (2024) added software-management-plan extension fields and refined the contributor model to align with CRediT.

    The tooling landscape

    By 2026 several mature tools implement the maDMP standard, with substantial integration across regions.

    DMPRoadmap and its descendants

    DMPRoadmap is the open-source maDMP platform jointly developed by the UK Digital Curation Centre and the University of California Curation Center. It powers the UK’s DMPonline service (used by all UKRI councils, NIHR, Wellcome, and most UK universities) and the US’s DMPTool (used by NSF, NIH, NASA, DOE, and a long list of US institutions). The 2024 unification of DMPRoadmap’s code base across the UK and US deployments was a significant administrative move; the platform is now a single shared upstream with regional customisations.

    Argos

    Argos is the European maDMP platform developed by OpenAIRE and EUDAT. Argos is the default DMP tool for HORIZON Europe-funded projects and integrates tightly with the EOSC Zenodo deposit workflow, the OpenAIRE Graph, and the Funding and Tenders portal. Argos’s interesting design choice was to model the DMP as a layered set of templates (funder-specific layered on discipline-specific layered on institutional), which allows a single underlying maDMP to be presented through whatever lens an evaluator needs.

    RDA-DMP-Common-Standard-native tools

    The RDA Common Standard is now natively supported by most major repository platforms (DataCite Fabrica, Zenodo, Figshare, Dryad), by several CRIS systems (Pure, Elements, Converis, DSpace-CRIS), and by funder portals. The interop story is real: a maDMP produced in DMPonline can be exported as Common Standard JSON, consumed by Argos for a HORIZON proposal, and round-tripped to a DataCite repository at the deposit stage.

    What an maDMP integration looks like in practice

    The integration patterns that have settled in 2026 follow this shape. At proposal stage the researcher uses DMPonline/DMPTool/Argos to draft a maDMP, pulling in ORCID, ROR, and grant metadata where available. The maDMP is exported as Common Standard JSON and attached to the proposal.

    At award stage the funder pulls the maDMP into its grant-management system; the project’s RAiD or grant DOI is back-linked to the maDMP record. The maDMP becomes the canonical project plan that the institution’s CRIS, repository, and reporting workflow all reference.

    At repository deposit the dataset metadata (title, authors, methods, related publications) is pre-populated from the maDMP fields. Saving the deposit triggers an update to the maDMP record itself, marking that planned dataset as deposited, with the resulting DOI.

    At reporting stage the funder’s annual report and the institution’s research-information report both query the same maDMP record. Re-keying of the same information across systems is materially reduced.

    The user-visible artefact is still a PDF (funders and reviewers still want one) but it is generated from the structured record on demand, not authored in prose.

    Where it falls short

    Three frictions remain in 2026. First, discipline coverage: the Common Standard was drafted with bench-science and social-science data primarily in mind. Humanities collections, qualitative archives, and operational data (e.g., conservation biology fieldwork data) fit the schema imperfectly. The RDA working groups have been extending the controlled vocabularies but the long tail is long.

    Second, repository alignment: not every repository accepts maDMP-imported deposits cleanly. The big repositories do; the long tail of institutional repositories often have legacy metadata schemas that need mapping.

    Third, privacy and sensitivity: a maDMP for a clinical study contains potentially sensitive information about data access controls, IRB approvals, and consent terms. The Common Standard supports flagging fields as confidential, but the operational practice of differential disclosure to different downstream consumers (funder, repository, public) is still being worked out.

    The Software Management Plan turn

    The 2024-2025 development that genuinely shifted the field was the formal addition of Software Management Plans as a sibling artefact to DMPs. Funders had been asking for them informally for years; the 2024 explicit requirement at NWO (Netherlands), NIH (for selected programmes), DFG (Germany), and several UKRI councils brought the SMP into the mainstream.

    An SMP describes how the project’s software will be developed and stewarded: licence, repository, citation, dependencies, sustainability beyond the project life. The 2024 SMP guidance from the Software Sustainability Institute defined a five-section structure that has been broadly adopted: software descriptions, software development practice, software deposit and citation, sustainability and maintenance, and intellectual property and licensing.

    The maDMP Common Standard 1.2 added an SMP extension that allows the SMP to be expressed alongside the data plan in the same JSON document, with cross-references between data products and the software that produces them. By 2026 this is becoming the default: a project produces one structured maDMP that covers data and software, with both halves referenced from the same RAiD.

    FAIR data integration

    The maDMP transition has reinforced the practical operationalisation of FAIR. A maDMP that names a repository (with a DOI), a metadata schema, a controlled vocabulary, and a licence is structurally more FAIR-compliant than a prose DMP that mentions “a suitable repository.” The maDMP-to-deposit integrations make F (findable) and A (accessible) measurable; the I (interoperable) and R (reusable) elements need the metadata-schema and licence choices to actually be implemented.

    The RDA FAIR Data Maturity Model indicators are now being calculated automatically from maDMP records and repository deposits in several institutional CRIS systems. The 2026 picture is that institutions can measure FAIR-ness of their research outputs at the data-product level, not just claim it; this is a real improvement on the 2020 baseline.

    What to do if you are starting now

    For a researcher writing a proposal in early 2026:

    1. Use the funder-recommended maDMP tool (DMPonline, DMPTool, or Argos depending on funder).
    2. Identify your data products and their target repositories early; choose repositories that accept Common Standard imports.
    3. If your project produces software, draft an SMP alongside the DMP using the SSI five-section structure. The Common Standard 1.2 lets you keep them in one record.
    4. Provide ORCID and ROR identifiers everywhere they are asked for. Link the maDMP to the project’s RAiD if your funder supports it (Australian, UK, EU funders are most likely to).
    5. Treat the maDMP as a living document. Update it on data deposit, on milestone reporting, and on project closeout. The point of machine-actionability is that updating it is cheap.

    For institutions setting policy, the RDA federation page tracks the working-group outputs and adoption status. The maDMP domain at CASRAI carries the canonical Common Standard reference.

    Related dictionary entries

    References

    RDA Active DMPs Working Group, DMP Common Standard for machine-actionable DMPs (v1.1, 2022; v1.2, 2024). Miksa et al., Ten principles for machine-actionable data management plans (PLOS Computational Biology, 2019). Software Sustainability Institute, Checklist for a Software Management Plan (2024 revision). EOSC, EOSC FAIR Implementation Profiles (2023).