The Time Has Come: Ethnography, Gesture Research, and Digital Technology

Lydia Rodríguez
PhD Candidate, Department of Anthropology
Scholars’ Lab Fellow

Respondent
Dr. Eve Danziger
Associate Professor, Department of Anthropology
University of Virginia

Summary:

In Western societies, time is usually perceived as a linear progression of events, but not all cultures think about and experience time in this particular way. In this presentation I analyze the relationship among linguistic, conceptual, and cultural notions of time through ethnographic observation of spoken interactions in Chol, a Maya language spoken in Chiapas, Mexico. In particular, I describe how the concept of time is depicted in the spontaneous gestures which are produced in conversational exchanges among speakers of Chol Maya. I also discuss the role that digital technology has played in the collection and analysis of gestural data, and how digital tools can be used to complement and enhance traditional ethnographic research about temporal conceptualization.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

I ran into an interesting testing challenge yesterday. In Neatline, there are a couple of controller actions that need to spawn off asynchronous background processes to handle operations that are too long-running to cram inside of a regular request. For example, when the user imports Omeka items into an exhibit, Neatline needs to query a (potentially quite large) collection of Omeka items and insert a corresponding Neatline record for each of them.

Jobs extend Omeka_Job_AbstractJob and define a public perform method:

And can be dispatched asynchronously by getting the job_dispatcher out of the registry and passing the job name and parameters to sendLongRunning:

It’s easy enough to directly unit test the perform method on the job, but, since actual execution of the process is non-blocking, the jobs can’t be tested at the integration level in the ordinary manner. For example, I’d like to just dispatch a request with a mock item query, and check that the correct Neatline records were created. This can’t be asserted reliably, though, since there’s no guarantee that the job will have completed before the testing assertions are executed.

The job itself is non-blocking, but the job invocation in the controller code is blocking, and can be tested pretty easily by replacing the job_dispatcher with a testing double and spying on the sendLongRunning method. Since this is a pattern that needs to be implemented in more than one test, I started by adding a mockJobDispatcher method to the abstract test-case class that mocks the job dispatcher and injects it into the registry:

Then, in the test, we can just call this method to mock the dispatcher, assert that the dispatcher is expecting a call to sendLongRunning with the correct job and parameters, and then fire off a mock request to the controller action under test:

This is a pretty good solution, but not perfect: The integration test is really asserting an intermediate step in the implementation of the controller action, not the end result – it tests that the job was called with certain parameters, not the final effect of the request. This opens up the door to false positives. For example, in the future, I might make a breaking change to the public API of the Neatline_ImportItems. Assuming I’ve changed the job’s unit tests to assert against the new API, the test suite would pass even if I completely forget to update any of the job invocations, since the integration tests are just asserting the structure of the invocation, not the final effects.

I’ve encountered a version of this problem more than once, and I’ve never really found a good solution to it. Short of moving up to something like in-browser Selenium tests, or resorting to hacky execution pauses in the integration tests, has anyone ever come across a better way to do this?

• Disabled animated opacity transitions on WMS tiles, which were causing performance problems in recent builds of Chrome;

• Fixed a bug that was causing the map not to focus correctly when a record is selected that has a default focus position/zoom, but no vector geometry.

Download Neatline 1.1.3.

Meanwhile, lots of activity on the Neatline 2.0 front – we’re almost done with a second alpha release, which gets us one step closer to a stable 2.0 release, which will include the migration to update existing installations from the 1.x series.

Stay posted!

Neatline 2.0 makes it possible to work with really large collections of records – as many as about 1,000,000 in a single exhibit. This level of scalability opens up the door to a whole range of projects that would have been impossible with the first version of Neatline, but it also introduces some really interesting content management challenges. If the map can display millions of records, it also needs utilities to effectively manage content at that scale.

This often involves a shift from working with individual records to working with groups of records. When there are a million records on the map, it’s pretty unlikely that you’ll want to change the color of just one of them. More likely, that record will exist as part of a large grouping of related records (eg, “democratic precincts,” or “photographs from 1945″), all of which should share a certain set of attributes. There needs to be a way to slice and dice records into overlapping clusters of related records, and then apply bulk updates to the individual clusters.

Really, this is a familiar problem – it’s structurally identical to the task of styling web pages with CSS, which makes it possible to address groupings of elements with “selectors” and apply key-value styling rules to the groups. Inspired by projects like Mike Migurski’s Cascadenick, Neatline 2.0 makes it possible to use a Neatline-inflected dialect of CSS to update groups of records linked together with “tags,” which can be applied in any combination to the individual records.

Neatline Stylesheet Basics

Let’s take a look at how this works in practice. Imagine you’re plotting results from the last four presidential elections. You load in a big collection of 800,000 records (200,000 precincts for each of the four elections), each representing an individual polling place with a point on the map. Each point is scaled to represent the number of ballots cast at that location, and shared red or blue according to which party won more votes. In this case, there are really seven different nested and overlapping taxonomies in the data. All of the records are precincts, but each falls into one of the our election seasons – 2000, 2004, 2008, or 2012. And each precinct went either democrat or republican, regardless of which election cycle it belongs to. Each record can be tagged with some combination of these tags:

Each of the groupings needs to share a specific set of attributes – and also not share some attributes that need to be assigned separate values on individual records. For example, all of the precincts – regardless of date or party – should share the same basic fill-opacity and stroke-width styles. All records in each of the groupings for the four election seasons need to share the same after-date and before-date visibility settings so that the records phase in and out of visibility in unison. And all republican and democratic records should share the same shares of red and blue. Meanwhile, none of the groupings should define a standard point-radius style, which is used on a per-record basis to encode the number of ballots cast at that location.

Neatline-inflected CSS makes it easy to model these relationships. To start, I’ll define some basic styles for the top-level precinct tag, which is applied to all the records in the exhibit:

Now, when I click “Save,” Neatline instantaneously updates the stroke-width and fill-opacity styles on all records tagged with precinct:

Next, I’ll set the before-date and after-date properties for each of the for election season tags, which ensure that the four batches of records phase in and out of visibility in unison as the timeline is scrolled back and forth:

Now, when I open up any individual record, the before-date and after-date fields will be updated with new values depending on which election the record belongs to:

Last, I’ll define the coloring rules for the two political parties. First, the Democrats:

Click “Save,” and all democratic precincts update with the new color:

Auto-updating stylesheet values

So far, we’ve just been entering hard-coded values into the stylesheet. This often makes sense for properties that have inherently semantic values (eg, dates). For other attributes, though (namely colors), it’s much harder to reason in the abstract about what value you want. For example, I know that I want the republican precincts to be “red,” but I don’t know off-hand that #ff0000 is the specific hexadecimal value that I want to use. It makes more sense to open up the edit form for an individual record and use the color pickers for the “Fill Color” field to find a color that looks good.

And even for styles that can be reasoned about in the abstract, it’s often easier and more intuitive to use the auto-previewing functionality on one of the record forms to tinker around with different values. Once you’ve decided on a new setting, though, it’s annoying to have to manually propagate the value back into the stylesheets so that all of the record’s siblings stay in sync – you’d have to copy the value, close the form, open up the stylesheet, find the right rule, and paste in the new value. To avoid this, Neatline also automatically updates the stylesheet when individual record values are changed, and immediately pushes out the new value to all of the record’s siblings.

Let’s go back to the election results. For the republican precincts, instead of pasting in a specific hex value for the fill-color style, we’ll just “register” fill-color as being one of the properties controlled by the republican tag by listing the style and assigning it a value of auto:

When I click “Save,” nothing happens, since a value isn’t defined. Now, though, I can just open up any of the individual republican records, choose a shade of red, and save the record. Since we activated the fill-color style for the republican tag, Neatline automatically updates all of the other republican records just as if we had set the value directly on the stylesheet:

And now, when I go back to the stylesheet, the fill-color rule under republican is automatically updated with the value that we just set in the record form:

This also works for styles that already have concrete values. For example, say I change my mind and want to tweak the shade of blue used for democratic precincts. I can just open up any of the individual democrat-tagged records, pick a new value with the color picker, and save the record. Again, Neatline automatically replaces the old value on the stylesheet and propagates the change to all of the other democratic precincts.

Claire and I went to the Arduino Hackday hosted by the Scholars’ Lab on Friday. We had no idea what we were getting into, which made it all the more fun. Jeremy brought in a bunch of Arduino kits of all shapes and sizes, and various people went to work to see what they could make out of them.

First Claire and I got a blinking light to work. From there we decided to skip several chapters to make a little music player using a piezo speaker component. At that point we went off the map, dreaming big and working off the page. We started out working with this schematic, but we wanted to expand things a little.

I apologize in advance for whatever vocabulary gap there might be in the discussion below; it was my first time coding in C.

For one, this set-up only uses a single octave major scale. We opened things up by expanding the range of tones the speaker could play, including both a chromatic scale and adding an extra octave. One difficulty here was in the way that way that accidentals would be read by the board. At first we tried to use standard notation – f sharp would be represented by f#. But the code finds the notes in the melody by reading character by character through an array. So when the computer sees “cc#”, it processes it as two ‘c’s and one nonsense syllable that it can’t process. There is probably a more elegant solution, but we got around this by associating the accidentals with new characters entirely

C#/Db             =>       l

D#/Eb              =>       m

F#/Gb              =>       n

G#/Ab             =>       o

A#/Bb             =>       p

Next, we added an extra octave. To extend the range, we hard coded frequencies for the new notes according to the formula given by the original Arduino code:

timeHigh = period / 2 = 1 / (2 * toneFrequency)

We probably could have done this in a more dynamic way. Or, as Eric and Ronda showed, we could have just downloaded a tone library to do this for us. They were jamming out to the Star Wars theme while we were still trying to get things working.  But eventually, we were able to program in the opening of “Mary Had a Little Lamb,” Mozart’s Lacrimosa, John Coltrane’s “26-2,” and “Somewhere Over the Rainbow.”

Here is where things got really ambitious, we came up with the idea to incorporate a RGB LED light that would change colors each time there was a note change in “Somewhere Over the Rainbow.” Rainbow lights for a song about rainbows.

To get the light working we worked off a slightly modified version of this schematic, mashed in with the piezo tutiorial. With some quick help from Eric, we modified the light arrangement so that each generates a random RGB combination. We then synchronized this with the rhythm of the melody.

In terms of the actual circuitry, we just split the digital signal so that it went out to two different parts of the bread board simultaneously and then fed information to both pins. Later we added a volume knob to reduce the maddening noise. You can see attached photos below, though you’ll have to meet us halfway with our diagram of the breadboard.

A later, unsuccessful attempt to key each frequency to a particular color resulted in a light that got brighter or darker depending on the note. I think with a little more time I could fix that by hard coding particular RGB values to particular frequencies, but we were trying to do it dynamically by converting the frequency directly into an intensity value.

Behold our final product!

// Piezo speaker connected to pins
int speakerPin = 6;
// RGB LED leads connected to PWM pins
const int RED_LED_PIN = 9;
const int GREEN_LED_PIN = 10;
const int BLUE_LED_PIN = 11;

// Used to store the current intensity level of the individual LEDs
int redIntensity = 0;
int greenIntensity = 0;
int blueIntensity = 0;

char notes[] = {"cCbgabccaag "}; // a space represents a rest
int length = sizeof(notes); // the number of notes
int beats[] = {4,4,2,1,1,2,4,1,1,1,4,1};
int tempo = 300;

void playTone(int tone, int duration) {
  for (long i = 0; i < duration * 1000L; i += tone * 2) {
    digitalWrite(speakerPin, HIGH);
    delayMicroseconds(tone);
    digitalWrite(speakerPin, LOW);
    delayMicroseconds(tone);
  }
}

void playNote(char note, int duration) {
char names[] = { 'c', 'l', 'd', 'm','e', 'f', 'n', 'g', 'o','a', 'p', 'b', 'C', 'L', 'D', 'M', 'E', 'F', 'N', 'G', 'O', 'A', 'P', 'B' };
int tones[] = { 1915, 1805, 1700, 1608, 1519, 1432, 1351, 1275, 1205, 1136, 1073, 1014, 956, 903, 850, 804, 760, 716, 676, 638, 603, 568, 478 };
  
  // play the tone corresponding to the note name
  for (int i = 0; i < sizeof(names); i++) {
    if (names[i] == note) {
      playTone(tones[i], duration);
    }
  }
}

void setup() {
  pinMode(speakerPin, OUTPUT);
}

void loop() {
  for (int i = 0; i < length; i++) {
    if (notes[i] == ' ') {
      delay(beats[i] * tempo); // rest
    } else {
      playNote(notes[i], beats[i] * tempo);
      greenIntensity = 255 * rand();
      redIntensity = 255 * rand();
      blueIntensity = 255 * rand();
      analogWrite(GREEN_LED_PIN, greenIntensity);
      analogWrite(RED_LED_PIN, redIntensity);
      analogWrite(BLUE_LED_PIN, blueIntensity);
      delay(beats[i]);
    }
    
    // pause between notes
    delay(tempo / 2); 
  }
}

[Cross-posted with dclure.org]

It’s here! After much hard work, we’re delighted to announce the first alpha release of Neatline 2.0, which migrates the codebase to Omeka 2.0 and adds lots of exciting new things. For now, this is just an initial testing release aimed at developers and other brave folks who want to tinker around with the new set of features and help us work out the kinks. Notably, this build doesn’t yet include the migration to upgrade existing exhibits from the 1.1.x series, which we’ll ship with the first stable release in the next couple weeks once we’ve had a chance to field test the new code.

45 minutes of Neatline 2.0 alpha testing, compressed to 90 seconds, set to Chopin.

In the interest of modularity (more on this later), the set of features that was bundled together in the original version of Neatline has been split into three separate plugins:

• Neatline – The core map-making toolkit and content management system.
• NeatlineWaypoints – A list of sortable waypoints, the new version of the vertical “Item Browser” panel from the 1.x series.
• NeatlineSimile – The SIMILE Timeline widget.

Just unpack the .zip archives, copy the folders into the /plugins directory in your Omeka 2.x installation, and install the plugins in the Omeka admin. For more detailed information, head over to the Neatline 2.0-alpha1 Installation Wiki, and take a look at the change log for a more complete list of changes and additions.

We’re really excited about this code. Since releasing the first version last summer, we’ve gotten a huge amount of incredibly helpful feedback from users, much of which has been directly incorporated into the new release. We’ve also added a carefully-selected set of new features that opens up the door to some really interesting new approaches to geospatial (and completely non-geospatial) annotation. It’s a leaner, faster, more focused, more reliable, and generally more capable piece of software – we’re excited to start building projects with it!

Some of the additions and changes:

• Real-time spatial querying, which makes it possible to create really large exhibits – as many as about 1,000,000 records on a single map;

• A total rewrite of the front-end application in Backbone.js and Marionette that provides a more minimal, streamlined, and responsive environment for creating and publishing exhibits;

• An interactive “stylesheet” system (inspired by projects like Mike Migurski’s Cascadenick), that makes it possible to use a dialect of CSS – built directly into the editing environment – to synchronize large batches of records;

• The ability to import high-fidelity SVG illustrations created in specialized vector editing tools like Adobe Illustrator and Inkscape;

• The ability to add custom base layers, which, among other things, makes it possible to annotate completely non-spatial entities – paintings, photographs, documents, and anything else that can be captured as an image;

• A revamped import-from-Omeka workflow that makes it easier to link Neatline records to Omeka items and batch-import large collections of items;

• A flexible programming API and “sub-plugin” system that makes it easy for developers to extend the core feature set with custom functionality for specific projects – everything from simple JavaScript widgets (legends, sliders, scrollers, etc.) up to really deep modifications that extend the core data model and add completely new interactions.

Over the course of the next two weeks, I’ll be writing in much more detail about some of the new features. In the meantime – let us know what you think! We’re going to be pushing out a series of alpha releases in pretty rapid succession over the course of the next couple weeks, and we’re really keen to get feedback about the new features before cutting off a stable 2.0 release. If you find a bug, or think of a feature that you’d like to see included, be sure to file a report on the issue tracker.

This week marks the release of a new version of Prism, a web-based tool for “crowdsourcing interpretation,” constructed over the course of two academic years by two separate cohorts of graduate fellows in our Praxis Program at the Scholars’ Lab.

Praxis fellows are humanities and social science grad students across a variety of departments at UVa, who come to our library-based lab for an intensive, team-based, hands-on experience in digital humanities project-work, covering as many aspects of DH practice as our practiced Scholars’ Lab staff can convey. (By the end of the year, our fellows have negotiated a project charter; learned to create and appreciate robust ontologies and database designs; programmed or at least hacked around in Ruby and Javascript/CoffeeScript; raised up a Rails scaffold and become competent in HTML/CSS; managed the versioning of open source code in GitHub and deployed staging and production instances of a project; made design decisions and analyzed and drawn conclusions about user-experience aspects of a real-world project; communicated the value of their work and grown more comfortable sharing it in iterations and open-access venues; honed their skills at speaking across disciplinary and professional lines; learned hard project-management lessons; expanded their contacts in the DH world; engaged in conversations about funding, academic personnel, professionalization, and broadened career paths for scholars; and had fun and survived it all.)

Where our 2011-12 cohort of Praxis fellows laid the groundwork (resurrecting an old SpecLab game that evolved into the finest bit of vaporware never to be produced by the humanities computing community at UVa, and creating a multilingual, prototype system that allowed multiple readers to mark up a pre-set list of texts according to a shared vocabularly), our 2012-13 team had the opportunity to refine the concept into a usable, open-ended tool. Thanks to their work, it’s easy to create a Prism account (including by logging in via existing services) and launch your own markup games, by uploading texts and defining the facets available to readers for the kind of blunt-force, collaborative annotation Prism allows. Users now have a catalogue of texts they’ve added to the system or participated in marking up, and can get a sense of the evolving, shared reading of those texts through two visualization modes — one new (showing a quantified breakdown of crowdsourced readings), and one (showing the affective frequency of reader agreement) refined. Best of all, Prism has become lovely and light. A design refresh and attention to ease-of-entry should make it an attractive tool for classroom use, and for experimentation and play.

Please try it out and let our students know what you think. (They are Claire Maiers, Sociology; Brandon Walsh, English; Gwen Nally, Philosophy; Cecilia Marquez, History; Chris Peck, Music; and Shane Lin, History — emerging scholars and scholar-practitioners to watch!) We would be especially interested in pedagogical applications of Prism. And, since next year’s Praxis cohort — soon to be announced — will be moving on to a new project (reviving and re-thinking another SpecLab classic, the Ivanhoe Game), we also encourage developers to send pull requests for bug fixes and new features. Much remains possible with the “crowdsourcing interpretation” concept at the heart of Prism, which one early reviewer called “potentially the beginning of a new research field.” Further visualizations? Image-based or non-textual approaches to collaborative markup? Computational linguistic analysis based on comparison of crowdsourced readings to larger corpora? The sky is the limit.

For now, we’re just enjoying the way the new, bright, child-like design for Prism matches the current mood in the Scholars’ Lab grad lounge: “Look! We made this!”

It has been a great journey, and I think my fellow Praxers would agree when I say that we have learned a lot.  Not only have we been introduced to the world of DH and received hands-on training in things like HTML, CSS, Ruby on Rails, database construction, and a smidge of JavaScript and Coffee Script, but we have also learned a great deal about working in a team environment and collaboration.

Although I plan to share some of the lessons learned throughout this year with you all in a subsequent blog post, I thought I would take this opportunity to tell you about what we have done with Prism this year.

Oauth:  With the new Prism, users are able to sign in through a variety of options.  We have retained the ability for users to create their own account on Prism.  However, users can also sign in through existing accounts with Facebook, Google, and Mozilla Persona.   Props go out to Brandon who tackled OmniAuth early on in the semester and then stuck with it despite many unforeseen hurdles!

Redesign:  From the beginning of our meetings, we discussed creating an online environment that was playful and would invite users to explore and participate.  In tandem with our vision of playfulness, we wanted to design the site with special attention to the user interface.  We pictured a site where the design itself would direct users on how to interact and lead them through the workflow from Prism creation to visualization in a streamlined manner.  Manifesting this vision fell to Gwen and Cecilia, and they have done a remarkable job creating a beautiful and functional site.

Database Refactoring: On perhaps a less glamorous note, Brandon and Shane (or “Brane” as I call them) have refactored the database for Prism.  This refactoring was crucial to some of the improvements we’ve made to visualizations, allowing for user uploads, and will hopefully allow for others to build upon our code more easily.

User Uploads: Thanks to Shane and Brandon, Prism now also provides the ability for users to upload their own texts to the site.  Our hope is that this contribution allows for Prism to be deployed in a variety of classroom and scholarly settings.  As users create a new Prism, they have the option to either make their Prism public and available to anyone for highlighting or they can choose to make an unlisted Prism.  Unlisted Prisms are not listed in the Browse page, allowing users to limit participation to desired audiences.  I encourage you to check this feature out for yourself!

A New Visualization:  This version of Prism also includes a second option for visualizing collaborative interpretation, the Winning Facet Visualization, developed by Chris.  This option allows users to see a combination of all the facet categories at once.  In addition, users can interact with the pie chart to see the exact break down of user highlights by category.

There are many other smaller improvements that I have not listed here, so go take a look at Prism and experience it for yourself!

Before I sign off, I want to give a shout out to the SLab faculty and staff.  They invested many hours in our team and rescued each of us from a precipice of panic or frustration more than once this year.  None of this would have been possible without them.  I will have more to say on that later, but for now, I will just say THANKS!

David Flaherty
PhD Candidate, Corcoran Department of History
Scholars’ Lab Fellow 2012-2013

Respondent:
Dr. S. Max Edelson
Associate Professor, Corcoran Department of History
University of Virginia

Summary:
The British Board of Trade, a bureaucratic body responsible for overseeing the 18th-century Atlantic colonies, had a broad geographic vision of the British Atlantic based on their extensive communication with colonies from Newfoundland to Honduras. This project maps the Board’s correspondence for a single year, showing which points on the map it received information about and where those letters came from, in an attempt to illustrate that vision.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

But for every task like Omniauth there have been other jobs that seemed large but turned out to be much easier than expected. I implemented a destroy function on prisms last week in just a couple of hours (Shane had already provided a lot of the scaffolding on an older database setup), which meant that I also had to implement user roles and permissions using cancan. Cancan felt like a bigger job than it wound up being, and the whole thing seems to be working in the feature branch now. Now a user can delete a prism that they have uploaded. Great success!

I think this ability to distinguish between large and small tasks is something that can only come with time and experience. We Praxers may be unable to tell how much work a particular feature will require, but the SLab team has been incredibly helpful in that regard. Where we see mountains, they see molehills, and vice versa. And when you get right down to it, Prism seemed like the biggest mountain of all a couple months ago. Prism felt like an insurmountable task until last week when everything came together in a flurry of productivity. I am impressed with what we have done.

Now, without warning, a couple of inspirational climbing videos.

In April, Dr. Alan Liu, Professor in the Department of English at the University of California, Santa Barbara, spoke about ways in which the skills and resources of the DH community can help advocate for the humanities.

Summary:
Alan Liu will present an informal talk exploring such issues as assessing values and narrative frames for communicating the worth of the humanities. He will also brainstorm next-generation methods for using digital/networked technologies to create material for public view of scholars’ normal research and teaching work.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

In March, Dr. Alan Liu, Professor in the Department of English at University of California, Santa Barbara,
and Rama Hoetzlein, Project Scientist, spoke about their work developing the RoSE Prototype.

Summary:
What if bibliographies of past authors and works could be modeled as a dynamic, evolving society linked to today’s scholars and students? What if scholars and students could add data about biographical, historical, and intellectual relationships to the bibliographical entries, thus using present-day crowdsourcing to make more socially meaningful the crowds of history? And what if visualizations could help us actively “storyboard” intellectual movements and not just spectate them? Alan Liu and Rama Hoetzlein present the conceptual framework and some of the discoveries and challenges of the RoSE Research-oriented Social Environment (in beta at the conclusion of a NEH Digital Humanities Start-up grant).

The Digital Humanities Speaker Series is co-sponsored by IATH, SHANTI, and the Scholars’ Lab.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

First—though this might seem trivial– we got to draw upon out teaching skills, devising a plan for how to teach someone to use Prism in under three minutes.  I authored the tutorial, and thanks to some great ad lib from Cecilia, I think the tutorial manages to capture the playful attitude with which we have approached our work and which we hope Prism engenders.

In addition, we learned how to use the iShowU HD software program.  Admittedly, this is a very user-friendly program which allows you to record an area on your screen as a video.  Still, it has left us with one more skill which we can confidently claim for our own.

And finally, and perhaps most importantly, we got to use this awesome microphone.   Need I say more?

The launch of Prism is just around the corner.  In the mean time, check out our tutorial here!

I have always known that I’m a social worker but this experience has confirmed that in order to be successful in my graduate career I will have to build a team of people around me who are willing and able to support me.  I am also increasingly thinking about what type of alt-ac careers would allow me to keep this team experience central to my work life.  I’m going to miss these weekly work/hang sessions.

Joanna Swafford
PhD Candidate, Department of English
Scholars’ Lab Fellow 2012-2013

Respondent
Dr. Herbert Tucker
John C. Coleman Professor of English
University of Virginia

Summary:
Although sound studies and interdisciplinary music and poetry scholarship have increased over the last decade, scholars have not had the digital tools necessary to make their auditory arguments accessible to a wider audience. This talk will present two tools built by Scholars’ Lab Fellow Joanna Swafford that will help change that: Songs of the Victorians, an archive and analysis of parlor and art song settings of Victorian poems, and Augmented Notes, a tool that will let scholars build their own interdisciplinary websites like Songs of the Victorians.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

In March, Dr. Walter Scheidel, Dickason Professor in the Humanities, Professor of Classics and History, and Chair of the Department of Classics at Stanford University, spoke about ORBIS, a tool developed at Standord that models the geospatial network of the Roman world.

Summary:
Ancient societies were shaped by logistical constraints that are almost unimaginable to modern observers. “ORBIS: The Stanford Geospatial Network Model of the Roman World” (orbis.stanford.edu), for the first time, allows us to understand the true cost of distance in building and maintaining a huge empire with pre-modern technology. This talk explores various ways in which this novel Digital Humanities tool changes and enriches our understanding of ancient history.

The Digital Humanities Speaker Series is co-sponsored by IATH, SHANTI, and the Scholars’ Lab.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

In March, Dr. Shawn Graham, Assistant Professor of Digital Humanities in the Department of History at Carleton University, spoke about using agent based simulations to understand aspects of Greco-Roman antiquity.

Summary:
Raising the dead presents certain difficulties, but computation suggests a way forward. In Practical Necromany, Dr. Graham discusses the use of agent based simulations to understand aspects of Greco-Roman antiquity, its perils and potentials, and how all of this fits into a worldview informed by the digital humanities.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

In February, Andrew Stauffer, Professor of English and Director of NINES, and Juxta Project Administrator Dana Wheeles spoke about using the newly released Juxta Commons in the classroom. Because the presentation was a show-and-tell, Dana has been kind enough to create this blog post as a companion to the podcast of their talk.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

The Juxta Commons Work Space

During our recent presentation of Juxta Commons in the Scholar’s Lab, NINES Director Andrew Stauffer and I showed a number of visualizations of texts collated within the interface of our newly-released application. Because this aspect of the presentation does not translate for an audience listening to the podcast audio, this blog post is meant as a visual companion to our talk.

We began the presentation with a tour of the Juxta Commons workspace, from the library section at the top of the page (for managing your source files, witnesses and comparison sets) to the visualization pane that dominates the lower portion of the window. Using a set comparing Lewis Carroll’s Alice’s Adventures Underground with the more well-know Alice’s Adventures in Wonderland, Dr. Stauffer showed how the heat map overlays color over variants – the deeper the color, the more different the passage. He also showed how the histogram offers a more global view of the collation, and allows the user to target the regions with the most difference quickly, even for long documents.

Alice Underground vs Alice in Wonderland: heat map and histogram

Dr. Stauffer also showed a comparison of two versions of D.G. Rossetti’s review, “The Stealthy School of Criticism,” illustrating how the author toned down his rhetoric in the version published in the Athenaeum.

Highlight of variant in Rossetti’s text

When I took the podium, I chose to focus on other ways of utilizing Juxta Commons, from authenticating texts found on the web, to exploring the history of news items and Wikipedia articles. For example, a look at two versions of an article posted on the New York Times website in November shows that the same article might be drastically different 30 minutes after posting.

A full compendium of the sets we shared can be found at the main Juxta blog at juxtasoftware.org.

If you have any questions about Juxta or Juxta Commons, please visit us at our development list, or write us directly at technologies at nines dot org.

In February, Gretchen Gueguen, Digital Archivist in UVa Library’s Digital Curation Services unit spoke about the challenges to fundamental principles of the archival practice by electronic communication..

Summary:
The information age has ushered in the biggest changes in human communication since the rise of printed text. The dynamic and ephemeral nature of electronic communication presents stark challenges to the fundamental principles of the archival practice. Join us for a look at how the tradition of collecting and creating archives is facing this paradigm shift and how the historical record will be shaped for the future.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.