3. Basic concepts and terminology
Prev |  | Next

## 3. Basic concepts and terminology

In this section we list and describe several concepts often used in this manual without a further reference.

file

  Files is a collections of trees (possibly acompanied with some meta data common to all trees). Although the in-memory representation of a file has always the same form, its “physical representation” (called format) may vary. The part of TrEd program responsible for reading and writing files in a specific format is called a I/O _backend. Depending on a format, files may differ in some features.

tree

  A tree in this context is a rooted oriented cycle-free graph of nodes. In other words: it is a finite ordered set of objects called nodes (sometimes, but not in this manual, also called verteces), each of the nodes but one is connected to another node called its parent-node. This connection is called an edge. Such a structure is then called a tree if edges never form a cycle, i.e. by following an edge-path (e.g. a sequence of adjacent edges leading from a node to its parent-node) we never return to the node where we started. There is exactly one node without a parent-node, called the root of the tree. Every edge-path in the tree leads to this node. If `A` is a parent-node of `B`, then `B` is a child-node of `A`. Nodes having the same node as their parent-node are called siblings. In TrEd's internal representation of a tree, there are the following additional links between nodes:

  - a link from a parent-node to one of its child-nodes (usually but not necessarily this is the first of its child-nodes in the linear ordering of the tree). This child-node is called the first-son of the parent-node.

  - First son is linked with its next sibling (if any), called its right-sibling node (or lbrother). This sibling is again connected to another sibling, etc, so that all siblings are connected and this connection contains no cycle. Hence child-nodes of each node form a (possibly empty) chain originating on the first-son and connecting all its siblings one after another. The last sibling in the chain is called the last-sibling or last-son.

  - For easier tree traversal, nodes in TrEd also contain link representing a reversed version of the previous “right-sibling” relation, called left-sibling (or lbrother). So, if a node `A` is the right-sibling of `B`, then `B` is the left-sibling of `A`.

node

  We have already describe a node as an object occuring in a tree and possibly connected to other nodes in the tree. Apart from that, every node may be associated with some data represented in form of an attribute-value structure (AVS or feature-structure if you like). Each members of this structure (also called an attribute) has a name and value. Each name may occure in AVS only once. The names of node's attributes and types of their values are file-specific (or in some cases I/O-backend specific). Generally, a value of an attribute may be of one of the following types (it must be noted that not all of the types are supported by the I/O backends equally):

  - string

  - enumerated type (a string value from a pre-defined list)

  - “flat” list of values of one of the above types, i.e. a string of `|`-separated items. This type is used e.g. by FS-backend.

  - constant (usually not very useful, but sometimes handy)

  - attribute-value stucture (implemented as a Perl hash reference, fully supported by PML-backend and partially emulated by FS-backend)

  - ordered list of values of any type except list (implemented as a Perl array reference of the `Treex::PML::List` class). Currently only supported by PML-backend.

  - unordered list of values of any type except list (implemented and supported likewise).

  - alternative of values of any type except alternative (implemented as a Perl array reference of the `Treex::PML::Alt` class). Alternative is very similar to unordered list but as long as it has only one single value, it is represented by that value (rather than a `Treex::PML::Alt` array reference containing that value). Alternatives are currently supported by PML-backend.

active (or current) node

  The active node plays a similar role to that of a cursor in a text editor. Each view remembers its active node. In general, if we refer to the active or current node, we usually mean the active node of the active view. In the default setup, the active node is by default visually differentiated from other nodes by its red color (other nodes are displayed as yellow or black). However, it must be noted that a stylesheet can (and often does) change the coloring of the tree, including definin its own way to distinguish the active node.

file list

  Files in TrEd are further organized into collections called file lists. A file list is basically a list of filenames of files belonging to the collection.

view

  A view is the part of TrEd window where a tree is displayed. TrEd allows for multiple views (created by splitting a view in half either along the horizontal or vertical axis). Always, one of the views is focused. This view is called the active view (also the current view). All commands related to a file, tree and node usually only apply to the active view (or more specifically, to the objects it displays). The active view is visually distinguishable from the other views by its thick black border. Optionally, inactive views may also be stippled (see `StippleInactiveWindows`). Views can display trees from one file but also from several unrelated files. It is also possible to display a single tree in several views simultaneously. Each view is associated with a file list and a in-memory representation of a single file from that file list (in case of the active view called the current file list and the current file).

value line

  This term refers to the text field that appears above all tree views in the main window of TrEd, just below toolbars. Its content is controlled by stylesheets and hooks. It is typically used to display textual representation of the tree in the current view, e.g. a sentence.

status line

  Status line is a text field that appears at the bottom of the main window of TrEd. It is content is controlled by hooks and is typically used to display additional information about the active node in the current view computed using by macros, etc.

macro

  TrEd by default offers only a small set of fundamental and generic tree-editing commands. Commands specific to certain purpose or data are typically implemented as user-defined macros. A macro is a small program (more specifically a Perl subroutine), typically associated with a keyboard shortcut or a menu item. See Section 15, “User Macros” for details.

hook

  Hooks are similar to macros but they are called indirectly by TrEd rather directly by the user, although they also in a way response to a particular event or action performed by the user. For example, every time the user performs an action resulting in a file being opened, TrEd tries to locate and call a user-defined function named `file_opened_hook` in the current annotation mode (described below). See Section 15.9, “Hooks: automatically executed macros” for details.

annotation mode (also called binding context)

  Macros serving similar purpose and often related to some specific data may be organized to sets called annotation mode. Each view is associated with a annotation mode (called the current mode) and the user may easilly switch from one mode to another. If the user presses a keyboard shortcut, TrEd tries to find a binding for that shortcut in the current annotation mode. If it fails, tries the same with a default annotation mode called `TredMacro`. Similar lookup applies when the user performs an action which requires a hook to be called. See Section 15.10, “Using different sets of macros in different situations” for details.

minor mode

  The concept of minor modes is borrowed from GNU Emacs editor. Minor modes use hooks to provide additional functionality that is independent of the current annotation mode. Different minor modes can be used for different views. Currently TrEd ships with the following minor modes:

  neigh_sent

    shows in the text view above the tree the information from a configurable number of preceding and following trees,

  neigh_trees

    shows the active tree and a configurable number of neighboring trees on the left and right.

  move

    allows the user to manually adjust position of nodes in the view by dragging the nodes and pressing Shift or Control before drop to move the current node or the whole subtree to the position of the drop.

  reslt

    is a helper minor mode used by tree query macros to colour nodes that match the query.

stylesheet

  A stylesheet is a set of rules (called patterns) modifying the default appearance of trees in a view. Each view initially uses a stylesheet provided by the data file (which may be empty), but the user may instruct the view to use another stylesheet. The same tree may be viewed simultaneously in different views with completely different stylesheets. If a very complex visual presentation is required, stylesheet rules may be accompanied by some further presentational code defined in a `node_style_hook`. For more information see Section 10, “Customizing Tree Appearance: Stylesheets”.

extension (or extension package)

  An extension package is a special type of a ZIP file recognized by TrEd, which provides some additional functionality to TrEd. It can be installed directly from TrEd using the Extension Manager by the individual users and usually contains macros (annotation modes), resource files, file lists of sample data, configurations of I/O backends, stylesheets etc. related to some specific annotation project. The format of an extension package is described in Section Section 17, “Extension Packages”.

I/O backend

  I/O backend is a module of TrEd responsible for reading and writing files in some particular data format. Thus, adding support for a new data format only requires writing a corresponding I/O backend. Different data formats not only represent the data (trees, nodes, meta data) differently, but often differ in the ability to interchange data with other I/O backends because of the nature of the data. For example, while some I/O backends are rather generic, other are tightly bound to the actual content of the data (hence loading a file using one I/O backend and saving it in another may not work as expected in all cases). Nonetheless, most of the I/O backends used in TrEd are able to read the data and save them back without any loss of information. Detailed discussion of I/O backends can be found in Section 16, “I/O backends”.

Prev |  | Next
2. Installation and start up instructions | Home | ToC | 4. Overview of TrEd's user interface