<?xml version="1.0" standalone="yes"?>
<Paper uid="W01-1515">
  <Title>Annotation Tools Based on the Annotation Graph API</Title>
  <Section position="3" start_page="0" end_page="0" type="intro">
    <SectionTitle>
2 Architecture
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.1 General architecture
</SectionTitle>
      <Paragraph position="0"> Figure 1 shows the architecture of the tools currently being developed. Annotation tools, such as the ones discussed below, must provide graphical user interface components for signal visualization and annotation. The communication between components is handled through an extensible event language. An application programming interface for annotation graphs has been developed to support well-formed operations on annotation graphs. This permits applications to abstract away from file format issues, and deal with annotations purely at the logical level.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.2 The annotation graph API
</SectionTitle>
      <Paragraph position="0"> The application programming interface provides access to internal objects (signals, anchors, annotations etc) using identifiers, represented as formatted strings. For example, an AG identifier is qualified with an AGSet identifier: AGSetId:AGId. Annotations and anchors are doubly qualified: AGSetId:AGId:AnnotationId, AGSetId:AGId:AnchorId. Thus, the identifier encodes the unique membership of an object in the containing objects.</Paragraph>
      <Paragraph position="1"> We demonstrate the behavior of the API with a series of simple examples. Suppose we have already constructed an AG and now wish to create a new anchor. We might have the following API call: CreateAnchor(&amp;quot;agSet12:ag5&amp;quot;, 15.234, &amp;quot;sec&amp;quot;); This call would construct a new anchor object and return its identifier: agSet12:ag5:anchor34. Alternatively, if we already have an anchor identifier that we wish to use for the new anchor (e.g. because we are reading previously created annotation data from a file and do not wish to assign new identifiers), then we could have the following</Paragraph>
      <Paragraph position="3"> The implementation maintains indexes on all the features, and also on the temporal information and graph structure, permitting efficient search using a family of functions such as:</Paragraph>
      <Paragraph position="5"/>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.3 A file I/O library
</SectionTitle>
      <Paragraph position="0"> A file I/O library (AG-FIO) supports input and output of AG data to existing formats. Formats currently supported by the AG-FIO library include the TIMIT, BU, Treebank, AIF (ATLAS Interchange Format), Switchboard and BAS Partitur formats. In time, the library will handle all widely-used signal annotation formats.</Paragraph>
    </Section>
    <Section position="4" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.4 Inter-component communication
</SectionTitle>
      <Paragraph position="0"> Figure 2 shows the structure of an annotation tool in terms of components and their communication.</Paragraph>
      <Paragraph position="1"> The main program is typically a small script which sets up the widgets and provides callback functions to handle widget events. In this example there are four other components which  are reused by several annotation tools. The AG and AG-FIO components have already been described. The waveform display component (of which there may be multiple instances) receives instructions to pan and zoom, to play a segment of audio data, and so on. The transcription editor is an annotation component which is specialized for a particular coding task. Most tool customization is accomplished by substituting for this component.</Paragraph>
      <Paragraph position="2"> Both GUI components and the main program support a common API for transmitting and receiving events. For example, GUI components have a notion of a &amp;quot;current region&amp;quot; -- the timespan which is currently in focus. A waveform component can change an annotation component's idea of the current region by sending a SetRegion event (Figure 3). The same event can also be used in the reverse direction. The main program routes the events between GUI components, calling the annotation graph API to update the internal representation as needed. With this communication mechanism, it is straightforward to add new commands, specific to the annotation task.</Paragraph>
    </Section>
    <Section position="5" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.5 Reuse of software components
</SectionTitle>
      <Paragraph position="0"> The architecture described in this paper allows rapid development of special-purpose annotation tools using common components. In particular, our model of inter-component communication facilitates reuse of software components.</Paragraph>
      <Paragraph position="1"> The annotation tools described in the next section are not intended for general purpose annotation/transcription tasks; the goal is not to create an &amp;quot;emacs for linguistic annotation&amp;quot;. Instead, they are special-purpose tools based on the general purpose infrastructure. These GUI</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>