A worked example, looking at one antiphon to which the CURSUS project gave the ID ‘c5111’ and how this and references to it are encoded, will help to explain some of the technical details of the project.[2] The c5111 antiphon appears, among other places, in the Peterborough Antiphoner[3] during the Vespers service for Maunday Thursday. Most manuscripts have a different date for this antiphon; all the other manuscripts edited on the project, for whatever reason, use it on the Tuesday or Wednesday of the medieval Christian Holy Week. In the underlying XML of the manuscript the pointer to this specific antiphon is encoded as in Figure 1 below.

What becomes instantly obvious (to those familiar with XML markup standards at least) is that this does not follow the current TEI P5 Guidelines. Indeed, the CURSUS project predates TEI P5, which was not released until 2007, and uses a project-specific extension of TEI P4 XML for its markup.[4] In Figure 1 a TEI P4 <xptr/> element points to the ID ‘c5111’ in the CAO repository of antiphons, responds, and prayers, and the markup instructs the processing to retrieve the content of the <aBody> element there (denoted by the value of the type attribute). A mere examination of the form of this <xptr/> in isolation does not explain much, but looking at it in progressively greater context shows more of the liturgy-specific elements that the project had added to its use of the TEI. The (custom) <antiphon> element that surrounds it is seen in Figure 2.

In Figure 2 the mixture of TEI P4 elements (such as “add,” “hi,” “supplied,” and “xptr”) and the project’s own additions (such as “antiphon” and “rubric”) are evident. Once the project’s principal investigator learned of the extensibility of the TEI as a system, he preferred discipline-specific terminology for important aspects of the text. Although there are differences between this markup and what one might see today in TEI P5, the general intentions and interpretations of the markup are still relatively clear.

Even in the full context (Figure 3) of the entire Vespers service that contains antiphon c5111, there are only a few additional non-TEI P4 elements (such as “Day,” “service,” and “incipit”). What starts to become evident through these examples, at least to those familiar with TEI P4 markup, is that this project took full advantage of a TEI DTD-based feature allowing the creation of custom DTD entities for repeated formulaic text, punctuation, and markup that are very common in the highly repetitive liturgical documents. This means that the encoders did not need to include repetitive portions of markup, and merely used a smaller “entity” to stand in for that markup. Even in the context shown through the markup in Figure 2, the use of the entity “&AE;” at the beginning of the “<antiphon>” element demonstrates this exploitation of a technical method of providing formulaic text and markup. The cursus.ent file listing the project’s DTD entities expands this as seen in Figure 4.

In this file the “AE” entity is shown to be expanded to a string of textual markup showing the rubricated text “In Evangelio.” Moreover, this formulaic text itself recursively includes an additional custom entity “A” which is replaced with the rubricated label “Ant.” While there are a number of drawbacks to such a system that mean it would not be recommended today, it was an imaginative exploitation of the ability of DTD-linked documents to provide re-used bits of text and markup.[5] However, this approach does introduce a significant fragility based on all files’ dependence on the DTD and entities file being present and accessible at the time of processing. If the files were to be normalized to TEI P5 XML, then a conversion process would have to begin with a basic identity transform which would expand all of these entities into their non-entity form.

This discussion explains what the encoding of the xpointer only for antiphon c5111 looks like solely in the context of one of the manuscript edition files, but the content of the antiphon is stored with all its textual variants in the CAO repository file. Figure 5 gives an example of this file.

New elements that the project introduced here (including ant, header, usage, and aBody), like most of the additions made by the project, could have been modeled in other ways with TEI elements. For example, the <ant> element could have used a TEI <ab> (anonymous block) element. However, in customizing the TEI, the project used element names that made sense for its encoding needs. The bespoke markup and TEI P4 XML of this project could, should there ever be a need, be converted to TEI P5 XML to be used in a modern production environment. Indeed, it is because of the adoption of the open international standard of the TEI that the markup would be straightforward to convert, even in the case of this extensive customization. The entries in the header are given as standardized numerical codes for all days of the medieval liturgical calendar created by the CANTUS project and are used to generate the links into the manuscript editions.[6] Similarly, the website generated version of the files automatically adds in the IDs of the previous and next liturgical items to the enriched form of the antiphon during the process of extraction by XSLT stylesheets into individual files. These are pieces of convenience data to enable easier processing of the underlying XML for online browsing.

Figure 6 shows the HTML view of this CAO repository entry – the entries are all browseable online and are dynamically transformed to HTML pages on the fly. The textual variants are laid out in parallel boxes showing their mutual differences with the witness sigils discreetly present, mimicking the underlying TEI parallel segmentation markup. In modern websites, these variants would likely be presented in a very different manner – the interface certainly shows its age, having been created in 2002.

This form of interlinking between manuscript edition and repository entries, which then link through to all the other places this antiphon is used, promotes a circular and generally beneficial form of user experience in the navigation. While the XML files store most of the intellectual output of the project, preserving only the XML files would mean that we would lose the argument presented by the interface for how we should interact with such editions. The aspects of interface as edition might be lost if we look only at the underlying files; the edition itself is a publication that includes not only the underlying data but the manner in which it was presented. The output of projects is not only the data they produce but the way in which those products are presented to the end user — when research is published in print, the book is the product, not the research notes or data that underlie it; in other words, the interface is the means of preservation. However, as with many digital resources, perhaps in a demonstration of an appreciation of the much vaunted but seldom realized re-use of materials, we concentrate on the underlying data as the primary output to the detriment of other aspects of the outputs. As a historical artifact representing digital editions from this period of our development in thinking about how to present such editions online, the CURSUS interface deserves preservation or conservation, in the same way one might argue the primary source documents do.

By 2003 the main CURSUS project was completed. Professor David Chadd and I had edited more manuscripts and produced more additional outputs than promised in the AHRB funding bid — but my contract came to an end, so I left UEA for a post at the Oxford Text Archive, University of Oxford. However, Professor Chadd continued work and did not really consider the project concluded, only its funded portion. He occasionally continued to update the website, and, in order to simplify some of the underlying publication technology and assist with technical aspects generally, he later employed Dr Richard Lewis (then a departmental postgrad).[7] This ongoing work meant that the project never reached a point at which Professor Chadd felt that working files could be canonicalized in their final form.

Sadly, in late 2006 Professor Chadd died after a short illness. Although his passing did not immediately affect the website, it did truly bring the project to a close. Professor Chadd had continued to edit manuscripts as and when he could up until his death, but, because he was not using a version control system or frequently uploading these to the website, his final work has been lost.[8] But even death was not the most impactful event in the CURSUS project afterlife.

More dramatically, an event totally unrelated to the CURSUS project in November 2009 had a severe detrimental impact upon it: a hacker illegally obtained over 1,000 emails spanning 13 years, along with 3,000 other documents, from the Climate Research Unit at UEA. A combination of ignorance and willful misunderstanding meant that even any unprofessional or confusing comments in them were used by climate change deniers to spread misinformation. This event became known as “ClimateGate” and as a result UEA temporarily closed all off-campus access to its servers.[9]

Originally, we had “set up one of the project’s desktop machines as a Debian Linux server” [Cummings 2006] but shortly before leaving I suggested it might be best to make it more official, and in my mind more stable, on a departmental server. Throughout all the tumultuous events above, even though the PI of the project had passed away, the CURSUS website continued to run unproblematically on the School of Music departmental server. The site had begun to be cited in journal articles, and not just by those directly concerned with musicology or digital publishing [Licence 2006].

However, sometime in 2010 a software upgrade on that server caused the website to go down, and it needed a configuration change and a restart. With the continuing ban on off-campus access and the fact that neither Dr Lewis nor I were in Norwich or had worked for the university for a few years, we had no easy way to restart the server. By this point the School of Music had little IT support, and UEA’s central IT had no ability to take on these extra duties. Indeed, later in 2010 the School also replaced their departmental server with a new one – having no local champions or even people who knew much about this legacy site, the CURSUS website at the University of East Anglia finally disappeared.[10]

We had backed up the latest version of the data on the server shortly after Professor Chadd’s death, of course, and it was around this time that I first contacted UEA to discuss getting the rights to put the website up again or hosting it elsewhere. Starting with the School of Music, who disavowed any responsibility for the site, I was eventually put in touch with UEA’s Commercialisation Manager from Research and Enterprise Services. A slow process of back-and-forth explanations resulted in 2016 in a Creative Commons Attribution Non-Commercial license for the intellectual property – after six years of negotiation – for a project that always had intended its data to be open but hadn’t explicitly licensed it as such.[11] Indeed, UEA had eventually closed its School of Music in 2014, after hard-fought campaigns to keep it, so even the academic department that had created and hosted this project was now gone [Cunnane 2011] [BBC 2011]. The closure of the department caused additional confusion as it was unclear to the university who in authority might give permission to license this data. But perhaps we did not even need permission: UEA as an institution did not even know it owned this data and the project’s intention was always to release it openly. An alternative, more assertive approach, would have been to put the site up while simultaneously pursuing the permission to do so.[12] While the website is still up, the problems noted above concerning sustainability of such resources indicate that even to preserve the project as a working resource has an inherent fragility. If it is not practical or feasible to preserve such resources, recording a screencast video using the website might be one solution at the very least to document the ephemerality of user experience and interaction for the future.[13]

Since 2016, the site has been hosted on a small personal VPS run by Dr Lewis and the cursus.org.uk domain name (paid for by me), and the underlying data and code stored in GitHub.[14] This arrangement is contingent and precarious; Dr Lewis might decide to stop hosting the site or I might not continue to pay the domain name registration fee. Although people still do use the site and the data, it raises the question of when and how to retire websites and merely preserve the data in case someone wishes to re-use it at a later date. Part of our reason for hosting it is a feeling that the main constituency of users would find the data hard to use in its underlying format. A compromise would be to undertake a project to flatten the website, removing any need for server-side processing and make this available online in a variety of forms. As the website was mostly static (only the XML to HTML transformations being dynamic), it would be easy to flatten it. The XSLT stylesheets and an HTML copy of the website as currently served (with relative links) was added to maintain a coherent version in the zip archive uploaded to Zenodo.[15] Updating the data to be more usable, for example converting to TEI P5 XML, is not a large project but would take a bit more work to rationalize the bespoke elements (only lightly documented in the DTD — these days we would document these extensions fully with a TEI ODD). [16]

Numerous red flags and warning signs indicated that the CURSUS project was at-risk and not properly preserved. Two decades on, it would be gratifying to be able to say that digital humanities projects no longer do such things. Alas, we cannot. However, there have been significant changes that make the preservation of project outputs more likely. For example, instead of keeping the master copy of data on the PI’s laptop, digital humanities projects now use GitHub routinely to store both versioned code and data while enabling collaboration.[17] Instead of using departmental servers stored under someone’s desk to host funded research projects, we now use institutional or virtual machines hosted in the cloud. Major institutional and international data repositories now exist for depositing copies of research outputs but did not at the time.

The majority of problems in the project’s afterlife are those that we did not reflect upon at all while the project was running. For example, we never considered the so-called “Bus Factor” – the minimum number of people who have to vanish from a project before it completely stalls due to the lack of necessary knowledge to sustain it. In this case it was Professor Chadd’s sudden death and the fact that legacy planning for the project site had not been undertaken. Since no other project staff were still employed by UEA, the intellectual content of the project could easily have slipped away. It is only because Dr Lewis and I wanted to preserve it, partly as a tribute to Professor Chadd’s legacy, that it survives at all. We should also recognize the CURSUS project’s strengths – in being fairly simple TEI-based XML with XSLT 1.0 conversion to HTML (albeit dynamic) without any JavaScript or additional libraries, it could easily be migrated and preserved. It is, I would argue, the relative simplicity of the site that has enabled its preservation. Just as a physical object in good condition might be preserved by benign neglect, this website’s minimal footprint, structured text-only content, and generally uncomplicated needs, enabled it to survive relatively well despite being subject to benign digital neglect. More active interventions and conservation might have resulted in the use of more advanced frameworks, features, or libraries, as these became popular, causing more long-term harm for its sustainability than otherwise (see Holmes and Takeda in this issue).

One of the reasons for describing the technical background of this project, and giving the detailed explanation of their use of the TEI Guidelines, is that it demonstrates the kind of complexity that could be achieved within the Endings Principles. To be clear, the CURSUS project does not meet those requirements since, in its current form, it still requires bespoke dynamic pipelined conversion of the underlying XML to HTML. While the experimental DTD-based markup entities were interesting, the fragility they introduce means such an approach should have been used only for the development of materials, not the publication copies. It would have been better to expand all the custom entities in all the files (as well as normalize the markup vocabulary) for a publication version, but with the ongoing nature of the project as Professor Chadd worked towards his (sadly unachieved) retirement, the curse of the perpetual beta meant that it never quite seemed “finished.” It would have been better if regular fixed releases were made, where the production system files (as opposed to the development version) were always in their final canonicalized forms. The server-side dynamic transformation does not add much that, with hindsight, could not have been accomplished with pre-generated flat files. The project was experimenting with various methods of digital publication of TEI-based XML and relished the idea of being “able to have virtual URLs, allowing our users to create dynamically-assembled pages from a variety of XML source files” [Cummings 2006]. It would have been better to pre-generate output files with massive redundancy of every possible view as the Endings Principles suggest.

A lesson for encoding and technical expectation management might be drawn from the number of new custom entities and bespoke elements the project created. Once Professor Chadd discovered the ease with which we could create new bespoke elements, his default approach when a new textual phenomenon or encoding problem was encountered was to create a bespoke element. Taking the easiest approach in any digital project always results in trade-offs and compromises for longevity. This approach sometimes meant that we were encoding things with new project-specific elements rather than looking slightly harder in the community for standardized approaches and solutions. While the CURSUS project was groundbreaking in some of its experiments in the publication of digital medieval resources, hindsight reveals some problems which should have been foreseen at the time.

The website was built on top of an early version of eXist-db (a native XML database) that at the time used Apache Cocoon for URL-based pipelined conversions, with which I was familiar from the CURSUS project. I had experimented with eXist-db during the CURSUS project; an XML database was desired because of the nature of the queries to be done — again on the fly — against a fairly complicated XML dataset. At the time, the popular idea that it “may not be possible to achieve one input — all outputs, but surely one input — many outputs is an entirely practical goal” [Walsh 2002] was brought from the CURSUS project and taken to heart. The project leads viewed it as not only feasible but also desirable to generate many of the project outputs from a single or at least small number of input datasets. Indeed, the project tried to create a network of interlinked inputs that generated a network of intertwined outputs that would decentralize any starting point and thus be open to exploration. The William Godwin’s Diary site, a “finely engineered architecture of XML tagging[,] allows the user to trace acquaintances across the decades, books through his library catalogues, and the author himself through the streets of the metropolis” [Bullard 2013, 752].

The project methodology of working in phases (first adding structural markup, then adding markup recording meetings, then recording and eventually identifying people, places, and events) meant the encoders always moved on to a new year of the diary they had not seen before. This iterative but distributed process meant that fresh eyes saw each entry several times, thus acting as additional proofreaders to reduce human error. From the point of view of the Endings Principles, this methodology ensured that after each phase the content was coherent and complete (as far as it went).[20] This methodological approach is something that many DH projects use to ensure a phased production of output work. The encoders also had diagnostics using a local XSLT stylesheet to transform their work into a debugging “proofreader’s” view that allowed them to spot mistakes through formatting realized in a manner that could never be acceptable in a user-oriented front end. This view highlighted any elements that should have had content but didn’t, and coloured things in a way to emphasize aspects that had not yet been completed.

The website infrastructure was fed directly from the Subversion repository and automatically produced a number of views on the website when updated each evening. The nightly jobs would transform any updated (but well-formed and valid) files into pure TEI P5 XML, load these into the eXist-db database and regenerate a wide variety of tables of information. These included not only lists of plays Godwin went to or books he was reading/writing, but also detailed tables of meals he had (and whether he was dining with the person or the person was dining with him), and other forms of meetings. These were displayed using the external jQuery library DataTables plug-in to provide a filterable, pageable, sortable view of the data that would certainly be against the Endings Principles if they had existed at the time.[21] The level of detail of the encoding and cross-references throughout are what enable the site to provide detail to researchers using it. As one reviewer wrote,

What makes the site an amazing research tool is the level to which Godwin’s meticulous (but brief) notes are cross-referenced against one another, creating a vast web of information that not only fleshes out the skeleton of the author’s life, but also provides a wealth of information about Romantic-era social networks and day-to-day life in the London of the period. [Thomas 2018, 603]

As one might expect, the diary data itself is organized chronologically. Each diary day is represented by a TEI <ab> element with a @type attribute of “dDay” and is required to have an @xml:id attribute based on the date. Each diary entry is required to have a <date> element with a @when attribute provided in W3C format, but the element will have transcribed text content here only if it existed in the diary. The production server markup uses only standard TEI elements, with arbitrary segments denoting meals, meetings, or similar concerns of the project using the <seg> element.

One of the major intellectual contributions of this encoding work — and a significant demonstration that good text encoding really is research in itself — is the identification and deduplication of 50,000 of the 64,413 instances of names in the diary.[22] In Figure 9, they are mostly given as their surnames, but even “A A” is identified and points directly to the website’s ALD02.html file where information about Amelia (Opie) Alderson and her 119 appearances in the diary is provided. Arguably, the data should have pointed to the underlying XML file (ALD02.xml) but this file URI was provided as part of the transformation to pure TEI for the website as a processing convenience. Similarly, the decision was taken early on that when a person’s name was mentioned as a venue where a meeting took place, the encoders would denote this distinction for various project needs, by embedding a <placeName> of @type “venue” inside the <persName> content. While this might have made more sense the other way around (a place name which had a personal name as its content rather than a personal name that had a place name as its content), this method was chosen for consistency with other decisions on the project.

The display of the diary entries themselves is as running text based on calendar entries. One can view a single day, a particular month (as in Figure 10), or a whole year at a time, all extracted dynamically from the underlying XML year file. Clicking on the year, month, or day in the accompanying calendar provides an easy form of date-based navigation for users. All of the transformations are done dynamically, converting underlying XML with XSLT to HTML for display. However, in some cases the query to discover, extract, and then convert the XML took so long that pre-cached static copies of the XML were created.[23] As one can tell from Figure 10, almost all the content of the diary entries links to more information. Any mention of people, places, meals, meetings, texts Godwin was reading or writing, topics discussed, or events links to more information about that named entity. In the display of the website, jQuery is used to toggle on/off highlighting of these to enable people to discover them more easily. If one toggles on highlighting of people, for example, then all the names of people are highlighted with a light pink box.[24] If one clicks on a name — for example, in Figure 10, the name “Johnson’s” in the “Dine at Johnson’s” in the entry for the 1 August 1797 — the name links to a page assembling not only the project-provided biographical details, editorial notes, and bibliography concerning the identified Joseph Johnson, but also an automatically-generated chart and details of all of his appearances in the diary that can be used to navigate back through the diary (Figure 11). This page includes some basic statistics, here that he was mentioned 413 times, not at home when Godwin called in 23 times, and listed as a venue 324 times. The statistics clearly indicate that Godwin called on Johnson much more than the reverse and that he also liked to host gatherings of all sorts that many attended – the data providing rich views of their interactions over the course of Godwin‘s life. Through such techniques, the site navigation still creates a richly encoded endless loop of exploration for researchers over a decade later, as noted by Thomas:

Part of the intent behind the site’s extensive interlinking is to allow readers to navigate the diary in any order that they choose, permitting a type of exploration that facilitates serendipitous insights (and, for enthusiasts, affords the simple amusement of searching for whatever the author was doing on any given day). [Thomas 2018, 603]

Another direction of travel from the diary pages is to click on the thumbnail for that week’s page image. As part of the agreement in receiving funding to purchase the Abinger Collection, the Bodleian Library imaged all of Godwin’s diary. The project PI decided strongly against the facing-page Text/Image that is common in many digital scholarly editions. Instead, he wished to privilege the edited text, only providing links to the images as thumbnail images that are placed alongside each page of text as a way of making these linked resources available. However, linking through to these images has proved very useful to those undertaking Godwin studies who now routinely include snippets of them in their slides and articles.

The images were taken and tiled, and a pan/zoom image viewer was built using the Google Maps API, long before collaborations such as IIIF were available (Figure 12). Today, a project would simply embed a IIIF viewer for the digitized images that the Bodleian makes available on its Digital Bodleian website, even though doing so introduces a dependence on an external service. Indeed, one of the reasons the images proved so popular with researchers was not the easy interface, but the fact that we provided a link to the full high-resolution image and had (after much effort) convinced the Bodleian to license the images with a Creative Commons Attribution license. With this full image, researchers could crop the portions they were discussing and use them in their conference presentation slides. However, the necessity of having both the full high-resolution image and pre-generated tiles for each of the page images at each level of magnification added significantly to the size of the virtual machine to be requested, which in turn may be partly why it was only reluctantly hosted by the Bodleian Library. For a project following the Endings Principles, there is a calculation to be done concerning any additional storage costs for hosting its images locally versus the fragility of pointing to an external institutional image server.

The project ran successfully and completed on time and budget in 2010, and in 2012 won an award for Digital Resources from the British Society for Eighteenth-Century Studies.[25] Shortly afterwards, the DPhil student assistants completed their theses, and the postdoctoral research associate moved on to another university, and within a few years the PI of the project moved on to the University of Warwick. The project Twitter account continued to tweet out diary entries every few hours (until a Twitter authentication change meant the script started to fail). Nevertheless, although the project was over, the website continued to function, relatively unproblematically. And yet, one of the aspects of hosting that was problematic with the William Godwin’s Diary project was the question of where institutionally the website was to be hosted. As the Bodleian Libraries did not yet have a centralized media server (now https://digital.bodleian.ox.ac.uk/), and the images were hosted locally on the virtual machine (VM) that housed the website, the VM would need to survive with all it needed, but this need meant a fairly large (for the time) VM. The availability of resources always affects projects’ afterlives.

One of the reasons for mentioning (above) the sources of funding for the Bodleian’s purchase of the rest of these (and other) materials of the Abinger Collection was that as part of the purchase agreement the library had promised that web hosting for this project, like the imaging, would be provided pro bono. At the beginning I brought together representatives of the project with those from Bodleian Digital Library Systems and Services, who agreed to provide a suitable VM inside the Bodleian Libraries’ infrastructure. When it came to it, however, since I was the sole technical developer on the website and happened to work for the Oxford University Computing Services (OUCS), the Bodleian decided that I should just set up a VM in Computing Services, and that they would transfer it over to their infrastructure at the end of the project. At the conclusion of the project, the Bodleian then made the argument that the OUCS VM was working well, and so even though it had a Bodleian URL there was no pressing reason to move the underlying VM to their infrastructure. It was only several years later, when the Computing Services (by then IT Services) and Bodleian Library were both having major upgrades to their VM infrastructure, that I finally convinced them that the VM should be moved under the Bodleian Library’s care. The operating system itself was updated to the latest long-term support version, but as I had only limited time to donate to the project, the version of eXist-db (now quite ancient) was not upgraded and just copied across. Even so, the VM remains one of those VMs on an older infrastructure on the outskirts of the purview of Bodleian’s overworked infrastructure team.[26] As it is, the website occasionally needs a restart; when the VM is rebooted, the website does not automatically start, and occasionally a small partition fills up with log files.[27] Both of these are problems that would have been addressable while I had access to the server, but in an immediately post-project setting, it never seemed important enough to ensure such access. While I would restart the website maybe once or twice a year while working there, I have had no local access to the server since I left the University of Oxford in 2017; as there is no one connected to the original project left at the institution, restarting falls to the busy infrastructure team of the Bodleian Library. This need to care for legacy websites and their compounding maintenance burden will become only more pressing as we continue to produce digital projects that are deemed too important to just “turn off” after a discrete period.

It may sound as though I am faulting the Bodleian Libraries, and especially the Bodleian Digital Library Systems and Services section, for not providing a VM at the beginning of the project as they had promised to do. And while they should have done so and enabled development or at the very least a production server to be hosted on their infrastructure, I certainly have sympathy for their point of view. Before the start of the project, the upper levels of the library administration committed them to providing support from system administrators but without providing any extra resources to the staff to enable this additional work. The necessary imaging of materials was provided, pro bono, and they promised to host the website but, when the development of the website had finished, hosting was understandably not a priority task for them. If I had been working directly for the Department of Politics and International Relations (where the project originated) and had not had sophisticated local IT resources at the time, then there would have been no question that the Bodleian would have provided the necessary infrastructure — the project would have been impossible without it. However, I happened to work for the Oxford University Computing Services, and so I had easy access to VMs and it seemed natural to them that I should provide these at no extra cost or immediate effort from them. This kind of approach is dangerous, and projects should be sure to get formal agreements of in-kind support where feasible.

This project relied on a single developer (me) to provide some degree of unpaid support long after the project had finished. This is why the Endings Principles are so important – they encourage discussion of the project afterlife. In the case of the William Godwin’s Diary project, the project team gave little consideration to what would happen to the site after it was handed over to the Bodleian. Much like a physical output such as a book, everyone seemed to think it would be handed over and that would be that. But digital research outputs are not like books; they demand care and attention, however fleeting, irregular, and inconsistent. This remains true, though to a much lesser degree, of static websites as well which at very least need servers to run on. While of course I had backups of the William Godwin’s Diary data, and it was deposited in the institutional repository, after my departure in 2017 I no longer had access to the server or Subversion repository. I only got around to uploading the underlying data and code to an open GitHub repository in November 2019.[28] I had also previously provided a full copy of the data to the Shelley-Godwin Archive at the Maryland Institute for Technology in the Humanities, who have had their own ongoing maintenance burden for the sites they create [Muñoz & Viglianti 2015].

Using freely-available but proprietary systems like the Google Maps API to build a pan/zoom image browser was always going to be a compromise.[29] The API has had major backwards-incompatible updates at least twice since the project adopted it. Indeed, I am amazed that it still works at all. There is an error message notifying the user that it cannot load Google Maps, but the message can be easily dismissed and the viewer functions as before, since all of the image tiles needed are on the local server. As I mentioned earlier, if built today the project would certainly have used the IIIF media server that the Bodleian has set up in the meantime. With archival digital image resources there is an open question on how best to interact with them and still adhere to the Endings Principles. In discussing these issues as part of the Endings Project Symposium, Martin Holmes pointed out that the use of IIIF might imply a viewer (such as Mirador) with server-side requirements and the consequent longevity problems inherent in any such software. This is true if the IIIF is hosted as part of the project website, but one could design the site so that only the remote media server’s viewer were used (embedding or merely linking to it) and if one day the images disappeared, the site could degrade gracefully, presenting only the text view. For some projects, a fine balance must be struck between treating whole remote collections of images as research objects and hosting these resources locally [Fenlon 2019]. A centralized institutional image store may make sense, especially where the same set of images may be used for multiple projects, but it needs to be carefully incorporated into the site in a manner that prepares for graceful degradation of any linked resources.[30]