Appearance
To write a data plan for a DH grant, answer five concrete questions in the funder's own template: what data you will create, how you will describe and organise it, where you will store it during the project, how you will preserve it afterwards, and how others may access and reuse it. Reviewers reward specificity — named formats, a named repository, a named licence — and penalise vague reassurances that data will be "carefully managed". Keep it to one or two dense, verifiable pages.
What questions does a grant data plan have to answer?
Almost every funder template, whether AHRC, NEH, NSF or Horizon Europe, reduces to the same five sections:
- What data — types, formats, expected volume.
- Documentation and metadata — how each dataset is described.
- Storage and security during the project — where the working copy lives, backups.
- Preservation — where the final data is deposited and for how long.
- Sharing and reuse — access conditions, licence, any embargo.
Write to those headings even if the template phrases them differently, and you will rarely miss a required element.
How specific do the data and formats need to be?
Specific enough to verify. Replace "we will produce digital files" with a concrete inventory:
| Dataset | Format | Est. volume | Standard |
|---|---|---|---|
| Transcriptions | TEI-XML (P5) | ~420 files | TEI Guidelines |
| Place gazetteer | CSV + GeoJSON | ~1,800 rows | WGS84, Pelagios-style |
| Master images | TIFF (uncompressed) | ~180 GB | FADGI 4-star |
| Derivatives | JPEG / IIIF | ~25 GB | IIIF Image API 3.0 |
Naming a recognised standard in each row signals to reviewers that the outputs will be interoperable, not bespoke.
Which repository and identifier should I name?
Name one, explicitly, and say why it is trustworthy. Avoid "a suitable repository will be selected." Strong choices include a CoreTrustSeal-certified domain repository, an institutional repository, or Zenodo for code and mixed outputs. State that the deposit will receive a persistent identifier:
text
Final datasets deposited in [named repository] under a CC BY 4.0 licence,
each issued a DOI, with TIFF masters and TEI sources retained for ≥10 years.
Code archived in Zenodo via the GitHub integration, with a release DOI.How do I handle sensitive or personal data?
If your sources mention identifiable living people, address it head on. State the legal basis (for UK/EU work, the relevant GDPR provision and any research exemption), your anonymisation or pseudonymisation approach, and any access controls or embargo. If there is genuinely no personal data — common for pre-1900 records — say so in one sentence rather than leaving the section blank; an empty section reads as an oversight.
What does a strong sharing and licensing statement look like?
Pick an open licence by default and justify any restriction. For data, Creative Commons (CC0 or CC BY 4.0) and Open Data Commons are standard; for code, an OSI-approved licence such as MIT or Apache-2.0. Where rights are mixed — third-party images you cannot redistribute — separate redistributable derivatives from restricted masters and license each appropriately.
How do I keep the DMP a living document?
A grant DMP is written once but should be revisited at least at the midpoint and at project end. Store it in the project repository alongside the README so changes are versioned:
bash
git add docs/dmp.md
git commit -m "Update DMP: switch master format to JP2, add embargo note"Funders increasingly ask for an updated DMP as a deliverable, so treating it as version-controlled documentation rather than a one-off submission pays off.
What is the reviewer's checklist?
- Are data types, formats and volumes named concretely?
- Is a recognised metadata standard cited?
- Is a specific, trusted repository named with a persistent identifier?
- Is a licence stated for both data and code?
- Are sensitive-data and rights issues explicitly addressed?
- Is a named person responsible for the data?
Key Takeaways
- Answer the five core questions: what, documentation, storage, preservation, sharing.
- Be verifiable — name formats, standards, repositories, licences and a responsible person.
- Cite recognised standards (TEI, IIIF, Dublin Core) to signal interoperability.
- Address sensitive data explicitly, even to say none is involved.
- Default to open licences and justify any restriction.
- Version the DMP in the project repository and update it at milestones.
Frequently Asked Questions
What is a data management plan in a grant context?
A short structured document, usually one to three pages, describing what data you will create, how you will document and store it, and how you will preserve and share it after the project ends.
Which funders require a DMP for DH work?
Most major funders do, including the UK AHRC and UKRI, the US NEH and NSF, and the EU under Horizon Europe. Each has its own template, so always start from the funder's own questions.
How long should a grant data plan be?
Usually one to two pages of dense, specific content. Reviewers want concrete formats, repositories and licences — not generic statements that the data will be "managed carefully".
What repository should I name in the plan?
Name a specific, trusted repository with a persistent identifier service, such as Zenodo, your institutional repository, or a domain repository like the UK Data Service. Avoid "a suitable repository will be chosen later".
Do I need to address sensitive or personal data?
Yes, whenever your sources contain identifiable living people. State your legal basis, anonymisation or access-control approach, and any embargo, even if the answer is that no personal data is involved.
How do I make a DMP defensible to reviewers?
Be specific and verifiable: named formats, a named repository, a named licence, and a named person responsible. Specificity signals competence; vagueness signals risk.