13:00–13:15

Welcome and Introduction

13:15–14:45

Beginners’ Training Session I: From Dramatic Text to DraCor TEI

Tutors: Julia Jennifer Beine and Aşina Aleyna Yıldız (both Würzburg)

14:45–15:15

Coffee Break

15:15–16:45

Beginners’ Training Session II: Analyses with DraCor Data

Tutor: Frank Fischer (Berlin)

16:45–17:15

Coffee Break

17:15–18:45

Opening Keynote

19:30

Informal Dinner

Tuesday, 8 September 2026

09:00–10:30

State of the Art: Women Playwrights in Digital Corpora
Speaker 1: Anna Axtner-Borsutzky
Speaker 2: TBA
Speaker 3: TBA

10:30–11:00

Coffee Break

11:00–12:30

Collaborative Working Session I

12:30–13:30

Lunch Break

13:30–15:00

Collaborative Working Session II

15:00–15:30

Coffee Break

15:30–17:00

Battle of the Plays World Championship 2026

Moderators: Frank Fischer and Antonio Rojas Castro (both Berlin)

Wednesday, 9 September 2026

09:00–10:30

Collaborative Working Session III

10:30–11:00

Coffee Break

11:00–12:00

Round Table Discussion

12:00–12:30

Closing Remarks

Heidelberg University is a comprehensive university with a strong focus on research and international standards. With around 32,200 students and 9,540 employees, including numerous top researchers, it is a globally respected institution that also has outstanding economic significance for the Rhine-Neckar metropolitan region.

The Heidelberg Center for Digital Humanities is one of Germany′s leading institutions in the fields of digital and computational humanities. Its key areas of focus are digital linguistics, digital heritage, and AI/machine learning. Thanks to its close ties with the Interdisciplinary Center for Scientific Computing (IWR), the HCDH pursues the computational humanities with particular intensity.

The Research Data Engineer full-time position (E13, 100%) for a term of 4 years, with the option to extend is available at the Heidelberg Center for Digital Humanities (HCDH) starting December 1, 2026 (or earliest possible).

Your responsibilities:

• Bridging the gap between cultural heritage data and advanced computational research: Design and build data storage layers and data processing pipelines that enable our humanities researchers to create and analyze massive, heterogeneous datasets (including legacy data)—ranging from historical texts and archives to multimedia, 3D and spatial data
• Research Collaboration: Act as the technical consultant for humanities scholars, translating complex research questions into viable computational and database requirements
• Data Pipelines: Design, implement, and maintain scalable pipelines to ingest, clean, and harmonize diverse cultural heritage and other data and create interoperable datasets for research
• Data architecture: Design, implement, and maintain data structures and connect to existing data storage layers and infrastructure
• Semantic Web & Knowledge Graphs: Develop and optimize graph databases, ontologies, and semantic models (e.g., using RDF, OWL, CIDOC-CRM) to interconnect complex historical and cultural data
• Tool Development & Automation: Build custom APIs, and scripts (primarily in Python) to automate data ingestion, text-mining, and natural language processing (NLP) workflows
• FAIR and FAIR4RS principles: Collaborate with the Research Data Unit and Scientific Software Center and its Data Science Unit at the IWR, and the University Computing Centre (HPC and storage infrastructure)

Your profile:

• Education & Background: Preferably a PhD, but MA/MSc are encouraged to apply
• Soft Skills: Strong communication skills to effectively collaborate across interdisciplinary teams of software engineers and traditional humanities scholars
• Core Tech Stack: Excellent knowledge of Python (plus libraries like Open3D, Pandas, SpaCy, or NLTK) and version control using Git, experience with Rust and/or PyTorch is a plus
• Database & Semantic Web Skills: Strong experience with databases (e.g., Neo4j, GraphDB, NoSQL, SQL) and semantic web technologies (e.g., SPARQL, JSON-LD)
• DH Standards: Ideally knowledge of text encoding standards (e.g., TEI-XML) and metadata schemas (e.g., Dublin Core, MODS, LIDO); desirable: Experience with working with humanities’ data
• Independent and structured work style, ability to work in teams and to fixed timelines
• Language requirements: Very good English language skills, desirable: basic German skills

We offer:

• The opportunity to work at the cutting edge of digital and computational humanities using modern AI and data engineering methods
• Work in an innovative environment with the opportunity of professional training and qualification in the emerging professional field of research data engineering
• A highly collaborative, interdisciplinary, and international research environment
• Support for active contributions to the Open Source and Digital Humanities communities
• Excellent opportunities for independent research and further academic training
• Flexible working hours and a good work-life balance; part-time remote work is possible
• Opportunity for further training and building a professional network by participating in national and international conferences
• A dedicated team that supports each other
• Workplace in the very Center of Heidelberg Altstadt with good public transport
• Access to university sports offers
• Support for employee mobility through a subsidized Deutschlandticket

The position is a 4-year fixed-term position with the possibility of extension. Remuneration is based on the TV-L collective agreement (pay group 13). The position is suitable for job-sharing.

We look forward to receiving your application (in English), including the following documents: cover letter, CV including a project list, proof of academic degree, employment references and list of references (2-3 names and contact details), by 14 September 2026, sent to as a single PDF file via email to nele.schneidereit@uni-heidelberg.de (max. of 25 MB).

There will be a two-stage process, with online interviews taking place in the first half of October. We will invite the remaining candidates to an in-person interview on October 23. Please save the date.

Heidelberg University stands for equal opportunities and diversity. Qualified female candidates are especially invited to apply. People with severe disabilities will be given preference if they are equally qualified. Information on job advertisements and the collection of personal data is available at www.uni-heidelberg.de/en/job-market.

Have you been meaning to set up an appointment to ask about research data management for your project, an aspect of your research workflow, or a specific DH tool or method? Visit one of our drop-in sessions and we will help you on the spot! No need to make an appointment!

The sessions are designed to support researchers, students, and staff members in all areas of digital scholarship. The initiative is a collaboration between Artes Research, DH-support staff and researchers at the Faculty of Arts, and ICTS at the Faculty of Arts.

Don’t have a question about any of the above but want to learn more about DH? No problem! Come and use our space for co-working! It’s a great moment to develop digital skills by starting a Programming Historian tutorial, for instance!

Everyone is welcome to attend, you do not need to register!

Stop by on one of the following dates and we will be glad to help you:

• 24/09/2026: 13:30h -15:30h, Het Salon LETT 00.24, Erasmushuis
• 22/10/2026: 13:30h -15:30h, Het Salon LETT 00.24, Erasmushuis
• 10/11/2026: 13:30h -15:30h, Het Salon LETT 00.24, Erasmushuis
• 10/12/2026: 13:30h -15:30h, Het Salon LETT 00.24, Erasmushuis

When I first read Kenny Werner’s book Effortless Mastery: Liberating the Master Musician Within, I was in college studying jazz improvisation and musical performance. At the time, the book was powerful and transformative for its approach to thinking through performance anxiety and imposter syndrome— things I still struggle with in relation to musical performance. Recent conversations about GenAI and digital humanities left me wanting to revisit Werner’s approach to thinking through craft and difficulty.

The central conceit for Effortless Mastery is this: the degree to which we care about an activity can get in the way of our ability to do it. When we care deeply about doing something well, about performing at a high level, this sincere anxiety and the tension that follows interfere with our ability to prepare for the excellence we want to achieve. Approaching our craft with this heightened sense of the stakes reinforces a fraught relationship to our craft that comes out in practice, play, and performance. Effortless Mastery is about choosing a different path, centering mindfulness in our craft in a way that can be practiced. In the prototypical Effortless Mastery exercise, one sits at the piano and only practices a single note for 5-10 minutes a day. The goal is to approach this isolated note with such intention and care that it becomes effortless. Let your finger, in a childlike way, press down on a key with as little tension as possible. Only add new notes when the first one has become the most perfect and effortless thing that it could possibly be. According to Werner, performers will likely find this approach to practice excruciating. We feel like we have too much material to learn. Too much to do—not enough time. But Werner argues that, if approached diligently, his form of practice will actually pay dividends and elevate all parts of our performance. Our relationship to our instrument and to music will improve, and we will find it easier to enter a heightened state of flow and bliss as we perform. There are also affirmations that focus on changing the way you relate to the instrument.

I’m interested in how we can apply the same kind of approach to the work that we do in the academy. In some ways, the concept of effortless practice cuts against the way I tend to teach and write about DH. I’ve argued in the past that frustration is a feature for DH students. Learning is hard in a way that we can’t avoid, and we have to teach students how to live with these challenging emotions. But lately I’ve been thinking about how perception of difficulty can get in the way of our pedagogies, particularly as we all try to reckon with the impact of GenAI on our teaching. When a humanist sits down to learn something new, it can be easy to reach for GenAI as soon as they start to feel frustrated. Is it useful for them to sidestep challenging emotions? Would we rather they sit with the difficulty longer? How do we help students shift their own understanding of what is difficult and what is not? Finally, to talk back to myself, how might it change the possibilities students see for themselves if we framed DH instead as a space of effortlessness rather than one of frustration and difficulty?

The domains are different—how many of us would describe our DH work as a space of artistic bliss? But I still think there can be utility in thinking through the shape of an effortless digital humanities. What is the DH equivalent of putting your finger to a single note? What are the building blocks for all other digital humanities work? And how might we practice these techniques daily in 10 minutes to promote an effortless approach to doing so? To begin answering these questions for myself, I sat down at my laptop and mapped out how this sequence might work in my classroom. In what follows, I map out a way you might extrapolate this kind of approach over the course of a sixteen-week semester, slowly building up a daily practice in the spirit of developing an effortless digital humanities. Try it with your students and let me know how it goes.

Terminal

One of the first things I do when sitting down for DH work is open my terminal, so this is where my daily practice begins. The terminal is an essential tool for so many other DH activities, but it adds a layer of abstraction to learning that can take a while for students to overcome. Here are some ideas for playing one note on the terminal each day. Under each week I describe a sequence of activities meant to be performed daily, early each morning, in about 10 minutes. Each new week adds one or two new elements to the repeated sequence. Only advance to a new week when you feel you can perform the previous week with complete effortlessness. Feel free to repeat weeks. Better to go slow. And be sure to include (or adapt!) the light affirmations that I include. Our primary statement will be one directly from Werner’s text: “It is not hard, it is just unfamiliar.” A few caveats: in what follows, unless otherwise specified, code blocks represent lines that should be entered into the terminal. Throughout this post I am sharing MacOS terminal commands. Programming Historian has some useful lessons for those looking to adapt these for Windows. And, finally, things will, by design, become very repetitive. It is quite possible I will leave out a step while copying things over. Let me know if you find such a thing and I will edit accordingly.

• Week 1:
  • Open the terminal. Say, “I have opened my terminal. It is not hard, it is just unfamiliar.”
• Week 2:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say “I am currently in my user folder. It is not hard, it is just unfamiliar.”
• Week 3:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop. It is not hard, it is just unfamiliar.”
• Week 4:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop. It is not hard, it is just unfamiliar.”
• Week 5:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 6:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”

For many experienced DH practitioners, these steps would take maybe 10 seconds. But if you’re new to the terminal entirely each of these things could take quite a bit longer and cause a great deal of anxiety. Encourage students to move slowly, repeating each week’s steps regularly moving on to the next step. After several weeks, hopefully, they will feel a greater sense of comfort with the idea of what the terminal is, where to find it, and how to use it. Working incrementally in this way can take something from challenging to rote practice.

Git

Version control systems seem especially good for this kind of regular work. Git and GitHub are tools that students often find very difficult to conceptualize and master, but 90% of what you need to do can be handled by the same set of steps. Perhaps by making Git practice an everyday routine we can make more room for understanding the concepts. The next several weeks will build on the previous terminal sequence.

• Week 7:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 8:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 9:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Add your new file to your git staging area with git add index.html. Say, “I have added my file to staging.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”
• Week 10:
  • Open the terminal. Say, “I have opened my terminal.”
  • Print out your current directory with pwd. Say, “I am currently in my user folder.”
  • Change to your Desktop with cd Desktop. Confirm you are in your desktop with pwd. Say, “I have changed to my Desktop.”
  • List out the contents of your desktop with ls. Say, “I am looking at the contents of my desktop.”
  • Make a new folder with mkdir test_folder. Say, “I have made a new folder.”
  • Change into the new folder with cd test_folder. Say, “I have changed into my new folder called test_folder.”
  • Make this folder a git repository with git init. Say, “I have made this folder into a git repository.”
  • Make a few file in your folder with touch index.html. Say, “I have made a new html file.”
  • Confirm you have a new file to add in git with git status. Say, “I have shown that git acknowledges the new file.”
  • Add your new file to your git staging area with git add index.html. Say, “I have added my file to staging.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Commit your new file with git commit -m 'My first commit. Say, “I am committing my new file to git.”
  • Confirm you added the file successfully with git status. Say, “Git status shows that I did this successfully.”
  • Return to your desktop with cd ... Say, “I have returned to my desktop.”
  • Clean up your workspace by deleting the folder with rm -rf test_folder. Say, “I have deleted the new folder. It is not hard, it is just unfamiliar.”

At this point, I might have students continue to repeat these steps for several weeks. Again, an experienced practitioner could do this in no time at all. Newcomers will find this to be quite a lot. At some point, after enough days have gone by, things might start to get annoying. Good! You’re experiencing effortlessness. Only add new steps when you feel like what you have done so far is effortless. Remember: it is not hard, it is just unfamiliar.

Building a basic website

At this point, my bulleted list is getting overly complicated, so I’ll simplify things going forward by using shorthand and sandwiching the new steps inside of a “set up” and “clean up” phase. Refer above for the associated commands. It is probably clear where I am going at this stage: I think designing a basic website and understanding how to view it on your computer is another foundational DH skill. And we can make this sequence a very light daily activity.

• Week 11:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Add a new line inside your index.html file that says, “This is a basic webpage.” Describe what you have done.
    • Open that file in the web browser of your choice. Say, “I am viewing my html file in a web browser.”
  • Clean up:
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 11:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Stage your change with git add . Describe what you have done.
    • Commit your change with git commit -m 'Made a change'. Describe what you have done.
  • Clean up:
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 12:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Include the basic skeleton of an HTML page by pasting the contents of this page in index.html.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 13:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • It’s a review week. Each day, write down comments, in your index.html file, explaining what one of the lines in the HTML file does.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 14:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Each day, write down comments, in your index.html file, explaining what one of the lines in the HTML file does.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 15:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Make a CSS file with “touch style.css”. Describe what you have done.
    • Link it to your index.html file by adding the following line within your <head> tag: <link rel="stylesheet" href="style.css">
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
• Week 16:
  • Set up:
    • Open your terminal, change to your desktop, and make a new folder called “test_folder.” Change into it. Initialize a new git repository. Make a new file called index.html. Add and commit this change. Add a new line inside your index.html page and open it in a browser. Paste the basic skeleton of an HTML page into your index.html. Make a new CSS file and link it to your index file. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”
  • New:
    • Change the background color of your <body> tag to be:

      body{
      background-color: red;
      }
      

    • Save your file. Refresh your browser to see the new page. Describe what you have done.
  • Clean up:
    • Add and commit all changes.
    • Change back to your Desktop and delete the folder. Describe what you have done. Say, “It is not hard, it is just unfamiliar.”

Again, step away from things if at any point the exercise starts to feel like they are causing effort or friction. Reduce what you’re asking yourself to do for the next session. I think you will find if you proceed like this for a week or two you will very quickly develop proficiency with a range of DH building blocks. A webpage with red background (my go-to example for teaching CSS because it is very obvious something has happened) might not feel very exciting to an advanced practitioner, but I would be immensely pleased with a student able to go from nothing to this level over the course of a semester.

These kinds of exercises might feel trite and meaningless, but you can’t put a price on confidence. Effortless fluency and literacy with the basics provide a strong foundation for more advanced study. Spend 5 to 10 minutes on them every day. As Werner would say, “What do you have to lose?” We can all find 5 or 10 minutes, and that unit of time is a small sacrifice that ultimately will not take that much away from other work. Wouldn’t it be great for students to approach their work with a sense of confidence that they can inhabit a DH space that works for them? Exercises like these can help our students make DH a daily part of their lives. Daily work building a personal, effortless digital humanities will prepare our students to face the bigger and more advanced problems they will inevitably face. They will do so with confidence that they can find the answers within themselves and their own process. The next time they reach for a GenAI prompt when faced with a problem, they just might pause and look inwards first.

Der NFDI4Culture Art History Award zeichnet Datenpublikationen und wissenschaftliche Arbeiten aus, die sich mit kunst- und kulturhistorischen Themen beschäftigen und dabei in besonderer Weise zu den Zielen in den Aufgabenbereichen des Konsortiums beitragen.

Unter allen Bewerbungen werden in zwei Kategorien durch die Jury der kunsthistorischen Community in NDFI4Culture bis zu fünf Einreichungen prämiert.

Einreichungszeitraum 2026: 01.07.2026–30.09.2026

Einreichungsthemen

Wir regen die Auseinandersetzung mit den Arbeitsbereichen unseres Konsortiums an und empfehlen eine Bezugnahme in der Einreichung zum Beispiel zu folgenden Schwerpunkten:

• (Weiter-)Entwicklung von Standards für Datenformate zur Codierung kunsthistorischer bzw. kulturwissenschaftlicher (Forschungs-)Daten
• (Weiter-)Entwicklung von Forschungssoftware für kunst- und kulturwissenschaftliche Anwendungsfälle
• Beiträge zur nachhaltigen Archivierung und Verfügbarmachung kunst- und kulturwissenschaftlicher (Forschungs-)Daten
• Strategien im Umgang mit Bild-, Persönlichkeits- bzw. Urheberrechtsfragen
• Entwicklung von Ideen zur Vermittlung kunst- und kulturwissenschaftlicher (Forschungs-)Daten und Ergebnisse
• Schaffung von Möglichkeiten und Formaten zur institutionsübergreifenden Zusammenarbeit

Kategorien

Der Award wird in den folgenden zwei Kategorien vergeben:

Kategorie 1 (Wissen teilen): bis zu 1.500 €

Eingereicht werden können in den Jahren 2025/26 abgeschlossene Qualifikationsarbeiten (M. A., Prom. und vergleichbare) und fachwissenschaftliche Aufsätze aus allen kunst- und kulturhistorischen Fachgebieten, deren Ergebnisse im Weiteren zu den Aufgabenbereichen von NFDI4Culture beitragen. Die Publikationen müssen Open Access und mit persistentem Identifier (z. B. DOI) frei verfügbar sein. 

Kategorie 2 (Daten teilen): bis zu 1.500 €

Eingereicht werden können Datenpublikationen unterschiedlicher Art von Kulturschaffenden und Wissenschaftler:innen aus allen kunst- und kulturhistorischen Fachgebieten, deren Ergebnisse im Weiteren zu den Aufgabenbereichen von NFDI4Culture beitragen und die nach den FAIR-Prinzipien veröffentlicht wurden.

Jury

Die Jury des NFDI4Culture Art History Award setzt sich zusammen aus Vertreter:innen von NFDI4Culture, dem Deutschen Verband für Kunstgeschichte, dem Arbeitskreis Digitale Kunstgeschichte und einer/einem Vertreter:in von Early Career Researchers.

Bewerbung

Sehr gerne unterstützt der Culture Helpdesk vorbereitend dabei, mögliche Anknüpfungspunkte des eigenen Projektvorschlags an die Ziele des Konsortiums zu identifizieren und herauszuarbeiten. Die Dokumentation der in der Beratung identifizierten Punkte werden in der Beurteilung der Anträge durch die Jury wertgeschätzt.

Die Bewerbung sollte folgende Unterlagen enthalten:

Kategorie 1

1. Lebenslauf
2. Qualifikationsarbeit  
3. eine Darstellung des Projekts, die deutlich macht, inwiefern die Arbeit zu Zielen von NFDI4Culture beiträgt und inwiefern kunst- und kulturhistorische Daten einbezogen sind (max. 1 Seite)
4. Übersicht über den geplanten Einsatz der Projektmittel

Kategorie 2

1. Lebenslauf
2. eine Darstellung der Datenpublikation, die deutlich macht, inwiefern sie zu Zielen von NFDI4Culture beiträgt und inwiefern kunst- und kulturhistorische Daten nach FAIR-Prinzipien veröffentlicht wurden (max. 2 Seiten)
3. Übersicht über den geplanten Einsatz der Projektmittel

Bewerbungen können bis zum 30. September 2026 mit dem Betreff “NFDI4Culture Art History Award” an das Culture Coordination Office gesendet werden. Bei Fragen wenden Sie sich bitte ebenfalls an diese Adresse: coordination-office@nfdi4culture.de.

Mit der Einreichung eines Vorschlags erklären alle Teilnehmenden, dass sie die Teilnahmebedingungen gelesen und ihnen zugestimmt haben.

Alle Informationen, z. B. zum Zeitplan, den Projektmitteln und den Teilnahmebedingungen, finden sich hier: https://nfdi4culture.de/de/nachrichten/details/nfdi4culture-art-history-award-aha.html.

Autor*innen (in alphabetischer Reihenfolge): David Maus, Staats- und Universitätsbibliothek Hamburg, https://orcid.org/0000-0001-9292-5673; Sarah Oberbichler, Luxembourg Centre for Contemporary and Digital History (C²DH), https://orcid.org/0000-0002-1031-2759 ; Grischka Petri, FIZ Karlsruhe – Leibniz-Institut für Informationsinfrastruktur ,https://orcid.org/0000-0002-2548-449X; Cindarella Petz, Leibniz-Institut für Europäische Geschichte (IEG) Mainz, https://orcid.org/0000-0002-6178-7332 ; Klaus Rettinghaus, Sächsische Landesbibliothek — Staats- und Universitätsbibliothek Dresden (SLUB), https://orcid.org/0000-0003-1898-2543; Ulrike Wuttke, Fachhochschule Potsdam. Fachbereich Informationswissenschaften, SeDOA, https://orcid.org/0000-0002-8217-4025 

Hintergrund des Panels auf der DHd 2026

Am 25. Februar 2026 fand bei der DHd 2026 in Wien das Panel “KI als Belastungsprobe für das offene Internet” (Link zum Abstract auf Zenodo: https://doi.org/10.5281/zenodo.18696199) statt. Organisiert wurde das Panel von Ulrike Wuttke (Fachhochschule Potsdam, Fachbereich Informationswissenschaften, SeDOA), David Maus (Staats- und Universitätsbibliothek Hamburg), Fabian Rack (FIZ Karlsruhe – Leibniz-Institut für Informationsinfrastruktur, NFDI4Culture), Klaus Rettinghaus (Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden), Sarah Oberbichler (Luxembourg Centre for Contemporary and Digital History (C²DH), und Cindarella Petz (Digital Historical Research | DH Lab, Leibniz-Institute of European History (IEG)). Moderiert wurde das Panel von Ulrike Wuttke, Klaus Rettinghaus und Cindarella Petz. Da Fabian Rack zum Termin leider verhindert war, nahm an seiner Stelle für die NFDI4Culture Grischka Petri (FIZ Karlsruhe – Leibniz-Institut für Informationsinfrastruktur) neben David Maus und Sarah Oberbichler einen Sitz als Panelist*in ein. 

Im Mittelpunkt des Panels stand der Umgang mit den durch die momentanen KI-Entwicklungen verursachten Herausforderungen für offene Informationsinfrastrukturen, wie z. B. KI-Bot-Aktivitäten, sowie der Umgang mit aktuellen rechtlichen Herausforderungen und methodische Implikationen, insbesondere für die Digital Humanities (Shearer und Walk 2025 (COAR-Umfrage), Berg-Weiß 2025, COAR 2026). Die Paneldiskussion adressierte neben technischen und rechtlichen Lösungsansätzen Chancen und Herausforderungen des aktuellen Paradigmenwechsels im Umgang mit offenen Informationsinfrastrukturen und hinterfragte, wie sich der aktuelle KI-Trend mit den Prinzipien offenen Wissens und ethischen Prinzipien in den Digital Humanities und darüber hinaus vereinbaren lässt. Dabei wurden von den Panelist*innen technische, ethische und rechtliche Aspekte beleuchtet.

Einleitung KI und offenes Internet

Eingeleitet wurde das Panel durch Klaus Rettinghaus mit einer thematischen Einführung zum Thema KI und offenes Internet. Er führte aus, dass als OpenAI im November 2022 ChatGPT vorstellte, einerseits das Interesse an dieser neuen Technologie auf Benutzerseite groß war; andererseits die Sorgen bei den Tech-Giganten viel größer waren, nun unter Zugzwang gesetzt zu sein, um schnell zu handeln. Dies führte dazu, dass viele eifrig mit dem Training eigener Modelle begannen, um nicht den Anschluss zu verlieren (Hao 2026).

Ein Problem bei dieser Entwicklung ist, dass die KI-Modelle immer mehr Trainingsdaten benötigen, die sie sich ungefragt und oftmals ohne Erlaubnis überall besorgen und damit den Internet-Traffic in ungeahnte Höhen treiben (Heise 2025a). Das führt dazu, dass inzwischen zahllose KI-Bots das gesamte World Wide Web “abgrasen” und sich dabei als „normale“ Benutzer tarnen (Heise 2025b). Viele „Hüter“ des freien Wissens (wie z.B. Bibliotheken, Wikipedia) werden von Stiftungen oder der öffentlichen Hand finanziert und sind technisch weder für diesen gigantischen Anstieg des Verkehrs ausgelegt noch vorbereitet (Bsp. Thread Fitzpatrick 2026). Sie versuchen, dem Treiben Herr zu werden, indem sie Schranken aufbauen und sich immer mehr abschotten. Klaus Rettinghaus stellte diese Punkte dem Plenum und den Panelist*innen zur Diskussion, denn noch ist kein Ende dieses “Spuks” vorhersehbar und wirft diese neue Realität viele Fragen auf.

Paneldiskussion

Ziel der Paneldiskussion war es, grundlegende Aspekte der aktuellen KI-Entwicklungen in Bezug auf das offene Internet zu diskutieren. Mit Sarah Oberbichler, David Maus und Grischka Petri waren drei Expert*innen der Einladung auf das Panel gefolgt, um die verschiedenen Perspektiven der Akteursgruppen Forschung, Infrastruktur/Bibliothek, Rechtswissenschaft, zu vertreten. 

Mit kurzen Referaten von jeweils 5 Minuten und den jeweils anschließenden Gelegenheiten zur direkten Nachfragen und Kommentaren stellten die drei Panelist*innen ihre Sichtweisen vor. 

Sarah Oberbichler (C²DH, Luxemburg) näherte sich der Problematik aus der Perspektive der Forschungsdatenpraxis in den Digital Humanities und stellte dabei eine grundlegende begriffliche Unterscheidung in den Mittelpunkt: Was bedeutet „offen“ überhaupt? Und für wen? Offene Daten umfassen mindestens zwei Dimensionen, die in der Praxis nicht immer klar unterschieden werden: öffentliche Verfügbarkeit (technische Offenheit) im Sinne des freien Internetzugangs und rechtliche Offenheit durch Lizenzen, die Weiterverwendung für Forschung und Lehre erlauben, auch wenn Inhalte hinter einem Login liegen. Eine wesentliche Frage für Forschende lautet deshalb nicht: Sind die Daten zugänglich? Sondern: Sind sie auffindbar, nutzbar und nachnutzbar?

Am Beispiel des Internet Archive lässt sich zeigen, wie das massenhafte Scraping das offene Internet selbst verändert, und damit die Archivierung historisch bedeutsamer Quellen gefährdet. Da KI-Unternehmen das Internet Archiv als kostenlose Datenquelle nutzen, hatten im April 2026 241 Medienhäuser den Zugang für das Archiv blockiert, gleichzeitig schließen dieselben Häuser aber Lizenzdeals mit KI-Firmen ab (Muno 2026). Das Ergebnis ist eine strukturelle Verzerrung des digitalen Gedächtnisses: Qualitätsjournalismus verschwindet aus dem Archiv, während Blogs, Verschwörungsseiten und Content Farms übrig bleiben. Und da Medienhäuser nicht immer selbst archivieren und das Internet Archive blockiert wird, archiviert am Ende niemand.

In diesem Kontext gibt es keine klare Lösungen, jedoch mögliche Neuausrichtungen: (1) ethische KI-Implementierung statt Massenscraping; (2) öffentliche Dokumentation von Datensätzen statt unbegrenztem Datenzugang, etwa durch sogenannte Data Envelopes (Luthra & Eskevich, 2024), die Auffindbarkeit gewährleisten, ohne unkontrollierten Zugriff zu erzwingen; und (3) gemeinsame KI-Entwicklung, bei der Kultureinrichtungen, Forschende und KI-Entwickler:innen zusammenarbeiten und einen Paradigmenwechsel von Quantität zu Qualität vollziehen. 

David Maus nahm eine Einschätzung aus der Perspektive eines Infrastrukturanbieters vor. Aus der praktischen Arbeit an forschungsnaher Infrastruktur, den Bibliothekskatalogen und den daran angeschlossenen Informationssystemen, stellen sich die massenhaften Zugriffe auch als Angriff auf die Infrastruktur dar. Weil die Bots die etablierten Steuerungsmechanismen (Robots Exclusion Protocol, aka robots.txt) schlicht ignorieren und gnadenlos aus allen Richtungen die verfügbare Bandbreite verbrauchen, legen sie regelmäßig Teile der Infrastruktur lahm. Sei es, dass die Systeme unter der Last zusammenbrechen oder sei es, dass die Betreibenden ihre Dienste einstellen oder nur noch restriktiv zugänglich machen.

Als Konsequenz drückte er seine Erwartung einer stärkeren Zentralisierung und Homogenisierung der online verfügbaren Angebote aus. Der Schutz vor aggressiven Bots erfordert eine Infrastruktur, die Angebote von engagierten Einzelpersonen oder kleinen Facharbeitsgruppen nicht aufbringen können. Infrastrukturanbieter wiederum skalieren ihre Dienste darüber, dass sie Plattformen mit einer einheitlichen Grundstruktur anbieten. Angebote, die selbst keine Ressourcen für einen Bot-Schutz haben, verschwinden aus dem Netz oder müssen sich den Plattformen der Infrastrukturanbieter anpassen.

Grischka Petri führte aus, dass es aus rechtlicher Perspektive ernüchternd ist, nach Maßnahmen zu suchen, mit denen man gegen die Verursacher der Server-Sonderbelastung juristisch vorgehen könnte. Die Auswirkungen gleichen einem DoS-Angriff, dafür ist eigentlich das Computerstrafrecht zuständig. Allerdings ist es in den Bot-Downloads nicht vorgesehen, dass die besuchten Server in die Knie gehen sollen – im Gegenteil, man will sie ja nutzen. Der Ansatz scheitert also schon am Vorsatz. Das Urheberrecht bietet attraktive Kategorien an, um Nutzungen zu regeln – allerdings besteht das Problem ganz unabhängig vom urheberrechtlichen Status der Daten. Womöglich ist es für Anbieter gemeinfreier Inhalte sogar noch größer. Das Prinzip Lkw-Maut erscheint erfolgversprechender. Das ist eine Infrastrukturabgabe für eine Sondernutzung. Abseits einer staatlichen Regulierung hat die Wikimedia Foundation mit Wikimedia Enterprise einen solchen Weg eingeschlagen und bietet entsprechende Sondernutzungsverträge an.

Letztlich zeigt sich aber, dass mit rechtlichen Instrumenten keine Betriebssicherheit zu erlangen ist, weshalb am Ende die Empfehlung für technische Maßnahmen übrig bleibt. Initiativen wie die CC Signals, die sich selbst als “a technical and legal tool and a social proposition” beschreiben, sind vom guten Willen der beteiligten Akteure abhängig.

Nach dem Austausch auf dem Podium zwischen den Panelist*innen wurde die mit allen Teilnehmenden im Plenum von Cindarella Petz mit einer digitalen Intervention eingeleitet, in welcher die zu diskutierenden Fragen mithilfe von Wooclap zur Abstimmung gebracht wurden. 

Umfrageergebnisse mit Wooclap.

Mithilfe eines webbasierten Etherpads hatte das Publikum die Möglichkeit, anonym Fragen zu stellen und interessante Aspekte zu kommentieren. Im Pad wurden konkrete Standards und unterschiedliche Granularitäten von Nutzungslizenzen diskutiert, Ansätze zur Umleitung von Webcrawlern durch beispielsweise “LLMs.txt” oder “MCP” aufgeworfen, partizipatorische Elemente der Organisation von Wissenschaften, Forschung und GLAM-Institutionen angeregt und die ethische Nutzung von gecrawlten Datensätzen wie “Common Crawl” hinterfragt und welche rechtliche Rahmenbedingung geschaffen werden müssten, um eine Haftbarmachung von Massencrawlern und Stör-Bots zu erreichen.

Fazit und Ausblick

Die Diskussion zeigte deutlich, das wissenschaftsadäquate Lösungsszenarien für die komplexe Herausforderung durch die aktuellen KI-Entwicklungen nur mittels einer diversen Perspektive – unter Einbeziehung verschiedener Akteure und der Einbeziehung fachlicher, rechtlicher, technologischer und ethischer Aspekte herausgearbeitet werden können. Es wurde deutlich, dass es notwendig ist, dass die kritischen Stimmen lauter werden müssen. Letztendlich “befüttert” der KI-Einsatz in der Forschung in vielen Fällen (zumindest implizit) genau die gleichen Akteure, die für den im Panel kritisch betrachteten “ruchlosen” Umgang mit den digitalen Commons und Infrastrukturen insbesondere aus dem Kulturerbebereich (CHI) verantwortlich sind. 

Zusätzlich stellt sich die Frage, welche Expertise und Kompetenzen Digital Humanist(a)s in die Herausarbeitung von “Leitplanken” (Werten, Richtlinien, Forschungsethik) für den KI-Einsatz einbringen könnten bzw. sollten. In dieser neuen Phase des offenen Internets gibt es keine einfachen Lösungen. Alles “wegzuschließen” (d.h. technologische oder rechtliche Sperren) würde vor allem auch der Forschung selbst schaden. Was nützt es, wenn mensch alles finden kann, aber nicht mehr damit arbeiten kann. Wichtiger scheint es, den großen kommerziellen KI-Akteuren (Tech-Giganten) Einhalt zu gebieten bzw. ihr Handeln und die Nutzung ihrer Tools kritisch zu hinterfragen. Das Feedback im Saal bestärkte auf jeden Fall das große Potenzial von Digital Humanist(a)s und der LIS-Community (Library and Information Science) in der Politikberatung und der Herausarbeitung kritischer Punkte. Die Zeit ist reif, den Finger in die Wunde zu legen.

Quellen 

Berg-Weiß, Alexander. “Offen für manche Menschen oder doch für alle(s)? KI-Bots und ihre Auswirkungen auf den Betrieb von Repositorien.” BuB 77 Nr. 7(2025), S. 372-75. 

COAR, Navigating the Uneasy Interdependence of AI and Open Science, A COAR Statement, 3.3.2026

https://coar-repositories.org/news-updates/navigating-the-uneasy-interdependence-of-ai-and-open-science/ 

Fitzpatrick 2026, “Just FYI: this is part of the damage being done by extractive AI companies. Their scraper bots routinely DDOS us, and they multiply to take up as much bandwidth as is available. We are having to put a huge percentage of our developers’ time into just keeping the site alive rather than building its future. They are actively destroying everything worthwhile about the internet.” https://hcommons.social/@kfitz/115854657278743117, Mastodon, 7.1.2026, 17:02.  

Hao, Karen. 2026. Empire of AI: dreams and nightmares in Sam Altman’s OpenAI. New York: Penguin Books.

Heise (2025a), „Besorgniserregender Trend“: KI verursacht immer mehr Traffic, 21.08.2025 https://www.heise.de/news/Analyse-KI-Crawler-koennen-Server-ueberlasten-10560038.html (Achtung ohne Pur-Abo: Tracking)

Heise (2025b), Wikipedia: Bot-Traffic tarnt sich zunehmend als menschlich, 19.10.2025 https://www.heise.de/news/Wikipedia-Bot-Traffic-tarnt-sich-zunehmend-als-menschlich-10778492.html (Achtung ohne Pur-Abo: Tracking)

Luthra, Mrinalini und Maria Eskevich. „Data-Envelopes for Cultural Heritage: Going beyond Datasheets.“ Proceedings of the Workshop on Legal and Ethical Issues in Human Language Technologies @ LREC-COLING 2024, S. 52–65. Torino, Italia: ELRA and ICCL, 2024. https://aclanthology.org/2024.legal-1.9/  

Muno, Martin. „Internet-Archive: Unser digitales Gedächtnis ist bedroht.“ Deutsche Welle, 21. April 2026. https://p.dw.com/p/5CKXK

Shearer, Kathleen und Paul Walk. „The impact of AI bots and crawlers on open repositories: Results of a COAR survey.” April 2025, aufgerufen am 30.07.2025, https://coar-repositories.org/wp-content/uploads/2025/06/Report-of-the-COAR-Survey-on-AI-Bots-June-2025-1.pdf.

Wuttke, U., Maus, D., Rack, F., Rettinghaus, K., Oberbichler, S., & Petz, C. (2026, Februar 20). KI als Belastungsprobe für das offene Internet?. DHd 2026 Nicht nur Text, nicht nur Daten (DHd2026) (DHd2026), Wien, Österreich. https://doi.org/10.5281/zenodo.18696199

Was? – Workshop „Tabellarische Quellen zwischen Geschichtswissenschaften und Digital Humanities – ein Transkribathon“ (Berlin, Do. 10.09.2026)
Wann? – Donnerstag, 10. September 2026
Wo? – Staatsbibliothek Berlin
Wer? – Stabi Berlin in Kooperation mit NFDI4Memory und der Professur für Digitale Geschichtswissenschaften der Otto-Friedrich-Universität Bamberg

Die tabellarische Strukturierung bzw. Visualisierung von Informationen zählt seit jeher zu den Standardmodi der Wissensvermittlung und -speicherung. Ungeachtet aller Dynamik auf den Forschungsfeldern von Computer Vision und Pattern Recognition stellen jedoch die automatische Erkennung und Extraktion der Inhalte historischer Tabellen in ihrer schieren Vielfalt nach wie vor die verfügbaren proprietären wie quelloffenen Softwareangebote für Optical Character bzw. Handwritten Text Recognition (OCR/HTR) vor beträchtliche Herausforderungen.
Diesem Defizit steht insbesondere von Seiten der historisch orientierten Wirtschafts- und Sozialwissenschaften der Wunsch nach niedrigschwelligen Angeboten zur automatischen Tabellenextraktion gegenüber – ein Spannungsverhältnis, das angesichts des anhaltenden Aufschwungs der Kliometrie wie auch der zahlreichen aktuellen Projektaktivitäten zur Generierung und Analyse langer Zeitreihen zusehends schmerzhafter wird. Unter den angesprochenen Vorhaben ist beispielsweise das auf 18 Jahre angelegte Frankfurter Akademieprojekt Finanz- und Unternehmensforschung aus der Langfristperspektive: Erschließung historischer Bestände deutscher Finanzmarkt- und Unternehmensdaten (1871–2025) zu nennen und nicht zuletzt das von der Deutschen Forschungsgemeinschaft geförderte Vorhaben der Staatsbibliothek zu Berlin Regionale Wirtschaftsentwicklung in qualitativ-quantitativer Doppelperspektive zur Digitalisierung ihrer herausragenden Sammlung an Jahresberichten deutscher Handelskammern des ‚langen‘ 19. Jahrhunderts.
Um das Fundament zur Einlösung des vielfach angemahnten Desiderats eines generischen maschinellen Datenextraktionsinstruments (historischer) tabellarischer Quellen zu legen, entsteht gegenwärtig an der Professur für Digitale Geschichtswissenschaften der Universität Bamberg ein Benchmarking-Datenset gedruckter Tabellen aus der Zeit zwischen 1750 und 1990. Dieses aus Mitteln der NFDI4Memory geförderte Vorhaben möchte die kaum überschaubare Vielfalt der historischen Erscheinungsformen von Tabellen in ca. 10.000 Objekten abbilden und deren Strukturmerkmale mit Annotationen erfassen. Denn frei verfügbare qualitätsgesicherte Referenzdaten (Ground Truth) zum Training von Tabellenextraktionsmodellen sind bislang rar und zudem überwiegend aus modernen Vorlagen geschöpft.
Vor diesem Hintergrund zielt die in Kooperation mit der Professur für Digitale Geschichtswissenschaften der Otto-Friedrich-Universität Bamberg und NFDI4Memory organisierte hybride Veranstaltung, zu der wir herzlich ins Stabi Lab der Staatsbibliothek zu Berlin einladen, darauf, den Teilnehmenden zunächst in mehreren Impulsvorträgen einen Überblick der aktuellen Entwicklungen auf dem Feld der automatischen Extraktion historischer Tabelleninhalte zu geben. Anschließend sollen ausgewählte Tabellen gemeinsam intellektuell annotiert und so wertvolle Ground Truth-Daten für das Training künftiger Softwarelösungen gewonnen werden. Bring your own table: Die Teilnehmenden sind ausdrücklich eingeladen, eigene tabellarische Quellen mitzubringen, um diese gemeinsam zu transkribieren und zu annotieren.

Weitere Informationen und die Anmeldung finden Sie / findet Ihr hier.
Über Einzelheiten der Teilnahme am Workshop, insbesondere was die „Bring Your Own Table“-Sektion am Nachmittag betrifft, werden wir Sie / Euch rechtzeitig informieren.
Wir freuen uns auf zahlreiche Anmeldungen!

Die Klassik Stiftung Weimar (KSW) ist eine gemeinnützige Stiftung des öffentlichen Rechts und zählt zu den herausragenden kulturellen Institutionen in Deutschland. Sammlungs- und Arbeitsschwerpunkte der Stiftung sind die Weimarer Klassik, ihre Nachwirkungen in der Kunst und Kultur des 19. Jahrhunderts und die Moderne mit Friedrich Nietzsche und dem Bauhaus. Die Sammlungen werden in der Herzogin Anna Amalia Bibliothek, dem Goethe- und Schiller-Archiv, den Museen sowie den historischen Bauten und Gärten betreut.

In der Direktion Herzogin Anna Amalia Bibliothek ist in der Abteilung Sammlungen, Sondersammlungen zum nächstmöglichen Zeitpunkt folgende Stelle in Vollzeit, zunächst befristet auf 2 Jahre, zu besetzen:

Data Librarian

E 13 TV-L, Kennziffer: 27/2026

Sie unterstützen die Herzogin Anna Amalia Bibliothek (HAAB) als Datenproduzent*in und Datenlieferant*in für Wissenschaft, Forschung und Öffentlichkeit, in ständigem Austausch mit der Abteilung Digitale Bibliothek, der Abteilung Informationstechnik und Organisation sowie der Querschnittsdirektion Digitale Transformation und Innovationsmanagement.

Das sind Ihre Aufgaben:

• Mitarbeit bei der Weiterentwicklung des normdatenbasierten Discoverysystems der HAAB (VuFind) und KSW
• Planen und Umsetzen von Datenintegration und Datenhomogenisierung
• Realisieren von Datenaustausch (z. B. Schnittstellenkonfiguration)
• Vornehmen von Datenvisualisierung, u. a. auch im Rahmen von Virtuellen Ausstellungen/Digitale Öffentlichkeitsarbeit
• Maschinelle Datenverarbeitung und -produktion/automatisierte Sacherschließung/perspektivisch KI und maschinelles Lernen planen und umsetzen
• Weiterentwickeln und bibliothekarisches Betreuen des Publikationsservers der KSW
• Mitarbeit in der Normdatenredaktion der KSW
• Mitwirken an KSW-Initiativen zu Langzeitarchivierung, Datensicherung, elektronischem Datenmanagement (E-Akte) etc. unter fachlicher Steuerung von Querschnittsdirektion Digitale Transformation und Innovationsmanagement sowie Stiftungs-IT

Das erwarten wir:

• abgeschlossenes Hochschulstudium (Master) vorzugsweise im Bereich der Bibliotheks- und Informationswissenschaften oder Qualifikation für den höheren Bibliotheksdienst (Referendariat oder Master)
• Kompetenzen in den Bereichen Bibliothekssysteme und bibliothekarisches Metadatenmanagement und Normdaten (PICA, MARC, GND, Wikidata, Linked Open Data)
• Vertrautheit mit Methoden und Workflows der Digital Humanities von Vorteil
• Affinität zur Arbeit mit historischen Quellen
• Hohe Kommunikationskompetenz, ausgeprägte Teamfähigkeit, Verlässlichkeit und Belastbarkeit in zeitkritischen Projektphasen

Wir bieten Ihnen:

• eine vielseitige und interessante Tätigkeit in einem kollegialen, engagierten Team
• ein familienfreundliches und attraktives Arbeitsumfeld mit moderner IT-Ausstattung, flexiblen Arbeitszeiten und die Möglichkeit der mobilen Arbeit
• attraktive Nebenleistungen wie vermögenswirksame Leistungen und betriebliche Altersvorsorge (VBL)
• individuelle Angebote zur fachlichen und persönlichen Qualifizierung
• einen zentrumsnahen Arbeitsplatz inmitten der UNESCO-Welterbestätten Klassisches Weimar und Bauhaus Weimar
• kostenfreien Eintritt in alle Museen der Stiftung

Die Stiftung gewährleistet die Gleichstellung von Frauen und Männern nach dem Thüringer Gleichstellungsgesetz. Bei gleicher Eignung werden Schwerbehinderte und ihnen gleichgestellte Menschen nach Maßgabe des SGB IX besonders berücksichtigt. Ein Nachweis der Schwerbehinderung bzw. Gleichstellung ist den Bewerbungsunterlagen beizufügen.

Wenn Sie diese Stelle interessiert, bewerben Sie sich bitte mit aussagekräftigen Unterlagen, Lebenslauf und Zeugnissen/Beurteilungen, zusammengefasst in einer pdf-Datei, bis zum 26. Juli 2026 über unser Online-Portal unter https://www.klassik-stiftung.de/stellenangebote/. Von postalischen Bewerbungen und Bewerbungen per E-Mail bitten wir abzusehen.

The following interview was conducted by Sam Goven, a master’s student in Journalism at KU Leuven, with Andreas Ketele, BiblioTech Hackathon participant. Andreas is a master’s student in Digital Humanities and works as legal counsel for the Agency Opgroeien. Andreas’ team, Inked and Stamped, worked with the postcards collection. You can learn more about the team’s work by having a look at their project poster in the BiblioTech Zenodo community and by visiting their project website.

The BiblioTech Hackathon is a 10-day event organized by KU Leuven Libraries and the Faculty of Arts. Students, researchers, and staff members of KU Leuven worked in multidisciplinary teams with digitized collections from KU Leuven Libraries. The theme of the 2026 edition was travel, which was reflected in the selected datasets: historical postcards and historical travelogues. More information about the hackathon and its results can be found on the BiblioTech 2026 website.

To start off, could you tell us a bit about your academic background? Had you participated in a hackathon before, and what drew you to this one?

I have a degree in law and have been working for a few years now. At the same time, I’ve always been very interested in IT and programming, so I was really happy when I discovered that there is an advanced master’s program in Digital Humanities. The program is a collaboration between the Faculty of Engineering Science and the Faculty of Arts, and it is specifically designed for people with a humanities background who want to learn how to program and how to use computational methods to strengthen their own field. For me, that felt like a perfect match, and I really enjoy it.

During the program, we learned about the hackathon and were encouraged to participate. What interested me most was the chance to apply what we were learning and really put it into practice. The program does include practical components, of course, but there is still so much more to learn when you can actually work with a large and complex dataset like the one we received during the hackathon.

This was also my first hackathon. I had done some programming before, but I had never participated in a hackathon.

Your team won the prize for best enrichment. Could you briefly describe your project?

We worked with the postcard dataset. One of the first things we did was index the postcards based on their use of color. From that, we were able to derive several insights, for example, who was printing in color, when this happened, and how that evolved over time. In addition, we made the collection searchable by the places depicted on the postcards. Finally, we extracted a number of postage stamps, allowing users to explore those in more detail as well. This part of the project was still in progress: we had several additional features in the pipeline, but they were not fully completed yet, so we weren’t able to deliver everything we had initially envisioned.

The final outcome is a website where users can explore both the postcards and the postage stamps, combined with a poster presenting our research findings.

Did you have a clear idea of what a hackathon actually is? What were your expectations, and did you feel that, with your background in Digital Humanities, you had the skills needed to get started?

Yes and no, let’s put it that way. In general, I try not to have too many expectations and to step into things with an open mind. As for having the necessary skills, yes, to some extent. In the sense that I had already done a bit of programming.

But for me, having the necessary skills often sounds like you’re expected to know everything already and be able to build a complete project in five minutes. And what I really liked about this hackathon was that this wasn’t the case at all. It was very explicitly communicated that this was also a space to learn, and that’s exactly what we did. We learned a lot along the way, which made the whole experience even more enjoyable.

At the ‘Meet the Data, Meet the People’ event, you were introduced to the data for the first time. What was the brainstorming process like? Did you feel overwhelmed with ideas, or was it clear early on which direction you wanted to take?

It was mainly a lot of different ideas coming together at first. Michiel, our team leader, did a great job of getting the conversation going, and from there we continued brainstorming and gradually exploring the data in more depth. The dataset itself was enormous, around 200 gigabytes, which is not something you can fully grasp in just a few hours. So we took time to really dig into it after the event and see what was possible.

What I really enjoyed was that process of exploration. We reflected on our ideas and experimented a lot, and that’s exactly what a hackathon is about for me: discovering possibilities along the way. If you already know everything in advance and the only thing left is implementation, you might actually miss interesting directions.

As we explored the data together, we also discovered each other’s strengths, which is one of the nicest aspects of working in a group like this. Everyone in the team was genuinely motivated, and there was a strong sense of what can we create together. That kind of shared energy is really the magic of a hackathon.

Could you describe your role in the project? Was it in line with what you were expecting?

I mainly contributed by programming and working on the content. I supported others whenever I could and asked for help myself when I needed it. Overall, it was very much a team effort: we shared tasks and built on each other’s strengths.

How would you describe the entire process from start to finish? What was your own experience like?

It was a fantastic experience. I’m usually not someone who uses very strong words, but this really was fantastic. Programming on your own can be enjoyable too, you can build interesting things that way, but here we were working as a group of highly motivated people. We collaborated very well and benefited enormously from all the support we received along the way.

That support was really essential: the infrastructure, the help, the tips, and the exchange of ideas. It made a huge difference, because you learn so much and can really move forward. A concrete example of that support is my experience with an AI model. At one point, I was working on a specific task, and the first steps went well. But when I reached a stage involving dimensionality reduction, the process ran for five minutes and then crashed with an error saying it was trying to allocate 40 gigabytes of RAM. Having access to a supercomputer where you can offload that workload is incredibly valuable, and frankly, also really exciting.

What I also loved was, on the one hand, building something ourselves, and on the other hand, seeing the final presentations from the other teams. I was genuinely impressed by what the other teams had created.

As an outsider, I also had the feeling that there was a lot of support around the hackathon, and that the people from the organizing team put a great deal of passion into it. That really stood out to me, whenever I spoke with them, you could hear how genuinely enthusiastic they were.

That’s actually something I’d really like to add as well, because I’m very grateful for it. I’ve also told them this directly: for me, this has been the best experience of my entire KU Leuven education so far, and I’ve studied in Leuven for several years. Being encouraged to explore, and being in such a positive environment where you can really feel that everyone wants to move forward, was incredibly special. It felt almost magical.

You’ve mentioned several times that you learned a lot during the hackathon. Which specific skills or aspects do you think you’ll be able to apply in the future?

Well, I’m already working on projects using the tips and techniques I picked up during the hackathon. I also received additional advice from some of the participants during the final presentations that I want to look into. So I do already have a few ideas I’d like to explore in the future.

The only downside, and I say this partly as a joke, is that now I’ll have to do it on my own (laughs).

Were there any roadblocks during the process? Did you run into things that didn’t go as expected, and how did you deal with them?

Of course, everyone in the team ran into obstacles at some point. And how did we deal with that? Partly by doing our own research, partly through trial and error, and partly by asking for help. Looking back, we probably could have asked for help even more often. Once you realize that something really isn’t working after a while, it’s important to look for a different approach.

That’s also one of the things I really like about a hackathon: you’re allowed to hack, not in the sense of breaking into things, of course, but in the original sense of creatively finding ways to make things work.

Another challenge was combining the hackathon with my situation as a working student. It was made very clear in advance that participation was possible for working students as well, and that the duration of the hackathon was designed with that in mind. Still, it was quite intense, and I ended up putting in a lot of hours. That was definitely challenging, but then again, if everything went perfectly smoothly, it wouldn’t really be a hackathon. I learned a lot from that experience too, and I’m very grateful to all my teammates for the great collaboration.

As a final question, what advice would you give to future teams taking part in a hackathon?

First of all, I would say: enjoy the experience, and make sure you set aside enough time. That’s really important. We had the incredible luxury of being able to ask questions and get support. We did make use of that, but looking back, I think I could have done so even more, so I would definitely encourage future teams to take full advantage of that opportunity.

It’s also crucial to communicate well within your group, so that everyone is working towards the same goal and pulling in the same direction. That’s not always easy, but it really makes a difference.

And finally, don’t be afraid to experiment. A hackathon is exactly the right place to try things out and explore ideas!

As part of our blog series, “Stories from the Research Trenches,” we often invite researchers and colleagues to share their personal experiences. For this post, we are delighted to hand the floor to Bonnie Varlet from the KU Leuven Cultural Studies Research Group, who offers a closer look at how she integrates Zotero into her research workflow.

Written by Bonnie Varlet

New technology, like machine learning systems, are being deployed across a wide range of institutional backgrounds. Hospitals use it to flag diagnoses, and archives use it to catalog their collections. Modern machine learning has made great leaps in its capabilities. However, these tools do not exist in a vacuum.

My research looks at what governs the relation between institutions and the technology they use. For example, when a machine learning system is introduced into a new operational environment, it changes workflows, changes what skills are required, and creates new dependencies that did not previously exist. Validation processes that were designed for human-scale output volumes become inadequate when a system can produce ten times more at the same time. Accountability structures built around individual judgment become harder to maintain when outputs are generated algorithmically. At the same time, organizations also change technology. Institutional priorities shape which systems get acquired and how they are used, and informal workarounds created by staff can become de facto operating procedures. The system produced by this process is often meaningfully different from the system initially deployed.

These processes do not happen independently. They influence each other; it is iterative, and it compounds. There is currently no widely adopted methodology for tracking this relationship in a way that is observable in comparable and replicable terms. Most existing research either examines technology deployment in isolation or analyzes governance structures without tracing their operational consequences. This remains largely unmapped, which makes it difficult for organizations, regulators, and researchers to fully understand how technology and institutions interact in practice. My work aims to help develop a way of systematically observing these interactions as they take shape in real operational contexts.

Tackling a project like this, especially my first one done independently during my Fulbright, was also a lesson in how small logistical problems can get you off course. Over the course of the project, I collected tens of papers, books, website links, and other sources. At the start, when it was only a couple of papers, it was manageable, but as the project matured, it became increasingly difficult to stay organized. This became particularly challenging given the breadth of the topic, which required me to move between technical material, governance literature, and case-based examples.

At that point, I was lucky to have resources available through KU Leuven, such as the Artes Research team, where I was introduced to tools that could help manage my workflow. I decided to try Zotero, which was easy to set up and start using immediately. What changed right away was that I stopped getting lost in my sea of sources. All my papers, books, and links were kept in one place dedicated to my project, and I did not have to go back and look up publication details because the browser extension stored that information when I saved a new source.

As I explored Zotero further, I also shifted how I organized my work. Because it makes it easy to tag and sort sources, I grouped them in the manner in which I used them. Sources used for case studies were given a case study tag, while sources that provided foundational knowledge were grouped separately. Since my project is broken up into different parts, this made it easier to see where I was pulling information from and how it influenced my analysis. In a project that tries to trace relationships between governance decisions and technical systems, being able to clearly track how different types of sources contributed to different parts of the argument was particularly useful.

I also began annotating and brainstorming directly within the same program, instead of splitting my workflow across multiple tools. For example, I would highlight a quote in a source, save it, and add a note explaining how or why it was useful. This made it easier to trace my thought process and how I arrived at certain conclusions, both for myself and in the final project.

Looking back, I wish I had reached out for help managing my workflow sooner. Not only with this specific software, but also with the more general question of how to structure a research project of this scope. I spent a significant amount of time at the start recreating approaches to organizing my work, rather than focusing on the project itself.

I would not treat exploring research management tools as a last resort. No matter the field, the people around you have likely encountered similar challenges and found better ways to address them. Trying something new partway through a project should not feel like a disruption. In my case, it was what allowed the second half of the project to go substantially better than the first, and made it easier to carry out research that depends on systematically tracing complex relationships between institutions and technology. It also made it possible to more clearly trace how different sources, ideas, and cases connect—something that is central to my research itself, which focuses on understanding how relationships between institutions and technology take shape over time.

The following interview was conducted by Sam Goven, a master’s student in Journalism at KU Leuven, with Luisa Ripoll-Alberola, team leader of the BiblioTech Hackathon project Captacats. Luisa is a PhD candidate at Leipzig University working on the Horizon Europe funded MECANO project. Luisa’s team, Captacats, worked with the travelogues collection. You can learn more about the team’s work by having a look at their project poster in the BiblioTech Zenodo community and by visiting their project website.

The BiblioTech Hackathon is a 10-day event organized by KU Leuven Libraries and the Faculty of Arts. Students, researchers, and staff members of KU Leuven worked in multidisciplinary teams with digitized collections from KU Leuven Libraries. The theme of the 2026 edition was travel, which was reflected in the selected datasets: historical postcards and historical travelogues. More information about the hackathon and its results can be found on the BiblioTech 2026 website.

Congratulations again on your team winning the prize for most original project! To start, could you tell us a bit about your background, what first interested you in the hackathon, and whether you had participated in one before?

I’m currently a PhD student in Digital Humanities, working on the MECANO project. I had never participated in a hackathon before, but I knew that I wanted to take part in one at some point. There’s a very large Digital Humanities hackathon in Helsinki every year, with five or six different datasets, but participating there can be quite expensive.

While I was doing a research stay here in Leuven, I learned about the BiblioTech Hackathon. It really felt like the stars were aligning, because it was the perfect situation. As I mentioned, I was already thinking about joining a hackathon, and having the opportunity not only to participate but also to be a team leader was exactly what I was looking for. It allowed me to take part in a Digital Humanities activity in a more informal setting, which I really liked.

Could you describe your project and your output in a nutshell?

We created a prototype web visualization called ShipAdvisor, which is loosely inspired by modern platforms like TripAdvisor, but focused on historical Mediterranean travel routes. Using travelogues from the eighteenth and nineteenth centuries, the tool allows users to navigate different routes and see how travelers at the time rated places and journeys.

Through the visualization, users can explore which routes were most popular and how perceptions of safety and danger varied across regions. These perceptions were shaped not only by environmental factors such as weather, but also by historical phenomena like Mediterranean piracy. In terms of design and approach, we drew inspiration from digital humanities platforms such as ArcGIS StoryMaps and Itiner‑e.

You mentioned that you were the team leader in your group. What did that role involve, and was it in line with what you expected? Did you find it difficult to lead the team throughout the project?

I have to say it was actually super easy. I was very, very lucky with my team, they were all extremely motivated. Supporting them felt very natural and light. We had quite a lot of meetings during the process, but it never felt forced; everything just happened quite organically.

As a team leader, I didn’t want to take up too much space. I really wanted the group to feel horizontal and collaborative. However, in the first few days, when people were still a bit shy, I think it helped for the team leader to propose ideas, bring different ideas together, and guide things slightly in that sense. Beyond that, my role was more about offering support, often acting as a bridge between the participants and the experts. Before reaching out to the experts, I was there to help where I could.

Overall, it was, as I said, very easy, and it never felt like an artificial hierarchy or like I was in a superior position. It really felt like teamwork.

At the ‘Meet the Data, Meet the People’ event, you were introduced to the data for the first time. How did the brainstorming process go?

At the beginning, we had four or five main ideas. Our approach was to take some time after the first day to reflect on them individually, and then meet again the following Monday to make a decision. During that meeting, we decided to go with the idea of ShipAdvisor, mainly because it allowed us to integrate many different elements.

For example, we could look at which routes were more affected by piracy, which was a particular interest for some of the team members, while others wanted to work with illustrations. The concept really allowed for different approaches to come together within the same interface.

At first, it can feel a bit overwhelming, you think, I need to produce something, but I’m not yet sure what that will be. But because everyone in the team was so motivated, we ended up arriving at a solid idea quite naturally.

What kind of audience did you have in mind when working on your project and the website? Who should be able to use it?

We mainly had the general public in mind. We didn’t want the website to require any specific background knowledge, whether technical or academic. The idea was that anyone could use it, people who are simply curious and want to explore the corpus in a different way.

Did you run into any problems during the hackathon, and how did you tackle them?

File coordination was probably the trickiest part. At the beginning, we planned to use all the infrastructure the library was offering, such as the computing cluster. In the end, though, we didn’t really use it. One reason was that the team had different levels of technical expertise, and for some people the computing cluster felt like too much to handle. As a result, everyone ended up working in their own way and sharing files through the Teams group instead.

That approach worked, but it wasn’t always ideal. At times it felt a bit overwhelming to navigate, because we had many documents and different versions circulating. Sometimes people were working in parallel, and you had to wait for the latest version from a teammate before you could continue your own work. Our file‑sharing setup certainly wasn’t the most structured solution, but in the end it worked for us.

You mentioned that this was the first hackathon you participated in. Do you feel you picked up any new skills along the way, and how might you use them in future research?

As a PhD student in Digital Humanities, I mainly work with text analysis. My thesis focuses on the reception of ancient authors in academic prose and academic discourse, so my work is very text‑based. Before this hackathon, I had never really worked with geographical data.

That made this project especially interesting for me, because in my own research I don’t often have the opportunity to work with spatial data. The hackathon gave me the chance to explore that a bit, experiment with different tools, and see how geographical data could be integrated into a digital humanities project.

What kind of advice would you give to someone who might be hesitant to participate in their first hackathon?

I think one of the biggest insecurities people often have is feeling that they don’t have enough technical skills to participate. What I would say is that the support provided by the library and the pool of experts was truly incredible, you were never really on your own. You were always supported, both by the experts and by your teammates.

People with less technical experience found other important roles within the team. That could be doing more close reading, contributing to the final analysis, or working on the design of the poster. I would definitely encourage anyone who feels insecure about their technical background to take part. First of all, you learn a lot. Second, as I’ve said, you’re never alone, you’re very well supported by both the experts and the team. And finally, even if you don’t feel fully comfortable at first, you will definitely find meaningful ways to contribute to the group.

And what kind of advice would you give to a future team leader of a hackathon team?

I would say: don’t stress too much. I remember feeling quite insecure at times about our final outcome, but in the end, whatever you produce is going to be fine. In reality, the hackathon is meant to be fun, and not a competition.

What really matters is not the end product, but the process: working together, learning new things, and enjoying the experience. That’s what makes it valuable.

The following interview was conducted by Sam Goven, a master’s student in Journalism at KU Leuven, with Dawn Zhuang, BiblioTech Hackathon participant. Dawn is currently the project manager and data coordinator for the research project RegInfra (Regionalizing Infrastructures in Chinese History). Dawn’s team, W@nder, worked with the travelogues collection. You can learn more about the team’s work by having a look at their project poster in the BiblioTech Zenodo community and by visiting their project website.

The BiblioTech Hackathon is a 10-day event organized by KU Leuven Libraries and the Faculty of Arts. Students, researchers, and staff members of KU Leuven worked in multidisciplinary teams with digitized collections from KU Leuven Libraries. The theme of the 2026 edition was travel, which was reflected in the selected datasets: historical postcards and historical travelogues. More information about the hackathon and its results can be found on the BiblioTech 2026 website.

To start off, could you tell us a bit about your academic background? Had you participated in a hackathon before, and what drew you to this one?

I’m currently working as a project manager and data specialist in the research group Regionalizing Infrastructures in Chinese History (RegInfra). My role combines digital methods with humanities research. I graduated from the Master in Digital Humanities three years ago, and that’s when I participated in the first edition of the BiblioTech Hackathon, in 2023.

That experience was a lot of fun, and I learned many new skills. It helped me see how the digital methods I learned during the program could be applied in a real project setting. On top of that, I made new friends throughout the hackathon, which is one of the main reasons I wanted to participate again this time.

On a more personal note, during the previous hackathon I worked with the postcard collection, and I noticed that the dataset was reused this year. I was curious to see how other groups would approach it. This time, I chose to work with the travelogue dataset, since it relates to the same overall theme. In a way, it felt like a continuation of an ongoing project.

Your team won the prize for best visualisation. Could you briefly describe your project?

We chose a small‑data approach and built an interactive map based on it. Starting from the travelogues dataset, we selected a small part of the larger corpus, specifically three volumes of The Book and the Land. We then visualized and mapped the routes described in those texts, as well as the stories that unfold along the way.

The result is an interactive map where users can click on nodes and routes to explore the journeys. Through this interface, they can see extracted illustrations along with their contextual information, which helps connect the visual material to the narratives in the travelogues.

As you mentioned, you had already participated in the first edition of the BiblioTech Hackathon. What were your expectations at the start of this one, and did you feel well equipped for the project?

Because techniques and AI have developed so much in recent years, I expected to learn even more this time, especially since the methodologies have evolved as well. I was also working with a different dataset, so overall I was really looking forward to trying out new approaches and learning new things with a different group of teammates.

At the same time, I did feel well equipped. During the first hackathon, I was still a student and everything felt very new to me. Now I already have some working experience with digital projects, and I can really see how my skill set has grown. I felt more confident this time and was happy to realize that I was able to take on more complex tasks.

At the ‘Meet the Data, Meet the People’ event, you were introduced to the data for the first time. What was the brainstorming process like? Did you feel overwhelmed with ideas, or was it clear early on which direction you wanted to take?

I’d say that during brainstorming you always get little sparks of ideas here and there. In our team, we had people from very different backgrounds, linguists, historians, and AI experts, and everyone just shared what they were thinking. At our first meeting, we didn’t go through the entire dataset yet, and some of the initial ideas turned out to be a bit too ambitious or not very practical in the end.

Still, I think the general direction was already quite clear early on. During the brainstorming phase, we decided fairly quickly that we wanted to work with an interactive map, and in the end that’s exactly what we managed to accomplish. After the weekend and one of the training sessions, we had an in‑person discussion where we exchanged our observations about the dataset and then pinned down a more practical pipeline and timeline to work with.

What’s interesting is that during the brainstorming itself, none of us really knew yet how we were going to do it. And somehow, through discussion and experimentation, it all came together. It’s a bit of a magical experience.

Could you describe your role in the project? Was it in line with what you were expecting?

I’d say it pretty much aligned with my expectations. I see myself as a digital humanities enthusiast, and through my experience I’ve become familiar with a range of tools and platforms that can help achieve different kinds of results. Within the team, I mainly took on a supportive role, contributing from the early exploration of the dataset to deciding which direction we should take.

I also have some experience with web design, so I ended up putting most of my effort into building the final webpage. Overall, I like working on different aspects of a project: trying out new techniques, moving between tasks, and supporting my teammates wherever needed.

Did you face any problems or roadblocks that you had to overcome during the project?

I think the most challenging part was moving from the initial idea to something concrete and practical. Before this project, none of us had experience linking data to a map and making it fully interactive. So while the concept was clear, the question was how we could actually realize it, what tools or platforms we could use, and how to build everything within the limited time we had.

We spent quite a bit of time and energy figuring out how to translate our idea into a realistic workflow and deciding what was feasible within the time constraints. I’d say that phase, moving from the blueprint to an actual work plan, was definitely the toughest part of the project.

Did you face any technical problems along the way, situations where things didn’t work as you had expected?

Initially, we wanted to retrieve the dataset directly from the ManGO platform. I tried running the code within the HPC environment, but I ran into a few issues. I then posted my question to the expert pool in MS Teams, and I received a lot of help.

The support was also very timely, I posted my question in the morning, and by the afternoon there was already a working solution. The expert team really provided solid support, which made a big difference in helping us move forward.

You already mentioned that during your first hackathon you picked up a lot of new skills. Did you have the same experience this time, and how might you use those skills in future projects?

Yes, definitely. I learned a lot from this project as well. For me, working with geo‑referencing and data conversion was completely new, and it’s actually quite relevant to my current work. I can definitely see myself using these skills in future research projects or for creating other visualizations.

Although our project didn’t ultimately rely on the HPC environment, I did participate in the training sessions and did some exploration on my own. I really appreciated the opportunity to work within that environment, especially because future projects I’m involved in will likely have some connection with the HPC. So for me, it was very good practice and a valuable learning experience.

What kind of advice would you give someone who is participating in their first hackathon?

I would say: think bold. There’s a lot of support available, and you’re surrounded by a great team of experts who are there to help you. If you allow yourself to think ambitiously and take a few risks, you’ll be surprised by how much you can accomplish by the end.

Lastly, how would you describe your overall experience?

For me, it was truly inspiring and very enjoyable. And something I didn’t mention earlier is that I really made good friends through the hackathon and learned a great deal from my teammates, as well as from the other groups. That’s a very precious takeaway for me.

On June 2nd I’ll be giving a workshop for the PHD+ program here on how to develop a sustainable summer writing practice. This session will be one of the opening discussions for a daylong event that asks PhD students to take their research topic and transform it across a range of different formats: podcasts, websites, and zines. The goal for my part is to collect a number of different writing activities to show examples for how one might experiment with writing practice. For me, sustainable writing can be found through regular work, joy, and playing with constraints. To get there, I suggest students do the following:

• Experiment with different formats for writing. For this I discuss otter.ai.
• Distinguish between the different phases of the writing process and sit down with a clear goal in mind.
• Scale up to a daily practice rather than experimenting to start with tons of words each day.
• Incorporate free writing (hat tip to Sean Michael Morris here for his beautiful approach to the craft).
• Incorporate stochastic practice as a means to jolt your creativity. I’ll use Peter Schmidt and Brian Eno’s Oblique Strategies deck here.

I then close with a short activity that asks students to brainstorm the different components for a practice of their own: format, location, frequency, amount, and method. After jotting a few ideas each for each category, I’ll guide them through a discussion of how to remix these components into something that works for them. Slides follow below. The particular deck theme I used was food themed, which felt appropriate.

A quick one today on how I manage my task list each day and the tools I use for doing so.

For years I have used Slack to manage my working life. If you click a single message you can select “remind me later” and select a date and time. I use this religiously, scheduling out reminders for particular times and dates. If I need to follow up on a thing, it gets a date. If I need more time to reply to a message, it gets a date. You can also schedule reminders for yourself separate from messages. So, if I have an overarching task, it gets a date and reminder. It’s not uncommon for me to open slack and get 10 notifications at 9:00 AM that tell me what I am supposed to be doing for the day. Here’s a glimpse at my reminders for today:

This system has worked well for years. I rarely let anything slip, because I just file everything away as a reminder and snooze if necessary. But Slack recently changed how their reminders work. DISASTER. I can’t fully grasp how to reset the way it manages this system, but now it seems to be giving me double alerts for these notifications in a way that collapses them with DMs. It’s deeply irritating. While I’m sure I could figure a workaround, I decided it was time to disentangle this particular tool from my daily task management.

So, I’m experimenting with a physical notebook for the first time in at least a decade. Here’s my daily notebook for today:

I’ve tried such things in the past but never stuck with them for long, but this run seems to be sticking. In part, I think this is because of how I’ve made working with the notebook part of a daily ritual. Each day’s page is broken into three segments: must do, can do, and waiting. I start each day by looking at the previous day by looking at the previous page to see what needs to be moved over. I’ll then check my inbox and shuffle things around based on how answering email goes. This process gives me a sense of things that are urgent and those tasks that require actions from other people. I typically close out each work day by referring to the page once more and updating things. This process is helped along by the fact that I have found a particular set of pens that are deeply, unironically joyful to use. Working with them provides a meditative tactile sensation that grounds my start and end to each day.

Sharing all this is a tad embarrassing. I have discovered writing in a journal! I have terrible handwriting! Pens are nice! But I can’t emphasize enough what a shift this has been for my working life. It’s brought an embodied ritual to each day that I didn’t have before, and I’ve found it surprising how much energy can come from shifting this foundational part of my working rhythm. So, if you’re feeling stuck, it’s never too late to change. Your process can always find new shape if you give it new tools.

Diese dreiteilige HERMES-Veranstaltungsreihe richtet sich an Betreuende von Qualifikationsarbeiten (Bachelor, Master, Promotion) im Bereich der digitalen Geistes- und Kulturwissenschaften. Die Reihe ist modular aufgebaut und jede Veranstaltung kann unabhängig besucht werden – ideal für eine gezielte, flexible und praxisnahe Weiterbildung im Alltag im Austausch mit Expert*innen.

Den Auftakt der Reihe bildet eine Veranstaltung zum Thema „Hochleistungsrechnen“, gefolgt von zwei Podiumsdiskussionen zu den Themen „GLAM“ und „Interdisziplinarität“. Hierbei kommen Vertreter*innen von Hochschulen und dem GLAM-Bereich (Galleries, Libraries, Archives, Museums) in unterschiedlicher Zusammensetzung miteinander ins Gespräch, diskutieren verschiedene Thesen und eröffnen Reflexionsräume. Die Teilnehmer*innen gewinnen durch den Besuch der Veranstaltungen neue  Perspektiven zu aktuellen Themen, die sie in die Betreuung und Beratung ihrer Studierenden und Promovierenden einbringen können. Raum für Fragen und eine offene Diskussion wird bei allen Veranstaltungen gegeben.

Die Veranstaltungen finden online statt, eine Registrierung ist über die einzelnen Veranstaltungsseiten möglich.

High Performance Computing (HPC) nutzen: Anja Gerbes und Dr. Sabine Bartsch

08.06.2026, 18-20 Uhr

Nach einer Roadshow von Anja Gerbes zu High Performance Computing des NHR, berichtet Dr. Sabine Bartsch von ihren Erfahrungen des Dienstes in Forschung und Lehre.

https://hermes-hub.de/aktuelles/events/betreuenden-ws-hpc-2026-06-08.html 

GLAM als Partner der Wissenschaft verstehen: Prof. Dr. Felix Schäfer, Konstantin Freybe, N.N.

16.07.2026, 18-19:30 Uhr

In der Podiumsdiskussion sprechen Vertreter*innen des GLAM-Sektors und Hochschullehrende über Angebote und Forschung an GLAM-Einrichtungen  sowie der gemeinsamen Betreuung von Qualifiaktionsarbeiten.

https://hermes-hub.de/aktuelles/events/betreuenden-ws-glam-als-partner-2026-07-16.html

Interdisziplinäre Qualifikationsarbeiten betreuen: Prof. Dr. Anna Neovesky, Dr. Shumon T. Hussain, Dr. Anna Froese

17.09.2026, 18-19:30 Uhr

Die eingeladenen Vertreter*innen aus der Wissenschaft diskutieren ihre Erfahrungen in Hinblick auf interdisziplinäres Arbeiten und deren  Betreuung.

https://hermes-hub.de/aktuelles/events/betreuenden-ws-interdisziplinarit%C3%A4t-2026-09-17.html 

The following interview was conducted by Sam Goven, a master’s student in Journalism at KU Leuven, with Roberta Pireddu, team leader of the BiblioTech Hackathon project PostScript. Roberta provides academic support for the Master in Digital Humanities at KU Leuven. Roberta’s team worked with the postcard collection. You can learn more about the team’s work by having a look at their project poster in the BiblioTech Zenodo community and by visiting their project website.

The BiblioTech Hackathon is a 10-day event organized by KU Leuven Libraries and the Faculty of Arts. Students, researchers, and staff members of KU Leuven worked in multidisciplinary teams with digitized collections from KU Leuven Libraries. The theme of the 2026 edition was travel, which was reflected in the selected datasets: historical postcards and historical travelogues. More information about the hackathon and its results can be found on the BiblioTech 2026 website.

Congratulations on winning both the first prize and the public’s favorite! Can you tell me a bit about what first drew you to the hackathon, and have you participated in one before?

I hadn’t participated in a hackathon before, but I had organized a small one myself. It was for a project on Artificial Intelligence and its application in the cultural heritage sector. I knew a lot about the organizational aspects, but not much about how to actually participate in a hackathon. What I mainly did then was observe the other groups: what they were doing and how they came up with their projects. So I was mostly involved from the sidelines.

As for why I participated: I’m currently praktijkassistant and teaching assistant for the Master in Digital Humanities, and digital humanities students are an important target group for the BiblioTech hackathon. Taking part myself allowed me to work on a project together with the students. I also already knew the postcard collection, as I had worked with it in the past, and I thought it would be nice to create something new using that material.

And your own background is in Digital Humanities as well?

Yes, that’s right. I studied Digital Humanities in Leuven, and before that I studied history, more specifically medieval history, so my background is very much in the humanities. I’ve mainly worked with heritage collections, like the ones that were used for this hackathon.

I already mentioned you won the first prize with your project. Could you describe it in a nutshell?

Our team worked with the postcard collection, which is a very large one, and visually very attractive. It’s rich in information, with a lot of detail in the metadata, but because of its size it can be quite difficult to really explore all of those details.

What we wanted to create was a kind of website or digital space where people could explore the collection more easily and from different perspectives. We chose three main perspectives. One of them, for example, is a map, where users can see the locations represented in the collection and then zoom in on the details. On the website, users can also explore specific elements, like all the trains in the collection, all the cars, parks, and so on.

In addition, we created a crowdsourcing section. We wanted to include user participation so that the collection could be enriched with additional information. For example, on the back of the postcards there are greetings, and we wanted to allow users to transcribe or translate those messages so they could be added to the metadata.

You were the team leader of your group. Was this role in line with what you had expected?

I expected that I would need to give structure to the team: define the focus of the project, set concrete steps, and remind everyone of deadlines. In the end, though, everything developed very organically and smoothly, and I was really happy with how it worked out.

At the ‘Meet the Data, Meet the People’ event, you were introduced to the data for the first time. How did the brainstorming process go?

At first, it wasn’t very clear what specific skills everyone could bring to the project, or how we should approach such a large collection. That led to a lot of questions: what do we actually want to do with this collection, and what do we want to highlight?

In the beginning, we had many different ideas. We thought about working with the colors of the postcards, or focusing on locations, and that’s when the idea of using a map came up. There were a lot of possibilities. At a certain point, though, we decided that we really needed to look more closely at the dataset, see what was actually there, and then make a decision. That happened a couple of days after the opening event. We had some time to reflect, explore the data, and then settle on a clear approach.

Was it difficult to decide in which direction you wanted to go?

A bit, yes. But in the end, the direction really emerged from what we actually found in the data. As I mentioned before, we initially wanted to work with color, but when we started thinking about the kind of results that would produce, we realized it wasn’t the direction that appealed to us the most. So at some point we had to make a clear decision: okay, let’s go in this direction and really commit to it.

That said, it was still a bit challenging, because along the way new ideas kept popping up. For example, we considered adding a gamification aspect to the crowdsourcing section, where participants could earn points based on how much they contributed. In the end, we had to leave that out because of time constraints. At some point we realized, there are only three days left, how can we realistically make this work? It’s important at that stage to be realistic and say, okay, this is something we can do, and this is something we can’t.

During your final presentation at the closing event, you mentioned the educational goal of the project and its collaborative aspect. What kind of audience did you have in mind? Who should be able to use the website you developed?

We definitely had researchers in mind. The idea was to help them shape their research by giving them access to all these additional details in the collection. Because the postcard collection is so broad, it’s not immediately obvious what kind of research questions you could explore with it, and we wanted to make that easier.

At the same time, we wanted to reach a wider audience, people who are curious about Belgium’s history, about tourist places, and what they looked like in the past. Some might be interested in comparing then and now, others in seeing how streets and cities have changed, or just browsing the collection and feeling a bit nostalgic.

One thing I found very appealing was how user‑friendly the website was, it really looked like something anyone could use.

Yes, absolutely. I think a lot of people would love the idea of being able to see how a place looked in the past and compare it to how it looks now, seeing how much it has changed, or sometimes how it no longer exists at all.

The end result was a success, but did you face any roadblocks during the hackathon?

There was one issue at the beginning related to the locations of the postcards. We wanted to create a map and link each image directly to a specific place, but the coordinates were missing in the collection. So we first had to retrieve that information, and that took some time. At one point, we even thought it wouldn’t be possible. In the end, though, one of the team members managed to clean the dataset and recover the exact coordinates for each location, which allowed us to move forward.

You mentioned that this was the first hackathon you participated in. Do you feel you picked up any new skills along the way, and how might you use them in future research?

The crowdsourcing concept was particularly interesting for me. It’s something I had already worked with in earlier projects where we involved the public. For example, we showed people images, often of places in cities, and asked them to share additional information about what they saw.

What was new for me in this project was the specific crowdsourcing tool that we embedded in the website. I think that’s something I’ll definitely use again in the future. It’s very user‑friendly and easy to integrate, and the fact that it automatically produces a file with all the participants’ responses is very useful.

What advice would you give to someone who might be hesitant to participate in a hackathon because of their background?

I really think everyone can participate, because there’s a place for everyone in a hackathon, even if you don’t have strong technical skills. Whatever your background or skills, there’s always a way to contribute and find your role within the group. That might be through creative ideas, working on the poster, or helping shape the concept of the project. There’s always something meaningful you can bring to the team.

Last question: what advice would you give a team leader?

I would say don’t be too strict at the beginning. It’s important to give everyone enough space to be creative and to let people explore ideas, so that everyone’s skills can really emerge. I think the brainstorming phase is especially important, because that’s when you start to understand what each team member can do and how everyone can contribute to the project.

Congratulations one more time! It’s amazing how much each team accomplished in such a short period of time. For me, it almost felt unreal, this looked like a year’s worth of work.

Yes, exactly. For me, this could have been a thesis, the kind of results you would expect from a master’s thesis. That’s really what made it so remarkable to me.

Este curso propone un espacio de formación y reflexión orientado a comprender cómo se investiga en el espacio digital desde las HD, abordando tanto sus fundamentos epistemológicos como sus metodologías y herramientas prácticas

Continue reading Escuela de otoño 2026 at Red de Humanidades Digitales.

The following post was written by Sam Goven, a master’s student in Journalism at KU Leuven. It offers a participant’s perspective on the BiblioTech Hackathon, reflecting on the experience, the creative process, and collaborative spirit that shaped the event.

Libraries are often seen as places of preservation rather than experimentation, but the BiblioTech Hackathon turns KU Leuven Libraries into a digital playground. Drawing on rich library datasets, students, researchers, and staff from diverse backgrounds work in interdisciplinary teams to reimagine historical collections through digital tools and collaboration.

The second edition of the hackathon culminated on 26 March in the University Library in Leuven, where seven teams presented their final projects to a jury. Over the course of ten days, materials from the library collection were transformed into innovative digital outputs, ranging from interactive maps and searchable databases to experimental interfaces, which can be explored via the project websites. Team PostScript ultimately claimed both the jury prize and the audience award with an interactive digital archive of Belgian postcards.

By combining technical support, curated library collections, and an emphasis on experimentation rather than competition, the BiblioTech Hackathon demonstrates that digital humanities can be accessible, creative, and collaborative, even for those new to computational approaches.

What is a Hackathon?

During a hackathon, a blend of “hacking” and “marathon”, participants work together in teams on a project against a tight deadline. These projects often have a digital component and can be developed over one or several days, resulting in a website, database, or another form of digital output.

The first edition of the BiblioTech Hackathon took place in 2023, organized by KU Leuven Libraries and the Faculty of Arts. Participants could choose from seven datasets, including the Bible of Anjou and wartime posters. The focus was on exploring documentary heritage from a fresh perspective by transforming it into computational data. The hackathon proved to be a success and led to a second edition in 2026.

Meet the Data, Meet the People

The second edition kicked off on 12 March in Agora Learning Centre in Leuven. As the smell of pizza filled the space, the perfect brain food for sharp minds, the seven teams discovered both the datasets and each other for the first time. In total, 39 enthusiastic participants from a wide range of backgrounds took on the challenge. The hackathon attracted not only master’s students, but also PhD candidates, postdoctoral researchers, and KU Leuven staff. Participants represented a broad variety of disciplines and research fields, including Computer Science, Egyptology, Law, and Economics.

To make the most of this diversity, teams were formed in advance based on digital skills and areas of expertise, ensuring a balanced mix. Each team was supported by a designated team leader to keep the project on track, while technical experts were readily available throughout the hackathon to answer questions and provide assistance. To ensure everyone could get started smoothly, an additional training session on the technical infrastructure and tools was organized the next day.

Following an introduction to the datasets and the available support network, the teams dove into the material. This year’s hackathon offered two datasets: well over 35.000 historical postcards from Belgium and around 300 travel accounts written by European authors describing the destinations they visited. Once again, these historical sources provided ample opportunities for innovative perspectives. Four teams chose to work with the travelogues, while the remaining three focused on the postcards.

The brainstorming phase reflected the exploratory nature of the hackathon. Faced with rich datasets and a wide range of ideas and ambitions, teams took time to explore different directions before narrowing their focus. Working within a limited timeframe required careful consideration of what was both innovative and feasible. This process not only helped shape the projects but also allowed participants to recognize and build on each other’s strengths. Andreas Ketele, a member of the Inked and Stamped team, reflected afterwards: “What I really enjoyed was that process of exploration. We reflected on our ideas and experimented a lot, and that’s exactly what a hackathon is about: discovering possibilities along the way.” (full interview)

The Final Projects

On 26 March, participants, jury members, and guests gathered in the University Library for the final presentations accompanied by a poster exhibition, marking the culmination of the hackathon and an opportunity for teams to present their work. The evening opened with welcoming words from the organizing team, Demmy Verbeke (Head of KU Leuven Libraries Artes), and Geert Brône (Vice Dean for Research at the Faculty of Arts), who praised the creativity and commitment shown throughout the hackathon.

The presentations were opened by team CaptaCats with their project ShipAdvisor. Loosely inspired by the travel website TripAdvisor, the team developed a web platform that maps maritime routes in the Mediterranean during the 18th and 19th centuries, based on historical travel accounts.

Next, team DH.xml presented their analysis of the postcard dataset. They argued that historical postcards functioned as a form of social media avant la lettre, and used the collection to identify recurring visual trends and patterns.

All Reads Lead to Leuven focused on how 19th-century French travel writers wrote about African languages. Their project resulted in a website featuring Instagram-inspired posts that reveal the vocabulary and framing these authors used when describing linguistic encounters.

Using the postcard dataset, Inked and Stamped built a searchable digital database. Its intuitive interface allows users to explore the collection by location, date, and even the color of the postcards.

Team PostScript adopted a similar approach, but with a specific focus on postcards from Antwerp. In addition to a searchable database, they introduced interactive features such as maps that contrast contemporary photographs with historical images from the collection.

The penultimate presentation came from Team W@nder. Drawing on The Land and the Book, a 19th-century publication by W. M. Thompson, they visualized the author’s travels in the Levant. As with other projects, historical illustrations were juxtaposed with present-day photographs to highlight continuity and change.

The evening concluded with a presentation by Team Julie Verne. They developed an oracle-like search tool based on the travelogues dataset. Through their website, users can query the texts and receive the most relevant responses generated from the corpus.

After a brief deliberation by the jury and a public vote, the awards were announced. The jury consisted of experts in data and digital research: Julie Birkholz (Coordinator CLARIAH VL+), Geert Brône (Vice Dean for Research of the Faculty of Arts), Jo Rademakers, (Head of LIBIS), Fred Truyen (Head of CS Digital), and Katrien Verbert (Program director of the POC Digital Humanities). Team PostScript was awarded both the jury prize and the audience award. As in the 2023 edition, however, each team received recognition, including awards such as Best Research Potential and Best Visualization. The evening concluded with a reception, where teams presented their project posters over food and drinks. To share the creativity and impact of the hackathon with a wider audience, the posters are currently touring across KU Leuven.

A Community Built Through Collaboration

Not only were the results of the hackathon impressive, participants also praised the atmosphere and strong sense of community that developed throughout the event. In post-hackathon interviews, several participants reflected on the collaborative environment that emerged over the course of the ten days. Andreas Ketele described the experience as particularly rewarding: “I’m usually not someone who uses very strong words, but this really was fantastic. […] We were working as a group of highly motivated people. We collaborated very well and benefited enormously from all the support we received along the way.” (full interview)

The diversity of backgrounds and skill levels did not prove to be a challenge, but rather one of the hackathon’s greatest strengths. By bringing together participants with different perspectives, expertise, and levels of technical experience, the hackathon created space for learning from one another. As Roberta Pireddu, team leader of PostScript, explained: “I really think everyone can participate, because there’s a place for everyone in a hackathon, even if you don’t have strong technical skills. Whatever your background or skills, there’s always a way to contribute and find your role within the group.” (full interview)

For many participants, this emphasis on collaboration rather than competition was key. As advice for future participants, Luisa Ripoll Alberola, team leader of CaptaCats, encouraged newcomers not to focus too heavily on the final outcome: “What really matters is not the end product, but the process: working together, learning new things, and enjoying the experience. That’s what makes it valuable.” (full interview)

The second edition of the BiblioTech Hackathon proved once again how working with library data can foster meaningful collaboration across disciplines. By bringing together diverse participants, the hackathon strengthened connections within the academic community and opened up new ways of engaging with humanities collections.

More information about the hackathon, its datasets, and the final projects can be found on the BiblioTech 2026 website. We encourage you to have a look at the project posters and websites to explore the teams’ outputs and discover the creative ways in which KU Leuven’s library collections continue to inspire digital humanities research. We also invite you to explore interviews with participants, offering a personal insight into their experiences during the event.