The data management plan has a reputation problem. For many researchers it is a compliance document written in the final week before a grant deadline, accepted by the funder, and never opened again. That is a waste of a genuinely useful artefact, and it is also a missed opportunity, because the same plan can be expressed in a form that systems can act on. This article walks from a conventional narrative DMP to a machine-actionable one, showing what the structure buys you. It builds on the machine-actionable DMPs domain and connects to the workflows described under research administration.
Where most DMPs start: the narrative plan
A data management plan (DMP) is a document describing how data will be handled during and after a project: what data will be produced, how they will be stored and backed up, how they will be documented and shared, who is responsible, and how long they will be kept. In its common form it is narrative prose, often written against a funder or institutional template, answering a set of standard headings.
A narrative answer typically reads something like this:
“The project will generate approximately 200 GB of microscopy image data and associated tabular measurements. Active data will be stored on the institutional research-data store with nightly backup. On publication, processed datasets will be deposited in a generalist repository under a CC-BY licence and assigned a DOI. Raw image data containing no personal information will be retained for ten years in line with institutional policy. The principal investigator is responsible for data management.”
There is nothing wrong with this. It is clear, honest, and answers the questions. Its limitation is purely that it is prose: a human must read it to extract any single fact, and no system can check it, update it, or connect it to anything else. Each fact — the licence, the repository, the retention period, the responsible person — is locked inside a sentence.
The next step: structure the same content
A machine-actionable DMP (maDMP) contains the same information, but expressed as structured, identified data rather than free text. The reference model is the RDA DMP Common Standard — a JSON schema developed by the Research Data Alliance to represent DMP content in a consistent, exchangeable form. Rather than a paragraph, each element becomes a typed field: a dataset has a title, a type, a personal-data flag, a planned size, a distribution with a named host and a licence, and a link to the responsible contributor, who is in turn identified by an ORCID iD.
The narrative paragraph above, restructured against that model, becomes a set of explicit elements:
- Dataset: “Microscopy image data” — type: image; personal data: no; estimated volume: 200 GB.
- Distribution: host: named generalist repository; access: open; licence: CC-BY; identifier: DOI (assigned on deposit).
- Retention: 10 years, per institutional policy.
- Contributor: the principal investigator, identified by ORCID iD, with the role of data contact.
- The whole plan itself carries a DMP ID — a persistent identifier, typically a DataCite DOI — so it can be cited and referenced across systems.
The content is unchanged. What changes is that every fact is now addressable on its own.
What the structure makes possible
Structuring the plan is not bureaucracy for its own sake; it unlocks behaviours that a narrative simply cannot support.
- Validation. A system can check that every planned dataset names a repository, that every distribution has a licence, and that the plan meets the funder’s required elements — before submission, automatically.
- Exchange between systems. A plan authored in a DMP tool can be passed to the institution’s research-information system, to the repository at deposit time, and back to the funder, without anyone re-keying it. This is the maDMP exchange the standard was built for.
- The living DMP. Because each element is addressable, the plan can be updated as the project unfolds — an anticipated dataset becomes a realised one when it is deposited, and the deposit’s DOI flows back into the plan. The DMP stops being frozen at award and becomes a current record of what actually happened to the data.
- Connection to the wider record. Because the plan, its datasets, its contributors, and its host all carry identifiers, the DMP becomes a node in the identifier graph — linkable to the project (via a RAiD), to the people (via ORCID), to the institution (via ROR), and to the outputs (via their DOIs).
A realistic view of where this stands
It is worth being candid: machine-actionable DMPs are an active and maturing area, not a universally deployed reality. The RDA Common Standard exists and is implemented in several DMP tools; DMP IDs are being minted; and funders are beginning to express interest in structured plans. But many researchers still write, and many funders still accept, narrative plans, and the end-to-end exchange between tools, repositories, and funders is still being built out. The practical takeaway is not that you must produce a maDMP tomorrow, but that writing your narrative plan with structure in mind — naming repositories, stating licences explicitly, identifying people by ORCID, treating the plan as living — positions the same content to become machine-actionable as the infrastructure matures.
The cheapest move toward a machine-actionable plan is to stop writing the DMP as an essay and start writing it as a set of clear, specific commitments — named repository, explicit licence, identified people, stated retention. Structured thinking comes before structured data.
Where shared vocabulary fits
“Dataset”, “distribution”, “retention period”, “data contact”, and “living DMP” need to mean the same thing in a DMP tool, a repository, a CRIS, and a funder’s system for any of this exchange to work. A shared, federated vocabulary that defines these elements precisely — pointing back to the RDA DMP Common Standard for the schema — is what lets a plan authored in one system be acted on by another. Supplying that definitional layer is the role the CASRAI dictionary is designed to play; the relevant terms sit in the machine-actionable DMPs domain.