The question of “scale” has been on my mind over the past couple of weeks. We are processing really vast amounts of text data — topic modeling for text data is the kind of approach whose power of discovery is predicated on the assumption that vast amounts of data will be available for it to run on. It makes me pause and reflect that the assumption that these approaches would keep becoming more prominent and visible in the coming years rests on some other assumptions, which are both technological and social. For one thing, increased success for these approaches will depend on Moore’s Law continuing to hold (i.e. more and more processing power being available more and more cheaply), and also on the willingness (and legal feasibility) of those libraries and institutions that own such vast repositories of texts, to make them available in computer-readable formats. I realize that it is studying information science at an info-school (I am an SI student at Michigan) which makes me think about these additional dimensions. If I had remained just a computer-science person, I probably wouldn’t have thought about simply how much of a socio-technical  infrastructure is needed to put so much text online, and if I had remained a humanities person (which I also have been in the past), then it might not have occurred to me to think about the underlying technological breakthroughs in electronics that is making such continued scaling-up possible (and will hopefully continue to do so in the future) for such approaches as topic modeling.  I appreciate how being a student of Information Science attunes me to think about the entire ecology within which a particular approach is being developed.

While the availability of vast and increasing volumes of data makes one think of issues of quantitative scale, I also had an appreciation, over the last couple of weeks, of what one might call the qualitative scale of the challenge posed by taking this approach, especially when one tries to improve on the sophistication of the underlying algorithm by bringing, for example, domain knowledge to bear on the problem. An example from what we have been doing: earlier, we were working with the “unsupervised” topic modeling approach, in which no knowledge of the content of the text is really needed — the algorithm simply cranks away at whatever text corpus it is working on, and discovers topics from it. For the last week or so, though, we have focused on the brand-new and cutting-edge “supervised” topic modeling approach that is being developed by the computer science folks here at the University of Maryland. The idea in “supervised” topic modeling is to “train” the algorithm by making use of domain knowledge. For example, for the Civil War era newspaper articles archive that we are working with, we are making use of such related pieces of knowledge coming from sources outside of the corpus, as the casualty rate for each week, and the Consumer Price Index for each month, during the time period that these newspaper articles were being published. The idea behind this approach is that the algorithm will discover more “meaningful” topics if it has a way to make use of feedback on how well the topics discovered by it are associated with a parameter of interest. Thus, if we are trying to bias the algorithm into discovering topics that more directly pertain to the Civil War and its effects, then it will make sense to  align the aforementioned “other kinds of data” such as — in our case, casualty figures and economic figures — which have a provenance outside the text corpus. This is where the “qualitative” scale becomes important, I think. The person who will use this kind of approach successfully, in other words, will have to have some grasp, at least, of a wide variety of other fields, and know which information sources to go to to look up additional kinds of data and bring them to bear fruitfully on the problem. The sheer number of areas with  which the successful practitioner of this kind of work will, therefore, have to have at least a passing acquaintance, will “scale” up, the more intelligently we try to leverage these approaches’ power. It also made me realize that, once again, it is people trained in information science — which is a truly interdisciplinary field — who are well positioned to do this. Over the last week, for example, I read several papers on the economic history of the Civil War (which we were pointed to by Robert K. Nelson, a historian at the University of Richmond who has worked on topic modeling and history) — who would have thought that one would have to read something  that in the course of a summer internship in Information Science?  I aligned the economic data with the text corpus, and based on what the data seemed to be telling us, I came up with a design for some experiments to test out some hypotheses, which we will proceed to carry out over the next few days.

Also, in a piece of exciting news, the paper proposal that we (Travis, Clay and I) submitted to the “Making Meaning” conference for graduate students, organized by the  Program in Rhetoric at the English Department of the University of Michigan, has been accepted. In preparing this presentation, too — which is going to be a reflection on how one might situate approaches like topic modeling  in the context of literary theory and philosophy — I think we will find that our interdisciplinary training as “information-science” people really helps us to see see, and think, in terms of the “big picture” — to scale up to the big picture, as it were.

P.S. Now that this post was a reflection on the question of scale, it just occurred to me that it is also appropriate that the programming language I learned during the earlier part of the internship was — Scala!

As far as how I’ll be spending my last week here – formatting all my documentation! I have some plans for what I think would be the most helpful for the next student who comes along to work on this project including: a diagram of how the javascript and php files talk to each other; an annotated list of web resources that were invaluable to me; Future Recommendations; a database design document that lists and describes the purpose of each table, the fields therein, and the relationship between tables; and a review of software tools that I used while working on my project. Documentation always made sense but during the course of spring semester’s Projects in Permanent Retention of Electronic Records, I learned the true importance of documentation. And not just documentation, but documentation as you go.  When my group was first assigned our project and told where to look for existing documentation we were both excited and a little scared. The archival imaging machine we were tasked with getting up to spec was a little too decontextualized for our taste. We knew what it was for, sort of. We knew some of the individuals that had worked with it. But we figured that if we could talk to everyone that had shared its past, find out what had worked and what hadn’t and the rationale behind certain design and software choices, we and anyone who came after us would be able to make considerable more progress than if they had to make the same mistakes all over again.

By the end of the semester, we had performed and transcribed a series of oral history interviews, exhausted a wiki, added to the archival imaging procedures and turned them into an illustrated manual, created a visual topology of the machine, and compiled an abbreviated/narrative version of the wiki into a project report. (Granted, I got lucky – my group was amazing!)  And even after all that, we all still felt that there was so much more to write down, so much more material to cover, so much more to do! The wiki had been essential for providing a space for us to jot down whatever tests we had run, whatever research we had done – a space to propose hypothesis about what went wrong and to figure out what needed to happen next. We tried so many different things that had we not documented all this as we worked, there would have been no way to reconstruct all the things we had done that failed (arguably the most valuable information for someone taking over the project), and all the places we had looked for answers. During this summer, I’ve been keeping track of questions and discoveries each day so that when I come in to work in the morning, yesterday’s questions propel me forward in my work.  And now, at the end, I can compile that into a tool for someone else to use to propel them forward. The iSchoolDH blog has also been a useful source of documentation for me. I’ve already referred pack to previous posts in the last few days to grab some info for the resources I’m currently compiling. So – documentation, good.

My time here has undoubtedly informed my understanding of what Digital Humanities is as well as forced me to think about its implications for many areas of scholarship. It has also stirred my imagination as far as the shape digital humanities might take at UT, where iSchoolers fit in to the equation, and how I might be involved in answering those questions.

I would like to say thank you to Keith Nickum, Programmer at CDRH, for all his help and patience. He is the creator of the Whitman Tracking application and has been a tremendous resource over the duration of my time here. Thank you to all the CDRH faculty and staff for making me feel at home in Lincoln.

This is Sayan Bhattacharyya again, making his second blog post. As you may remember from my previous blog post, I am a grad student from the University of Michigan interning this summer at MITH, working on the topic modeling project that is underway here. In this post, I will describe the “what” and “why” of what I have been doing, and  I will try to put it in the wider context of digital humanities.

Travis Brown and others have developed Woodchipper, a visualization tool which runs the Mallet package developed at the University of Massachusetts at Amherst to perform topic modeling on a selected corpus, and then displays the results of a principal-component analysis. An attractive feature of Woodchipper is that it is oriented towards “drilling down” — a concept that is particularly relevant to the digital humanities. Those of us who “do” humanities pride ourselves on being close readers of texts. To be appealing to humanists, then, topic modeling, in so far as we can think of it as a method of “distant reading“, will need to be combined with close reading. The humanist scholar or researcher who uses an application like Woodchipper would typically want to switch (“drill down”) from the “distant” view provided by the results generated by the topic model, to individual texts, and the application should provide the affordance necessary for this kind of switching of scale to take place at a mere mouse-click. Woodchipper does this by displaying each page of a text as a clickable data point on a two-dimensional graph, the spatial layout of the graph having been shaped by the results of the principal component analysis.

Once the user clicks on a data point (i.e. on a selected page from a given document), that is when the connection/relationship between the “distant” aspect of the text’s high-level attributes — its “topics” — connect with the “close” aspects the text — its individual words. Visualization of this relationship is, therefore, the crucial part of this model. The challenge this poses for the visualization is the following: why should the researcher trust the high-level attributes that the model tells her that the text supposedly has? If the visualization can bridge this gap between the high-level and text-level attributes of the text by clearly displaying the connection/relationship between the levels, then and only then will the user be likely to trust the high-level properties discovered by the topic model.

As I mentioned in my last blog post, this is why we decided to work on making the visualization more expressive and richer, so that it could convey more adequately the relationship between the high-level topics discovered by the algorithm for a given page in a text, and the actual contents of that page itself. Earlier, Woodchipper displayed only a specified number of topics that had been adjudged by the algorithm to be the best topics for the page, with the visualization representing each topic by a list of the first few words that were the most representative of that topic. As mentioned in the last blog post, we changed this to incorporate a pie chart which showed how relevant each of these topics were for the page. The idea was to then highlight those words in the page that “belonged” to a topic, with the same color as the color of that topic in the pie chart. However, we then realized that it was not possible to trace out this connection between topics and actual words in the document, without making further changes to the code in order to refine how we represent topics. A topic is a probability distribution over words, and hence to simply represent a topic as a list of a few selected words is misleading, because, even if those selected words represent the highest-probability words in that topic, the actual probability mass represented by each word in that topic may be quite different. It would be more logical and more expressive, therefore, to represent a topic by those words which, together, add up to a certain specified fraction of the total probability mass. Doing so necessitates changing the Scala code on the server side, which furnishes these words, before the Woodchipper client accesses it.  Instead of passing the top x number of words for that topic to the client, we would now be passing to the client the top words (however many they may be) that together add up to a specified fraction of the total probability mass,  together with the probability of each word (for that particular topic).

We also realized that a further change needed to be made. Each page was too small in size, so that, very often, no word in the page actually matched the top words in the topics for that page. We realized that we probably needed to break up the documents into larger sized units than merely physical pages, in order to be able to show to the user a more trustworthy picture of how the top-level (“topics”) meshes and connects with the bottom-level (“words on a specific page”) when we metaphorically “drill down” from top to bottom.

• for French 17 and the Mountain Meadows Massacre project, TEI encoding, which means learning a strict set of rules and understanding how to apply them (a discerning eye is helpful);
• for Louis XIV, updating a website’s design and adding content, which requires creative, technical and organizational skills;
• and for both French-language projects, I did some translating of texts from French to English.

If one part of my brain ever became “fatigued,” there was always something different waiting in the wings.  All of these jobs were challenging at times, and also quite rewarding.

Posted by: Rosie Hanneke

I’ve been working with Drupal since the beginning. I get the impression that when you know Drupal, you’re something of a rare gem in a web development organization or setting. I’ve talked to several clients and done some consulting, everyone wants my opinion about whether you can do this with drupal, whether you can do that. My career advisor said now that I know drupal I will always have job offers. I definitely see what she means now… Anyway, I finished the original project a long time ago. Well actually, I finished all of the base functionality. Dave and I haven’t been able to meet with the professor that is doing this project yet, so that’s been put on hold. She may want additional things in it. So they gave me another project, a beast of sorts: migration. That’s probably the most dreadful thing one can do in CMS, but I’m tring to make the best of it. I’m migrating a project they’ve been working on here “TheatreFinder” onto Drupal. I feel like I’m almost done, but that doesn’t at all mean I’m almost done. I have to break the process down into several substeps, and it’s hard to estimate how long some of the future substeps will take.

I’ve realized now that the term “migration” is not very appropriate. What it really is, is remaking the site with some additional content plugged in. So in a sense it’s far more work than just making a site from scratch, because not only do you have to make the “scratch” but you have the plug in tons of existing content to it.  All you migrate is the database, and that’s the easy part. But pretty much everything else needs to be created from scratch in drupal. This has taken me longer than the original project. The nice thing is, I’ll have 2 projects to add to my portfolio when I’m done at the end of the summer.  Which by the way, I am remaking my portfolio now (in drupal, of course), and when it’s ready I’ll post it here.

I’m learning a lot, not only about drupal specifically, but about problem solving and troubleshooting in general. I’m also getting more experience with database handling and using tools like phpMyAdmin. Amazing how much you learn from real work experience! =) And I thought I knew Drupal before! Haha.

A very important final update. I ordered Drupal stickers last week and they came in today. I distributed it around the office and made everyone happy. If you want some, let me know before they run out.

Posted by: Isabela Carvalho

I have also been working on a project with the archives here to create relationships between the universities digital commons, the archive’s photo server and the archives instantiation of Archon. Archon is an archival information management system similar to the archivist tool kit, I have enjoyed the chance to experiment with it.

Posted by: Stephen Pipkin

I also worked on digitizing some old 1/4 inch tape.  This isn’t specifically related to the project I have spent most of my time on, but it was something I wanted to gain experience doing.  I used an old Tascam tape player and Audacity to capture recordings of speeches by Michigan State affiliated people and by Robert F. Williams, a radical civil rights activist.

Posted by: Steve Cherry

For example Apple IIe systems either have Apple DOS or ProDOS on them. Specifically, that software is located on the PROM chip of the Disk II controller card, and it operates with Applesoft II BASIC, located on a ROM chip on the motherboard. What appears as a fluid interface on the screen is really two pieces of software in two different places, and each has a distinctive history and properties. This type of distinction seems especially appropriate for organizations that will be using their systems for research and media access, and would like to assess the details of a machine or of media at a glance.

There isn’t an organization I’m aware of that is doing this for its audience or users at this point. It seems typical to document extensively at the level of the computer system. That is intuitive, especially in the timeframe that saw so many vertically-integrated personal computers (Commodores, Apples, IBMs) but the march of PC clones complicates that approach. 

In another light one can see this as the popular ideal of the computer. Observe the iMac. It looks like it doesn’t have any parts, like it sprung from the forehead of Jobs as Athena from Zeus, fully formed and completely capable. And it is pleasing to the eye. But of course in both cases there’s a savage history to observe. 

Anyways, it’s been really edifying to do this research. Omeka’s API has been pretty capable for this sort of task too. 

Posted by: Walker Sampson

In my work
on Louis XIV, I’ve been trying to keep in mind the site’s primary audience,
that is, French language students.  While the site is available on the Web
for anyone–teachers, students in other disciplines, or enthusiasts–it was
originally designed to be a classroom aid in the French department.

Because the site is (at least for now) written entirely in French, yet its
users do not speak the language fluently, I am developing features that I hope
will help users’ comprehension without translating the text for them. For
example, in long sections of uninterrupted text (such as this passage), I am incorporating links to external websites whenever
an important person, place or idea is mentioned.

The linked
websites include encyclopedia articles, official websites of châteaux and
towns, a free Google Books version of a play mentioned in the text, maps,
photos and dictionary definitions of lesser-known vocabulary.  They are all French resources.  In this way, we can help students improve
their comprehension of a given text without resorting to English translation.

Posted by: Rosie Hanneke