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.

I recently got word that my manuscript for Embedded Pedagogies: Digital Humanities Teaching and the Infrastructure of Change was accepted for publication with Open Book Publishers. As exciting as this is, there is still much work to do. I could not have asked for more thoughtful and generous peer reviewers, but even thoughtful and generous feedback still takes time to incorporate. One reader’s report especially requires a kind of work that used to give me a lot of difficulty when I was a graduate student. The substance of the report was that there were two critical conversations with which I needed to engage more deeply. The reader suggested thoughtfully that I needed to incorporate those conversations that critique the field of librarianship (#critlib especially) if I wanted to claim librarian as an identity. The other critique: my writing on artificial intelligence felt a little thin and needed to be built out. Also very fair. I hadn’t actually anticipated writing about AI, but it does feel more and more urgent the more time passes. Despite my own reluctance I found myself needing to read much more about generative AI.

So, here I have two areas in which I need to read more deeply. Such critiques can feel very overwhelming and abstract, and it is helpful to find ways to make them smaller and actionable. Experience has helped me towards a system that works for me, so I thought I would share a few thoughts here on my workflow for this research and revision process. While each step below does build on the others, I typically think of each phase as a separate component. I try to stick to a single goal when I sit down at my desk (or stand at my treadmill—more on that below).

Gathering

First, I gather a list of citations to explore. I might drop a bunch of links in a word doc, open a range of tabs, or print a stack of texts. The anonymous reviewer above suggested the #critlib Zotero library, which turned out to be an extraordinary resource. Reading through a collection of articles here took me to the Critical Library Pedagogy Handbook. Exploring that resource took me to the Journal of Critical Library and Information Studies. And working through that material took me on a deep dive into In the Library with the Lead Pipe. In each case, I started by skimming titles and abstracts just to get a sense of what could be relevant.

Reading

I read 2-3 articles per day from the stack created during the gathering phase (after all, one can only take in so much per day). As I go, I typically underline some things, underline and star others, and then underline and star and write CITE in capital letters next to others. At the end, I’ll make a few notes at the top of the article about whether or not the thing seems useful and about where I see the material fitting into the book. I typically do this work on the treadmill, which I mention for no other reason than to note how important it is for me to associate particular kinds of work with particular spaces and practices. In this way, my “to read” pile gradually morphs into a “read but needs to be transcribed” pile.

Lifting and Transcribing

At this point, I shift back to my computer. I have three folders there: “to transcribe,” “to integrate,” and “done.” For each article that I have read, I create a blank word document titled with the name of the author. I transcribe that article’s quotations with page numbers into its corresponding holding document, and I also assemble the actual, formatted citation for my references list. As this point, I am typically done with the actual, full text of the article. It exists for me only as a series of quotations, a citation, and a few notes to the effect of “mention in Chapter Three when you talk about the interview” or “more of an explanatory footnote than an actual citation to Chapter Four.”

Integrating

Only now do I actually open the manuscript itself. Given that is revision work for an actual, already extant manuscript, I typically have a pretty good idea of where things are likely to fit in and be useful. This phase involves integrating the new material into my text, stitching things together, and rewriting whatever components were complicated by the new references. Sometimes, this process is fairly seamless. Other times, this process involves substantial rewriting in light of the way the citations change my thinking about particular ideas. After the initial pass at integration, I make a note about the page numbers where I have revised new material. That way, I have a better sense of which pages to focus on during later editing.

Proofing

In this final phase, I make sure to return to things with fresh eyes. I will read more broadly than just the sections I have surgically edited, and I’ll hope to see where things fit, where they don’t, and what other edits might be needed to make things flow together. But the pages listed in the previous phase help me know where to focus.

Each of these phases feeds the others, so I am constantly moving forward. I feel as though I am making progress, and I also feel as though the big abstract task of reworking my argument to fit more closely into a particular critical conversation is more manageable and more doable. Importantly, each of these segments requires a different kind of work in ways that I appreciate. Transcribing and creating a citation require far less mental energy for me than reading or integrating. I welcome these variations.

Hopefully this is useful for seeing how I go about the revision process. Keep an eye out for Embedded Pedagogies, the text of which will be available print on demand and freely online. I am so grateful for the particular anonymous reader I describe above. It’s been enjoyable to dig into broad areas that overlap with my work but that were not top of my mind. I’ve learned a lot, and I think my work is much stronger for it.

Am 10. und 11. März 2026 fand die Abschlussveranstaltung des Projekts Materi-A-Net: Material als Akteur in den transkulturellen Netzwerken zwischen Frankreich und Deutschland im Spätmittelalter und der Frühen…

The post Abschlussworkshop des Projekts „Materi-A-Net“ und Launch der Datenbank appeared first on CCeH.

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.”

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.”

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.”

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.”

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.

Brandon Walsh’s 1st book, “Embedded Pedagogies: Digital Humanities Teaching and the Infrastructure of Change” is forthcoming from Open Book Publishers!

Brandon Walsh presented on adaptive makerspace tech & some of our digital collecting projects, for our local historical society’s event at a retirement home.

Will Rourk directed a team of students, Fluvanna County community, & architecture preservation professionals in completing the documentation necessary to nominate the ~1935 Evergreen African-American School as an official historic site with the Virginia Dept of Historic Resources.

KU Leuven Libraries has invested in an integrated approach to strengthen the discoverability and accessibility of physical resources through digital access, thereby supporting and stimulating research, education, and heritage activities.

The Digitisation and Enrichment of Collections Service creates, manages, and enriches data through metadata creation, digitisation, and imaging and serve as experts in these fields. Through state-of-the-art infrastructure such as the Imaging Lab and the Scan Hub, both fragile heritage materials and modern documents are digitised. These processes are supported by metadata creation and embedded within a broader policy framework for the preservation and management of physical collections. The team follows the latest developments in the field with regards to technical aspects and concerning digitisation project management and legal matters.

To make this often invisible expertise visible, Digitisation and Enrichment of Collections of KU Leuven Libraries developed the YouTube series “How KU Leuven Libraries Digitises” (in Dutch). Through a seriest of 4 videos you can discover, step by step, how materials are prepared, handled, placed under controlled lightning, scanned, and described. They show the people, equipment, and procedures behind the digitisation workflow. Discover the series below, or directly on Youtube.

If you want to know more about KU Leuven Libraries digitisation process, visit the website.

1. Safely handling

2. Metadata creation

3. Imaging Lab

4. Scan Hub

The Train Moves On!

Progress is happening. Much of it reworking what I already did. End of year projects crept in and put this project on the back burner for a couple of weeks. But despite the delay, the train moves forward! And what once was done is now redone!

Servo Motors

For example, the servo motors. The first version worked, sort of. They didn’t move a full 180°, and they were kind of weak.

So I found new motors, bought a couple, and tested them out. That of course, required recreating the servo gear and the whole housing unit.

After many iterations of the servo gear…

I dialed in the tolerances and sizing so the new servo horn/arm fits and stays in place. But just to be safe, I’ll be screwing in each of the servo gears.

Holder

The new servo motor is bigger than the previous. That means the holder needs altering. Fortunately, I designed it measurements so that a quick change of a few select dimensions and the holder fits the new motor snug, but not as tight as a fat kid in the middle seat. Hence the screw.

Also note that I started writing the version number on the object.

I also opened up the back side so it is easier to install the gears, especially the servo gear. I tightened up the tolerances here, too.

(New version on the left.)

And here’s the new gear train all assembled with the new servo. It moves so much more cleanly and smoothly.

And just for fun, here are most of the parts I 3D printed so far.

Moving On

This got me to the point of creating the states. I first needed to calculate how big this project was going to be more accurately.

So I counted all of the hexagons horizontally, and vertically to get a much better calculation than we had used in the past.

I plugged these numbers into a spread sheet, and iterated over a few hexagon dimensions in order to see how big this map can be, or how small it needs to be. Two factors weighted the dimensions the most: 1) the maximum size that the laser cutter can cut, 2) the size of a doorway. I figure that I can cut the map out in multiple pieces, so the size of the laser cutter is not too much of an issue. But if this thing needs to travel, then it definitely needs to fit through a doorway. So that is really the limiting factor, because it will need to travel at some point in it’s existence.

Our original dimensions called for a map that was nearly 4 feet by 3 feet. Too large for the laser cutter, and too large to fit through a door.

A good size ended up being a hexagon that is 20mm from side to side, which creates a map about 30 inches long and 23 inches wide. A common, indoor doorway in the US is 30-32 inches wide. Such a table will definitely slide through at 23 inches wide.

All posts in this series:

• Part I - Critical Making Project 2026
• Part II - Jump on the Gear Train
• Part III - Gear Train Assemble
• Part IV - Back on the Train

Funding provided through a generous grant from UVA Arts Council.

Digital images are in constant motion. They traverse various platforms, feeds, databases, and archives, often reappearing in modified forms. Through my research on digital art, I have recognized this phenomenon as more than a mere feature of online dissemination. It constitutes both a methodological challenge and a perceptual issue.

What appears to be a single image may, in actuality, exist as a collection of various versions: cropped, compressed, recoloured, or reposted without proper attribution. Although these differences may seem insignificant at first glance, they give rise to a question that is more complex to answer than it initially appears.

      Under what circumstances can two images be considered identical?

That question became the basis of my assignment for the CodeLab course in my ongoing Praxis Fellowship Program. Using Python with the ImageHash and Pillow libraries in VS Code, I built a small tool to test how visual similarity might be measured across images that have changed through circulation. What started as an exercise became a way of thinking through something larger: what does it mean for a computer to recognize an image, and does that match what we mean when we say two images are the same?

The approach

The tool uses the imagehash library to compute perceptual hashes and compare images by visual similarity.¹ Unlike cryptographic hashing, which changes entirely if even a single byte changes, perceptual hashing captures how an image looks. Two visually similar images should produce similar hashes; unrelated images should not.

After generating the comparison data, I modified the script to export results as JSON and render them as an HTML page. Instead of raw values, the interface ranked each image against the reference, displayed a distance score, and grouped results into categories from “nearly identical” to “different from the original.” The script processed files in the images/ folder, saved results to version_results.json, and generated output in results.html.

Figure 1. HTML interface showing ranked comparison of image variants against the reference image. See https://jimgaconcept.github.io/image-versioning-demo/

The dataset

The reference image is a digitized hand-drawn cartoon illustration made with pen and ink and watercolor on paper. This detail turned out to matter a great deal. I compared it to two modified copies (resized and compressed), one digitally recreated version, and three visually unrelated images, to test whether the tool could distinguish genuine variants from unrelated works.²

Results

The two modified versions, resized and compressed, both scored between zero and two, confirming their close relationship to the reference. The three unrelated images all scored above 20, well outside any similarity range. The digitally recreated version (Fig. 1) scored 18, placing it in the category that the interface labeled as different from the original.

That score of 18 was the result I did not expect, and the one worth thinking about most carefully.

What the computer sees, and what we see

The recreated image and the original share the same subject, composition, and color palette. A human viewer encountering both would almost certainly recognize them as versions of the same thing. The algorithm did not. Scoring 18, it placed the recreation closer to the unrelated images than to the two modified copies, which scored between 0 and 2.

The reason lies in what each image actually is at the data level. The original is a scan of a physical drawing, and its pixel data carries the texture of its medium: the grain of the paper, the way ink spreads at the edges of marks, the tonal variation of pigment on a physical surface. The digital recreation was built entirely within Photoshop and saved as a JPEG. Even a faithful digital reconstruction is made from digital brushes and algorithmically generated marks. There is no paper grain, no ink bleed. The two images look the same to us, but their underlying data structures are built from entirely different material.

This is a version of what computer vision researchers call the cross-depiction problem: the gap between human visual recognition, which operates on meaning and composition, and machine recognition, which operates on statistical patterns in pixel data. My experiment gave that abstract problem a specific, personal form. What appears identical to the human eye may share almost nothing in common at the data level. The computer is not seeing the image. It is reading a numerical structure, and two images that represent the same thing visually can be built from entirely different data, depending on how and where they were made.

This relates to a broader discourse within the field of digital humanities. As Drucker (2013) has articulated, digitization constitutes not merely a neutral representation but rather a form of interpretation. Factors such as resolution, lighting conditions, and the medium of capture all influence the transformation of an image into data.³ My findings exemplify this argument concretely. The scanned watercolor and the Photoshop recreation are not simply two variants of the same image; rather, they represent two distinct interpretations, which the algorithm processes accordingly.

If we are building archival systems or image databases that rely on computational similarity to group and relate works, we need to ask whose sense of “the same image” is being encoded. A tool trained on pixel-level data will consistently separate a scanned physical artwork from its digital recreation, not because they are different images in any humanistic sense, but because they are different kinds of data.

Limitations and what comes next

Perceptual hashing assesses visual similarity at the data level. It does not establish authorship, confirm provenance, nor consider contextual factors. Outcomes may also differ based on the specific hashing algorithm employed, as various implementations assign different weights to visual features. This tool serves as one component within a broader interpretive framework, rather than substituting human judgment.

This assignment illuminated a perception that is both straightforward and profound. It is evident that the computer and the human eye do not observe the same aspects, even when examining the same image. The disparity between data and meaning represents the realm where the most compelling inquiries within digital art history reside. As Burdick et al. (2012) suggest, the significance of computational tools in the humanities lies not in their capacity to resolve questions, but rather in their ability to render certain questions newly answerable.⁴ This experience has prompted a question I was previously unaware of having.

The live output and ranked visualization are at the project web interface. Full code is on GitHub.

Professors HATE This One Weird Trick for Summarizing Your Research

There’s an old story, almost certainly apocryphal, about former British Prime Minister John Major asking Boris Yeltsin to describe the Russian economy in one word. Yeltsin said it was “Good.”

Seeking a bit more detail, Major asked Yeltsin if he could describe it in two words. Yeltsin replied, “Not good.”

Major finally asked for a three-word summary. Yeltsin’s response? “Not good enough.”

While the exchange is most likely a myth, there is something irresistible about its structure, and it was rattling around in my head during a recent session of my dissertation seminar.

During the break, I asked someone to sum up their partner’s dissertation in one word. They said: “Empathy.” I relayed the Yeltsin joke and we decided to test whether the structure held up in summarizing academic research. Two words: “Not empathetic.” Three words: “Not empathetic enough.” Gabby, whose research is about depictions of madness in modernist literature, thought about it for a second and said: “Yeah, that’s actually not a bad summary.”

We started going around the room with it. Spencer, who is working on trans bibliography, offered “hermaphrodite” as her one-word summary, which yielded “not hermaphrodite,” and then “not hermaphrodite enough.” Applied to my own dissertation, which focuses on contemporary poems written from the perspective of animals, I get:

Animal.

Not animal.

Not animal enough.

Which, for a 3-word summary of what is supposed to be a book-length scholarly work investigating the strategic deformation of syntax, figuration, and sound that poets undertake in order to make language register as issuing from a nonhuman consciousness, is pretty good.

The question, of course, is to what extent “not X enough” is actually a useful model for summarizing research and to what extent it just feels like it works because the rhythm is satisfying. But I do think there’s something real going on in the unfolding of X, not X, not X enough. So many research projects, across disciplines, are fundamentally about some quality or condition that is absent, insufficient, or misrecognized. The three-word version locates a gap, names an inadequacy, and implies a standard that hasn’t been met. It’s a tiny argument. It can’t work for everything. But it’s a fun test and I’d argue it extends even beyond academic research to artistic projects more broadly.

So, does this method work for summarizing your research or current project? Does it not work? Does it not work well enough?

I blinked and realized that Amanda Wyatt Visconti and I have been at the Scholars’ Lab for nine years as of April 24, 2026. Time flies. We typically celebrate by eating or drinking something sweet in the Lab (I’m still vibrating from the cream soda we had half a decade ago). We weren’t able to do so this year, so I thought I would share a quick post to mark the last nine years.

Nine things I’ve learned

1. Drink a glass of water and put both feet on the ground.
2. Don’t over-engineer things.
3. Slow down and appreciate.
4. Some things get easier. Some will not.
5. Write it down. It will be helpful for someone. That someone might be you.
6. Snacks always help.
7. Be explicit about what you need and what you don’t.
8. There are limits.
9. Structures give shape. Structures can be changed.

Nine memories to hold onto

1. Amanda biting into a lemon after eating miraculin.
2. The moment when each student steps into their own expertise.
3. Shane saying, “agenda item: be better friends.”
4. When I cried at the Afton overlook because I wouldn’t have to commute for work anymore.
5. Biscuit baking lessons on zoom with Jeremy and Amanda.
6. The support each colleague gave when I needed it.
7. The satisfaction that comes from seeing a student graduate as a DH practitioner, especially when you met them as a prospective student.
8. Those who are gone. Ryan. Leigh. Scott. Rebecca. Effie. Stéfan. So many others for different reasons.
9. All the unjust things. All the people working to make it better.

Nine things I’m grateful for

1. Our students. They’re the best.
2. Our colleagues. They keep me coming back.
3. To still be here, doing this.
4. Everyone who has taught me.
5. Those who are still here.
6. Those who made space for me when I burnt out.
7. Eliza, Ben, Ava.
8. That I was given a chance.
9. Every accident that brought me here.

It’s not lost on me that so many others deserve to be in stable employment who are not. I’m very lucky to have a job in this world on fire. So, I will close with gratitude and a determination to pay it forward to the next folks in line.

At the beginning of the spring semester, each of the Praxis fellows was asked to run a pen-and-paper workshop introducing the rest of the fellows and staff to a digital method. No screens, no code, just the low-tech materials needed to think through a concept with your hands.

The driving philosophy for my workshop came from a quote by Richard Bach: “We teach best what we most need to learn.” I found this a clarifying provocation because instead of asking myself thorny, stressful questions—What will I teach? What do I know well enough to even be able to teach? What will be interesting to the other fellows and staff?—I was able to begin with a simpler one:

What do I need to know?

That was easy. I need to know how to curate and organize works of literature into coherent clusters and how to present those clusters to an audience. The structure of my dissertation is somewhat unusual in that it isn’t organized into chapters based on individual authors—for example a chapter on Elizabeth Bishop, a chapter on the works of Ted Hughes, a third on Gwendolyn Brooks. Rather, my chapters are conceptually themed around three kinds of poems I believe to be undertheorized: poems written from the perspective of animals, poems mourning the death of an animal, and poems detailing an animal encounter. Because these are undertheorized categories, there is no obvious starting point, no established canon to lean on. One of the central challenges of this work is determining what poems to include and how to present them to a reader. Hence my workshop.

A Word Teeming with Life

I decided to begin with a brief etymological history. (Based on my previous blog post, you may sense that this is a common pattern for me, and you would be correct.) The word anthology can feel dead and tiresome, especially in the context of an English department, where it quickly becomes synonymous with The Norton Anthology of English Literature—the ubiquitous teaching tome that conjures up associations of imperialism, hierarchy, and canon-formation. But it felt important to go back to the original anthology, a word whose origins are quite literally teeming with life.

Anthology comes from the ancient Greek anthologia (ἀνθολογία), meaning “flower-gathering”—from anthos (ἄνθος), “flower,” and legein (λέγειν), “to gather or collect.” The word traces back to a specific act of curation: around 100 BCE, the poet Meleager of Gadara compiled what is considered the first true anthology, a collection of epigrams by forty-six Greek poets. He called it The Garland—Stephanos (Στέφανος)—and in his introduction, he compared each poet to a different flower, weaving them together into a literary wreath. From its very beginning, an anthology was never just a heap of texts. It was a garland—something deliberately woven, where the selection and arrangement were themselves creative acts.

I shared this with my fellow fellows to begin reframing the kind of work an anthology can do. The anthology is not a neutral container. It is an argument about what belongs together and why.

Aesop’s Fables

I then introduced the anthology-making exercise. I gave each pair of participants a set of eighteen Aesop’s fables—but only their titles and associated morals, printed on cards. I chose not to include the full text of the fables at the wise suggestion of Brandon Walsh, which saved on reading time and allowed me to include enough fables to make the anthologizing meaningful. Participants were asked to select, cluster, order, and title an anthology from this set of cards.

The decision to strip the fables down to title and moral started me thinking about metadata. In this exercise, what is normally considered metadata—the title, the summary moral—was itself the data, given that participants didn’t have the fables themselves to read. This necessarily informed how they constructed their anthologies. Several groups clustered the fables based on the morals, sorting them into thematic categories like greed, deception, or flexibility. But I noticed that these morals are open to interpretation. Given the cryptic nature of some of the fables, it is fully possible for a single fable to have several competing morals, all of which would in turn affect how it was categorized. Is “The Crow and the Pitcher,” a fable about a thirsty crow attempting to drink from a pitcher too narrow for its beak, about cleverness, persistence, or desperation? The answer depends on the anthologist, and each reading produces a different garland.

Titling conventions themselves proved significant. One participant (Shane, unsurprisingly) included only fables featuring dogs (and the dog-like) and titled his anthology “Canidae.” It made me realize how contingent such an anthology is on the metadata available. If the titles of the fables were different, if they foregrounded the morals rather than the characters, could such an anthology even exist? The exercise revealed something I hadn’t fully articulated before: that the categories we use to organize literature are not found but made, and they are made from whatever information is legible to us at the moment of sorting.

Wireframing

The second part of the workshop asked participants to take their anthology and imagine it as a website. Using markers and blank paper, each pair sketched wireframes for three pages: a homepage, a browse page, and a single fable page. The shift from editorial decisions to design decisions turned out to be more disorienting than I expected—and more productive. Suddenly the question was not just what belongs together but how does someone move through what belongs together.

One of the most interesting wireframes came from Shane, who designed a single fable page that presented two fables simultaneously. At the top left of the page, a small illustration accompanied the first line of “The Town Mouse and the Country Mouse,” reading right-side up. But the next line down was the last line of “The Fox and the Grapes”—printed upside down, beginning from the bottom of the page. The two fables were enmeshed, line by line, so that as you read downward through one fable you were also reading upward through the other, the right-side-up text and the inverted text meeting in the middle. Even the pairing was deliberate: the contentment of the country mouse set against the fox’s sour dismissal of what he cannot reach.

To sharpen the design conversation, I borrowed a technique I’d been advised to try (also from Brandon): after the initial wireframing round, I asked participants to create a deliberately bad wireframe, then swap it with another group to fix. It is easier to talk about good design in the context of bad design, and the exercise gave everyone a shared vocabulary. But Shane’s wireframe complicated things beautifully. The group that received it didn’t want to “correct” such a fun and original idea (and who could blame them?) Their fix was to simply present the two fables one after the other, essentially normalizing the layout. It was the responsible design choice. It was also, in some way, a loss. Watching it play out, I realized the exercise had surfaced a genuine tension at the heart of digital presentation: between accessibility and experimentation, between making something usable and making something that rewards a different kind of attention.

This, I think, is the crux of the digital anthology problem and the reason I designed this workshop. The editorial and the digital are never really separate; they shape each other. The way you organize a collection changes what kind of interface it demands, and the affordances of an interface change what kinds of organization are even possible.

Anthologies Reimagined

But why stop at a website? The wireframing exercise opened a door in my thinking that I’m still walking through. If an anthology doesn’t have to be a book—if it can be a website with its own navigation and architecture—then what else could it be? What would an anthology you could walk around in look like? What if it weren’t a book to flip through linearly but something more like a room in a house you could dwell in. Where the poems on the walls changed depending on which door you entered through, where proximity meant something, where you could sit with a cluster of texts the way you sit in a corner of a room?

I don’t have answers to these questions yet. But I think the workshop helped me understand why they matter. Meleager’s original garland of poems was a wreath, a circle with no fixed beginning or end and where each flower touched the ones beside it. Somewhere between the garland and the Norton, we flattened the anthology into a line. The digital gives us a chance to unflatten it, to think about what it means to arrange literature not just sequentially but spatially, relationally, experientially.

We teach best what we most need to learn. I walked into that workshop needing to think more carefully about how the structure of a collection shapes the experience of reading it. I walked out with eighteen fables, four very different garlands, a handful of good (and bad) wireframes, and a vision of an anthology as a room. That feels like progress.

I. Have. A. Website. ✨ https://winnieepm.github.io/ ✨

As this academic year is coming to an end, I don’t have a dissertation to defend yet, but I did publish a public website freely hosted on GitHub Pages—it’s been three years in the making. What took so long, you ask? A combination of reasons, with two that stand out. One, I couldn’t make up my mind about the method for making it or the design. Too many choices, possibilities, tools to try, strong opinions, use-cases. Two, I chose to code my own website, and self-learning coding while you’re a full-time doctoral student in the humanities brings its own significant systemic and personal challenges: there’s no reward for the quirky extra major, at least not immediately. So, why do it at all?

I chose to explore minimal development stacks because building them forced me to learn how they work. At what point is HTML and CSS alone not enough? Why do you need a framework? What decisions draw projects to content managers or static websites? When is a database required?

The ubiquity of websites, especially for professionals today, ticked my curiosity to learn how they worked to produce an online presence of a person IRL, but popular options like Wordpress, Wix, and Squarespace, offer limited out-of-the-box theme options to display and manage your content. Also, it will typically cost you to access their full library of design and layout resources to make a personalized website that uniquely represents you and stands out. Each of these also require constant updates to ensure the site’s safety and functionality, which means your website can easily break, or be exposed to cyber attacks, if you fall behind updates.

Though the CMS (content management system) route makes sense for many, I had questions about web sustainability, development, and design that drove me instead to pure HTML/CSS pages, and static site generators (SSGs), for making myself a website I could style and organize at will locally. SSGs take in textual content written in markdown, your designated layouts, and data, they then process all these files locally to produce a version of your website in a set of HTML files ready for hosting. This simple production pipeline makes for fast, flexible, and design agnostic webpages that are so small in file size they can fit in a 1GB flashdrive.

But the benefits come with a steep learning curve. It requires great learning effort, if you’re unfamiliar with coding, and a significant time commitment. For collaborative projects, creating different user access levels and credentials is not supported and would require coding a custom solution. You also need to use a code editor for updating the website, which is something not everyone is comfortable doing or needs to learn.

I built and continue developing my own portfolio website using the 11ty framework, an SSG based on JavaScript that has become popular in the past years because it’s easy to set up, compared to others like Jekyll, and it makes no decisions on how to style your projects out of the box. Honestly, I wasn’t aware of how long it would take me to learn all the things I’ve come to learn up until this point, but I also don’t regret it because I have been able to support other digital projects just because I have spent enough time banging my head against the wall to setup up and customize 11ty. If I had to do it all over again, I would, though I’d focus more on simplifying my goals and tasks, rather than setting out to accomplish really ambitious projects that constantly feel out of reach while you’re working on them.

Anyway, I made my website. It’s live, it’ll keep growing, and it’s mine.