Indiana University, Institute for Digital Arts and Humanities

Proposal to the National Endowment for the Humanities

Preservation and Access/ Research and Development Program

Proposal Title - Developing the Annotator’s Workbench for Scholarly Research

and Creative Activity in the Humanities

Project Description and Significance

One page abstract written for non-specialist audience, explaining project’s importance to the
humanities, its principal activities, and its expected results.

Table of Contents
List all parts of the application and, beginning with the narrative, number all pages consecutively

Narrative
Twenty single-spaced pages (one-inch margins, font size no smaller than 11pt). Use appendices
to provide supplementary material. Narrative should consist of the following sections.

Significance
Explain issue/problem, how humanities would benefit from proposed solutions. How does
project advance humanities research, education, public programming etc.? How does it relate to
other work in the field? How will it contribute to solving research problem? List relevant
sources in bibliographical appendix.

Background of Applicant
Describe institution’s (IU & IDAH’s) capabilities for conducting the project – does it have the
necessary technical infrastructure, scientific facilities etc. Describe institution’s experience in
areas related to project

Indiana University

Institute for Digital Arts and Humanities

Project Partners
Describe project partners and their involvement - DLP, ATM, Media Center, UITS, etc.

Project History, Scope and Duration

Give a concise history of project and any preliminary research, or planning. If project will take more than 3 years
to complete describe scope and duration of entire project and specific accomplishments or products intended for
grant period for which funding is requested.

The Annotator’s Workbench began in 2001 as a Mellon Foundation funded project. The
Planning Phase was from 2001 – 2002, followed by a 3 year development phase and a 3 year
implementation phase. The purpose of the grant was to develop best practices for preservation of
video shot in the field by ethnomusicologists, to determine the best documentation and metadata
needed for each collection, provide access to these collections through a web based application
and develop the infrastructure, applications and tools necessary to support the segmentation and
annotation of these videos.

This project was a collaboration between the University of Michigan and Indiana University. The
University of Michigan did most of the encoding of the videos to digital formats and Indiana
University developed the applications and tools. The central tool developed was the Annotator’s
Workbench, a segmentation and annotation tool for digital video.

At Indiana University several different units in the university collaborated to make the project
successful including the Department of Folklore and Ethnomusicology, the Archives of
Traditional Music, the Digital Library Program within the University Libraries, the Digital
Media Network Services in the University Information Technology Services department as well
as software development staff in the EVIA project itself.

To support the ethnomusicologists in using the Annotator’s Workbench, an institute was held at
Indiana University, Bloomington over a two-week period for each summer for four years. During
that time the technology staff worked extensively with the ethnomusicologist to train them on
using the Annotator’s Workbench and to collect information on how to improve the tool.

In addition to the ethnomusicoligists, several other projects at Indiana University have used the
Annotator’s Workbench, making it necessary to add other features and enhancements. The
Kelley School of Business online Master’s program, Kelley Direct, used the Annotator’s
Workbench to segment, annotate and make available online a series of interviews with business
leaders. The Central American and Mexican Video Archive (CAMVA), a grant funded by the
Technological Innovation and Cooperation for Foreign Information Access (TICFIA)
Program in the department of Education, worked with three partner institutions in Central
America and Mexico to segment and annotate videos from their archives to present online. We
are currently working with the Ethnomusicology Multimedia project, funded by the Mellon
Foundation, which will link annotated video and audio with new books published in
Ethnomusicology by Indiana University Press, Kent State University Press or Temple University
Press.

With input from the ethnomusicologists and from the other projects that used the AWB to help
us determine the best features to add, we are on the fourth release of the Annotator’s Workbench.
Each release has involved significant new features, enhancements, improvements and, of course,
bug fixes. Some significant changes have been:
• The development of an interactive timeline allowing the users to graphically interact with
the video to create segments and annotations
• The creation of a multi-lingual version of the Annotator’s Workbench to support the
CAMVA project.
• The ability to configure the AWB for different workflows to support different projects.
• The development of the Controlled Vocabulary Maintenance tool to allow library staff to
create thesauri and controlled voacaularies for use with the AWB.
As can been seen, the Annotator’s Workbench has already been used by a variety of projects and
we have been able to adopt the tool to a great variety of needs. The purpose of the current project
is to extend those capabilities further. One possible use of the AWB from the beginning of the
project was as a field tool. With so much field video being born digital, it no longer seemed
necessary to wait until you returned from your field work to begin annotating your video. To this
end, one of the principal investigators of the EVIA project, Ruth Stone, used the AWB in the
summer of 2007 on a field trip to Liberia. During that same time frame several other
ethnomusicologists who had used the Annotator’s Workbemch were doing field work as well.
After they all had returned from the field, we met to discuss how the AWB worked as a field tool
and what could be done to make it work better.

While having a tool in the field that you could use to reivew with the people you were filming,
could use to record information as you talked with those people about the participants, the type
of ceremony or dance or song and other activities was important, it became appartent in these
discussions that one problem confronting some one working in the field with born digital files
was the need to have help organizing and working with so many digital files. When working in
the field for several months, you could create literally hundreds, maybe even thousands of video
files.

Around this same time, we were working with other projects, like CAMVA, who were working
with large numbers of digital files and were having similar problems of tracking, organizing and
annotating all the files. Further discussions with other groups who were considering using the
AWB made it clear that a central problem was how to handle the hundreds of digital files these
projects would generate and how to annotate them.

It became clear that just having an annotation tool was not enough. If we could provide a
frontend to the AWB that would work like an image management system for digital video and
audio files and would then feed into the AWB for segmentation and annotation, we would be
able to solve some of the problems that afflicted both fieldwork and the annotation of large
collections.

Proposed Improvements to the Annotator’s Workbench

The first major improvement to the AWB would be the creation of a new front end. Now, when
the AWB is loaded, you are presented with the tool’s desktop and you must create a new video
project or open a previously saved project. To accommodate the needs of both the users in the
field and other projects that need to deal with large quantities of video, we propose adding a new
front end that would work similarly to photo organization software, such as Apple’s iPhoto or
Google’s Picasa. Using the AWB with this new front end would open a screen with a list of
video files in some chosen directory. You would be able to move from one directory to another.
Once you found the video file you wanted to work with, a double click on the file would load it
into AWB. If you had segmented and annotated the video before, the AWB would load that into
the AWB desktop. If not, then the AWB would create a new project file for the video. If you
selected multiple files in the front end, then the AWB would either load all the project files
(previous segmentation and annotation) or create a new project that would contain all the video
files selected on a single timeline.

In addition since some of the projects would involve multiple video files, you would see a side
bar with a list of projects for the video files that are in the current directory. By double clicking a
project file, you would be able to load all the segmentation and annotation for that project,
whether it is a single video file or multiple video files.

Additional New Features

Images could be incorporated into the project file in two ways. First, the image would
simultaneously display with some segment of the timeline. The annotator would determine how
long the image would display as the video is playing. Second, the image would be available as
more or less a slideshow in the project. The annotator would layout a series of image files on the
timeline and determine how long each image would play.

Adding audio files to an existing project would require three different modes. First mode: the
audio replaces the audio on a given segment of video. Second mode: the audio plays
simultaneously with the video audio, giving the ability to do a voice over on the video. Finally,
the audio would be inserted into the time track and would be additional material, not replacing or
supplementing any video tracks.

As with images, text would be added either at specific points on the timeline and given a display
duration or would be in addition to multimedia segments. Another way that text might be added
would be to associate a text file with a given video segment, similar to the way the descriptive
metadata is associated with segment now except that this text would possibly be more extensive
and the annotator would be able to do more extensive formatting.

Improved transcription and translation. Associate line by line transcriptions with a given part of
the timeline.

Cut and paste video segments on the timeline including metadata.

Merge multiple project files into one project file.

Methodology and Standards

Explain and justify procedures and standards to be used. Describe how project will test the potential applicability
of any innovative techniques and procedures that the project is likely to develop. Provide a plan for evaluating
results of project.

Projects developing new software are encouraged to make the software free in every sense of the term, including the
use, copying, distribution, and modification of the software. Applicants are also encouraged to make any
humanities content created during the project free and accessible to the public.
Discuss any intellectual property or privacy issues that might affect the availability of the project’s results—for
example, copyrighted materials, proprietary technologies, or licensed software. Permissions in matters concerning
intellectual property must be obtained, and any pertinent documentation must be provided in an appendix.

If funding involves the development, acquisition, preservation, or enhancement of geospatial data, products, or
services, applicants must conduct a due diligence search on the Geospatial One-Stop (GOS) Portal
(www.geodata.gov) to discover whether their needed geospatial-related data, products, or services already exist. If
not, the proposed geospatial data, products, or services must be produced in compliance with applicable proposed
guidance posted at (www.fgdc.gov).

Using the Scrum Process For Software Development

General Definitions
Scrum is a Software Development Process. Its name derives from the rugby scrum
where the players huddle together to put the ball into play. What makes the Scrum
process unique is its emphasis on daily team meetings and a short 30 day cycle to
deliver executable functionality for an application. It doesn’t try to deliver all
functionality within 30 days but rather bites off only those parts of the requirements
the team can implement in 30 days. It is an iterative methodology in that this 30
day cycle repeats until all requirements are implemented.

The key features of Scrum are:

• Daily Scrum Meetings – the technical staff meets on a Daily basis. Each staff
member reports on 3 things.
o What I did since the last meeting.
o What I will do before the next meeting.
o What impediments have I encountered.
• The Project Backlog – a prioritized list of features, functionality and issues for
the project. This list is dynamic and changes as features and functionality are
implemented, as new technologies emerge, as requirements change. Any one
can add items to the Backlog. Only the owner of the Backlog can prioritize it.
• The Sprint – a 30 day development cycle, the end result of which is
implementation of new features and functionality.
• The Sprint Planning Meeting – the meeting just prior to a Sprint, where the
development team chooses the top priority items from the Project Backlog
which it believes it can implement in the next 30 day sprint. The goal of the
Sprint is the implementation of these items by the end of 30 days.
• The Sprint Review Meeting – the development team presents the new
features and functionality to the rest of the project team for review and
discussion. This meeting may result in new items being added to the Project
Backlog, items being removed from the Project Backlog, or items given a new
priority in the Project Backlog.

The following diagram shows the workflow of a typical project using Scrum:
 Scrum Process for EVIA Digital Archive

Project Conditions &

Requirements

Sprint Backlog

Daily
Scrum

Sprint Review
Sprint Planning Meeting
Project Backlog text
Meeting

Sprint

Standards,
Conventions,
Guidelines

Project Conditions & Requirements - collected during the planning phase of EVIA Digital Archive

Project Backlog - a prioritized list of features, functionality, and issues of the project. This list is dynamic and
changes as technology, requirements and functional need changes. As new items are added,
the list is re-prioritized.

Sprint Backlog - a prioritized list of features and functionality for the next 30 day sprint of activity.

Daily Scrum - a daily meeting of the development team to discuss what each of them did since the last
meeting, what each plans to do before the next meeting, and any impediments to getting things
done.

Sprint - a 30 day development cycle; the goal is an Executable Product Increment. The project would
consist of a series of these 30 day sprints, until the final application was completed.

Implementing Scrum

Advantages
The Scrum Process is very effective when dealing with projects where the
requirements will change as the project progresses. This is true both in terms of the
user needs and the technology. While the initial phase of the project has identified
the basic features, functionality and issues which will need to be implemented,
there is still significant work to be done to make these features work with the
existing technologies of Indiana University, to make these features meet the needs
of the user and to determine what new technologies will work best with these
features. This means that whatever approach we take to this project, we will need
to be both flexible and agile to implement successfully. The Scrum process offers
some of the flexibility and agility we will need.

With so many factors influencing the direction of the project, the 30 day
development cycle of the Scrum process guarantees constant review and means
that while we may get off course, it will only be for a short 30 day period. In a more
traditional methodology, where we might collect requirements for several months,
then design for several more months, then code, we could find ourselves
considerably off course when we start the review process at the end of such a
lengthy period and find we would have very little time left to make a course
correction.

Another advantage is working from the Project Backlog list which allows the
development team to stay focused on the high priority items and not get distracted
working on lower priority topics. In addition it provides a built in reporting tool for
the rest of the project team since for any given Sprint, the 30 day development
cycle, it is clear what features and functionality is being implemented from the
Backlog. The Backlog list also lets everyone know what the priorities are and allows
them to argue for change to those priorities.

The daily Scrum meetings are open to other project team staff and allow them to
know exactly what is happening on the project on any given day. The project status
is really contained in those daily meetings.

Implementation
To move forward with the Scrum process on this project, the first thing to do would
be to define the Project Backlog. At this time we do not need to define all features,
functionality and issues, but enough to enable the development team to put
together the first set of goals for the first Sprint. For instance, since the Annotator’s
interface is currently being worked on, we would add to the Project Backlog the
features and functionality we would expect from this interface. Based on this the
development team might say we can deliver the interface with all features, except
controlled vocabulary. So at the end of 30 days, the development team would
deliver for review the annotator’s interface without controlled vocabulary. The
controlled vocabulary would remain on the Project Backlog list and based on its
priority might get included in the next Sprint.

There would be several roles we would need to implement as well. First we would
need to identify some one to own the Project Backlog and keep it up to date and
prioritized. We would need to identify a Scrum Master (pretty awful terminology but
that’s what he or she is called) whose primary responsibility is to run the daily
Scrum meetings and make sure we adhere to the Scrum Process. We would need to
identify the members of the development team for each Sprint. And who would be
on the Sprint Review Team.

Conclusions
While there is some risk involved in implementing a new development process, the
advantages to be gained from Scrum could be significant on a project of this nature,
where the technical and user requirements will change over time and the team will
need to be flexible in its response to those changes. The Scrum Process gives us the
best chance to be flexible and responsive while at the same time maintaining
control and focus.

Work Plan
Describe work plan in detail, including a schedule indicating what will be accomplished during each stage of the
project.

Year One
The first half of year one will be spent on design. We will need to design the front end system,
which will look similar to Picasa or iPhoto and will allow the users to tag files, sort on tagged
values, sort on other metadata, such as date filmed. In addition the user will be able to select a
file or multiple files and load those into the AWB. On the AWB side we will need to design the
interaction of the front end with the application. We will need to determine how to merge
multiple annotation files (.awx files) into a single file when multiple files are choose. We need to
be able to cut and paste video segments, including the metadata.

In the second part of the year, we will begin developing a prototype to use in usability testing to
determine if the design is workable. This will involve developing a usability plan to test the new
features of the AWB and how well they interact with the segmenation and annotation part.

In addition we want to develop an interface with FEDORA (Flexible Extensible Digital Object
Repository Architecture) so that both the digital video files and the metadata files can be stored
in FEDORA as one option. Retaining the files in the filesystem would be the other option.

At this time we would also develop the interface and determine the metadata we would need to
collect to represent audio files and image files on the timeline. These two features would be very
important for using the AWB in the field.

Year Two
We would finish the prototype in the first part of year two and do a round of user testing with the
prototype. After we repair any problems or bugs that the user testing would reveal, we will begin
the development and implementation of the prototype into production. Once the application has
been completed, we would do a final round of user testing.

Staff
Identify project staff including outside consultants. Describe staff members’ duties and
qualifications for those duties. Indicate amount of time principal members of project staff will
devote to project. All people directly involved in the conduct of the project, whether paid for by
NEH or by cost sharing, must be name in the budget, along with their anticipated commitments
of time. In an appendix provide two-page résumés for major project staff and all consultants.
If project has advisory board, list names and affiliations of board members and explain board’s
function.

The Institute for Digital Arts and Humanities

Digital Library Program

Archives of Traditional Music

University Technology Services

Media Center

Indiana University Libraries

Dissemination
Describe plans to disseminate project results through various media (printed articles, books, and
presentations at meetings, electronic media, or some combination of these). IN the case of
digital products, explain provisions made for their long-term maintenance and interoperability
with other resources. Applicants are encouraged to make freely available to the public and any
software, source code, or other products created as a result of the project, preferably through a
publicly accessible online repository such as SoundForge.

Budget
Using the instructions and budget template, complete the budget spreadsheet or a format of your
own that includes all the required information. While all items should be justified by the
narrative, further explanation may be included in brief budget notes.

For a any outsourced work, third-party contractor costs should be included in the budget
category “Services.” Attach a complete itemization of these costs to the budget form. If there is
more than one contractor, each one must be listed on the budget form and the costs itemized
separately.

To the maximum extent practical, all procurement contracts must be made through an open and
free competition. They are to be awarded to the bidder or offeror whose bid or offer is most
advantageous, considering price, quality and other factors. Applicants must justify procurement
contracts in excess of $100,000 that are not awarded by competitive bids or offers.

Permanent equipment may be purchased for a project if an analysis demonstrates that purchasing
is more economical and practical than leasing. Permanent equipment is denied as nonexpendable
personal property costing $5,000 or more and have a useful life of more than one year.
Consistent with the Buy American Act (41 U.S.C. 10a-c and Public Law 105-277), grantees and
subrecipients who purchase equipment and products with grant funds should purchase only
American-made equipment and products.

Appendices
Use appendices to provide

Bibliography

Résumés
Brief résumés (no longer than two pages) for staff with major responsibilities for the projects
implementation

Letters of support
Letters should address the project’s significance and be written by experts in the project’s subject
area, proposed methodology, or technology. Authors of letters of support will not participate
further in the NEH review process.

If relevant also provide

Representative samples of the final or anticipated form of the work

Job descriptions for any additional staff that will be hired specifically to work on the project

Brief résumés (no longer than two pages) for project consultants

Letters of commitment from consultants and participants from cooperating institutions.

History of Grants
If the project has received previous support from any federal or nonfederal sources, including
NEH, list on one page the sources, dates, and amounts of these funds. If the project has a long
history of support, the sources and contributions may be grouped and summarized.

Project Participants, Consultants, and Advisors

On a separate page, list in alphabetical order, surnames first, all project participants, consultants,
members of the project’s advisory board (if there is one) and authors of letters of support;
include the institutional affiliations of all of these individuals. The list is used to ensure that
prospective reviewers have no conflict of interest with the project that they will evaluate.