NOMOS User Manual

Overview Download Manual Tutorials Bug Tracker Contact

Installation and Running

Requirements

NOMOS is developed entirely in Java and therefore should run any platform supporting Java. However, NOMOS requires:

Java Runtime Environment (JRE) 5.0 or higher

• Download for Windows/Linux/Solaris or OS X.
• In addition, you must make sure that J2SE? 5.0 is the default version of Java on your system:
  • In Windows, go the Control Panel and double-click "Java" (if no "Java" icon appears, then you do not have Java properly installed). Choose the "Java" tab at the top and click on "View..." on "Java Application Runtime Settings." Make sure that a platform version 1.5 or higher is checked as "Enabled" and at the top of the list.
  • Note that older releases of J2SE? 5.0 from Apple do not make their installation the default version of Java on your system; you must set this option in the Java Preferences Utility which can be found in /Applications/Utilities/Java/J2SE 5.0/
• To verify your Java installation: At the Windows command prompt, cygwin shell, or OS X Terminal, type java -version and make sure your build is at least version 1.5.0 or higher.

Java Media Framework 2.1.1e or higher

• Download for Windows/Linux/Solaris/OS X
• Note: OS X users should use the "cross-platform" version.
• Note: Installing JMF is not strictly necessary to use NOMOS. If you choose not to install JMF, you will be limited to a single audio file per discourse, there will be extremely limited or no video capabilities, and you will have not be able to use multiple synchronized media files.

Compatibility

NOMOS has been tested under the following configurations, in order of most to least use.

Installation on popular platforms like Windows XP/2000, OS X, or Linux is a breeze. With respect to annotation capabilities, there is no reason to prefer one platform over another. However, be aware that since we utilize the Java Media Framework to play audio and video, you will have varying success with displaying media on different platforms because of platform-specific format support. Windows supports the widest range of audio and video formats, though media in the right format can be viewed on all of the platforms listed below. For a complete list of compatible media formats, see Sun's JMF documentation.

Installation

1. Make sure that your system meets the system requirements.
2. Download the latest version of NOMOS, selecting either a platform-specific installer or the platform-independent package.
   A platform-specific installer is often easier for getting started right away!
3. Install NOMOS:
   • Windows: Run the NOMOS setup program ("NOMOS_2_0_0_setup.exe"); the wizard will guide you through the installation process.
     • Note: Please uninstall any older versions of NOMOS before running the setup program.
   • Platform Independent: Unzip the compressed archive ("NOMOS_2_0_0.zip") to a directory of your choice.
4. If you are new to NOMOS, we recommend also downloading our sample video, used in the tutorials. Simply unzip the compressed archive to a directory of your choice.

Running

If you used the Windows installer...

• Start NOMOS by going to your Start Menu, then selecting Programs or All Programs, then the Nomos folder, then Nomos.

If you used the platform-independent package...

• On Windows, OS X, or other windowing systems: Using Windows Explorer (My Computer), Finder, or the equivalent, browse to the folder where you unzipped NOMOS and double click on nomos.jar. In Windows, the file may appear simply as nomos (depending on your local settings). The icon should look something like this:
  
• On Linux, Unix, Cygwin, or in the OS X Terminal: Change to the directory where NOMOS was unzipped and run: java -jar nomos.jar, or use nomos.sh.

Quick Start and Tutorials

To start using NOMOS right away, we encourage you try our quick start guide and tutorials. These tutorials are designed to walk you through basic usage examples, demonstrating various features of the NOMOS application and illustrating major annotation concepts. We strongly recommend that new users complete all main tutorials, as harnessing NOMOS's flexibility and power sometimes requires a thorough understanding of the application's conventions and capabilities.

Topics Covered:

The Basics of Semantic Annotation

NOMOS uses an ontology-based Semantic Web annotation architecture. To those unfamiliar with the Semantic Web Ontology Language (OWL), this may be seen as paralleling the use of XML Document Type Definitions (DTDs) in an XML-based architecture. An XML DTD acts as a specification for a class of properly formed XML documents, specifying and constraining the way its elements may be formed. Similarly, NOMOS uses OWL ontologies to define a space of meaningful annotation terms. NOMOS is then used to make assertions using this terminology. The benefit of the OWL approach is that it is an expressive formal logic which provides a well-defined meaning to the annotations as well as the ability to infer further information through formal reasoning.

The Annotation Language

All information processed by NOMOS is encoded in a logic called OWL. OWL is a W3C? standard language which is widely used as the foundation of Semantic Web technology. OWL is a description logic, which is a family of logic-based knowledge representation formalisms similar to frame-based systems. A description logic knowledge base is composed of two parts:

• A terminology (T-Box) which contains definitions and axioms (the annotation schema)
• A set of assertions (A-Box) which contains specific facts about individual entities (the annotations)

The Annotation Schema (The Terminology)

The terminology is a set of definitions of classes, properties, relations, and restrictions. It does not contain information about specific entities, but rather provides a set of terms which may be used to assert facts about the world and its entities. A terminology may be thought (slightly erroneously) as a set of interfaces in an object-oriented programming language. The wine ontology is a classic example.

The Annotations (The Assertions)

In NOMOS, the actual annotations are done through the assertion of facts about individuals using the defined terminology. For example, (PersonX is-a Female) states that the entity PersonX belongs to the class Female. Unique identifiers (e.g. PersonX) are assigned to individual things (e.g. words, utterances, people, chairs, video frames or whatever you are annotating), and terms from the terminology (e.g. Female), are used to make assertions about them. Assertions are always a triple (subject predicate object), and may be built up from identifiers for individuals (e.g. PersonX), terms from the terminology (e.g. Female), literal values like strings or dates, or special terms from the OWL logic (e.g. is-a).

Annotation Layers

A unified set of assertions (really just a list of triples) is called a model in OWL parlance. Additionally, models may be specified to depend on other models. This concept is referred to as model inheritance or importing. In the context of NOMOS, this can be thought of as layered annotation. For example, when creating annotations for a corpus of dialogues, a model would be created which identifies the participants in the corpus. Also, a model would be created which contains assertions about when the participants spoke. In this case, the latter model is dependent on the former because assertions about what a person does cannot be made without reference to the person objects themselves. Therefore, the latter model would be set to import the former. In this manner, models containing different types of knowledge are built on top of one another in layers, creating a dependency structure. (See the section on session inheritance for more on this topic.)

File Format

All NOMOS annotations are written to N-Triple syntax, one model per file. This format is standardized and easily parseable into a relational database structure if needed. The terminology is automatically written out in this form as well.

Core NOMOS Annotation Concepts

Session Inheritance

Most sessions import one or more other sessions, creating a dependency structure between sessions. For example, a session containing annotations of topics will typically inherit a session containing the transcript annotations. This dependency structure reflects the concept of layered annotation, in which annotations are built on top of one another. This concept is called inheritance and a session is said to import another sessions. A typical import hierarchy is:

We note that the trees begin with metadata for a single sequence of meetings (meeting_sequence_a) which imports nothing. This metadata would include information pertinent to all of the meetings. For example, sequence metadata often defines the participants in the sequence of meetings and their properties.

The next level of the hierarchy in this case is metadata for individual meetings. This typically includes information about a particular meeting itself (it's start and stop times, and participants) as well as information about the media used to record the meetings (video and audio files).

The next level in this case is transcripts of the meeting. In the above hierarchy, we can see that alex annotated meeting_1 while jamie annotated meeting_2.

Finally, at the next level, annotations are performed over the transcriptions. Here jill and fred each annotated the meetings for sequences of topics, and used the transcripts to do so.

"Persistent" Annotation Sessions

Often, an annotator may want to make annotations not just of events and entities which are in a particular meeting, but of entities which persist across multiple discourses. Imagine that you were annotating words for their discourse referents. It is quite likely that the same discourse referent will be mentioned in multiple meetings (participants might discuss a report assigned as an action item in a previous meeting, for example). This means that annotators must have some way to create persistent entities which can be loaded into multiple meetings. To handle such persistent data, a more complex import hierarchy must be used. Building on our previous example, we would yield the following hierarchy to include annotations of discourse referents:

Note that some sessions each import two other sessions. These sessions import a persistent session, which will be used to store the actual referents, as well as the transcripts over which the annotations will be made. Imports serve as a powerful mechanism for creating data which "persists" across multiple discourses.

Local Configuration

Local configuration is necessary for referencing media and annotation files from special locations on the local file system. NOMOS configuration properties are defined in the file config/nomos.config. To change these properties, create a new file called nomos.local.config rather than modifying nomos.config. (nomos.local.config will not be modified or deleted by the NOMOS installer or uninstaller whereas any changes made to nomos.config will be overwritten during either an uninstall or upgrade process!) In this new file, you may override any of the default settings in nomos.config. The first line of nomos.local.config should be:

inherits=nomos.config

Then, any properties which are redefined in this file will override the definitions in nomos.config. By default, the startup scripts will look for nomos.local.config and back off to nomos.config if the local file cannot be found. The following properties must always be set and will likely need to be configured for your local system:

Loading and Importing Corpora

The NOMOS corpus importing process is documented in detail in the separate corpus importing page.

Ontologies and Annotation Schemata

The core NOMOS ontology (corpora_2_0) and other ontologies which extend the core are documented in detail in the separate ontology documentation page.

Advanced Customization using Java

NOMOS has a number of avenues for customization and enhancement though Java programming, typically called "plugins" (e.g. importers, scripts, GUI plugins). Introducing Java class extensions may be done by adding your class files to the NOMOS executable classpath, but we recommend and can only support NOMOS extension development through our Eclipse-based source distributions. See the following page for instructions on downloading this source-based version of NOMOS and beginning development:

• The Semlab Open-Source Software Programmer's Manual

The following resources are also available for Java developers who are interested in extending NOMOS:

• NOMOS Advanced Tutorials
• CSLI corpora module Javadocs
• CSLI model module Javadocs
• CSLI util module Javadocs

Troubleshooting

Please use the NOMOS Bug Tracker for information on bugs, proposed features, and common issues.

Reference

Menus

This section describes the main NOMOS application menu options, and what actions they perform. Links to relevant parts of the manual are given.

Keyboard Shortcuts

(Given for Windows, Mac users should use Command instead of Control.)

Always available:

Available while an annotation session is open:

Glossary

A selection of terms you may encounter in our documentation.

action item

"a documented event, task, activity, or action that needs to take place." (WP)

annotator

corpora

"a large and structured set of texts (now usually electronically stored and processed)" (WP)

discourse

"In semantics, discourses are linguistic units composed of several sentences — in other words, conversations, arguments or speeches." (WP)

entities

import

importers

(Type of script.) Provide corpora importing capabilities.

labels

(Type of plugin.) Display entities on tracks.

media

An audio and/or visual recording of a meeting.

meeting

models

In NOMOS, annotations are represented as assertions about the data, which are grouped into collections of assertions called models. Each of these models is generally referred to as a session. More specific information about models is available in the section on semantic annotation.

metadata

"data that describe other data. Generally, a set of metadata describes a single set of data, called a resource." (WP)

ontology

"a data model that represents a domain and is used to reason about the objects in that domain and the relations between them." (WP)

partitioning

In a perspective, the action which may be applied to queries which automatically divides the query results into multiple tracks, based on the model from which the result originates or on the value of some other variable in the query.

panels

(Type of plugin.) Displaying non-*temporal* entities.

perspectives

Define what data is displayed, how that data is displayed, and how the user can interact with the displayed data. A perspective is a specific configuration of the GUI, consisting of a user-defined set of queries and plugins which together determine the way data is displayed to, and annotated by, the user.

plugins

NOMOS uses a variety of plugins to display, process, and interact with data. Plugins are Java code extensions to the NOMOS code base. NOMOS allows for the usage and development of several different types of plugins: tracks, labels, panels, scripts. NOMOS provides a full-featured annotation environment out-of-the-box, but it may be useful to create custom-designed interfaces for specific annotation tasks. For these tasks, new or derived plugins provide a mechanism for altering NOMOS's default behavior.

processors

(Type of script.) Provides data processing capabilities. Usually requires Java coding to implement. (See also, queries.)

producer

The source of annotation data; the annotator.

queries

Select data for display or manipulation within NOMOS. A query is constructed using a convenient table/grid interface, but is internally represented with standard SPARQL. Usage does not require Java development. (See also, processors.)

scripts

(Type of plugin.) Provide an interface for running batch processes over multiple sessions via the NOMOS GUI. Scripts can be used for almost any processing task. They are ideal for exportation tasks: for example, you could write a script which would convert a set of annotations into an XML file format. Processors and importers are types of scripts.

semantic

"Semantics refers to the aspects of meaning that are expressed in a language, code, or other form of representation." (WP) However, often refers to technologies or standards associated with the Semantic Web (WP).

session

A session is a tuple, consisting of an annotator, a dataset to annotate, and a perspective. A session encompasses the performance of a single annotation task by a particular annotator (human or otherwise) on a particular dataset. Each session is referred to by a unique name, using the following string attributes:

• annotator: The person (or computer program) that made the annotations in the session
• main object: This is a string describing the "main object" being annotated.
• data type: A short string describing the type of annotations stored in this session.
• session ID: The session id mainly exists as an extra attribute to differentiate otherwise identical sessions. For example, it might carry version information.
• In NOMOS, and in this manual, sessions are often abbreviated in the form annotator--main_object--data_type--session_id.

sparql

SPARQL Protocol and RDF Query Language (WP)

templates

A deprecated term for perspectives. You may still encounter this word in source code or some older documentation.

temporal

Relating to time, or time-dependent.

tracks

(Type of plugin.) Visually display temporal entities (or entities related to temporal entities).