Appearance
To plan edition sustainability, treat the scholarly data and the public website as two separate commitments with two separate plans. Keep the data as standards-based TEI/XML and IIIF, independent of any framework, and deposit it in a trustworthy repository with persistent identifiers and checksums. Deliver the website as statically as you can manage, and — most importantly — name a long-term custodian (a library or archive) in writing before you launch. An edition with no named home is already at risk; the day the grant ends, no one is responsible for it.
Why does sustainability planning come first, not last?
Because the decisions that make an edition durable are architectural, and architecture is cheap to choose at the start and ruinous to retrofit. If you build on a bespoke database in year one, no amount of good intentions in year five will make it preservable. Planning sustainability up front costs almost nothing and changes how you store data, choose tools, and write your charter. Bolting it on after launch usually means a rebuild.
How do I separate data from presentation?
This is the load-bearing principle. Your scholarship — transcriptions, apparatus, metadata — must live as standards-based files that mean something without any specific software. The website merely renders them.
text
edition/
data/ # TEI P5, IIIF manifests — the preservable scholarly asset
build/ # generated HTML/JS — disposable, regenerableTest the separation with one question: if your publishing framework vanished tomorrow, would your edition's content survive intact? If yes, you are sustainable. If your readings only exist inside a database, you are not.
What does a minimal-computing delivery look like?
Minimal computing means delivering the edition as static files — HTML, CSS, JavaScript — with no server-side database to patch. A static edition is a folder you can host anywhere and even archive as-is.
bash
# build once, deploy a folder, no running database
make build # XSLT/CETEIcean -> build/
rsync -a build/ host:/var/www/edition/
# or deposit the whole build/ into a repositoryCompare the two delivery models honestly:
| Aspect | Static (minimal) | Server (database) |
|---|---|---|
| Hosting cost | Very low | Ongoing |
| Maintenance | Rare rebuilds | Continuous patching |
| Preservation | Archive the folder | Hard; needs the stack |
| Dynamic search | Limited/precomputed | Full |
For most editions, static delivery is the sustainable default.
Where and how do I archive the data?
The live site is for access; a repository deposit is for preservation. Package the data with BagIt so its integrity is verifiable, and deposit it where it gets a persistent identifier:
bash
bagit.py --md5 --sha256 edition-data/
# deposit the bag to Zenodo / institutional repo -> get a DOINow there is a fixed, checksummed, citable copy of the scholarship that does not depend on the website existing. Refresh the deposit when the edition reaches a new milestone.
Who will look after it after the funding ends?
This is the question most projects dodge, and it is the one that decides whether the edition survives. Before launch, identify a custodian — typically a university library, a national archive, or a domain repository — and get a written commitment to host or steward the deposit. Document the handover: what they receive, in what formats, and what minimal maintenance they accept. An edition handed to a library as clean static files plus an archived data bag is something an institution can actually keep; a bespoke server they cannot.
What pitfalls quietly kill editions?
The classic killers: a one-developer server stack that goes unpatched; presentation logic baked into the source so the data cannot be reused; facsimiles stored as loose TIFFs with no manifest; no checksums, so silent corruption goes unnoticed; and no named custodian. Each is avoidable at planning time and nearly fatal afterward. Walk your plan against this list before you write a line of code.
Key Takeaways
- Plan data preservation and website longevity as two separate commitments.
- Keep scholarship as standards-based TEI/IIIF that survives any framework.
- Prefer static, minimal-computing delivery to avoid perpetual server maintenance.
- Deposit checksummed, BagIt-packaged data in a repository with a persistent ID.
- Name a long-term custodian (library or archive) in writing before launch.
- Test sustainability by asking if content survives the framework disappearing.
- The biggest killer is a bespoke server stack maintained by one person.
Frequently Asked Questions
What is the single most important factor in edition sustainability?
Separating your data from your presentation. If your scholarship lives as standards-based TEI/XML independent of any framework or database, the edition survives even when the website dies. The website is replaceable; the data is the edition.
How long should a digital edition last?
Aim for the data to be preservable indefinitely and the live website to last at least 10–15 years with planned maintenance. These are different commitments: data preservation is archival, while a live interface needs periodic technical care and eventual rebuilds.
What is the 'minimal computing' approach to sustainability?
Minimal computing favours static sites — plain HTML, CSS, and JavaScript with no server-side database — because they are cheap to host and easy to preserve. A static edition can be dropped onto any web host or into a repository and still work years later.
Where should the data be archived for the long term?
In a trustworthy repository with persistent identifiers — an institutional repository, Zenodo, or a domain archive — packaged with BagIt and checksums. The live website and the archived data are two copies serving two purposes: access and preservation.
Who maintains the edition after the grant ends?
Name a custodian before launch — usually a library, archive, or institutional repository — and secure their commitment in writing. An edition with no named long-term home is at risk the day funding stops, no matter how good the scholarship is.
What is the biggest sustainability mistake?
Building on a bespoke, server-heavy stack that one developer maintains. When that person leaves or the grant ends, the database goes unpatched, breaks, and the edition vanishes. Prefer standards and static delivery you can hand to a library.