DH 2026

Daejeon, July 27–31

Wed, July 2916:30–18:00S048106
Short Paper

Self-degradation as a Software Design Principle: How an Integrated Static Mode Sustains ConedaKOR as an Information Infrastructure

Fabian Cremer
Leibniz Institute of European History (IEG) in Mainz, Germany · mail@fabiancremer.de
Moritz Schepp
Wendig OÜ · info@wendig.io
Thorsten Wübbena
Leibniz Institute of European History (IEG) in Mainz, Germany · wuebbena@ieg-mainz.de

Sustaining online databases and web-based information systems in the DH

Since the early days of Digital Humanities, data collections stored in online databases have become a preferred scholarly output format; however, their innovative research potential is overshadowed by issues related to long-term preservation (John Unsworth 2000; Cohen and Rosenzweig 2006). Sustaining complex digital resources, especially web-based information systems, has recently become a rising topic in the DH (Meneses and Furuta 2019; Miller and Taylor-Poleskey 2020; Tucker 2022; VandeCreek 2024). In the following use-case, the long-term provision is directly addressed in the software design. The proposed solution is a controlled transformation, or “graceful degradation” (Nowviskie and Porter 2009), as a static site, implemented as a software feature. This approach enables the software to adapt to changing circumstances, such as the end of a research project, without compromising the integrity of the data.

ConedaKOR: developing a sustainable cultural heritage software

ConedaKOR is a graph-based database system for cultural heritage objects, developed since 2009 in collaboration with multiple research projects (Schepp et al. 2025), available as open-source software. Renowned national and international academic institutions have been working with ConedaKOR for years, relying on it for the professional management of data and media (Wübbena 2020). In addition to research institutions, ConedaKOR is particularly suited to university departments that manage items containing visual media and wish to make these accessible to academics and students.

The Institute of Art History at Goethe University Frankfurt, for example, operates a ConedaKOR installation containing around 350,000 entities (including approximately 160,000 images and 650,000 relations) and enables around 1,000 users to carry out comprehensive research for teaching and research purposes.

It incorporates trends from DH at different times: knowledge graph data model, API-based services, collaborative editing environment, etc. The usage of standard web and database technologies, such as a relational database implementing the graph-data-model, enabled easier maintenance when hosted in university computing centres (Klammt et al. 2022). The later introduction of a Software-as-a-Service-model as part of disciplinary infrastructure (DARIAH-DE) were important steps towards easier operation. But still, the experiences have shown that for research projects with limited resources, the long-term operation of a server-based system poses a major challenge. A common curation measure for many legacy websites is the creation of static versions, usually accomplished with web crawlers. Since we consider this static stage to be integral to the life cycle, ConedaKOR now features an integrated static mode, allowing for a seamless conversion without compromising data, content, or user experience.

Latest static version: https://github.com/coneda/kor/tree/static.

Design and Implementation of the static mode

ConedaKOR has separated layers for data and interface. The server-based backend kept its tried and tested Ruby on Rails setup, the frontend and its logic were entirely moved to the client. This has become a popular approach for separating concerns in the code base and to leverage increasing computing capacity available on clients. Built on this “API-first-approach”, the static environment could be implemented by saving JSON-responses to JSON-files, which the frontend could load instead of the JSON-API (Fig 1.). An implemented thin glue layer in the frontend loads these files and reshapes the data to work well with the client.

Figure 1: Overview of the final structure.

Since, in static mode, no database is available, some common features have to be replaced. First, the client has to run all the search workload. To enable this, we used a small summary JSON-file with only the searchable data included. Test with clients proved remarkable speed and overall performance even on mobile devices. In general, our tests have shown that static mode performance is even better than non-static mode performance, even with hundreds of thousands of records.

Tests with ~300k records and a Pixel 4a phone delivered search results in less than a second. The specific performance is ultimately limited by the client's compute power and its network connectivity. Several users confirmed that the reaction time feels considerably better in static mode, but the tests do not reflect controlled measurements. In the future, a set of benchmark tests would be beneficial in order to gauge the performance impact of ConedaKOR's static mode.

Another common feature in complex database systems which cannot be provided in static websites is an extensive rights management. Therefore, ConedaKOR’s static build is created from the view point of a specific user and their permissions, which enables a rights-based and fine-grained selection of publishable content and/or multiple environments. APIs like ConedaKOR’s OAI-PMH are not available in static mode, but become dispensable if the harvesting is done before entering static mode. Finally, this approach makes it possible to revert back to a non-static mode: Given that all dependencies are still available, the static JSON files can simply be removed and the frontend will use the JSON API again.

The benefits of a static mode and its potentials as a design principle

Overall, this leads to a time saving maintenance, cost efficient data provision, and reduced consumption of environmental resources. By integrating a static degradation into the software development phase, it shifts curation resources into the funding period of a project. It enables compliance with the “Endings Principles for Digital Longevity” (Matthew Huculak and Davis 2024) without having to forego important functions at the height of the project. In summary, several facets of sustainability are considered, as described by Tucker (2022): technological, financial, environmental, and “human” aspects. Furthermore, a key feature of the implementation is the reversibility: Once resources are available again, one can rebuild the full application from its static conversion.

The implementation of a static web application from the very beginning offers a sustainable and powerful option for some projects, but cannot cover all situations (Wikle and Williamson 2025). The use cases of ConedaKOR’s confirm its scope of application: collaborative projects whose core tasks include the collection, cataloging and presentation of (image) data and which have the staffing, resources, and project duration that make the use of a complex database system both necessary and feasible. Conversely, this also means that small, short-term, or resource-constrained projects should refrain from using this type of software. Hence, if a collaborative editing environment for a flexible data model that implements large ontologies remains a requirement for a collaborative project, then there is no substitute for a database system like ConedaKOR. However, such a database system can follow principles of Minimal Computing (Risam and Gil 2022) in the operation phase by disconnecting the components for editing the data and extending the data model. An important aspect is the provision of the (original) user interface – another requirement in the humanities, for pragmatic reasons of broad accessibility and inclusiveness as well as the shared methodological foundation in the humanities, to provide an interface to information (Drucker 2011). The ConedaKOR case study shows that it is possible to incorporate a sustainability measure, which normally would only be carried out after the end of a project as data curation, into the project (or software development) phase. However, in this particular case, the development of this feature was only made possible by dedicated funding for the sustainability of research software, which underscores the need for such programs.

ConedaKOR-StatServ was funded by NFDI4Culture, the German national consortium for research data on material and immaterial cultural heritage.

References
  1. Cohen, Daniel J. / Rosenzweig, Roy (2006): 2006. Digital History. Philadelphia : Univ. of Pennsylvania Press.
  2. Drucker, Johanna (2011): “Humanities Approaches to Interface Theory.” Culture Machine 12.
  3. Unsworth, John (2000): “Thematic Research Collections”, Washington, DC, December https://johnunsworth.name/MLA.00/ [06.05.2026].
  4. Klammt, Anne / Schepp, Moritz / Schlauch, Deborah / Wübbena, Thorsten (2022): ConedaKOR Tutorials. TIB AV-Portal. https://av.tib.eu/series/1367.
  5. Huculak, Matthew J. / Davis, Corey (2024): “Preserving Digital Humanities Projects Using Principles of Digital Longevity.” In The Routledge Companion to Libraries, Archives, and the Digital Humanities, 1st ed., edited by Isabel Galina Russell and Glen Layne-Worthey. Routledge. https://doi.org/10.4324/9781003327738-22.
  6. Meneses, Luis / Furuta, Richard (2019): “Shelf Life: Identifying the Abandonment of Online Digital Humanities Projects.” Digital Scholarship in the Humanities 34 (Supplement_1): i129–34. https://doi.org/10.1093/llc/fqy079.
  7. Miller, A. / Taylor-Poleskey, Molly (2020): “Digital Humanities Preservation. A Conversation for Developing Sustainable Digital Projects.” In Balkun, Mary McAleer / Deyrup, Marta Mestrovic (eds.): Transformative Digital Humanities: Challenges and Opportunities, 1st ed. London: Routledge. https://doi.org/10.4324/9780429399923.
  8. Nowviskie, Bethany / Porter, Dot (2009): “Graceful Degradation: Managing Digital Projects in Times of Transition and Decline” https://dh-abstracts.library.cmu.edu/works/1099 [06.05.2026].
  9. Risam, Roopika / Gil, Alex (2022): “Introduction: The Questions of Minimal Computing”, in: Digital Humanities Quarterly 16, 2 http://www.digitalhumanities.org/dhq/vol/16/2/000646/000646.html [06.05.2026].
  10. Schepp, Moritz / Wübbena, Thorsten / Park, Yohan / Fraixedes, Ivan / Li, Zuoyue (2025): Coneda/Kor: V5.0.1. Zenodo. https://doi.org/10.5281/zenodo.17863555.
  11. Tucker, Joanna (2022): “Facing the Challenge of Digital Sustainability as Humanities Researchers.” Journal of the British Academy 10: 93–120. https://doi.org/10.5871/jba/010.093.
  12. VandeCreek, Drew (2024): “Great Lengths: A Review of Website Preservation Activities at Three American Universities with Digital Humanities Centers.” Digital Scholarship in the Humanities 39 (1): 409–22. https://doi.org/10.1093/llc/fqad080.
  13. Wikle, Olivia / Williamson, Evan Peter (2025): “Static Web Methodology as a Sustainable Approach to Digital Humanities Projects.” The Code4Lib Journal, no. 60 (April). https://journal.code4lib.org/articles/18372.
  14. Wübbena, Thorsten (2020): “Von Warburg zu Wikidata – Vernetzung und Interoperabilität kunsthistorischer Datenbanksysteme am Beispiel von ConedaKOR”. In: Bilddaten in den Digitalen Geisteswissenschaften, edited by C. Hastik and Ph. Hegel, Wiesbaden: Harrassowitz, pp. 133–148, https://www.doi.org/10.13173/9783447114608.