The SLS Lecture Browser has two major components, a web client that handles user interaction and media presentation, and a web server that responds to lecture queries from the client. There is also a small program for adding lectures to the database and a second web server that provide access to the lecture media.
The lecture browser is an example of a web application, which means that a client program, typically a web browser, provides the user interface to an application that runs on a web server. The user starts the application on the web server by visiting a web page. In response to user actions, the client will make requests to the web server and take some action based on the response from the web server.
There are many approaches to web applications. The lecture browser uses AJAX and dynamic HTML. In its initial request to the server, the browser retrieves the initial web page layout and all the software that it will use. Thereafter, all clicks, button presses, etc. are handled by a program running in the browser. That program asynchronously sends queries to the server, and the server returns the results as XML. The client program then locally modifies the HTML to format the results. This is how the browser is able to show help tips as the mouse is moved and highlight words as they are played.
We currently have two sources of media, lectures from MIT Open Courseware, and lectures from MIT World, some of which are part of a seminar series, and some of which are just lectures. We have manually created short descriptions of the courses, seminars, and seminar series, and associated titles, dates, speaker information, and URLs for the media with the lectures. We also the lecture to be associated with zero or more categories, such as “physics,” and a group, such as “mitworld.”1 Ideally, all this information would be stored in a repository of some sort, but at this time it is simply recorded in files that serve as input to the indexing process.
As for the lectures themselves, we manually extract the waveform from the media file. For unknown reasons, this sometimes results in a slight linear discrepancy in timing between the extracted waveform and the RealPlayer file. Since the time-aligned transcriptions are based on the extracted waveforms, each lecture has an associated timescale which can be used to compensate for the difference. After lectures are transcribed, they are automatically divided into segments based on content.
In addition to indexing information about the lectures, we maintain a tables of courses, seminar series, and categories. When a lecture is added to the lecture index, it is assigned a unique identifier which is associated with any course, seminar series, and category information, as well as speaker, date, etc. Each segment of the transcription is assigned a unique segment identifier and associated with the lecture. Then each word of the segment is assigned a unique word identifier, which is associared with the segment identifier, begin and end time of the word, and the actual text.
All the words of a segment are treated as a single document, and, together with the group and the course, seminar series, category, and lecture identifiers as attributes and indexed by a text indexer. Thus a text query identifies segments, and text queries can be filtered based on lectures, courses, seminar series, categories, and groups. The segments located during a text query are scanned for matching words, and then a chunk of text (called a fragment) surrounding the matching words is returned.