If you are a student interested in programming and literature, music, or some other aspect of the humanities and libraries, check out our page of ideas and our GSoC homepage. Feel free to drop us an email or join us on IRC to discuss potential projects.

About Google Summer of Code

Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects. Google works with many open source, free software, and technology-related groups to identify and fund projects over a three month period. Since its inception in 2005, the program has brought together nearly six thousand successful student participants and over three thousand mentors from over a hundred countries worldwide, all for the love of code.

Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.

To learn more about the program, read the 2013 Frequently Asked Questions page.

The post MITH Participating in Google Summer of Code 2013 appeared first on Maryland Institute for Technology in the Humanities.

The Open Annotation Data Model Rollouts are a series of three meetings organized by the members of the Open Annotation Consortium and Annotation Ontology to introduce the Open Annotation Data Model Community Specification developed through their collaboration as the W3C Open Annotation Community Group. This series of meetings is made possible by generous funding from the Andrew W. Mellon Foundation.

These day-long public rollouts will inform digital humanities and sciences computing developers, curators of digital collections, and scholars using digital content about the W3C Open Annotation Community Group’s work. Topics will include the Open Annotation Data Model, the W3C Open Annotation Community Group, existing implementations of Open Annotation producers and consumers, and developer tools and resources.

MITH will be presenting its video annotation developer toolkit developed in conjunction with Alexander Street Press. The toolkit provides a JavaScript framework for creating and viewing annotations of video embedded in a web page without having access to the video stream, enabling annotation of proprietary video. MITH will also outline its ongoing work developing a Drupal module that will use this toolkit to enable annotation of video embedded in a website.

The May event is the second in the series. Other rollouts are being held at Stanford University in April and at the University of Manchester in June.

The post MITH to Host U.S. East Coast Open Annotation Data Model Rollout appeared first on Maryland Institute for Technology in the Humanities.

We’re used to blogs with comments. Each comment is a piece of text associated with the blog entry or another comment. Systems like WordPress or Movable Type own the comments. They store the comments in the same database as the other content. Comment providers such as Disqus manage all of the comments in their own database and associate them with the appropriate blog page.

Open Annotation goes one step further. With Open Annotation, the comments could be stored anywhere and still be associated with the blog entry.

Open Annotation frees commentary by allowing anyone to own the commentary, anyone else to own the object under discussion, and yet another person to make the associations between the comments and the object. In fact, Open Annotation could be one of the enabling technologies for Alan Liu’s vision of opt-in communities for information authority (a.k.a. censorship and peer review). You get to decide whose annotations you want to use.

MITH has been part of the Open Annotation Collaboration for a few years now. Over the last year, we worked with Alexander Street Press to develop a JavaScript library that lets you add video annotation capabilities to your website.

It’s a bit raw still, but it provides the basic framework. With a little effort and comfort with JavaScript (especially closures and anonymous functions), you can make it work with your application. If you want to use a video player other than HTML5, you need to write a driver that lets the library control the player. If you want to allow annotations other than text, you need to write some JavaScript that lets the library know how you want the annotation body rendered. If you want to be able to pick out parts of images that aren’t rectangles or ellipses, again, you can write a bit of JavaScript and you’ll be good to go.

In the spirit of Open Annotation, our library doesn’t demand any particular integration into your website. You get to decide how you want people to interact with the video annotation capabilities. You get to decide how annotations are stored or discovered. The source code of our demo is a good place to start to see how you can use the library.

Of course, this flexibility means that you have to do a little work to use it. If the prospect of annotating video intrigues you but you don’t have time to incorporate it into a platform such as WordPress or Drupal, hang on for a year. We’re going to be developing a Drupal plugin that will let you add video annotation to almost any HTML5 video on your Drupal site. We’ll also add more documentation and tutorials.

James Smith is MITH’s Software Architect. His research interests focus on narrative and enabling humanities research through computation; he works on a wide range of projects, from statistical models of prose to MUDs to web application frameworks.

The post “A Web Developer’s Toolkit for Annotation of Streaming Video” appeared first on Maryland Institute for Technology in the Humanities.

In one of the experiments, MITH worked with Alexander Street Press to create a developer’s toolkit that lets you add video annotation to your web pages with only a little JavaScript coding, styling, and some kind of server side storage to keep the annotations around for later.

The toolkit allows you to address time spans as well as areas within a frame as targets for annotation. It comes with code to provide rectangular and elliptical areas, but it’s easy to add new shapes with only a little code. The demonstration shows how to add controls and visualization of the annotation body as well as import and export annotations using RDF/JSON.

The experiment pointed out a few areas where the Open Annotation data model needed some extra work when expressing annotations of parts of videos, namely, being able to specify the size of the video play surface on which the annotation target was drawn. MITH will be working with others in the community over the next month to find some options that the W3C community group can discuss at their next meeting in September.

The Open Annotation Collaboration is ending most of its standards development efforts, folding them into a new W3C community group that brings together the OAC community and the Annotation Ontology community. As mentioned above, the W3C community will be meeting in September to discuss several open problems that came up at the meeting in Chicago.

OAC is continuing to develop several of the experiments into open source projects that can serve as examples of Open Annotation use. For example, MITH will be developing a Drupal plugin that will add video annotation capabilities to any Drupal site. The community will also be developing services for storing and searching annotations.

If you are interested in the emerging Open Annotation standard, we encourage you to follow the W3C community group since OAC has passed the standards development work to the W3C group.

The video annotation developer’s toolkit is available on Github at http://umd-mith.github.com/OACVideoAnnotator/.

The post MITH Demonstrates Video Annotation at OAC Meeting appeared first on Maryland Institute for Technology in the Humanities.

Simplified diagram of information flow in a typical application developed according to the principles outlines in this post.

Underlying all of the scholarly work in a digital humanities project is the digital, something that tends to be swept under the rug along with managing a DH center. I want to spend a little time today talking about how we are approaching the technical side of some of our DH projects, namely how we are designing our JavaScript libraries.

Here at MITH, we want to do more with less. We want our output to be exponential: proportional to how much we have already produced. This means that we have to be able to leverage our past work in our current work. We have to maximize reusability of everything we write.

The problem is that we can’t spend a lot of time on a grant writing code that we aren’t going to use for the grant deliverable. It would be wonderful to be able to create a platform on which we could build our projects, but that platform isn’t a grant deliverable, and probably won’t ever be one because it doesn’t produce anything interesting in the humanities.

To try and get around this problem as we wrote a streaming video annotation client for Open Annotation, we developed a way of dividing up the code that we write so that we have a good chance of reusing it later. Instead of writing a lot more or a lot less code, we end up writing a lot of different code. The lines we draw between different pieces of code are drawn in different places.

The first thing we did was make data central to the application. We created an object that holds all of the application’s information and is responsible for notifying other components if the information changes. We don’t have to worry about copies of the information being out of date. The only component that trusts its copy of the information is the data manager.

Then, we split other pieces up based on responsibility. We have presentations that manage the display of renderings of data items. We have templates that render the items for the presentations. We have controllers that translate user interface events into more meaningful events, allowing us to change the UI interaction without affecting anything else in the application.

Now, we’re working on dividing out a few last pieces that we built for development. We’ll be releasing the application as a library paired with a small demonstration web page showing how to tie the pieces together.

We made at least three fundamental decisions in this process.

First, we decided to build a data-centric application. Everything is designed to reflect the current state of the data. Because of the way we built the data management piece, we can add new kinds of information without affecting anything else in the application. This means that we don’t have to plan just the right hooks for all of the plugins people might want to add to the application. The framework supports them at a level below the semantics of the application.

Second, we decided to divide code into classes based on responsibility, not based on its use of particular data. Types of components are responsible for a few, well-defined things, and those things are the responsibilities of a few, well-defined components. If what we’re trying to write doesn’t fit one of those responsibilities, then it doesn’t go into that component. Components only track what might be called “local” data: information that is specific to the component doing its job and information that is of no concern outside the component.

Last, we went with an event-driven framework for tying the components together. This fits in well with the way browsers work. It also allows our components to be lazy. Instead of each component watching for changing information and figuring out if it needs to take some action, it waits for the data manager to alert it to changes. The responsibility for firing the event lies with the component responsible for managing the information that triggers the event, so this fits well with the other two decisions. Instead of having to change a component if we want the events to come from a different source, which we would have to do if they were coded to watch for particular data changes, we can just reconfigure which listeners are added to which firers.

The resulting information flow is somewhat like that in the diagram: the data store fires its event that something has changed, the date view fires its comparable event if the change is within the scope that it is interested in, and the presentation responds by updating the display of the information. If something happens in the presentation to indicate that something in the data should be changed, the presentation calls a method on the data store to request that the information be changed. This change will lead to another sequence of events.

Before, we would update our presentation of the information in response to an edit. Now, we’re moving to a model where we update our presentation in response to changes in the data, and update the data in response to an edit. This decoupling of input and output ensures that what we see in the presentation will reflect the application’s understanding of the information. If we try to change something and we see it change on the screen, then we know that the application understood what we were trying to do and made the change.

We made a few other decisions along the way that aren’t as fundamental as the above three. We’re moving towards CoffeeScript since it helps us avoid common pitfalls in JavaScript. We’re using that-ism instead of this-ism. We’re working on three levels of documentation: code, API, and tutorial.

By making sure we get the local boundaries of the components right by basing them on a set of principles instead of a project-specific API, we don’t have to worry about fitting into some grand API scheme in order to have interoperability. The end result is a set of components that we can use in other projects. For example, the component that renders the spatial constraints over the video is just as happy rendering them over scans of a manuscript.

We’ll be releasing two libraries in the next few months: the streaming video annotation client and a core library supporting this event-driven, responsibility-oriented, data-centric way of building applications. Both will be under open source licenses.

The post Designing Applications for Extensibility and Reuse appeared first on Maryland Institute for Technology in the Humanities.

The post Update: Server Maintenance This Weekend appeared first on Maryland Institute for Technology in the Humanities.

For those not familiar with NaNoWriMo, head to the website and take a look. I want to explore why NaNoWriMo works and what it could mean for digital humanities.

When teaching creative writing, I have two weeks titled “Editing without writing” and “Writing without editing” that cover sophistication and voice.

This is based on the idea that we have two competing forces that together produce what we do: idea production and idea rejection. What isn’t produced can’t be rejected. What isn’t rejected is done. We can’t write what we don’t come up with, but neither do we write what we reject. If we’re staring at a blank piece of paper, it’s often because we are rejecting what our mind is producing instead of accepting it.

Editing helps us survive. If we did everything we thought about and didn’t reject anything, we’d act as if we were drunk. That’s why we do stupid things when we’re drunk. Alcohol turns off the editor.

This model is useful and matches well with my own experience. For more background that seems to support this model, read Blink: The Power of Thinking Without Thinking. For now, let’s assume that we need to turn off the editor if we want to let production flow.

Crisis does this. Judgment takes time. If we don’t have time to think, then we don’t have time to judge. Baseball gives the batter a half-second or less with the ball in the air. Since it takes almost half that time to realize the ball’s on its way, there’s no time to think through options. The batter’s production side is tuned to create choices that don’t need winnowing.

This is where we could do a post about neural networks and feedback loops. Memorizing vocabulary doesn’t train the production side of the brain. Guided trial and error are best. Experts have been through about ten thousand hours of this trial and error. After reading about neural networks over twenty years ago, I gave up trying to memorize as a way of internalizing. I just let my brain do the learning while I gave it opportunities to correct itself.

Sophistication is tightening prose, selecting better words, or removing clichés. Voice is the result of our production. Voice comes through practice as we teach our subconscious what is or isn’t appropriate. It will never rise to the level of sophistication. That’s what editing is for. Voice is what we have before we edit. Sophistication can come from a checklist of things to look for because it rejects what has been written. If the most frequent mistakes are avoided, the text might be publishable. This is why we practice so much: to develop our voice so that after we’ve rejected everything, there’s still good stuff left over.

NaNoWriMo is all about writing stuff that we can reject later. Throwing us into a crisis by making us write forces us to turn off our judgment and commit to what comes to mind. The result is fifty thousand words of pure voice. We don’t have time to edit if we’re going to write sixteen hundred words a day.

A problem I see in DH is the tendency to edit too much before anything can get done. People don’t want to make mistakes. They may not know how to program, feel in control of the computer, or know HTML and CSS. Instead of trying something and learning from failure, they don’t do anything at all. They have the equivalent of writer’s block.

No one has to be a professional to participate in NaNoWriMo. No one should have to be an accomplished programmer to get started in DH. They just need the crisis that forces them to turn off their judgment and start typing.

We need a NaNoWriMo-like event for digital humanities. Take a month and write a web-based project. It doesn’t have to work well. You won’t want to read my novel at the end of November, but I can take time after November to edit what I’ve written. Once a month has passed and the project is starting to take its first shaky steps, the polishing can begin.

How much should be done in a month? We don’t want this to be easy. The whole point is to have no time to edit while writing. NaNoWriMo chose fifty thousand words because it’s an arbitrary number that is long enough not to be a novella while still being reasonable. The DH equivalent should be more than a tool, but not as large as the blockbuster projects out there.

If we assume about fifteen words per sentence on average, then we have 3,333 sentences in our NaNoWriMo novel. That’s a little over a hundred sentences a day.

We can think of these as lines of code. As a professional programmer, I can do a hundred lines of edited code a day if I know what I’m aiming for, so expecting about three thousand lines of unpolished code in a month isn’t too far out there to be impossible. Having to write this code on your own time may be enough to induce crisis, similar to what is happening to me with my NaNoWriMo novel.

What about rules? Considering NaNoWriMo, no code should be written before the event begins. Instead, things like planning, platform selection, learning APIs, and sketching the look and feel can be done in preparation. Use a framework that lets you focus on the things that are important to your project, just as a novel writer selects a genre and all of its expectations so they can focus on the important parts of the story.

Your three thousand lines of code won’t be publishable. You shouldn’t test or debug during the month of writing. That’s editing and polishing. Getting the code down forces you to think through all of the parts of your project and how they might interact. In fact, you may want to start over from scratch after the month. You’ll have a much better picture of what’s going into your project.

Anyone interested in trying this?

The post NanoDHMo, NaDHMo, … Whatever, Let’s Just Make Something appeared first on Maryland Institute for Technology in the Humanities.