Stravinsky in Urbana: The Case for the Evolution of Digital Library Software Design to Support Musicological Scholarship

1.1 Designing for discoverability for different kinds of music information retrieval

Within the field of music information retrieval (MIR), the initial emphasis was understandably on how to help people retrieve the music that they want to hear, drawing on the larger body of work on information retrieval: ‘Following the practices of text information retrieval, MIR treats digitally encoded music as information‑carrying documents’ (Lewis et al., 2015, p. 636). As early as 2010, MIR researcher Lee explored known‑item searches in the context of music‑information seeking (Lee, 2010). Her work clearly illustrates that the users of MIR systems come to perform their searches using a wide variety of techniques and prior knowledge (including a number of metadata elements). This phenomenon is sometimes overlooked in the modern MIR literature, which tends to focus on music–content matching approaches. However, there is a growing interest in supporting scholarly research on music, again well illustrated by Lewis et al. Thus, we might draw a distinction between music‑(information retrieval) (M‑IR) and (music information)‑retrieval (MI‑R)—that is, between retrieving the music (M‑IR) and retrieving information about the music (MI‑R). In this study, we focus on the latter and its need for diverse, distributed, heterogeneous, and sometimes fragmentary pieces of information. Within M‑IR, there has been a widening of approaches to retrieving music that may be of interest, from known‑item searching to embracing recommendations, browsing, and facilitating serendipitous discovery (see, e.g., Schedl et al., 2013; Knees et al., 2020). With the approaches outlined here, we wish to contribute to something similar for MI‑R, particularly for supporting scholarly discovery, in line with broader trends to support information practices in the humanities (Bulger et al., 2011). For scholarly work, including in MI‑R, there is often a greater need to uncover interesting connections between items of interest (which can be disparate and fragmentary) rather than finding and retrieving the one best piece of music for a user (M‑IR).

Our work is in alignment with Gotham et al.’s vision of working toward an ‘Everything Corpus’: ‘a collection of not only source material (e.g., audio) but ancillary and supportive data’ (Gotham et al., 2025, p. 71). This can include ‘documentary evidence recording the compositional process’ and ‘information about the individuals involved, their roles and relationships (both musical and social‑societal)’ (Gotham et al., 2025, p. 76), as well as the venue. As they note: ‘Writing about music in the popular press is rather under‑explored by MIR’ (Gotham et al., 2025, p. 79). All this necessitates having multimodal datasets and multidisciplinary design teams, as exemplified in our research.

1.2 Designing for a few scholars as a means of designing for many

As a case study, Stravinsky in Urbana followed a not‑uncommon pattern of humanities scholarship where a researcher serendipitously encounters an item of interest and then explores related collections across different archival resources. In a more traditional, pre‑computer world of humanities scholarship, this usually involved travel to different sites that house primary and secondary materials (libraries, museums, and archives). The scholar would take notes and then integrate findings derived from multiple different sources into a report, book, paper, exhibit, or other scholarly output. The integration would occur not only in different locations but also at the scholar’s own desk—often involving copious amounts of paper, spilling onto the floor. The promise of digital humanities is that digitization can significantly improve access and reduce travel; a topic that has remained pertinent within the field, alongside other elements of accessibility (Horava, 2010, p. 147).

Digital scholarship, however, still has to be able to cross application boundaries between different databases, DLs, and other digitization projects—even if that movement between applications can all be done without leaving one’s desk and desktop PC. In this study, we had the opportunity for expert developers to build add‑on resources to a DL in order to help the humanities scholars with their investigations. By reflecting on this rather resource‑intensive and inevitably rare opportunity, we can consider how best to develop generalizable resources for far more researchers across multiple DLs.

The approach of initial development for an ‘n‑of‑1’— that is, a design approach centered on a single, well‑defined user or use case—is of growing interest in software design of novel technologies (Li et al., 2010), allowing for a careful consideration of ecological validity (Rogers and Marshall, 2017; Pruitt and Grudin, 2003) in a very constrained case. This can then be used as a basis for scaling up. The approach bears similarities to design with and for personas (Pruitt and Grudin, 2003)—but, here, we have designed for an actual use case rather than a fictional case that is highly representational of many use cases. It can be contrasted with other approaches to designing for a large number of people, but where certain oversimplifying assumptions can render the result less than ideal for almost everyone.

DL‑based scholarship does not stop with finding known items in a DL. Rather, a digital project and its outcome may:

gather primary sources or evidence derived from sources, and integrate those sources with annotation, contextual information, secondary sources, or functional and interactive elements in order to construct platforms for learning and research (Fenlon, 2020, p. 2).

We need better support for browsing and serendipity. We also need to be able to integrate resources from multiple DLs and archives and in multiple formats. This requires assembling the materials, analyzing them individually, and comparing and connecting different materials. Different materials—for example, musical scores, recordings, concert programs, posters, handwritten letters, and newspaper articles—require different kinds of analysis. Finally, the end result of the scholarship needs to be sharable, in an appropriate format, with others.

Fenlon (2019) explores different types of digital humanities collections, showing that a good DL will explicitly support a rich diversity of use cases. She notes, ‘The outputs of DH [Digital Humanities] research are increasingly media‑rich, data‑centric, interactive, dynamic, interlinked, and subject to indefinite evolution.’ As a result, there is a need to support not only the content within a collection but also, just as importantly, the interrelationships within it and with the context surrounding it. Furthermore, much content may be external to the collection in question, residing in and linked to or from a number of other collections at other sites. This is especially important when the research work is ‘gathering sources to provide evidence for a specific interpretive or analytical goal’ or to ‘reconstruct and expose hidden relationships and personal histories’ (Fenlon, 2019, pp. 141–42).

Different DL platforms emphasize different aspects of scholarly production, reflecting their historical origins and design priorities. Many general‑purpose open‑source systems are optimized primarily for information retrieval, search, and discovery and are particularly effective at supporting known‑item searches. Examples include DSpace,¹ Fedora‑based repository frameworks,² ePrints,³ and Greenstone,⁴ each of which provides robust mechanisms for ingest, metadata management, indexing, and web‑based access, albeit with differing assumptions about collection structure, workflow, and modes of use. Comparative studies of open‑source DL and repository platforms highlight both their shared core capabilities and their divergent strengths in areas such as metadata modeling, extensibility, preservation support, and user‑facing presentation—see, for example, the works of Pyrounakis and Nikolaidou (2009) and Rathour and Sahu (2011). They are typically optimal for use of their own materials and, in some situations, have features for assembling and making connections (serendipity) between materials in their collection. However, they can be less helpful for assembling and making connections between materials from different online collections.

Some, often bespoke DLs have processing capabilities for analyzing certain kinds of materials. For example, DLs for music content may have specific music‑analysis features (Abdallah et al., 2017), DLs with large numbers of handwritten articles may have features for script analysis (Muehlberger et al., 2019; Terras et al., 2025), DLs with lots of scanned documents may have features for image analysis (Contreras and Narros, 2025; Smits and Wevers, 2023), and so on.

In this article, we situate the work undertaken in the context of general‑purpose DL design and describe how we have shaped it to develop a workflow that is supportive of the needs of a musicologist in pursuit of constructing and analyzing event‑focused, multimodal, and source‑rich historical narratives. The chosen case study draws from a variety of sources that document the presence and interactions of the Russian‑born modernist composer Igor Stravinsky and members of his family—principally his son Soulima—at the University of Illinois, where Soulima held a faculty position, and among the local communities of Urbana‑Champaign. Focusing on musicians, audiences, and events at the University of Illinois (including the Krannert Center for the Performing Arts), the Stravinsky in Urbana project demonstrates some of the values, tools, and methods of the InterMusE project in action; it also illustrates how further development and refinement of this data‑rich digital environment has the potential to enable a group of researchers to develop an event‑focused historical narrative deeply embedded in and closely linked into surviving documentary sources of many types and formats that would otherwise be difficult to assemble.

The details provided happen to be for the open‑source DL Greenstone3, but the workflow described—and, consequently, the functionality needed by the DL—is broadly applicable to DSpace, Fedora, and other general‑purpose DL platforms (Witten et al., 2010). In particular, through this article, we make the case that this work—via an n‑of‑1 case study—provides a roadmap for a way that DL software may be further developed to better support this form of musicological scholarship.

This article extends the details provided in Goldstein et al. (2024) and additionally reports on more recent work. It is structured as follows. We start, in Section 2, by providing some background to the Stravinsky family’s connection to Urbana‑Champaign and the archival materials involved. In this section, we also describe the initial use of DL software in assembling the collection. Section 3 details the development of an environment for enhanced scholarly study that integrates tools such as audio analysis and image‑based document annotation, leading to a set of design principles that encapsulates what a DL platform needs to provide to support such enhanced capabilities. Following this, we discuss the impact of these developments on musicological research practices. In Section 5, we conclude by reflecting on the requirements of this case study and how these have prompted a broader rethinking of DL architecture.

2.1 Location

The story of Stravinsky in Urbana began in 1949 with a post–World War II drive by the director of the University of Illinois School of Music, John Kuypers, to increase the prestige and visibility of the School through the Festival of Contemporary Arts, which occurred prior to the construction of the Krannert Center in 1969 (Silverberg, 1995, p. 60). For Stravinsky in Urbana, three festivals in 1949, 1950, and 1963, respectively, would have particular importance. The 1949 festival saw Igor Stravinsky (1882–1971) and his son Soulima (1910–1994) appear as headline artists: alongside the University of Illinois Sinfonietta, they performed a set of Igor Stravinsky compositions, including the Suite from Pulcinella for chamber orchestra (1922) and the Concerto for Piano and Orchestra of Wind Instruments (1924).⁵ The InterMusE team was able to capitalize on the potential for drawing this performance into the project in 2022, when a graduate assistant (Karina Cooper⁶) working at Illinois’ Rare Book and Manuscripts Library came into contact with the Urbana musicology professor on the InterMusE team, who had previously seen possibilities for linking a Stravinsky‑focused project to Krannert performances by way of a commonality in Stravinsky’s Pulcinella. The faculty member had requested the 1949 Pulcinella materials, including documents from Igor Stravinsky (Stravinsky and Kuypers, 1949)—photographs, letters, rehearsal directions, and stage information— for display during a class visit. These materials, and the graduate assistant’s identification of historical materials online, provided the students with helpful context and acted as a foundation for our future work.

The 1949 performance, in particular, is significant both for its impression on Igor Stravinsky—who noted in a letter to his close friend and personal assistant, the conductor Robert Craft, ‘O Bob! Two (2) wonderful concerts: URBANA’ (Craft and Stravinsky, 1979, p. 425)—and in the possibility it opens up to model a decentered narrative of the study of culture and performance away from major hubs. Igor Stravinsky returned in 1950 for another performance with the Festival of Contemporary Arts, and Soulima also returned, performing as an artist in the Star Course series, and stayed as a soon‑to‑be faculty member for piano at the University (Garling, 1950, p. 6).

Soulima’s presence at the University of Illinois would continue to keep Igor Stravinsky anchored to the institution. Igor would introduce Pierre Boulez for a lecture at the Festival of Contemporary Arts in 1963 (Boulez and Stravinsky, 1963). Stravinsky’s compositions would take on a new level of popularity with University ensembles after 1949, with the Pulcinella Suite and Octet for Winds seeing repeated performances, and the Pulcinella Suite would take on particular significance when it was featured as the accompaniment to the American Ballet Theatre’s performance of Pulcinella Variations, one of the events that marked the opening of Krannert Center in 1969.

2.2 Connections and scope

The Stravinskys’ presence and impact at a college town in the American Midwest have not been documented in wider academia to date, with most scholarship emphasizing the composer’s greater connections in London, Paris, and New York. For Igor Stravinsky in Urbana, connections are decentralized and occur largely through contact with Soulima. The initial phase of this project focused on a study of concert‑related ephemera archived at Krannert Center—primarily a large program‑scanning project that ran from 2022 until 2023, taking a chronological approach. The limitations of this soon became apparent due to the volume of material and the physical storage media of the programs—large bound books that required specialized scanning hardware to process, as they could not be unbound for the purpose of scanning. The scanning project attempted to resolve the problem of volume of material by shifting to a ‘slice‑history’ model, focusing on specific sets of years (1969–1975, 1989–1995, and 1999–2005). Slice history had been used by members and associates of InterMusE in the AHRC‑funded Concert Life in Nineteenth‑Century London database project from 1997 and was adapted from a concept established by Australian historians (see Bashford et al., 2002, p. 3).

While this work was underway, more information came to light regarding the 1949 concert involving Igor Stravinsky. This synchronized well with the work completed for 1969–1975, which included multiple performances of Pulcinella and several significant concerts in response to Stravinsky’s death in 1971. With a clear case study in view and concert artifacts ranging across half a century, Stravinsky in Urbana was gathering momentum. The project then proceeded to emphasize Stravinsky‑related material involving either the composer, his compositions, his son, or his son’s compositions. This web of material made it possible to sketch connections between otherwise nominally separate archives in a larger picture of sounds, words, and images. Management and presentation of this material were then explored through initial use of the Greenstone3 DL platform.

The majority of the digital material that went into this version of the DL was in the form of concert programs. As Soulima’s and Igor’s personal correspondence on the topic of study was limited, additional effort was spent augmenting the programs through existing digitized archives, such as those of the student newspaper, the Daily Illini, and the student yearbook, the Illio. These print sources were further supported by audio media preserved by the Sousa Archives and Center for American Music on campus, which holds a wealth of audio sources stored on media ranging from acetate discs to already digitized versions.

The gathering of this content unfolded in an organic manner: concert programs would provide basic threads of information, which could then be ‘pulled’ to acquire additional materials. There were limits to this approach, however; not every concert was digitized or recorded, although it was fortuitous for the project that Stravinsky was a famous figure at the time, which allowed for a higher than ordinary level of preservation of materials.

This larger process relied on a certain amount of asynchronous research and preservation alongside some serendipity; through this activity, it became apparent that past archivists and others involved in this broad act of preservation had felt the need to preserve as much material as possible, and, by using a common element—concert history—alongside digital storage and search methods, it was possible for us to cultivate serendipity to collate the larger body of work. Ultimately, the assembled digital material included photographs, unpublished materials (such as rehearsal notes and diagrams), audio samples from performances, concert programs, letters, lectures, and interviews conducted among the community.

2.3 Initial DL experimentation

Before we describe the workflow that was ultimately developed to support scholarly analysis through the Stravinsky in Urbana collection, it is instructive to look at the results of the initial period of experimentation with the DL software. Figures 1–4 show a representative sample of snapshots taken from the DL for, respectively, browsing the content, viewing one of the scanned image documents, the result of searching within the collection, and the landing page for the collection.

Figure 1

Figure 2

Figure 3

Figure 4

With the metadata associated with the DL collection, there are a variety of ways to browse the collection—for example, by title, document type, archived location, and by year. Figure 1 shows the user part‑way through accessing the content by document type. Folder icons are displayed alphabetically in a vertical list. Types of documents include audio, interviews, letters, newspapers, photographs, and videos. The folders can be interactively opened and closed to reveal the titles of documents of that type, also ordered alphabetically.

Clicking one of these documents takes the user to Greenstone3’s Document View page. Given that Greenstone3 is designed to be agnostic toward the types of documents included in a DL collection, this is a highly configurable component of the DL system. We return to this point in Section 3, where we discuss the enhanced version of the DL that followed this one.

Figure 2 shows the default document view provided through the software when a user accesses a scanned document. Individual pages can be viewed through clicking on vertically numbered pages displayed down the left‑hand side. The snapshot in the figure was taken with page 12 opened, resulting in a screen‑resolution version of the page being displayed (but note also that this has been cropped to save space). Located in the upper right‑hand corner of the main document page is an interactive thumbnail preview inset that has been designed to be reminiscent of print‑preview dialogs. There are also controls that:

• Produce a full‑screen ‘slide‑show’ style view of the document pages;

• Alter whether images, the text for the pages (typically the result of an OCR process), or both forms together are displayed;

• Cause all the pages in the documents to be opened or closed; and

• Provide a cursor‑over‑image magnifying feature.

In Figure 3, the query term ‘Boulanger’ has been entered in the search box, and the results of a full‑text search across the collection are displayed in the main page area. Clicking on one of these search results takes the user to the Document View page for that item. Through the faceted search box inset on the right‑hand side, the returned results can be further filtered by document type. There is also an Advanced Search page, accessed through a link provided below the Search button. Rounding all of this out is the About this Collection page, shown in Figure 4. Here, the musicologist has provided some text details about the content that has been brought together to form this DL collection. It is text that is ultimately intended for general consumption once the formed digital resource is ready to be made public. However, the phase of development in which we encounter the DL collection in Figures 1–4 is still only intended for internal consumption by the project team.

Some indicators of this can be seen in the figures, such as the Not Cleared for Publication folder that appears in the list of document types in Figure 1 and the browse by Unpublished Content tab in the main navigation bar. We expand upon this notion of ‘internal use,’ along with the interactive process the musicologist on the project team goes through, in the next section, where we describe the workflow used to develop the DL collection.

2.4 Workflow

The key software component used to develop this DL collection and to manage it over time was the Greenstone Librarian Interface (GLI). This provides a graphical user interface for the underlying DL infrastructure and allows users to gather sets of documents, import or assign metadata, build them into a Greenstone3 collection, and serve it from their website. It supports the following activities:

1. Opening an existing collection or defining a new one;

2. Copying documents into it, with metadata attached (if any);

3. Mirroring documents from the web or other protocols such as the Open Archives Initiative’s Protocol for Metadata Harvesting (OAI‑PMH) if required;

4. Enriching the documents by adding further metadata to individual documents or groups;

5. Designing the collection by determining its appearance and the access facilities it will support;

6. Building it using Greenstone3;

7. Previewing the newly created collection from the Greenstone3 home page; and

8. Exporting the collection to other formats such as MARCXML, FedoraMETS, and DSpace.

Figure 5 shows GLI in use. Prominent in its design is its use of six tabs—Download, Gather, Enrich, Design, Create, and Format—which broadly correspond to Activities 2–7 above. The options to open (Activity 1) and export (Activity 8) a collection are accessed through the Graphical User Interface’s File menu.

Figure 5

Figure 5 shows the latest incarnation of GLI, originally developed as a Java‑based desktop application, which has now been ported to WebSwing,⁷ meaning it can be accessed directly in a user’s web browser. Once the digital librarian has been authenticated by the DL site, they have access to a comprehensive suite of capabilities to create and adjust the design of new and existing collections.

In the context of the Stravinsky in Urbana project, the musicologist assumed the role of digital librarian, being involved in the development of the DL structure in addition to the active research process. From a technical standpoint, the pattern of use of the DL software is an iterative one, whereby a ‘rough‑cut’ cloud‑shared drive, developed by the team to store digitized versions of located documents, is transformed into a metadata‑enriched and increasingly refined DL collection. Unlike the shared‑drive approach, which is restricted to a single folder‑based hierarchy, a key advantage of our DL approach is its open‑ended ability to create additional ways by which the materials can be organized and searched.

From a scholarly perspective, as a musicologist obtains a deeper understanding of the material before them, they craft new metadata structures that reflect their understanding, which in turn evolve how the DL is formed, much like the looping process we described in Dix et al. (2014). Thus, as a musicologist progresses to writing a scholarly article, both the article and DL collection are improved through a process of mutual recursion. The end result of this mutually reinforcing process is a piece of scholarship more strongly grounded in, and linked to, the supporting evidentiary materials.

3.1 Enriched document view for audio

The first refinement made to the functionality focused on the DL Document View and how audio files were displayed there. The initial design made use of the DL’s default capability, which is to display a table of metadata that provides general information about the document, such as its title, the year of its publication, and its document type. One of the rows displayed is a hyperlink to the source document, so the user can download it and then open the file using a relevant software application they have installed on the desktop PC. In the case of an audio file, double‑clicking on a downloaded file will cause it to be played by the default audio app.

To provide the ability to listen to—and study—the audio directly in a web browser, work centered on the inclusion of two JavaScript libraries: Wavesurfer⁸ and Tartan‑ify.⁹ The former allows an audio file to be played directly in the web browser, and the latter performs audio‑based content analysis to display a ‘heatmap’ as a two‑dimensional visualization representation.

Figure 7 shows the result of this work. Based on a document’s Document Type metadata value in Greenstone3, its configurable Document View is set to call Wavesurfer with the source‑document hyperlink to the audio file. In addition to playing an audio file, Wavesurfer can display a waveform rendition of the audio, along with a graphic equalizer feature to modify the audio being played in real time, which we took advantage of to analyze audio data.

Figure 7

Below the Wavesurfer component, the Document View is set to call Tartan‑ify with the same source‑document hyperlink. In the first instance, this produces the button ‘Analyze Audio’ (not shown). Pressing it results in the browser performing the necessary audio processing to produce the self‑similarity heatmap seen in the figure, below the audio waveform. With a little bit of custom JavaScript to synchronize the two components, pressing the audio‑play button triggers the white corner‑rectangle cursor that moves through the self‑similarity map as the audio plays (and vice versa). The self‑similarity heatmap also supports a ‘magnify view’ cursor feature, which is also shown in use in Figure 7.

3.2 Text annotation of scanned images

The second refinement made was also focused on enhancing the DL Document View for the collection. This time, the refinement work centered on the display of scanned documents. Through work on the sister InterMusE project, the British Music Society Concert Ephemera DL collection, the Mirador Document Viewer¹⁰ had been integrated into Greenstone3. While, in principle, the Mirador Viewer’s integration plays out in a similar way to Wavesurfer and Tartan‑ify, requiring the inclusion of a JavaScript library to access the functionality it provides, this particular library places stricter requirements on the functionality that the web server must provide. The two critical requirements for our use were (i) that the images to be displayed must be accessible through an IIIF‑compliant server and then (ii) to support the user adding annotations to the images, a compliant Annotation server must be available, such as OpenAnnotation.

As part of its modular design, Greenstone3 offers an extension mechanism for enhancing the functional capabilities the DL server provides. In the British Music Society Concert Ephemera collection, we had previously taken advantage of this, activating the Cantaloupe¹¹ extension, which provides IIIF Image Server functionality, as well as the Apache Jena Fuseki¹² extension, which provides a Triplestore capability, allowing OpenAnnotations to be supported.

While the implementation work needed to combine these components was notable (Bainbridge et al., 2023), this work had already been completed, and so it was a straightforward matter to transfer it to the Stravinsky in Urbana collection. Figure 8 illustrates the result of integrating this into the collection, which shows the full program of events at the 1950 Festival of Contemporary Arts.

Figure 8

In the Mirador Viewer, a comparable interactive thumbnail view is displayed horizontally along the bottom of the page. A click on a thumbnail causes the main display area to update with that page. The result of the OCR’d text is displayed down the left‑hand side. With the annotation feature in Mirador active, an authenticated user is able to edit the OCR’d text and also add new annotations. Annotations can be a combination of text and graphics, positioned anywhere over the image. Further, such annotations get included as metadata in the DL, which subsequently allows them to be searched. Through the control settings icon located in the upper‑right of the displayed page, the user can access image‑control settings that allow them to adjust contrast and brightness and to rotate the image, among other things.

3.4 Derived design principles

Figure 9 presents a schematic overview of the key software components of the developed DL architecture and their relationship to the workflow designed to support a musicologist’s study. The upper portion of the figure captures the iterative process in which the DL software (Collection‑Building & DL Server) acts as a conduit between the source‑digitized content (Digitization & Staging) and the evolving structures of the DL collection (User Interface).

Figure 9

Over time, the scholar’s interactions center on the alternating use of two tabs in their web browser. One is the WebSwing‑based GLI browser tab, which allows the scholar to access and adjust the file structure of the digitized, collated files and to enrich the content with manually assigned metadata. After (re‑)building the collection in GLI, the scholar switches to a second browser tab to preview the latest incarnation of the DL collection. Ideally, the affected change is as intended, with the evolved representation helping to inspire further insight. In other cases, the intended change may not occur due to a misunderstanding of how the DL is configured. In either situation, the next step is typically to return to the GLI tab, this time focusing on the Design portion of the interface to make further adjustments. The process then repeats.

The UI features provided in the developed DL collection make use of Greenstone3 extensions. Figure 9 highlights which of these require additional server‑side functionality—the IIIF Image Server and Annotation Store—and which operate entirely within the user’s browser—the Mirador Viewer and Audio Tools.

From our experience, a number of design principles can be derived for other general‑purpose DL platforms. A fundamental requirement is that the system be agnostic to the metadata sets that are used and ideally allows for the formation of ad hoc metadata sets. This flexibility is critical to supporting the exploratory development of an emergent DL structure. In Greenstone3, this is achieved through the Greenstone Editor for Metadata Sets (GEMS), which can be launched from within GLI (omitted for brevity in the above description but implicit in the development of metadata such as siu.Organization).

It is also essential that the scholar be able to exert control over, and shape, the formation of the DL collection. This equates to access to the DL’s collection‑building and configuration tools. When such access is provided via the web browser, it also facilitates the sharing of scholarly output with others, as it allows for the resource being shaped to be online. In Greenstone3, this capability is realized through GLI, with the musicologist effectively taking on the role of digital librarian.

To support the expansion of functionality provided for scholarly study, the DL software—and, in particular, its interface—must be customizable. When such functionality is delivered entirely through the web browser, it is relatively straightforward to manage from a software‑engineering perspective. This approach underpins the audio‑based self‑similarity matrix shown in Figure 7. More generally, this principle extends to any JavaScript‑based or WebAssembly functionality that can be introduced to support the scholar’s engagement with music content. In Greenstone3, this is enabled through its XSLT mechanism, which decouples underlying document representation from the interface presented to the user.

For more deeply rooted changes in DL operation, our experience indicates that the DL platform should also support the expansion of server‑side functionality exposed via service or API calls. This capability underlies, for example, the integration of the annotation‑based image viewer into the developed DL collection. In Greenstone3, this is achieved through the document‑processing ingest plugins in combination with modular back‑end functionality implemented through servlets and again makes use of the XSLT mechanism to customize the interface.

For interested parties, the source code for Greenstone3 is available via its subversion server.¹³ The configuration files for the Stravinsky in Urbana DL collection are incorporated into the main InterMusE installation. These files are installed using Greenstone3’s get‑installation script, including a README file with more detailed setup instructions.¹⁴

A publicly available version of the collection can be accessed through the main InterMusE DL site:

• https://intermuse-dl.datatodata.org

The enhanced Document View shown in Figure 7 for displaying audio‑based music content can be accessed directly via:

• https://intermuse-dl.datatodata.org/greenstone3/library/UofI_Orchestra_Stravinsky_undated_sample

Note: given this is a publicly accessible version, Greenstone3’s security module has been used to password‑protect in‑copyright documents in the collection.

4.1 Limitations of the approach

While the Stravinsky in Urbana case study demonstrates the potential of extending general‑purpose DL platforms to support musicological research, several limitations should be acknowledged. Foremost, the work has not been subject to formal evaluation or validation in the sense typically expected in human–computer interaction research. The approach has instead been developed through a practice‑led, iterative process grounded in close collaboration between domain experts and software developers. While this has enabled rapid refinement and strong ecological validity, it limits the extent to which the effectiveness of the system can be quantified or compared with alternative approaches.

A study that seeks to emulate the iterative DL elements of this work, while scaling to a larger cohort of participants, represents a challenging but achievable next step. Within the musicological domain, one possible approach would be to conduct a structured evaluation involving a cohort of graduate students, each working with their own instance of a DL collection centered on a common subject or corpus. Such a design would allow for comparative analysis of how different users engage with iterative metadata development and collection‑building workflows.

A further limitation is related to the architectural principles explored. While these are intended to be generalizable—such as metadata flexibility, iterative collection‑building, and extensible interfaces—their implementation in the reported work was realized through a particular set of tools: Greenstone3 for the DL infrastructure, Mirador Viewer for scanned images, and Wavesurfer and Tartan‑ify for audio‑based features. These tools should not be understood as strict requirements of the approach; rather, they reflect choices shaped by practical availability, prior expertise, and compatibility with the particular goals of the case study. Alternative platforms and tools could equally have been employed. As a guiding principle, from the insights we have gained through the work, we emphasize the value of selecting technologies that support openness and extensibility within an existing DL framework.

4.2 Location, status, content, and functionality

Reflecting on this particular case study of Stravinsky in Urbana, we can see themes that generalize to other contexts and possible kinds of scholarship that become more feasible with advances in DL technologies and digitizations. Much early work in DLs was based on a tradition of database design that aimed to optimize the efficiency of retrieving one or more particular items in the database of digitized materials that matched specific search criteria. This could be by issuing queries for particular metadata values or for strings of text in the digitized elements (full‑text search). As with many kinds of information retrieval, substantial effort was devoted to what is often called ‘known‑item’ search.

However, scholarship in traditional physical libraries and archives does not solely involve retrieving a few items with particular characteristics known in advance—the essence of searching. Scholarship additionally involves browsing—more exploratory activities that can enable the discovery of items that may not have been possible to specify in advance. Serendipity plays a significant role, but a skilled seeker of information can employ a range of techniques to increase the odds of uncovering items of interest and importance. With the great strides made in optimizing search, DL developers can give more attention to features, functionalities, and interfaces that also facilitate browsing, as noted in Section 3.1. Here, the writing of a scholarly article served to improve the DL at the same time, through iterative improvements to metadata, which in turn aided future browsing and discovery. Further developments along this line are possible, especially through adjustments to the interface, particularly as the volume of information becomes greater but also more defined (Cowgill et al., 2024).

With close collaboration between scholars and DL developers, ideas for improved functionality and interfaces can be derived from particular use cases, which then prove useful for future scholarly investigations. The connections made in the work reported here involved techniques that have traditionally been deployed in scholarship undertaken in physical libraries and archives—but they now can also take advantage of materials that have been digitized and made available in a DL that supports more browsing‑based discovery as well as search. Recalling the use of the Mirador Viewer and the example of Figure 8, various elements, such as OCR and annotations, can be used to sharpen the specific details of an element in a DL collection and assign new metadata that better reflect the research process—in this case, connections to Igor Stravinsky—and the context of items within that collection. What previously would have existed as a physically written note, or attachment, is now directly viewable by the researcher and future researchers and is now in proximity to relevant collection items. With the potential for the addition of future tools, these otherwise dissevered ephemera can be more easily joined together; because these elements exist within the DL, the transition of study for future research and researchers is eased. Further collaboration has also occurred between researchers as files and formats have been added, at times as experiments in miniature, such as the integration of .ogg files in audio formats. This collaboration acts as a bidirectional link between the perspective of musicological scholarship and software architecture, with each informing and refining the other.

Digitization efforts often begin with the more prestigious materials in elite locations. However, as further efforts at digitization continue and the costs of the needed hardware fall, it becomes feasible to digitize other materials that also have great value but which have been somewhat marginalized. The InterMusE project overall and this particular case study are a nice illustration of this.

Concert programs, brochures, and other ephemera are conventionally treated as less prestigious than other documents but, once digitized, become accessible to a wider range of people who might be interested in the stories that they have to tell and the connections that can be made across documents to reveal a richer picture. Similarly, cultural events in places such as London, Paris, and New York may well receive the first attention of early digitization efforts, but there can also be activities of excellence and both local and international cultural relevance in places such as Huddersfield and Urbana. DLs offer the possibility to help artifacts and locations that may be overlooked become more discoverable.