Tag: data management planning

  • The DMP tools landscape: comparing DMPTool, DMPonline and Argos

    A standard for machine-actionable data management plans is only useful if researchers have tools that put it into practice. Over the past decade three platforms have come to dominate the data-management-planning landscape, each developed and maintained by a significant open-science organisation, and each now working towards interoperability through the same common standard. For an institution choosing how to support its researchers, or a researcher trying to understand the options, it helps to see how DMPTool, DMPonline and Argos compare — what they share, where they differ, and what unites them. This article surveys that landscape through the machine-actionable DMP domain of the CASRAI Dictionary.

    Why dedicated tools exist

    It is reasonable to ask why data management planning needs special software at all, when a plan could be written in a word processor. The answer lies in everything a good tool does beyond capturing text. A dedicated DMP platform guides researchers through funder and institutional templates so they answer the right questions; it supplies guidance at the point of need; it allows plans to be shared, reviewed and collaboratively edited; and, increasingly, it exports plans in structured, machine-readable formats so the commitments they contain can be acted on by other systems rather than read once and filed. This last capability — producing a machine-actionable plan rather than a static document — is what distinguishes a modern DMP tool from a template in a folder.

    DMPTool

    The first of the three, DMPTool, is developed and operated by the California Digital Library. It emerged to help researchers, particularly in the United States, meet the data-management-planning requirements of funders, and it provides funder and institutional templates, tailored guidance and a collaborative environment for producing plans. DMPTool has been a leading voice in the move towards machine-actionable planning, contributing to the development of the standards and infrastructure that allow plans to become connected, living objects rather than text deliverables. Its institutional adoption across many universities has made it a familiar part of the research-support landscape, and its development sits within the broader work of the California Digital Library on open scholarship and research infrastructure.

    DMPonline and DMP Roadmap

    The second platform, DMPonline, is developed by the Digital Curation Centre, a long-standing centre of expertise in research-data curation. Like DMPTool, it offers funder and institutional templates, embedded guidance and collaborative editing, and it is widely used across the United Kingdom, Europe and beyond. DMPonline and DMPTool are closely related at a deeper level: they share a common open-source codebase known as DMP Roadmap, jointly developed by the two organisations. This shared foundation means the two services have a great deal in common under the surface even as each is tailored to its own community of funders and institutions. The collaboration behind DMP Roadmap is itself a notable feature of the landscape: rather than building competing systems from scratch, two major infrastructures pooled effort into a common platform, which has helped align their approach to machine-actionable planning.

    Argos

    The third platform, Argos, comes from the European open-science ecosystem and is developed in association with OpenAIRE and EUDAT. Argos was designed from the outset with machine-actionability and openness in mind, and with close integration into the wider European research-infrastructure landscape. It supports the creation of plans against templates and, in keeping with its origins, emphasises producing plans as structured, openly available outputs that connect into the broader graph of European research information. Its provenance in OpenAIRE and EUDAT positions it naturally within an ecosystem oriented towards linking outputs, projects and funding, and it reflects a vision in which the DMP is not an isolated document but a connected node in the research record.

    What unites them: the RDA DMP Common Standard

    For all their differences in origin and community, the three platforms are converging on a shared foundation for interoperability: the RDA DMP Common Standard, developed through the Research Data Alliance. The common standard defines a shared model and structure for expressing the information a DMP contains, so that a machine-actionable plan can be exported from one system and understood by another. This matters because plans do not live in isolation: a plan created in one tool may need to be read by a funder’s system, harvested into a repository, or connected to the persistent identifiers for the people, projects and outputs it describes. Without a common structure, every such exchange would require bespoke translation. With it, a maDMP exported from DMPTool, DMPonline or Argos can in principle flow into the wider ecosystem and be acted upon. The standard is what turns three separate tools into parts of a connected planning landscape.

    Choosing between them

    For an institution or researcher, the choice often comes down to context rather than a verdict on which platform is best. Existing institutional adoption, the funders one works with, the surrounding national infrastructure and integration with other systems all weigh on the decision. Because all three are moving towards the same common standard, the choice is less consequential than it once was: the goal is interoperable, machine-actionable planning, and each platform is a credible route to it. The decision is one of fit, not of compatibility.

    A consistent vocabulary across tools

    For plans to move between these platforms and the systems that consume them, the elements they contain must mean the same thing everywhere — the data types, the licences, the identifiers, the contributor roles. That consistency is what the CASRAI Dictionary provides, complementing the structural interoperability of the RDA standard with shared meaning for the terms that flow through it. And because data management planning is part of the wider research record, the contributions it documents can be described in the same shared framework — the CRediT taxonomy and its full set of contribution roles. To weigh the platforms side by side in more detail, our comparison resources set out their features against one another. The tools differ in origin and emphasis, but they share a destination: planning that machines as well as people can act upon.

  • Living DMPs: dynamic data management plans across the lifecycle

    The data management plan has a familiar life story, and for much of its history an unhappy one. A researcher writes a plan to satisfy a funder’s requirement at proposal stage, describing data that does not yet exist. The plan is submitted, the grant awarded, and the document filed away — never opened again. By the time real data begins to flow, the plan is already a work of fiction: the formats changed, the volumes grew, the consent arrangements were refined. A plan written once and never revisited describes the project that was imagined, not the one that happened. The living DMP — a plan that updates dynamically across the lifecycle of a project — is the response, and it belongs to the machine-actionable DMP domain of the CASRAI Dictionary.

    The trouble with the static plan

    The deepest flaw in the traditional DMP is one of timing. It is required precisely when the least is known — at the proposal stage, before the work has begun — then frozen at the moment it is most speculative. Research is not like that. Data management decisions are made and revised continuously: the instruments produce more data than expected, an ethics review changes how participant data must be handled, a new repository becomes the obvious home. A static plan cannot reflect any of this. It becomes, at best, a historical curiosity and, at worst, a misleading record nobody trusts. The energy spent writing it is largely wasted, because the document never connects to the reality it was meant to govern. The static plan fails not because planning is pointless but because a plan that cannot change cannot stay true.

    What makes a DMP “living”

    A living DMP treats the plan as a dynamic document that evolves with the project rather than a fixed deliverable. It is created at the start, as before, but expected to change — updated as decisions are made, as data is produced, and as circumstances shift. The aim is for the plan to remain an accurate description of how the project’s data is actually being managed, useful to the people doing the work rather than written only for an external reader. A living plan can answer real questions: where is this dataset stored, under what licence will it be shared, who is responsible. Because it stays current, it can guide practice, support handovers, and provide an honest record at the end. The shift is from plan-as-document to plan-as-living-record — from something written to be filed, to something maintained to be used.

    Why machine-actionability is the key

    Keeping a plan current by hand is a burden few will sustain, which is why the living DMP depends on machine-actionability. A traditional plan is prose: to update it, a human must edit text. A machine-actionable DMP (a maDMP) expresses its content as structured, machine-readable information, and this changes what is possible. Updates need not be manual: when a dataset is deposited, when an identifier is minted, when a project record changes, the plan can be updated automatically to reflect what has actually happened. The structure also lets the plan be checked — systems can verify whether stated commitments have been met — and lets it exchange information with other systems. Machine-actionability is what makes “living” sustainable: the plan keeps pace with the project without depending on someone remembering to rewrite a document nobody wants to maintain.

    The RDA DMP Common Standard

    For plans to update automatically by exchanging information with repositories, funder systems and institutional databases, those systems must agree on how a plan’s contents are represented. This is the contribution of the RDA DMP Common Standard, developed through the Research Data Alliance: a common, machine-actionable model for the information a data management plan contains. By defining a shared structure for the elements of a plan — the datasets, their characteristics, storage and preservation arrangements, licensing, costs and contributors — the standard lets a plan be created in one tool, understood by another, and updated by information arriving from a third. Without it, every system would represent a plan differently and automatic exchange would be impossible; with it, a living, dynamic DMP can flow between the systems that read and update it.

    Integration with repositories and CRIS

    The living DMP only realises its value when connected to the systems where the real activity happens. Two integrations matter most:

    • Repositories. When data is deposited, the repository holds authoritative information — identifiers, formats, access conditions. A connected DMP can be updated from this directly, so the plan reflects what has actually been deposited rather than what was once intended.
    • Current research information systems (CRIS). A CRIS holds the institutional picture of projects, people, grants and outputs. Linking the DMP to the CRIS lets the plan draw on and contribute to that picture, keeping data management visible alongside the rest of a project’s record — a concern of research administration more broadly.

    Through these connections the plan stops being an isolated document and becomes a node in the research-information landscape — reading from and writing to the systems that record what a project is doing. This is what turns the machine-actionable plan from a clever idea into an operational reality.

    A consistent vocabulary for plans that travel

    For a living DMP to exchange information with repositories, funder systems and a CRIS, the elements it contains must mean the same thing in every system it touches. A licence, a retention period or an access condition recorded in the plan must be understood identically by the repository that updates it and the CRIS that reads it. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so the contents of a machine-actionable plan are understood the same way wherever they flow. And because the people who steward a project’s data make a real contribution, that work can be described in the same shared framework — the CRediT taxonomy and its Data curation role. The static DMP described the project that was imagined; the living DMP describes the project as it really happens — and stays useful from proposal to completion.