Category Archives: Projects

Digital Medieval Studies

How DH Has Helped Me Make Sense of My Field

Early in my graduate studies, when I took the Digital Humanities Colloquium at Boston College, the professor had us read a series of definitions of “the Digital Humanities” to introduce us to the scope of the work we might be doing. Many of these definitions rightly focused on interdisciplinarity, computational analysis, multimedia pedagogy and scholarship, and the need for an umbrella term to encourage institutional support and funding. One definition, however, continues to resonate with me as it is particularly germane to my own field of medieval studies: “[u]ltimately, what sets DH apart from many other humanities fields is its methodological commitment to building things as a way of knowing.” This emphasis on DH as primarily a methodology of building things clarifies what I can do with DH. When conceptualizing a new DH project, I begin by asking myself, “what am I hoping to build to help me know something new about this topic?”

Often, the answer to that question has something to do with the materiality of the topic. As a translator in medieval studies, I have spent untold hours poring over manuscripts and textual editions, navigating the webs of cramped handwriting spilling across pages and the matrices of the apparatus criticus. Text encoding, the DH work I have done with such manuscripts, has given me a deeper insight into the physicality of the scribal tradition and allows me to represent the complexity of the folios. Because DH prioritizes the creation of new material, I get to know the material culture of my field more closely than I might have otherwise.

Comparison of the beginning of Ælfric’s Preface to his Catholic Homilies from Cambridge, Corpus Christi College, MS 178 f. 134 (left) and my own TEI XML file of the same text (right)

This digital methodology of “building” gives me a different way of knowing the content and the context of the material I study. Both formats, manuscript and XML file, have their affordances for marking intertextual material, line breaks, section headers, etc., and the painstaking encoding process creates an intimacy with the text which more traditional humanistic scholarship may not allow. In many ways, the detailed encoding (done in an XML file) feels like the practice of copying a manuscript, and the final result visually complements the original folio.

DH methodologies ask me to think about the medieval world in a new way, demanding that I consider how to transfer the technology of the manuscript into digital technology. As I build a digital manuscript of my own, I can almost see through the lens of the scribes themselves, how they constantly referred back to their source text to produce a faithful copy. Digital humanities offers a new entry point to the field and literally allows me to continue the tradition I study, and it doesn’t hurt that the end result is really cool, too!

Manuscript viewer built from the XML file above through Edition Visualization Technology v. 1.3. This work-in-progress provides multiple nodes of engagement with both the manuscript and the text itself.

Apple’s Reality Composer, a Free AR App

In collaboration with the Center for Digital Innovation in Learning (CDIL), Digital Scholarship and the BC Libraries have begun exploring the use of AR experiences in teaching and research. As part of this effort, we have been experimenting with Apple’s Reality Composer, a free AR app that allows for the creation of basic AR experiences without the need for coding skills. Here you will find a series of AR projects created with it. Clicking the image on an iPhone or iPad* will automatically open the model.

*Currently, these experiences are only accessible through Apple iPhones or iPads running an up-to-date iOS. We have iPads and Reality Composer as part of our 3D modeling station.

Animated robot AR model as seen on the Apple Quick Look gallery

Lion-headed stamp AR model created in the BC Digital Studio

Simple 3D models in Apple’s .usdz format allows them to be opened in AR and to be in a WordPress or Omeka page, as seen here. Clicking the image on an iPhone or iPad will automatically open the model in AR when pointed at a horizontal surface; clicking on a Mac or PC will download the AR file.

The two models above are simply models, but using Apple’s Reality Composer allows you to create more complex experiences with basic interactions without needing to code.

In the example below, built for a Boston College biology class, 3D models of hominid skulls were created using photogrammetry, uploaded into Sketchfab, and placed in AR to share with students, in order to replicate the experience of engaging with the models in the classroom.

Simply click the 2D image of a skull, and the AR experience will begin to load. Please note that the experience may take 15 seconds to 1 minute or so to load depending on the iPhone or iPad in use and the internet connection, and requires a flat, horizontal anchoring surface.

AR experience created by Nina Araújo; 3D models by Matt Naglak.

Hominoid skull

A second example was created using 3D models of an active excavation site just outside of Rome, Italy. It allows users to “re-excavate” a specific ancient tomb on the site and see the specialized burial technique that was utilized. The experience opens at life-size, so a relatively open space is necessary (Trigger warning: a 3D model of an adult skeleton uncovered which dates to around 100 BC is shown). 3D models by the Gabii Project; AR experience by Matt Naglak.

Ancient tomb outside of Rome Italy

Interested in AR but on a Google or Android device? Check out the variety of AR apps available for download from Google Arts and Cultures or from the Google AR/VR page. Note these apps are mostly also available on Apple products as well.

Stylus; the Earliest Boston College Newspaper

Over 400 copies of Stylus, Boston College’s original student newspaper, have been digitized and are available online due to a team effort of the Digital Repositories Group and Burns Library.

This is the original masthead from the first edition of the Stylus from 1883.

From 1883 to now, the student newspaper has developed a reputation for being a wellspring of artistic student expression. While the original publication covered administrative, alumni, art, and sports news pertaining to the Boston College community, the paper became a literary magazine in 1933. As a literary arts publication, stories, essays, poetry, and other creative content became usual, with standalone art submissions and occasional illustrations.

This piece was presented on the inside front cover of Winter 1968, issue 2, of the Stylus. It was done by Brian Henehan, a member of the Stylus Art Staff at the time.

Now that so much of the publication has been digitized, it is easily searchable, and specific articles can be found from the first edition in 1883, to the latest digitized copies in 1977. The platform at newspapers.bc.edu provides readers with a set of tools to browse the entire collection, find the title of a specific work, or even a specific word, phrase, or author.

This cover from 1977 represents well some of the changing styles over the century that have contributed to Stylus’ rich tradition and history at Boston College.
This cover was used in the early 1900s; this example comes from the May 1930 issue.
This is the Stylus cover from March, 1945 – the only issue published that year.

The partnership between Stylus and the Boston College Libraries means more than the availability of digital copies of the magazine online to Boston College students. As newspapers.bc.edu is an open site, anyone with an internet connection is able to search through Stylus looking for trends in student artwork or specific pieces from certain time periods. Being a part of the public domain, all of the work that has been digitized as a result of this process is usable in research. As a result of this digitization, the work of Boston College student artists can reach more people.

Other BC publications made available by the Libraries may be viewed online here.

New digital resource: 19th century petition letters for Jesuit mission assignments

A set of original handwritten letters housed in the Jesuit Archive in Rome has been scanned and transcribed and is now available freely on the web for research and study. A collaboration between Boston College Libraries, the Institute for Advanced Jesuit Studies and Emanuele Colombo of DePaul University, the Digital Indipetae Database offers an ordered glimpse into the mind and world of Jesuit priests applying for assignments worldwide for missionary work.

The content within the searchable catalog was prepared over years by a team of international scholars transcribing and describing documents. In that time, a team of Libraries staff worked with them on image provision, metadata, rights, technology and functionality. A customized Omeka site was designed to accommodate particular metadata needs and a relational database was developed to search, store and index data, and provide access to content, data, and records. The database allows for collaborative data input and editing across the multiple institutions involved, and is integrated for searching via the Portal to Jesuit Studies.

The Libraries are pleased to support this resource and enable research in collaboration with our Boston College partners. For more information, please consult the Digital Indipetae Database.

Highlights from the 2019 Digital Scholarship Open House

On May 1, 2019 the Digital Scholarship Group hosted an Open House that featured the work of several faculty, graduate students, and librarians. Here is a brief overview of the presentations with links to slides and other materials shared kindly by the presenters.

Richard L. Sweeney (Assistant Professor, Economics Department) who participated in this past year’s GIS Faculty Cohort presented on his applications of spatial visualization and GIS for investigating the fracking boom.

Title page from The court & kitchin of Elizabeth, commonly called Joan Cromwel (1664)

Sharon Lacey (independent scholar) and Margaret Summerfield (PhD student, English Department) who participated in this past year’s Digital Scholarship Incubator each presented on their research projects. Lacey created a video discussing her research into how painting techniques in Europe developed across time in relation to other sociocultural factors. Summerfield presented on a collaborative transcription and annotation project (under development) with several faculty, students, and librarians, A Digital Scholarly Edition of The Court and Kitchin of Elizabeth, Commonly called Joan Cromwel (1664).

There were several presentations focused on collaborative projects or pedagogical support with librarians and faculty. Seth Meehan (Associate Director, Institute for Advanced Jesuit Studies), Anna Kijas (Senior Digital Scholarship Librarian) & Sarah DeLorme (Associate Digital Scholarship Librarian) presented on one of these projects, the Jesuit Online Bibliography, a recently launched bibliography database of scholarship in Jesuit Studies.

Stephen Sturgeon (Senior Digital Scholarship Librarian & Bibliographer for English) discussed the collaborative efforts that went into migrating and re-imagining metadata and records for the Becker Collection: Drawings of the American Civil War Era. Carling Hay (Assistant Professor, Department of Earth and Environmental Sciences) shared pedagogical approaches and tips for incorporating podcasting into her weather and climate class (EESC1172).

Header image: Joseph Becker, Railroad Pass with Chinese Workers, 1869-1870. Becker Archive, Boston College Fine Arts Dept.

A New Home on the Web for the Becker Collection: Drawings of the American Civil War Era

Post by Stephen Sturgeon, Senior Digital Scholarship Librarian & Bibliographer for English

In fall 2018 the Digital Scholarship Group launched The Becker Collection: Drawings of the American Civil War Era, a digital archive of nineteenth-century drawings with a substantial history of curation. We created the site in collaboration with the drawings’ owners, Sheila Gallagher and Judith Bookbinder, both of whom are faculty in Boston College’s Art, Art History, and Film department, but this was not the first time the drawings had been prepared and contextualized for public consumption, nor the first time they had been rendered digitally. In the fall of 2009, Boston College’s McMullen Museum of Art exhibited them and published an accompanying catalogue, and it was alongside these events that BC’s Instructional Design and eTeaching Services department (now known as the Center for Teaching Excellence) built a website that hosted digital surrogates of the drawings, offered metadata records for each one, provided biographical entries for their artists, and used the metadata and a set of tags to enable searching. By 2017 the architecture of this website began showing security vulnerabilities, and the Libraries agreed to design and a build a new digital presence for this archive of drawings.

The collection is named after Joseph Becker, whose works figure most prominently in it. Becker, like the sixteen other men whose drawings the collection features, was an artist-reporter working for Frank Leslie’s Illustrated Newspaper, a weekly periodical founded in 1855 that specialized in visual depictions of contemporary news. When the Civil War began, Becker and his colleagues were dispatched to battlefields and military camps to document what they saw in drawn sketches, and the artists would then send their work to the newspaper’s offices for adaptation into print engravings. In addition to these drawings of military events the archive contains depictions of other nineteenth-century American topics that the newspaper featured, dating to the war years or in some cases to just before or just after, such as the Great Chicago Fire of 1871 and the building of the Transcontinental Railroad throughout the 1860s (major themes and topics are outlined on the site’s Browse Collections page).

Thanks to Professors Gallagher and Bookbinder, we were not tasked with creating a web resource from scratch that would do justice to this rich primary source material: the difficult conceptual labor of contextualizing items in the archive in ways that would stay true to the complexities of their genres and histories and also accommodate diverse web audiences was, essentially, already done. Professors Gallagher and Bookbinder and a team of students had years ago created the item-level metadata for the archive, written the artists’ biographical entries, and established what search functionalities would best suit the material and researchers. In 2017 the Digital Scholarship Group’s job was to decide on a platform for hosting that content, migrate it into its new framework, revise erroneous or corrupt metadata, and keep our eyes open for opportunities to make the archive more interactive.

We settled on Omeka for the archive’s new platform, using a slightly customized set of the Dublin Core extended metadata elements. The Becker Collection’s many drawings of military scenes come with consistently precise geographic and temporal information: because Becker and his colleagues made drawings for the sake of illustrating the news, the artists nearly always specified what they were depicting as well as when and where it was happening. And so we revised all items’ geographic and temporal metadata into the formats recommended by the International Organization for Standardization, in the hopes that doing so would make it more widely accessible, as well as more readily malleable and linkable in spreadsheets and website architectures. This in turn led to our creation of a new feature within the Becker Collection, a mapping tool designed in Carto that plots the locations of Civil War battles according to year.

The Boston College Libraries is very happy to give a new home to the Becker Collection’s digital presence, and the Digital Scholarship Group depended on staff in many Libraries departments to get the work done. Special thanks to Chris H-P for composing the site’s design; to Ben Florin and Jesse Martinez for customizing Omeka’s search function; and to Chris Mayo for help with metadata migration. Lastly, thanks to the staff at Boston College’s Center for Teaching Excellence, in particular Cristina Mirshekari, Tim Lindgren, and Jamie Walker, for giving the Becker Collection its original home on the web and handing it off to the Libraries seamlessly.

Encoding the Thomas D. Craven Diary

In the spring of 2018, several library and archives staff from Thomas P. O’Neill (Nancy Adams, Meg Critch, Sarah DeLorme, Anna Kijas) and John J. Burns Library (Kathleen Monahan, Annalisa Moretti) began a collaborative transcription and encoding project of a 1917 diary written by Boston College student, Thomas D. Craven. This diary was written during the spring semester of Craven’s senior year when he began serving in the Army Air Corps Medical Corps during World War I.

Thomas D. Craven (The Sub turri: The Yearbook of Boston College, 1917).

Nancy and I created a Guide to Transcription to help guide the transcription process for the team members. This guide also provides basic TEI encoding directions, because we wanted to begin identifying elements and attributes as we transcribed each entry with the hope that it would make the later review and encoding phase a bit easier and streamlined. After the project team reviewed the guide and provided input, everyone began transcribing approximately 50 entries per person. Kathleen and Sarah began working on a prosopography to identify people, places, and organizations mentioned in the diary. Meg began developing the TEI header for the diary, which will include descriptions about the electronic edition and manuscript source. The transcription phase was completed in December 2018 and the next phase has begun to review and make corrections, as well as do a closer encoding of the text.

Here is the first page from the diary dated January 1, 1917 followed by the first draft of the encoded transcription:

Page 1 of Thomas D. Craven Diary from January 1, 1917

Diary entry dated January 1, 1917

Encoded transcription of diary entry dated January 1, 1917

Our next task is to review the transcriptions and further encode the text according to the TEI. This will also require a discussion on the use of specific elements and attributes. The group agreed that we will use TAPAS to render and publish the TEI files from this project, although we may consider creating a stand alone project website where we can present the edition with additional content, images, or visualizations.

The work of this group aims to not only make this content more accessible and visible to a wider community, but to expand our own expertise and understanding of the TEI through project-based learning. The TEI files and guidelines will demonstrate how we chose to encode these texts and can be re-used for other projects or pedagogical purposes. In addition, encoding these materials will make them easier to discover and access online and will further promote the John J. Burns Library collections. Project-based learning can be used as a model for future initiatives at Boston College that aim to develop expertise and skills in areas of digital scholarship.

This project is currently under development, but you can view a sample of encoded text from this diary (created previously) and other special collections materials found in our TEI Learning Docs project hosted in TAPAS. It is part of our ongoing effort to learn the TEI, explore research and pedagogical applications of the TEI to primary source documents, and make the process and contents visible and accessible to a wider community of students, scholars, and archives/library professionals.

Source citation: Diary, Thomas D. Craven papers, BC.2004.121, John J. Burns Library, Boston College, http://hdl.handle.net/2345.2/BC2004_121_ref5.

A Shared Common Space for Digital Scholarship Projects

Over the past several years, the Digital Scholarship Group has developed and collaborated on multiple open access digital scholarship (DS) projects. Each DS project is developed with specific goals in mind and is built with different content, frameworks, programming languages, and design elements.

In order to make our work discoverable and accessible, we promote and disseminate our projects through various means, including on our library and digital scholarship websites, social media, professional organization mailing lists, conference presentations, and literature, as well as share our code in repositories and with discipline-specific communities and projects (such as the CANTUS Manuscript Database).

One of the ongoing challenges of creating DS projects has to do with preservation and sustainability. While many of our projects are developed from the bottom up (Burns Antiphoner) and require significant programming or application development, others make use of existing infrastructure (John La Farge, Stained Glass in New England) and can be edited through a content management system. Our projects all currently live online and are being maintained, however we want to make sure that the core components remain accessible, preserved, and can be reused for years to come. This is why we are engaging in multiple approaches to document our projects, store our code, (meta)data, and other content types. We have a BCDigSchol GitHub repository, which we use during a project’s development to keep track of our code and make our work accessible and reusable. Although digital objects featured in our projects, such as Cristóbal de Morales’s Missarum liber primus (Lyon: Moderne, 1546) in the Morales Mass Book or audio files of traditional Irish tunes in The Séamus Connolly Collection of Irish Music are accessible in compressed format on the project sites, any raw image or audio files that require preservation are stored on a preservation quality server rather than in the GitHub repository. Our goal is not to store and preserve each and every piece of a DS project in a single repository, because there are already mechanisms in place for preserving digitized images and audio, but rather to identify which data and content types of a DS project would most benefit from a shared common space.

To that end, we recently began exploring the Open Science Framework (OSF) as a repository where we could share data and content types from our DS projects that would be most meaningful to other scholars and practitioners. We looked at the OSF because of the potential it has as a repository, a scholarly commons, and an open data set. OSF’s potential as an open data set is a promising endeavor and is being developed in partnership with ARL’s SHARE initiative. If the SHARE initiative is successful in meeting its goals—identified as “building a free, open, data set about research and scholarly activities across their life cycle”—then one of the benefits for DS projects with content in OSF is that the projects will be automatically aggregated and made widely accessible and discoverable through a single search interface.¹

We selected The Séamus Connolly Collection of Irish Music as a use case for OSF, because this project had a number of content types and documentation that could be brought together into a shared space.

Example of The Séamus Connolly of Irish Music OSF repository.

We linked the project’s GitHub repository to OSF so that all of the Omeka files can be easily accessed. In addition, we used a Python script to export all of the metadata from Omeka to CSV files and added them to the repository. Each song and tune transcription, which is displayed as a PDF on each item page in Omeka (for example, see For Betty Killoran) was converted to MusicXML and the files were uploaded into the OSF project.²

Although the work on The Séamus Connolly Collection of Irish Music itself is complete, we are currently pursuing exploratory work related to the collection and focused on developing linked open data and network visualizations. Within the main Connolly OSF project we were able to create a component (module) for the Linked Data Exploratory Project where all the datasets and documentation were uploaded and made public.³

In addition to the potentials already highlighted, here are some additional features of OSF, which appealed to us:

Identifiers – OSF enables you to easily generate a DOI and ARK for your entire project. Although each DS project has a domain name and stable URL, providing a DOI will further ensure that a project and components (hosted in or pulled into OSF) are discoverable, identifiable and citable.

Attribution – DS projects are often collaborative endeavors developed by many individuals from different backgrounds, departments, and roles. This feature enables you to identify all of your collaborators who contributed to the project. You can specify those who are bibliographic or non-bibliographic, as well as give them different credentials within the project repository. While we identify collaborators and roles for DS projects at Boston College Libraries on their respective project sites, one thing that is missing in OSF is the ability to identify or assign specific roles to the collaborators. It could be as simple as a tag, which administrators could create and assign in order to identify roles, such as project manager, developer, metadata librarian, etc.

Sync with external services – Another aspect that drew us to OSF is that it is interoperable with external services so that you can easily sync files from your code, content, and citation management repositories, such as GitHub, Box, or Zotero. These files will then appear in your OSF project repository.

Analytics – Basic analytics enable you to view number of visits, forks, external links to your project, template copies, top referrers, and popular pages.

Some of the other features worth noting are the Activity Log where all activities within the project repository are visible making it easier for a project team and anyone visiting the site to see how active the repository is and who has made what type of changes or contributions, as well as a Wiki space and Tags that can be added to increase greater visibility to your project site.

We plan to continue to explore the potential of OSF and upload additional data and contents for select digital scholarship projects in order to make them discoverable and accessible.

1. More details about ARL SHARE can be found online.
2. We would like to acknowledge Michael Scott Cuthbert who encouraged us to output the transcriptions in MusicXML and ran the initial conversion.
3. A current interactive version of the Connolly Collection network visualization can be explored online.

Creating a Timeline with TimelineJS and JSON

This tutorial was written by Sarah DeLorme, Associate Digital Scholarship Librarian.

The John LaFarge stained glass digital guide is a great way for users to explore the varied works of LaFarge in one accessible site. The two interactive timelines featured there help to visualize the chronology of LaFarge’s life and his work. These timelines are generated using an open-source tool called TimelineJS by Knight Lab at Northwestern University. TimelineJS can work with a Google spreadsheet to automatically create and populate a customizable timeline. This is a great option for many people, however the Digital Scholarship group was interested in hosting the timeline data locally—not pulled in via Google. In order to migrate the data, we recreated the timeline using JSON.

JSON is a format for structuring data that uses JavaScript object notation. It is used for exchanging data between a browser and server. JSON text is simple to read and work with, and is easily parsed by machines. The TimelineJS JSON format starts with a single JSON object (the timeline), and then populates it with shorter lists of objects (properties), which become the items on the timeline. The properties are events, title, era, and scale. The properties that are used will depend on the content of the timeline, and the nature of the data. The only property that is required to create a timeline is events.

Below is an example of a timeline JSON object with the title property displayed.

Each property contains its own list of properties, like a nesting doll. For both title and events properties, the items in that list are known as “Slide objects”. Slide objects include: start_date, end_date, text, and media properties. (start_date is the only slide object required to generate an event).

Each slide object then has its own list of properties for you to define, which will be where the data will be inserted. For example, the start_date slide object will have a list of “date” objects like year, month, and day. The values for these properties (the data) is entered in quotation marks, as seen in the example below.

Each property in the event object is used to customize the slides of your timeline. Aside from the start date and headline, the media property enables the embedding of images, videos, music, and more. Each event on the timeline is separated in its own set of curly brackets ({ }) within the “events” property, and separated by a comma.

Two JSON files were created for the John LaFarge stained glass digital guide, because there are two timelines featured on the site; one of LaFarge’s life, and another for the chronology of his stained glass work. The second step in this process of hosting our timeline data locally was to integrate these timelines into our website, which is hosted on Omeka. This was done by adding a few lines of JavaScript to our web page, with the help of Jesse Martinez, the Library Applications Developer.

The LaFarge site was created in the exhibit-builder module of Omeka, so the JavaScript was added to the show.php file in our theme directory, the path being: exhibit-builder/exhibits/show.php. There were three items that needed to be added to pull in our timeline: a link tag (to load the CSS), a script tag (to load the JavaScript), and an additional script tag to generate the timeline.

You will notice that since there are two separate timelines on this site, a function was added to the final script tag to identify each separate JSON file. The function decides which timeline data to pull in depending on which timeline has been identified: timeline1-embed or timeline2-embed.

Once the JavaScript was added to our file, the last step was to call the JavaScript on the pages where we wanted the timelines to appear. To do this, we navigated to the exhibit page in Omeka. We added a text box item, and then inserted this div using the HTML editor:

This told the page what to pull in, and how to style it. The div for the second page looked similar, but called in the second timeline using a different identifier:

The end result is a locally hosted, fully functional timeline.

If you are interested in further TimelineJS JSON documentation, or would like to learn how to further customize your timeline, please consult the Knight Lab’s official guide.

Representing Musicians in the SCCIM as a Network

We have made some strides since the last post where I described our initial work to represent relationships between musicians in The Séamus Connolly Collection of Irish Music (SCCIM) as linked data and a network graph. Recently, Kelly and Meg completed their work in creating links between the artists and recordings in MusicBrainz and this has resulted in a rich set of metadata. Each artist and instrument is now connected to each relevant recording.

Screenshot of Connolly data in MusicBrainz

Fig. 1 Connolly data in MusicBrainz

This results in linked records with aggregated data that shows all of the recordings a specific musician is connected to and the instrument they performed on per recording.

Screenshot of MusicBrainz data for Tina Lech

Fig. 2 MusicBrainz record for Tina Lech

Another goal of this project is to create a network graph of the musicians in the SCCIM. To visualize the relationships between each musician, I am using Gephi, an open source network visualization tool, to generate the network graphs and render them with the Sigma.js library.

A force directed layout (ForceAtlas2) was applied to render this network graph. This layout is useful for smaller graphs, such as the SCCIM network, which has 158 nodes and 224 edges. Within the network graph, the musicians are represented as nodes (dots) and relationships are edges (lines). A musician is connected to other musicians by an edge if they performed together on one or multiple tunes. The network also shows single nodes, which represent a musician who composed and/or performed the tune as a soloist. All of the data was drawn directly from the metadata in the SCCIM.

Fig. 3 Snapshot of edge data

Fig. 4 Group legend

A color is assigned to each node in order to represent groupings by role. Group 1 includes musicians who are only performers; Group 2 includes both performers/composers; and Group 3 includes only composers. Relationships are defined as a collaboration between musicians on a tune within the SCCIM collection.

Fig. 5 Sidebar view

When a node is selected, a sidebar opens up on the right with data about the musician and relationships within this network. Their name and role is listed, as is the degree (number of edges), which tells you how many collaborations this specific musician has within the context of the SCCIM. The musicians they collaborated with appear as links under “Connections.” When one of these names is clicked, the graph adjusts to show their connections. If Alice Bérubé is selected, for example, you’ll see that she collaborated with four different musicians, three of these are performers (Jeannine Webb, Pete Sutherland, and Ken Perlman), and one is a composer/performer (Seamus Connolly). Bérubé composed the tune “Don’t Get Me Anything” and also played the fiddle with Webb (fiddle), Perlman (banjo), Sutherland (piano), and Connolly (fiddle).

Fig. 6 Alice Bérubé’s connections

We focused solely on collaborations, because it was not possible to identify other types of relationships, such as who may have influenced who, who someone studied with, or band membership, because this data was not part of the original collection. In some cases, the stories written by Connolly shed some light on these additional relationships, for example, it might be mentioned that one of the musicians was a student of a certain individual or that they were influenced by a specific musician. This information might be useful to scholars and musicians interested in learning more about the way that musical traditions are transmitted, taught, and shared in the traditional Irish music community.

Visualizing the musicians who contributed compositions, performances, or both as a network graph provides a bird’s eye view at the distribution of roles. Using the “Group Selector,” you can easily see that there are 91 performers, 43 musicians who are both composers/performers, and 24 composers in this network. You can view the makeup of each group by selecting one specific group. These views depict the level of collaboration by role.

: Performers

: Performers/Composers

: Composers

A longer term goal of this project is to not only show a general list of connections for each node, but to provide further context through the use of RDF and LOD so that users will be able to see how many times a musician interacted with another musician, on which tune(s), and which instrument they played, or whether they composed the tune that was performed. This data, which will live in RDF pages, such as this example, would be dynamically generated and accessed when someone selects a musician (node). This project is ongoing and additional updates will be shared along the way. You can view the version of the interactive network graph as described in this post online.