Read-Only: A New Phase for Derrida's Margins

One of the cornerstone activities of the CDH has been our collaborative projects with Princeton faculty, where we partner to create customized software to advance faculty research. These partnerships open new research avenues for the faculty and result in new resources or software that enrich the humanities generally.

Along the way, we are challenged with defining endings for digital humanities projects. Whereas books or articles are “completed” at the point of publication, and the long-term maintenance of the artifact moves to the publisher and the university library, digital humanities projects are always in progress. Moreover, it’s hard to predict how researchers will continue to engage with the projects in the future, and robust digital projects with web interfaces represent a significant investment of time, intellectual labor, and money. While there is no possibility of preserving in perpetuity all digital scholarly outputs (just as not all books survive the passage of time), simply relegating projects to the digital “dustbin” by default is not sustainable or responsible.

As a digital humanities center, we are co-creators of digital projects, but typically not the primary user of the resulting digital artifact. Thus, we are in a unique place to consider the potential futures of digital projects when the original research need is completed. In the case of Derrida’s Margins, a research website that captures and displays the marginalia that Derrida wrote within the books of his library, Lead RSE Rebecca Sutton Koeser chose to create a live archive of the site. In this interview, Rebecca and I discuss the project, the decision and process of transforming the site to a “read-only” version, and what was gained and lost in the process.

JW: What is the history of Derrida’s Margins? What problem did it set out to explore/solve?

RSK: This project came out of the excitement around Princeton University Library’s acquisition of Derrida’s library and the enticing idea of understanding how his reading fed into his writing by following the evidence of the annotations in the books he quoted. Derrida annotated a lot, although quite sparsely. Verbal annotations are fairly rare, at least in the texts we were working with, but he does a lot of underlining, circling, marginal lines, arrows, etc. You can see some examples in the banner images above and below, which were created for the site by UX Designer Xinyi Li.

To make the project manageable we focused on a single seminal text: de la Grammatologie (Of Grammatology). The project team came up with a way to characterize types of references, cataloged them in the published text, and then connected them with annotations in the cited works. We later broadened the term “annotation” and called them “interventions” in order to include the odd materials Derrida inserted in his books as a different kind of commentary.

The primary outputs from this project were the web application and published datasets which we exported from the relational database. The datasets include information on the library books, the references, and the annotations related to those references. You can find a full list of outputs on the project page on the CDH website.

JW: What does it mean that the Derrida’s Margins site is now “read-only”? What has changed?

RSK: The project site was implemented as a custom Python/Django application, which runs on a server and uses a relational database (postgres) to manage content and a search index (Solr) for powerful faceted searching. All that is great if you need it, but this site hasn’t been updated in quite some time: no one is adding any new texts, references, or annotations. Keeping the code up to date and secure and all the services running has a cost, and we determined this application no longer needed to live in the same way.

We’re calling the site “read-only” at the suggestion of previous CDH UX Designer Gissoo Doroudian—she thought that would be the clearest way to communicate to users what kind of functionality they could expect. This is actually a web archive, a snapshot of the full site that we created using web recorder tools, primarily Browsertrix, before we shut it down. If you’ve ever used the Wayback Machine on The Internet Archive, it’s a similar technology. You can still browse around the site and access all of the content that was publicly available before, but you can no longer use the search and filtering capability that was powered by Solr. We left the filters somewhat visible and interactive as a window into the content on the site but disabled them visually and semantically to make it clear they’re no longer interactive.

JW: Why convert the website into this archive format? What is gained and what is lost?

RSK: DH projects like this one are scholarly outputs that should be durable and citable, but that doesn’t mean they need to keep running with the technology originally used to publish them. For anyone who has referenced content on this site(a specific book, page, or list of references),that URL will still resolve and provide the same content that was previously available,or close to it. It’s also fantastic that web archiving has come along so far and that there are readily available tools and open formats. When I first started thinking about shutting down the project, I had just imagined crawling it and converting it to a plain static site with the HTML pages and all the assets; but the site uses query parameters for paging through the listings of the different sections of the site, and we couldn’t preserve that in a purely static site, and web archiving can.

What we gain is we can shut down an old application that isn’t being maintained or used without losing the content and the beautiful, thoughtfully designed interface that was publicly available. We can put up in its place a static capture of the site that will require minimal maintenance, if any.

What we lose is the ability to use the search and filtering capability that was originally designed and built for this project, to look for specific books, references, and interventions. My hope is that the loss is mitigated by external search options and the published datasets.

JW: What did you learn in the process? How does it connect to larger questions in DH about legacy projects?

RSK: I’ve been aware of web archiving for some time but until this, I didn’t have a real reason or need to dig into it. It was fantastic to have local support; Francis Kayiwa (who used to provide DevOps support to Documenting the Now), connected me with Ilya Kreymer (the creator of WebRecorder and related tools), who was also interested in this use case and supportive of the work. I wanted to deploy a web archive at the original URL with the banner that you see on the site now because I wanted all the original URLs to resolve to the captured snapshot for that page. We were able to do this using the web archive playback tools that Ilya and his team have developed, which provide options to customize the archive site with a banner and custom styles, which we used to disable the filters that are no longer functional.

I’m excited about this as an approach for preserving projects that can no longer be maintained because I think it’s such a powerful and flexible solution. There’s been a big push in recent years for everything to be static first, due in part to work on the Endings Project and Minimal Computing —there’s a lot of valuable work there, and static site technologies are powerful and worth considering. But they don’t do everything, and we shouldn’t bend over backward to force dynamic content into a static form or reinvent wheels unnecessarily. I’m a big believer in the “use boring technology” approach of using tried and true, well-supported industry software that your team knows and meets the needs of the project. You still need to think about the lifespan and durability of any software or website you build, as well as good design principles and site architecture designs that help with accessibility and SEO, which also usually overlap and benefit long-term preservability. The maturity of the web archiving tools means there are more options for preserving web projects and having more tools benefits everyone.

We shouldn’t just be thinking about web archiving at the end, either. We have an agreement with Princeton Special Collections for our project sites to be archived, and I’ve had the privilege of partnering with the archivist who handles that to ensure that our sites are archived well and make adjustments when needed. Web archives and web recorder tools can also be used to power another cool protocol, Memento, which allows you to view a web page as it was on a particular date (depending on how often you’re capturing), which sounds useful for scholarly communication and citation.

Conclusions

Replacing the original web application with a usable archive enables the public interface and resources of the project to persist, even though the more advanced research functionality made possible by the application is no longer supported. What the CDH gained in the shift was the ability to keep the website and the URLs active, without having to maintain the complexity of the web application. While we commit to supporting web applications used for active faculty research, once that phase of the project is done, we need to assess what level of support is feasible and sustainable. The live archive enables us to sustainably continue to serve the larger research community that might use the “front-end” of the website, even as we turn off the more computationally complex back end.