After familiarizing myself with Mukurtu CMS throughout my Studio fellowship this summer, it became increasingly necessary to address issues of open access, organizational principles, and ethics in building a digital archive for the Transgender Oral History Project of Iowa (TOPI). To learn more about the project, please read my original blog post about my summer work building an archive. Mukurtu is an open access content management system, it is designed for use by indigenous communities and directly responds to issues of tribal knowledge and cultural protocols based on historic and spiritual practices. Recognizing the specific colonial legacies Mukurtu is designed to address, it is clear that a transgender digital archive requires a different code of ethics and access. While both the history of indigenous communities in the U.S. and transgender and gender non-conforming people have been similarly marginalized and rendered invisible, the structures and practices of each archive are inherently different.

It is important to not only recognize that there are different historical legacies marginalizing both indigenous and transgender communities, but it is also crucial to acknowledge the present day differences and how this translates to digital archiving practices. For communities using Mukurtu, they often have a historically defined tribal community whether or not that is federally recognized. Many indigenous communities have their own land and community councils. The significance of this community definition is that the contours of each indigenous community have clear boundaries, membership, and leadership. In contrast, the transgender community has no boundaries and no clearly defined membership or leadership with power. There are certainly community organizations, groups, and nonprofits organized in geographic regions that have a concentration of transgender and gender non-conforming people, but transgender communities are ultimately dispersed.

For the design of Mukurtu, indigenous communities are provided full control and the ability to continually edit and alter access protocols. It rests with the leaders and authorities within each community to define and update these protocols. For TOPI, there is no singular community to hand over control of the archive (see figure below for user permissions). Control over access to the digital TOPI archive cannot mirror the control that Mukurtu provides. As an oral history project, TOPI addresses the needs and privacy concerns of the individual interviewees involved in the project. Traditionally, oral histories are either made fully accessible to researchers and to the public immediately, or they are embargoed for either a set number of years or until after an interviewee passes away. The reality for transgender communities is that their history is undervalued by academics and the result is a dearth of archival material and scholarly publications. Recognizing, celebrating, and studying the history of transgender and gender non-conforming people, is a valuable asset to creating a society more accepting of transgender people. The interviews collected for TOPI must be made accessible to the public, to researchers, and to members of the community.

In contrast to the archival practices embedded in the design of Mukurtu that allows indigenous communities to actively control access, the access to archival materials digitized in TOPI’s archive is predetermined. The user permissions and the structure therefore must operate in response to how interviewees define access. For the oral histories collected digitized access will be determined at the point of the interview and verified through the sharing of the written transcription. Interviewees mark off the portions of the interview to be made publicly accessible, accessible to researchers, at a more granular level to the transgender community at large, and even further, portions made accessible to only people who share identity terms with the interviewee.

Navigating this structural logic in by designing an archival space in Mukurtu this summer was a challenge because of how TOPI is taking shape. Considering both indigenous and transgender archives, what is made clear is that open access is not the best practice for communities historically subjected to violence within and outside of the archive. New digital archiving projects force archivists, scholars, and digital humanists to rethink notions of privacy, ethics, and open access.

To keep up with TOPI as the project moves forward and the archive launches, follow us on Twitter @TransIowa. If you want to get involved in the project as an interviewer or interviewee, please email us at transoralhistoryiowa@gmail.com.

To follow my work in the realm of digital public history and community archive building follow me on Twitter @ambettine.

Aiden M. Bettine
Ph.D. Student in History
Master’s Student in Library and Information Science
The University of Iowa

As a concept, making Dance For Screens seemed completely doable: make some choreography, capture it on film, edit that footage into a series of short screendances and then implement those screendances on a couple of cell phones for an interactive installation. Simple, right? 

Not quite. 

Each aspect of this project came loaded with a its own set of learning curves and tiny hurdles to overcome. And, despite the frustrations I met along the way (or perhaps because of them) I feel absolutely satisfied with what I’ve made. So… what did I end up making?  

What resulted at the end of the summer was an interactive dance installation not for 5 cell phone screens, but one giant screen. I’ve been testing it touchscreen display that lives  just north of the Studio doors. The videos I shot and edited (and re-edited [and re-edited again {and again}]) that were originally meant to be displayed on a loop on a couple of phones are now movable across a 4K display. There are now 7 distinct scenes that can be displayed at will inside the resizable frames. I even developed a button that will shuffle and rotate the frames randomly on the screen surface. And, perhaps the thing that most excites and frustrates me about the interface (because I can’t seem to get it to work as seamlessly as I would like) is the ability for whomever interacts with the installation to take a screencapture of the display and email it to themselves.

 

IMG-689

An interesting thing happened toward the end of the process. I began to understand to more clearly the purpose of my project. It’s a way to dance the archive. Most often dances are received passively by their audiences. A choreography is made, rehearsed, and packaged up with costumes, lights and music for an audience that sits and receives it in a theater. Or if it’s received as a screendance, it’s been captured on film, edited for the screen and distributed (more often than not) digitally to some sort of device. Either way, much of the labor that went into making and packaging the dance is invisible to the audience. I realized that what I was revealing with Dance For Screens was a way to make some of that labor less invisible. 

While the process of getting from nothing to something seemed like an arduous trek while I was in the thick of it (mostly because I was really charting my own path and developing my own workflows), in retrospect those hills I climbed weren’t insurmountable as I thought. Making choreography is nothing new to me — but making choreography that is meant to be filmed and displayed on 2D surfaces? I had to check that one off the list. Not only that, I had to be my own cinematographer and camera crew. The came the editing (and generous re-editing). I challenged and tested my skills using Adobe Premiere Pro and After Effects. Check that off the list too. And finally implementation. While I intended for this installation to be experienced on cell phone screens, thanks to Hannah and Ethan (part of the genius crew at the Studio), I was able to test the videos on the touchscreen and instantly fell in love with the interface. The only problem there was I had never used the Intuiface software that creates and manages the content on the touchscreen. So I had to learn that software as well, crash-course style. And while each of these softwares and methods was exciting and challenging to learn in order to produce Dance For Screens, ultimately what was most valuable was learning how to develop efficient and useful workflows — I’m grateful that I had the time and space to do precisely that.

-Marc Macaranas

 

As a summer fellow in the Digital Scholarship & Publishing Studio, I have focused on building the structure of a digital archive for the Transgender Oral History Project of Iowa (TOPI). The mission of TOPI is to recognize, collect, preserve, and celebrate the lives and stories of transgender and gender non-conforming people within the University of Iowa, Iowa City, and surrounding communities across the state of Iowa while simultaneously building an archive of transgender history in Iowa. A primary goal of the project is to empower transgender and gender non-conforming communities to collect and preserve their own histories by training trans-identified people in the methodology of oral history. The project also looks to the trans community in defining its content and the definition of its boundaries (participants, questions, etc.). To include trans people as both storytellers and interviewers engages the entire community in history-making regarding the creation of primary source materials. It also disrupts potential forms of oppression and violence trans people encounter when telling their stories to community outsiders.

A primary concern of TOPI is how to build an archive of oral histories, related documents, and ephemera that will not only preserve the histories of transgender and gender non-conforming people but also protect them. Protection is a vital component in the creation of this archive. Statistics show transgender people face high rates of discrimination that lead to police and community violence, both physically and mentally. The process of collecting and preserving the oral histories of transgender people potentially re-exposes them to former violence when information is first shared with and then accessed through the archive. For this reason, I am specifically interested in structuring TOPI’s digital archive practices in a way that keeps more sensitive information accessible to only the transgender community and restricts public access.

Currently, there is only one content management system for digital archiving that allows varying levels of access and community control, Mukurtu CMS. Mukurtu is an open access content management system for use by indigenous communities around the globe. With a purpose of empowering indigenous communities “to manage, share, and exchange their digitized cultural heritage,” the Mukurtu design team works directly with indigenous communities to create a platform that facilitates culturally relevant and ethical digital protocols. The strength of Mukurtu is the ability to provide granular level access to different user groups that access the digital archive. By grouping users into different protocols for viewing archival materials, privacy and protection can be designed into archives built on Mukurtu.

The first half of my time as a summer fellow has been focused on familiarizing myself with Mukurtu. By uploading various media types, defining different access protocols, and building communities on Mukurtu, I have been able to learn the ways Mukurtu functions and how an archived designed for indigenous communities can be utilized to fulfill the needs of the transgender community. The similarity between these archives meant for differing marginalized communities is the ability to control archival content, provide privacy and varying levels of access, and creating new practices for ethical digital archiving.

To keep up with TOPI as the project moves forward and the archive launches, follow us on Twitter @TransIowa. If you want to get involved in the project as an interviewer or interviewee, please email us at transoralhistoryiowa@gmail.com.

To follow my work in the realm of digital public history and community archive building follow me on Twitter @ambettine.

Aiden M. Bettine
Ph.D. Student in History
Master’s Student in Library and Information Science
The University of Iowa

For me, grad school, and especially the process of dissertating, has involved not knowing what I’m doing a lot of the time. I don’t think that experience is atypical, but this fellowship semester has been a period when I felt like I knew what I was doing—I was making a website about a Boston periodical called the Commonwealth because one didn’t exist already and I thought it should. There were other questions, such as who’s interested in this material other than me and what they’d find useful in my website, but my answer to the most common small-talk question about what I was up to was simpler, both explainable and understandable, this summer than it’s been since I started grad school.

Despite this certainty about my task, I became less sure about what to call the project, especially after it changed from being about the content of the Commonwealth to being about the people who ran it and contributed to it. I decided to call the project a “digital exhibition” early on, but that phrase always served as a placeholder for a better term that I thought I would come up with or discover at some point. The word “exhibition” just doesn’t seem to describe what I’ve done, perhaps because what I’ve created only has physical form on a screen. Even adding the descriptor “digital” doesn’t seem to solve that problem for me. This is a fairly esoteric issue, and I suspect I’m the only one worried about it. Nevertheless, this problem of terminology does remind me of conversations we’ve had in class meetings about “digital scholarship”—what it means, how to apply it, and whether it matters at all. At the risk of reducing complex discussion and presenting only my side, here’s what I concluded: we need to be able to describe what we do for various reasons, ranging from the small-talk conversations I mentioned previously to job-application reasons, even though we also recognize that the terms used don’t always serve us well. Lately I’ve been calling my project a website, but “digital exhibition” works, too.

You can find my website, which I made using the free version of Omeka, here. Pdfs of the Commonwealth are there with metadata, recorded in Dublin Core, about those pages, and I also made a page about the newspaper describing its founding and including a pitch for its importance. Most of the pdfs that are currently posted are of varied contributions to the paper by Louisa May Alcott, whose three series published in winter, spring, and summer of 1863 are progressively more autobiographical. In coming days, I’ll be adding pages on two editors, Moncure D. Conway and Frank Sanborn, as well as Alcott’s first series for the Commonwealth, a short story about an interracial romance that’s based on the true story of William Allen, an African American professor, and his white wife Mary King. One expectation I had of this summer was that I’d be finished with the project by the end of summer. Well, I was wrong about that. Now I’m thinking that material about teaching periodicals might be a good addition to the site in the future, and I’ve thought throughout the process about other directions I could go in. Since I’m taking this expansionist approach, I’m less shy about sharing the website I’ve created, which I consider to be still unfinished, than I would be about, say, sharing a draft of my dissertation.

-Jaclyn Carver

The past few weeks at the Studio have been a unique learning experience as I now have more familiarity and better working proficiency with Audacity and WordPress—tools that I am using in my project. Since I am building a multimedia archive of the stories of South Asians residing in the Middle East, I have conducted telephone interviews with half-a-dozen people. These interviews were conducted in three languages (English, Hindi, and Malayalam). Translating and transcribing these interviews have certainly taken much more time than I had expected. Along the way, I found a collection of short stories about the migrant population in the United Arab Emirates (UAE). My reading of the book Temporary People followed by an interview with its author Deepak Unnikrishnan was instructive not only for the archive, but also for my dissertation research about migrant media in the UAE.

How do we chart the migration experiences of people and present them in a way that is visually engaging and potentially useful for research? One way to do so is through a map, which shows the geographical axes displaying an approximate path along which migration has happened and then linking that with the corresponding people. Because most of the “audience” for this project would ostensibly be located in the Global South, I wanted the website to be lightweight, yet pleasing to the eye. Rob Shepard at the Studio suggested that the Leaflet mapping tool would meet such a requirement. The next steps are to figure out the background and font themes so that the entire thing looks aesthetic. I will be working with Ethan DeGross to polish and beautify the archive without necessarily making the webpage slower to load.

With regard to the relationship of the archive to scholarship, it is interesting to see the myriad ways in which people have articulated the meanings of home and belonging as well as the role of media in doing so. I look forward to gathering more interview data and then analyze the transcripts from a media and migration studies perspective. The final output, I hope, would be a journal article that would add to my existing research.

As an aside, in the last few weeks, I was also able to build a research cum teaching portfolio with some assistance from Ethan. The portfolio is now live and it can be accessed here.

Finally, I would like to express my gratitude to the University of Iowa Graduate College and the Library Studio staff for their help in different ways because of which I was able to kick-start this ambitious project.

 

Subin Paul
University of Iowa

My project creates the visualization of people’s ‘cognitive structures’ (or mental map) using survey responses, as shown in my previous blog posting. At the end of the summer, I am very happy to share my experience in the Digital Scholarship and Publishing Studio.

First, I have explored possible options for choosing available programming packages and coding options for my project. Based on my previous knowledge of Stata (advanced) and R (very basic), I have engaged in a self-learning process to learn new codes and apply them to develop my current project. Though it was tedious and time-consuming (in fact, I spent most of my summer on this!), it substantially advanced my programming skills.  

Second, in addition to the self-learning, it was a great opportunity to discuss my project with programming experts in the studio, which greatly expanded my perspective. I contacted Nikki in the studio when I confronted any kind of struggles. I often explained what I wanted to visualize and what kinds of messages or stories I would intend to share with the audience. In the discussions with her outside of my field, I could re-evaluate my project with fresh eyes and develop the visual argument of my projects – effectively emphasizing the characteristics of each cognitive structure.

Third, I now get a sense of what digital scholarship means and understand how much it will advance our understanding of interdisciplinary work. Weekly seminars of the summer fellowship program were especially helpful to learn digital scholarships. The seminars covered a wide range of topics such as planning, conducting, evaluating, or mentoring digital projects. Guest speakers shared their ideas and experience of digital projects, which include practical advice to us.

Thanks to the summer fellowship, I could deeply engage in a digital project building on the understanding of digital scholarship. Of course, my journey has not been completed yet, and my programming work for the current project is still ongoing. More specifically I plan to learn the JavaScript for the visualization of cognitive structures, which will give intuitions to the audience across disciplines. I would like to further expand my experience with digital scholarship.    

Ji Hye Kim (Ph.D. student, Sociology)

As the summer fellowship is wrapping up I am finding myself making a few small, but important, breakthroughs in my work. The most recent being the ability to utilize more of the functions of the ArcGIS platform. Specifically the select tool for highlighting information that is relevant for my work. 

Figure 1. ArcGIS map of counties, in peach, that have had exploratory oil & gas wells drilled in them. 

The map above gives the general sense of where exploration for hydrocarbons in the state of Iowa have taken place. For context, the easternmost counties are all on the border with Illinois, a state rich with oil and gas deposits that were developed primarily between the 1940s and the 1970s. The southwestern most counties fall into a geological feature known as the Forrest City Basin. Many successful wells have been developed in the parts of the basin located in northeastern Kansas. In addition there have been wells drilled along the midcontinental rift zone which bisects the state from its southwestern corner to its border with Minnesota around the area of Winnebago, Worth, and Mitchell county. This rift is a Precambrian geological feature created when the North American continent unsuccessfully tried to break apart. The possibility of hydrocarbon traps along the eastern and western sides of the rift account for the drilling through this area. 

 

 Figure 2 ArcGIS map with Counties, Townships, and Sections highlighted where O&G wells were drilled nearby. 

This map gives a more focused idea of where the wells were drilled in each county. You can see the predominance of wells in the Forrest City Basin area, and the wells north of Polk county lining up along the eastern and western flanks of the midcontinent rift. 

 

Figure 3 ArcGIS detail map of southwestern Iowa counties. 

By zooming in to the southwestern corner of the state we can begin to see some the irregularities in the data. The map shows the counties in peach, townships in green, sections in pink, and the USGS well data as red with black borders (they look like martini olives!). The USGS well data do not align perfectly with the USGS’s Public Lands Survey System (PLSS), the layer I used to create the township and range data. 

 

Figure 4 Dallas County, IA with townships, sections, and USGS well data highlighted. 

This final map gives you a better sense of how vague the USGS well data are. You can see that within a given township several sections might be highlighted due to intersecting with one well data point. This is due to the decision by the USGS to represent the wells by quarter-mile squares that do not neatly plot into the existing PLSS grid. This is an intentional obfuscation on their part because the data are proprietary to S&P Global’s subsidiary RigData. However, by being able to use the select tool in ArcGIS I have been able to create lists of counties and townships that have had wells drilled in them, which allows me to cross-reference this data with what exists on the Iowa DNR data portal. 

My next step will be to create a time-enabled layer that will show what decades the wells were drilled in, giving me yet another means by which to narrow my search. I hope to have this work done over the weekend and ready to show for our last class on Wednesday. 

Best,

-J.W. Jepsen

In the course of the last couple of weeks, I’ve made some significant progress on my project and my website and I’ve come a long way in my understanding of the code that I’ve been trying to use. The various elements have occasionally felt a little bit eclectic as I’ve transitioned from a Codecademy course on JavaScript to doing data entry into Heurist to running up to Special Collections to get high quality scans of some of illustrations that go with the periodicals, but it’s started to come together over the course of the last week. 

Much of my time since my last blog post has actually been devoted to “breaking” things. I spent an entire morning breaking the CSS for my website to figure out how to change the menu color (there were several hours where all the menus were a rather aggressive shade of laser green) until I finally figured out how to override the basic menu options (please feel free to leave any suggestions or feedback in the comments section). Then I spent the better part of two days successively breaking the JavaScript and data for the D3 visualization to figure out it’s limits and get everything to load correctly. More and more the code that I’ve been using has come to seem like a giant puzzle and the process of tweaking it and figuring out what it can and cannot do is, while a bit tedious, rather addictive. 

As a result of all this breaking, I’ve been able to do some building as well. The biggest developments have been the faceted search interface that’s now up and running on my website. Through it, users can search for the articles that in the database and the bibliographic information for each article. Additionally, with a great deal of help from Nikki White in the Studio, the D3 network visualization is now working and interactive. Though there’s still quite a bit of work to do, you can see how some of the data is coming together (articles are in blue, authors are orange, and periodicals are green). Working with the JavaScript for the visualization, getting the data into the right format, and getting it to work with WordPress has been the most challenging part of this fellowship experience, but it has also been the most rewarding. Finally, getting everything to load and work together was one of the highlights of my summer. 

As this experience winds down, there are a couple of key takeaways that I’ll carry with me into the next stage of my project. The first is the time distribution for any coding project is about 80% breaking the existing code, 10% consulting forums and Slack groups, and 10% actually writing code (and that’s when it’s going smoothly). The second is a reminder about the importance of collaboration in any digital project. This has been a major part of every digital project that I’ve worked on, but it’s been especially true on this one. Without the help of a wide variety of people who’ve sat down to chat with me, walk me through things, or answer my questions online, my project would exist only in a notebook (the paper kind). I would especially like to acknowledge Professor Lindsay Mattock of the SLIS department and Nikki White in the Studio for all of their help and guidance. Finally, this experience has underscored the importance of being able to devote significant periods of focused time to these types of scholarly projects. Learning the code, breaking the  code, doing the data entry, re-conceptualizing my approach, and developing projects like this one would not have been possible during the academic year and I cannot thank the Graduate College and the Digital Scholarship and Publishing Studio for providing the time, support, and space for my work. 

Now, back to data entry and the next visualization…

-Brady Krien

To begin, I would like to thank the Graduate College and the University of Iowa Libraries Digital Scholarship & Publishing Studio for the opportunity to work on my digital project over this summer. 

To recap, I intended to build an interactive map of nuclear waste transportation routes from operational and retired nuclear reactors to Yucca Mountain, Nevada. Essentially, I wanted to rebuild the 1995 nuclear waste transportation route map in ArcGIS and make it interactive.

 

To recreate the above 1995 map on the left from the US Census Bureau Tiger shapeline file for the nation’s railways on the right, one has to select each pathway individually and add it to the map on its own layer. 

There are a few ways one can do this in ArcGIS. The first, is to use the select tool from the drawing menu and select an individual route. As most of the Tiger file rail routes were drawn as individual polylines of short duration, I found this to work better for editing individual routes rather than building a map from them.

My preferred way of selecting rail routes was by using the polygon tool (also within the drawing menu):

After highlighting the route to be taken, chose Select by Graphics:

Which will give you the following results:

This method, however, adds in a certain messiness that will have to be cleaned up in the editing stage. 

My first iteration resulted in:

On the surface, this isn’t a far cry from the original 1995, but there still is a significant amount of work to be done. 

During the editing phase I realized that while the Tiger rail shapefile was drawn in short, almost unmanageable polylines, the national highway grid wasn’t. This made cleaning up a bit easier. 

Upon my second iteration, I deleted my existing highway selections from the map and used the Select by Attributes feature. To find the attributes of any giving segment click the Identity button from the main menu: 

And your cursor will change to: 

With a little “i” above it. From here you can pull up the Attributes table and select by your preferred attribute, in this case the I-35.

Under the first method, my original IA highway grid looked like:

Under the second, however, it looked like:

Much cleaner and easier to work with. In the first mapping I would have to edit out all of the unintended selections while in the second, I still have to edit part of the I-35 that extends south of the I-80.

I finished my second iteration by the end of the third week and once again started on my edits. And like all great epics, this is where the story begins, in the midst of things.

If you recall from my earlier post, I was unaware that ArcGIS did not run on Macs, so I had to reschedule time to edit throughout the lab, which created scheduling conflicts for me outside of the labs operating hours. I resolved this by having the university’s ArcGIS program downloaded on my office computer. The only problem here was that the University’s license was for ArcGIS 10.4 and the Studio was already operating on 10.6. All of my existing work would not run in 10.4. Fortunately there is work-a-round where you can save ArcMap files under an earlier version. Problem one solved. Now for problem two.

There’s an issue with ArcGIS’ licensing where the program doesn’t respond for up to 2o+ seconds under borrowed licenses. This makes editing unmanageable. For each selection count twenty seconds. For each deletion, twenty more. Then add time if you are extending a road or route. Triple it if the deletion you just made bifurcated the route in two and now you need two more edits. It only gets more complicated from here. It took twelve hours of lab time to clean up California. Granted not every state is as complicated as CA, but some are two to three times more detailed. 

There is a work-a-round for this too that we have yet to try. Per message boards and forums, downloading a local license manager should alleviate the problem. This will have to wait for the second iteration of this project, however.

This fellowship taught me to be a better problem solver and project manager, two critical skills necessary to undertake any future project.

Best,

Greg Rozsa