Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

“The last one leaves the light on”. Static service as a key to sustainable data provision

by Moritz Schepp and Thorsten Wübbena

The headline “Everything dies, including information”, published 2022 in MIT Technology Review, still resonates today. The article states that almost every project-based third-party funded project must store its data somewhere permanently, “but there are no overarching requirements about who must store the data or how long it must be saved.” While robust solutions exist for static data publications, the challenge of sustainability still applies to living systems, such as databases developed in our DH projects. And as Huculak and Davis (2024) so simply and accurately described: “Databases need periodic upgrading, which can break entire applications.” Consequently, one principle from the “Endings Principles for Digital Longevity” is: “No dependence on server-side software: build a static website with no databases, no PHP, no Python.” Yet, principles often falter when confronted with the realities of project implementation — and justifiably so. DH research often requires active, dynamic databases to function effectively. We feel that projects should have access to the best of both worlds here. In advancing our database system “ConedaKOR”, we reconciled the functions of a living database during the project period with a minimal computing approach and a “static version” for the long-term provision.

The database system

ConedaKOR arose from the need for software that can manage visual objects of cultural heritage and, in doing so, can map the added value of information—which is rarely contained in the pure quantity of data, but rather in the networked relationships. To accomplish this task, we decided to give the data curator the ability to create and customize a graph structure and populate it with data via a simple web interface. The open-source database system has been developed over several years in close collaboration with multiple research projects and takes into account various key developments from different periods: Knowledge graph data model, API-based services, collaborative editing environment, Wikidata integration etc.1
While the data model ConedaKOR presents to the user is graph-shaped, the backend operates only widely supported and established components such as a relational database. This leads to simplified maintenance, which is a major advantage when hosting in university data centers.2 Beyond its use as a database system with its own user interface, there are also use cases that allow ConedaKOR to appear as a powerful interface tool (including OAI-PMH harvester/repository and JSON REST) in the backend.3 The introduction of a software-as-a-service model as part of the DARIAH-DE infrastructure was an important step toward low-threshold use of ConedaKOR and, in this form, has been used for several years, for example, by the academic project “Text database and dictionary of classic Mayan” to manage and make its extensive image collection freely available.

The challenge

The use of ConedaKOR in various research projects in recent years has shown that the time-limited nature of the projects poses a major challenge for the sustainable operation and provision of a powerful database system and its contents. Small research institutions, which have become increasingly involved in digital projects in recent years, face particular challenges, especially when preservation and the digital provisioning of their assets are not part of their core activities. And so, with the expiry of funding, most institutes (in view of tight budgets) find it virtually impossible to maintain a dynamic database system with its infrastructural requirements on a permanent basis. Temporary projects with limited resources but a keen interest in the afterlife of their data must address this situation proactively from the outset on.

For web based systems, one approach to meeting this challenge is a controlled transformation or “graceful degradation” to a static format. We have now chosen this path and implemented this transformation as a software feature. Starting with version 5.1.0, ConedaKOR now has an integrated static mode that enables seamless conversion without compromising data nor content. This means efficient data provisioning, elimination of software dependencies and reduced resource consumption.

Design and implementation of the static mode

Since around 2016, under the hood, ConedaKOR actually consists of two pieces of software in one: A frontend and a backend: While the backend (based on Ruby on Rails) deals with the database interaction, indexed search and asset transformations, the frontend takes care of the layer interacting with the user while communicating with the backend through its JSON api.
When we considered implementing this separation, we knew that it would be a substantial amount of work. Nevertheless, we felt that it was still worth it, because the separation would make it a lot easier for us to develop future features, since many changes would require modifications only to the frontend or backend, but not to both. Also, some of the functionality built in the frontend would run entirely on the user’s workstation and we expected the overall user experience to be more snappy.
So we went ahead with the transformation and we never regretted the decision: The static mode introduced in v5.1.0 is only the most recent example: Since the frontend was already effectively static, we just needed to store all JSON API responses in JSON files and write a small glue layer in the frontend to transform this data back into reasonable JSON API responses that the existing frontend can consume. Here is a diagram:

ConedaKOR, schematic illustration
ConedaKOR, schematic illustration

Since no database is available in static mode, some basic functionality had to be replaced. First, the client must run the entire search logic. To enable this, we used a small summary JSON file that contains only the searchable data. Tests with clients showed remarkable speed and overall performance, even on mobile devices.4 As expected, our tests showed that performance in static mode is even better than in non-static mode, even with hundreds of thousands of records.
Another common feature in complex database systems that cannot be provided on static websites is comprehensive rights management. Therefore, the static version of ConedaKOR is created from the perspective of a defined user and their permissions, enabling rights-based and fine-grained selection of publishable content and/or multiple environments. APIs such as ConedaKOR’s OAI-PMH are not available in static mode, but as an API used mostly for archival, it becomes largely redundant if harvesting is done just before enabling static mode.
At last, we made sure to include reversibility as a key part of the implementation: as long as all dependencies remain available, the static JSON files can simply be removed and the frontend will once again use the server-supported JSON API, the complete ConedaKOR application can be restored to its dynamic form.

By proactively integrating static degradation into the software development phase, ConedaKOR enables a strategic reallocation of resources—from reactive, post-project maintenance to proactive, funded project activities. This enables compliance with the aforementioned “Endings Principles for Digital Longevity” without having to forego necessary dynamic functions in the peak phase of the project. In essence, integrating static degradation is not a compromise but a strategic innovation—transforming digital longevity from a post-project afterthought into the core of software design. This principle enables researchers, developers, and institutions to build digital projects that are not only impactful in the short term but also responsible, resilient, and meaningful in the long term. We also followed our own principles in curating institutional legacy data collections: minimalized tech stacks, separated GUI and data layers, allowing intermediated infrastructure, and finally: additional investment as our developments were only possible thanks to funding from NFDI4Culture.

Bibliography

  • Huculak, John Matthew and Corey Davis. Preserving Digital Humanities Projects Using Principles of Digital Longevity, in: Russell, I.G., & Layne-Worthey, G. (Eds.). (2024). The Routledge Companion to Libraries, Archives, and the Digital Humanities (1st ed.). Routledge. https://doi.org/10.4324/9781003327738
  • Klammt, Anne, Moritz Schepp, Deborah Schlauch, and Thorsten Wübbena. ConedaKOR Tutorials. TIB AV-Portal, 2022. https://av.tib.eu/series/1367.
  • Nasarek, Robert and Lozana Rossenova. Linked Open Data Management Services: A Comparison (1.0.0) [Data set]. DHd2023 Open Humanities Open Culture (DHd2023), Trier and Luxembourg. Zenodo. https://doi.org/10.5281/zenodo.7738424
  • Nowviskie, Bethany, and Dot Porter. Graceful Degradation: Managing Digital Projects in Times of Transition and Decline. Paper presented at ADHO 2009 – UMD College Park. 2009. https://dh-abstracts.library.cmu.edu/works/1099.
  • Schepp, Moritz, Thorsten Wübbena, Ivan Fraixedes, and Zuoyue Li. ConedaKOR: V5.0.1. Zenodo, released December 09, 2025. https://doi.org/10.5281/zenodo.17863555

Featured Image: Geisel Library at UC San Diego (detail), sarahmirk, Geisel Library at UCSD, CC BY 4.0

  1. In 2023, Lozana Rossanova and Robert Nasarek conducted a comparison of database systems from the perspective of Linked Open Data (LOD), including Omeka S, WissKI, and ConedaKOR, among others. []
  2. For instructions on setting up ConedaKOR, have a look the video tutorials or the documentation overview. []
  3. As was the case, for example, in the Sandrart.net project. []
  4. Tests with ~300,000 data sets and a Pixel 4a smartphone delivered search results in significantly less than a second. []
Thorsten Wübbena
Thorsten Wübbena

Nur der Text ist unter der Lizenz Creative Commons Namensnennung 4.0 International nutzbar. Alle anderen Elemente (Abbildungen, importierte Anhänge) sind „Alle Rechte vorbehalten“, sofern nicht anders angegeben.


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Thorsten Wübbena, Moritz Schepp (20. Februar 2026). “The last one leaves the light on”. Static service as a key to sustainable data provision. DH Lab. Abgerufen am 5. Juni 2026 von https://doi.org/10.58079/15qle


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

This site uses Akismet to reduce spam. Learn how your comment data is processed.