The Concept of Behavioral Elements, Categories and the Representation of Data in Solomon Coder
In Solomon Coder the coding of behavior is done with the use of Behavioral Elements. On the user interface each behavioral element is represented as a button. The user can define the number of elements and the name and category of each individual element. A behavioral element can be any event or state of interest e.g.: Sit, Stand, Run, Bark, Is Near Owner, etc.
By many practitioners of behavior research the usual custom before starting to quantify (Code) behavior, is to define the Variables of interest. These variables are usually something similar as: duration of X, frequency of X, latency of first Y, frequency of Y, frequency of Z, etc. These variables are not identical to the behavioral elements that have to be used in Solomon Coder. Staying at the former example, the five variables should be represented as three behavioral elements (X, Y, Z). Then the occurrences of X, Y and Z registered, which then provides the raw data (Coding Sheet). In the next step the data is analyzed, where the desired variables defined by the user will be calculated. This has the benefit that new variables can be calculated from the raw data later, without the need to repeatedly code the videos (e.g.: duration of Y and Z, etc.).
The first step when starting to work with Solomon Coder is creating a Configuration file. This contains the behavioral elements created by the user, their categories and the layout of the user interface. For an array of videos taken in the same experimental setup the same configuration file can be used. This, besides being more comfortable, provides the uniformity of the coded material and simplifies the later analysis of the raw data. Coded data (Coding Sheets) are stored in files with .arch extensions. Each .arch file also contains the configuration file which was used when creating it. This enables to reopen .arch files even if the original configuration file is not loaded in the program. These files can be reopened and data can be added or modified if needed.
This is often necessary as the user wants to code new behaviors not coded in a previous session. New behavioral elements and categories can be added to already existing configurations. Then loaded into the program and an already existing .arch file can be reopened using the expanded configuration. The original configuration stored in the .arch file has to be overridden so finally new data can be added.
Although the program provides some safety measures, deleting of behavioral elements or changing their categories in configuration files should be avoided when reopening already existing .arch files using the modified configuration file! This could result in incorrect data without warning. This is why deciding the categorization of behavioral elements prior to creating the configuration file is extremely important. Configurations can be expanded safely and used in combination with existing .arch files created with the previous version of the configuration. A configuration modified in any other way should never be used with already existing .arch files!
The categorization of behavioral elements serves two purposes: 1) grouping the elements so they can be more easily dealt with; 2) enabling the use of elements that could occur at the same time. If working with multiple behavioral elements it is often necessary to put them into different categories. For example we want to code the following behaviors of an animal: stand, sit, lay, looking at A, looking at B. These five elements can be naturally put into two categories: "Posture" (stand, sit, lay) and "Attention" (looking at A, looking at B). What makes necessary to put these elements in separate categories, is that the elements in the Posture category could co-occur with any element of the Attention category. This would causes a problem because of the way behavioral data is represented in Solomon Coder.
The data is stored in a table (coding sheet) which has columns equal to the number of categories and each row represents a certain point in time.
In case two events would occur at the same time and they were in the same category (column), only one of them could be stored. That is why putting the behavioral elements in the right number of categories needs to be carefully considered before creating a configuration file.