Most NXT corpora come with a script for invoking the GUIs that work with the data; look for a top level file with the extension .bat (for Windows), .sh (for Linux), or .command (for Mac OSX). Where these scripts fail to work, it is usually because you need to edit them because you have put the data in a different place than where the script author expected. These start-up scripts will give as options the standard search gui and generic display gui, plus any other interfaces that have been registered for the corpus by editing the callable-programs section of the metadata. For corpora with many different annotations, the generic display as accessed in this way is unusable because by default, it tries to load and display everything - the command line call will give better control.

Section incomplete

EXPLANATION OF SEARCH HIGHLIGHTING

In the search highlighting, if there isn't a direct representation of some element on the display, then there's nothing to highlight. For instance, in many data sets timestamped orthographic transcription consists of w and sil elements but the sil elements are not rendered in the display, so the query ($s sil): won't cause any highlighting to occur. This can be confusing but it is the correct behaviour. Good interface design will have a screen rendering for any elements of theoretical importance.

The search GUI can be reached either by using search.bat/search.sh and specifying which corpus to load or by using the .bat/.sh for the specific corpus (if it exists) and choosing the Search option. It has two tabbed windows. The query tab allows the user to type in a query. Cut and paste from other applications works with this window. The query can also be saved on the Bookmark menu, but at May 2004 this doesn't work well for long queries. There is a button to press to do the search, which automatically takes the user either to a pop-up window with an error message explaining where the syntax of the query is incorrect, or, for a valid query, to the result tab. This window shows the results as an XML tree structure, with more information about the element the user has selected (with the mouse) displayed below the main tree.

The GUI includes an option to save the XML result tree to a file. This can be very handy in conjunction with knit for performing data analysis. It also includes an option to save the results in a rudimentary Excel spreadsheet. This is less handy, especially in the case of complex queries, because the return value is hierarchically structured but the spreadsheet just contains information about each matched element dumped into a flat list by performing a depth-first, left-to-right traversal of the results. However, for relatively simple queries and people who are used to data filtering and pivot tables in Excel, it can be the easiest first step for analysis.

The search GUI works on an entire corpus at once. This can make it slow to respond if the corpus is very large or if the query is very complicated (although of course it's possible to comment out observations in the metadata to reduce the amount of information it loads). Sometimes a query is slow because it's doing something more complicated than what the user intended. A query can be interrupted mid-processing and will still return a partial result list, which can be useful for checking it.

At May 2004, when the user chooses to open a corpus from the File menu, the search GUI expects the metadata file to be called something.corpus, although many users are likely to have it called something.xml (so that it behaves properly in other applications like web browsers). Choose the All files option (towards the bottom of the open dialogue box) in order to see .xml files as well as .corpus ones.

NXT comes with a generic display so that it can at least display and search any corpus in NXT format "out of the box", without having to configure the end user coding tools or build a tailored tool. It provides the absolute basics. It isn't meant for serious use, but it can be useful to test out new data or if you don't need GUIs often enough to spend time getting something better set up.

The Generic Display works on one observation at a time. It can be invoked at the command line as follows:

java net.sourceforge.nite.gui.util.GenericDisplay -c CORPUS -o OBS -f FONTSIZE -q QUERY

In the call, CORPUS gives a path to a metadata file and OBS names an observation that is listed in that metadata file. These are mandatory. You may optionally specify a font size for the data rendering. You may also specify a query that will be used to choose kinds of data for display. Only the variable type information will be used in the processing; the display will show data just from the files that include data that matches variables of those types. For instance, -q '($w word)($d dialogue-act):' will render display windows for words and dialogue-acts only, ignoring all other data. This is particularly useful for corpora with many different kinds of annotation, where it would create too busy a display to show everything. For larger corpora, NXT is unable to render all of the annotations at once because this would take too much memory. It is only possible to run the generic display for such corpora with the -q option.

add screenshot. Is there more to say?

The Generic Display simply puts up an audio/video window for each signal associated with an observation, plus one window per coding that shows the elements in an NTextArea, one element per line, with indenting corresponding to the tree structure and a rendering of the attribute values, the PCDATA the element contains, and enough information about pointers to be able to find their targets visually on the other windows. It doesn't try to do anything clever about window placement. As with other NXT GUIs, there is a Search menu, and the display shows both search and time highlights.

The signal labeller is for creating timestamped labels against signal, with the labels chosen from an enumerated list. This can be used for a very wide range of low-level annotations, such as gaze direction, movement in the room, rough starts and ends of turns, and areas to be included in or excluded from some other analysis. The tool treats the labels as mutually exclusive and exhaustive states; as the user plays the signal, whenever a new label is chosen (either with the mouse or using keyboard shortcuts), that time is used both for the beginning of the new label and the end of the old one. Although there are several similar tools available, this tool will work on either audio or video signals, including playing a set of synchronized signals together, and works natively on NXT format data, which is of benefit for user groups that intend to use NXT for further annotation. It does not, however, currently include either the palette-based displays popular from Anvil and TASX, and the signal control is meant for the coarser style of real-time coding, not for the precision timing that some projects require. It also does not contain waveform display, and therefore is unsuitable for many kinds of speech annotation.

Java class: net.sourceforge.nite.tools.videolabeler.ContinuousVideoLabeling

The second end user GUI is for coding discourse entities above an existing text or speech transcription. Coding is performed by sweeping out the words in the entity and then mousing on the correct entity type from a static display of the named entity type ontology, or choosing it by keyboard shortcut. It can be used for any coding that requires the user to categorize contiguous stretches of text (or of speech by one person) using labels chosen from a tree-shaped ontology. In addition, it allows the user to indicate directional relationships between two coded entities, with the relationship categorized from a set of labels. The most common uses for this style of interface are in marking up named entities and coreferential relationships.

Java class: net.sourceforge.nite.tools.necoder.NECoder

The final GUI is for segmenting discourse into contiguous stretches of text (or of speech by one person) and categorizing the segments. The most common use for this style of interface is a dialogue act coder. Coding is performed by marking the end of each discourse segment; the segment is assume to start at the end of the last segment (or the last segment by the same speaker, with the option of not allowing segments to draw words across some higher level boundary, such as previously marked speaker turns). A permanent dialogue box displays information about the currently selected act and allows a number of properties to be specified for it beyond simple type. The coding mechanisms supported include a tickbox to cover boolean properties such as termination of the act before completion, free text comments, and choice from a small, enumerated, mutuallly exclusive list, such as might be used for noting the dialogue act's addressee. Although this structure covers some styles of dialogue act coding, this tool is not suitable for schemes such as MRDA where dual-coding from the same act type list is allowed. This tool additionally allows the user to indicate directional relationships between acts using the same mechanism as in the discourse entity coder, although for current dialogue act schemes this is a minority requirement.

Java class: net.sourceforge.nite.tools.dacoder.DACoder

This is the first in a series of tools to display multiple versions of a particular type of annotation. The non-spanning comparison display can show two different annotators' data over the same base-level transcription. We use annotator loosely to mean any human or machine process that results in an annotation. This is a display only, not an annotation tool. Display details are controlled using a configuration file much like the other end user GUIs, though there are two extra settings required (see below)Where?. The display shows the two annotators' names, with the first underlined and the second italicised, in a small Annotator Legend window. Every annotation by the first annotator is underlined and every annotation by the second is italizized so that the two can be distinguished. The types of annotations will be distinguished in the same way as for the discourse entity coder.

Java class: net.sourceforge.nite.tools.comparison.nonspanning.NonSpanningComparisonDisplay

This is the second in a series of tools to display multiple versions of a particular type of annotation. The dual transcription comparison display displays two transcriptions side-by-side using a different configuration for each. For example, a manual transcription on the left and an automatic transcription on the right. This is a display only, not an annotation tool. Display details are controlled using a configuration file much like the other end user GUIs. Any annotations on the transcriptions will be displayed in the same way as for the non spanning comparison display.

Java class: net.sourceforge.nite.tools.comparison.dualtranscription.DualTranscriptionComparisonDisplay

There are two basic steps to configure one of these end-user tools for your corpus:

<callable-program description="Named Entity Annotation" 
  name="net.sourceforge.nite.tools.necoder.NECoder">
    <required-argument name="corpus" type="corpus"/>
    <required-argument name="observation" type="observation"/>
    <required-argument name="config" default="myConfig.xml"/>
    <required-argument name="corpus-settings" default="my-corpus-settings-id"/>
    <required-argument name="gui-settings" default="my-gui-settings-id"/>
</callable-program>

<NXTConfig>
  <DACoderConfig>
    <!-- Corpus settings for the ICSI corpus -->
    <corpussettings
        id                      = "my-corpus-settings-id"
        segmentationelementname = "segment"
        transcriptionlayername  = "words-layer"
        transcriptiondelegateclassname = "MyTranscriptionToTextDelegate"
        neelementname           = "named-entity"
        neattributename         = "type"
        annotatorspecificcodings= "nees"
    />    

    <guisettings
        id                      = "my-gui-settings-id"
        gloss                   = "My Corpus settings"
        applicationtitle        = "My Corpus Tool"
    />

  </DACoderConfig>
</NXTConfig>

It's often useful for applications to be able to pop up a search window and react to search results as they are selected by the user. Using any in-memory corpus that implements the SearchableCorpus interface (for example NOMWriteCorpus), you can very simply achieve this. If nom is a valid SearchableCorpus we could use:

net.sourceforge.nite.search.GUI searchGui = new GUI(nom);
searchGui.registerResultHandler(handler);
...
searchGui.popupSearchWindow();
          

In this extract, the first line initializes the search GUI by passing it a SearchableCorpus. The second line tells the GUI to inform handler when search results are selected. handler must implement the QueryResultHandler interface. This simple interface is already implemented by some of NXT's own GUI components like NTextArea, but this mechanism allows you complete freedom to do what you want with search results. There is no obligation to register a result handler at all, but it may result in a less useful interface.

The third line of the listing actually causes the search window to appear and will normally be the result of a user action like selecting the Search menu item or something similar.