ActSds and OdfSds: Programs for Converting INTERACT and The Observer Data Files into SDIS Timed-Event Sequential Data Files

Abstract

Programs for converting Mangold International’s INTERACT and Noldus Information Technology’s The Observer data files to Sequential Data Interchange Standard (SDIS) timed-event sequential data files are described. Users who convert their INTERACT or The Observer data files can then take advantage of various flexible and powerful data modification and computational procedures available in the Generalized Sequential Querier (GSEQ), a program that assumes SDIS-formatted files.

Mangold International’s INTERACT (www.mangold-international.com; Mangold, 2006) and Noldus Information Technology’s The Observer (www.noldus.com; Noldus, 1991; Noldus, Trienes, Hendriksen, Jansen, & Jansen, 2000; Noldus Information Technology, 2003) are sophisticated software packages for the collection and analysis of observational data. Typically coders work with multimedia digital files (other possibilities include video tapes or live coding); the results of their coding with INTERACT are stored in tab-delimited text files with the extension ACT and with The Observer in text files with the extension ODF (Observer Data File). The Sequential Data Interchange Standard (SDIS) is a standard format for sequential data (Bakeman & Quera, 1992); files using this format have the extension SDS. The programs described here, ActSds and OdfSds, convert ACT or ODF into SDS files. In particular, OdfSds is a more general version of an earlier ODF to SDS conversion program (Bakeman & Quera, 2000) that required Version 3 Observer Data Files, whereas OdfSds should work with files produced by various versions of The Observer.

Conversion is useful for investigators who use either INTERACT or The Observer to code behavior but who then wish to perform at least some of their analyses with the Generalized Sequential Querier (GSEQ), a program that analyses SDIS-formatted data (Bakeman & Quera, 1995). The Observer and INTERACT were designed initially to facilitate data collection. In contrast, GSEQ has no data collection capability but was designed to facilitate more sophisticated data analyses in conjunction with standard statistical packages. Thus the conversion programs described here are useful for investigators who wish to take advantage of the extensive data modification and analytic capabilities of GSEQ. For example, users can define new codes that occur only at those times when two or more earlier behaviors were all coded (a logical and), or at times when any one of a set of behaviors was coded (a logical or); other logical operations are also available. Further, users can define new codes that are tied to the onset, offset, or occurrence times of existing codes. For example, a new code might include the 10 seconds before or the 5 seconds after the onset of an alarm cry, or a stretch of time that includes seconds coded for baby crying and 5 seconds after. GSEQ allows for lag sequential analysis to any of a number of positive or negative lags and also includes a procedure that converts time-based to event-based data. Another useful feature in GSEQ, especially when observers are first being trained, lets the user define codes within a specified time window as an agreement and then computes the kappa agreement statistic for two observers using this flexible window.

INTERACT is commercially available from Mangold International; The Observer is commercially available from Noldus Information Technology; and GSEQ for Windows (GSW), ActSds, and OdfSds can be downloaded from the authors’ web pages (see Availability section).

Events, Time Formats, and SDIS Data Types

Basic to observational research is the event. Coders are asked to detect and identify (i.e., code) events as they occur in the stream of behavior. Programs like INTERACT and The Observer are useful because they permit users to view and review video records and identify events of interest; the programs then automatically record when those events occurred. Both INTERACT and The Observer store information about coded events in data files; both also have ancillary files that contain information about the codes used and other information. ActSds and OdfSds process only the data files, hence these programs should work with data files produced by different versions of INTERACT and The Observer, even when the format of the ancillary files changes, as long as the basic data file format remains constant.

INTERACT records times as hh:mm:ss:ff, where hh is hours, mm is minutes, ss is seconds, and ff is frames; ActSds lets the user specify whether there are 30 frames per second, the US standard (NTSC), or 25 frames per second, the European standard (PAL). The Observer records time in decimal format (e.g., sss.dd), so the frames per second is not an issue. Both ActSds and OdfSds convert all times to a decimal format and let the user specify whether to round to the nearest 100^th or 10^th or nearest second—although, note, rounding to the 100^th cannot make video more precise than the 25^th or 30^th of a second used for recording. By default AcdSds and OdfSds round to the nearest second, recognizing that human observers are involved, that coded behaviors usually last a few seconds at least, and that as Bakeman and Quera argue (1995) it does not make sense to use more precision than is reasonable or required.

SDIS permits several time formats. ActSds and OdfSds convert INTERACT and The Observer data files into SDIS timed-event sequential data (TSD) files. Data in TSD files consist of codes along with their associated onset and (explicit or implicit) offset times. There are other SDIS data types (Bakeman & Quera, 1995), but essentially these are notational conveniences; all types are compiled by GSEQ into files with a single binary format, which GSEQ then uses for analysis. When codes are organized into mutually exclusive and exhaustive (ME&E) sets of codes, coders do not need to enter offset times explicitly because the onset of another code in the set implies the offset for the previous code in that set. Both INTERACT and The Observer let users define sets of ME&E codes in an ancillary file. INTERACT then enters offset times for codes in such sets explicitly in the data file. Thus ActSds produces entries of the SDIS form, Code,OnsetTime-OffsetTime. In contrast, The Observer does not enter offset times explicitly in the data file. Thus OdfSds produces entries of the SDIS form Code,+OnsetTime (termed a context code); offset times are determined by the GSEQ compiler from information concerning sets of ME&E codes given in the SDIS declaration, as described later.

Subjects and Sessions

Observational researchers, even as they lavish time on careful coding of behavior, have in mind eventual data analysis, which will be shaped by the study’s design. Thus it is important at the outset to specify the basic sampling units (individual participants, parent-child dyads, families, or other groups—cases in SPSS, or subjects in older literature) and the research factors that constitute the design. Traditionally such factors are described as between-subjects (e.g., gender with two levels, male and female) or within-subjects (e.g., subjects observed more than once, for example, at 12-, 18-, and 24-months of age, or in different contexts). When repeated measures exist, analytic units, each identified with a repeated measure, are nested within sampling units. Hereafter, when we use the term unit, we mean an analytic unit, either one per sampling unit for between-subjects or more than one for within-subjects designs.

GSEQ lets the user compute various scores from an observational session. These scores are then organized by the research factors for subsequent analysis. In other words, we are defining session as synonymous with analytic unit (Bakeman and Quera, 1995, defined a session as a sequence of coded events for which continuity can be assumed, i.e., an uninterrupted stretch of time that is coded but here we recognize that a session might be segmented by either planned or unplanned breaks; more later). Statistics and indices derived from the coded data for an observational session constitute scores; scores from several sessions (analytic units) are then organized by the between- and within-subjects factors of the design and analyzed using conventional statistical techniques. (Howe, Dagne, & Brown, 2005, use the term episode instead of session; we prefer to reserve episode for stretches of behavior within sessions, e.g., a growling episode made up of individual growls).

Each ODF file includes data for a single unit, whereas each ACT file can contain data for one or more units (termed Sets or, in an earlier version of INTERACT, Takes). In contrast, an SDS file contains data for all units included in a particular study, which is why ActSds and OdfSds let the user select several files for conversion to a single SDS file. In SDS files, the unit label (i.e., name or identifier), if present, is enclosed in angle brackets and precedes information about that unit’s events. ActSds uses the Set label, if present in the ACT file, and OdfSds defaults the label to “<Unit#1>,” <Unit#2>,” etc. However, before conversion, both programs let the user edit these unit (i.e., session) labels as desired.

SDIS permits a session to consist of more than one segment, separating each with a semicolon; thus the general form of a session in an SDIS file is:

<identifier> sequential codes and times [; sequential codes and times]/

where square brackets enclose optional material and the slash indicates the end of data for that unit (see Figure 1). Any breaks in continuity might be planned (e.g., one recording per day for a week for one child) or unplanned (e.g., an unexpected event intrudes during data collection). INTERACT does not have notation for an interrupted recording within a Set, hence each unit produced by ActSds consists of one uninterrupted session. Typically, an ODF file comprises data for one session, indicated by a line that contains {start}, subsequent lines with times and codes, and a final line that contains the offset time followed by {end}. However, a second {start} may follow a previous {end} (in some versions of The Observer), or there may be a {susp} followed by a {resu} (for suspend and resume). If an ODF file contains more than one session segment, they are separated in the SDS file with semicolons.

Figure 1.

Examples of INTERACT and The Observer data files converted into SDIS files by programs ActSds and OdfSds, respectively.

Technical note: SDIS allows for explicit session start and stop times; if absent, they default to the onset time of the first code and the offset time of the last code, respectively. If an ACT file has explicit start and stop times listed in the Set line, ActSds uses these; OdfSds uses the time on the {end} line as an explicit session stop time.

Research Factors

In its current version, INTERACT allows for Sets with their associated Events to be nested within Groups. Thus group labels could represent the levels of a research factor or variable; for example, the variable could be gender with two groups, male and female. The Observer lets users name levels of independent variables within each ODF file, one per line, on lines between a line that contains {indvar} and the line that contains {start}. SDIS permits users to define up to 7 unique variables, corresponding to factors that reflect the design of the study, along with up to 12 unique levels for each variable. For example one factor might be gender with two levels (male, female) and a second factor might be treatment with two conditions (experimental, control), thereby defining four conditions or cells for this 2 ×2 design (i.e., two between-subjects variables, each with two levels).

Assigning units to conditions (i.e., levels of each factor) in SDIS is useful primarily when condition information (i.e., the values or levels for each variable) is exported to standard statistical programs (e.g., SPSS or SAS) along with summary statistics for each analytic unit, so that, for example, standard analyses of variance may be performed. Additionally, all summary tables produced by GSEQ may, optionally, be pooled over levels of a factor, which is often useful during initial exploratory analyses of ones data.

In SDIS, factors, if used, are indicated by terms for levels enclosed in parentheses just before the slash that terminates each session, for example, given the two variables mentioned earlier a unit might end with:

<identifier> sequential codes and times (male, control)/

ActSds and OdfSds let the user name as many as seven factors (none, or one, or two is more typical) and specify their names. Then factor levels can be assigned to each unit. In ActSds, factor level labels can also be formed from file names or group or set labels. In OdfSds, if users wish lines following {indvar} to be used as level names, they name the number of factors and for each indicate which line after {indvar} should be used for the factor level label. Factor names default to Factor#1, etc., but the user can edit both factor names and their level names, as desired. If the user specifies factors and their levels, the appropriate syntax for the SDS file is generated.

INTERACT Categories and The Observer’s Actors, Behaviors, and Modifiers

INTERACT organizes codes into categories (in the ACT datasheet, each category is a separate column), with each event on a separate line. Data lines in an ODF file contain information about the events coded. These lines have the general form:

time [Act,] Beh [,Mod] [,Mod] [,/* comment]

where time is a decimal number indicating seconds, Act indicates an actor code, Beh a behavior code, Mod a modifier code (e.g., the recipient of the behavior, its intensity or direction, etc.; Noldus, 1991), and square brackets optional material. SDIS has a simpler structure. Its codes are unitary, not multipartite; moreover, GSEQ’s flexible data modification commands let the user derive useful new codes from the initial ones. Thus ActSds and OdfSds create codes for the SDS file by concatenating category and initial codes (INTERACT) or actor, behavior, and modifier codes (The Observer). Ideally, for readability of output, SDIS codes should be relatively brief, seven characters or fewer. Hence both ActSds and OdfSds let the user edit the proposed SDIS code names before conversion. Further details are provided in technical write-ups that can be downloaded along with the programs.

SDIS Type, Code, and Condition Declarations

SDIS files begin with a type declaration and, optionally, a list of permissible codes and conditions, if any. ActSds and OdfSds generate declaration line(s) for the SDS file like this:

Timed (codes) [* conditions] ;

Timed indicates a timed-event sequential data file (TSD) and the square brackets indicate optional material, present only if factors (i.e., conditions) are defined. In its output, GSEQ orders codes as they are listed in this declaration, so users may wish to declare the codes in a way that makes sense to them. Further, per SDIS syntax, codes that constitute a ME&E set should be enclosed in parentheses. By default, ActSds does not define any ME&E sets and any sets defined by OdfSds may not be correct [OdfSds assumes, e.g., that all behavior codes, or all codes derived from each actor if any, constitute a single ME&E set]. In either case, the user should edit the SDS file before compiling so that the declaration reflects the assignment of codes to ME&E sets. Two examples of data conversion are shown in Figure 1.

ActSds and OdfSds Programs: Details and Availability

The ActSds and OdfSds programs consist of three or four tabbed pages, each of which represents a step in data conversion, and three menus (file, edit, and about). Each tab contains a “when-done” button that lets the user move to the next tab. Again, further details are provided in technical write-ups that can be downloaded along with the programs. A zip file containing the ActSds program and its technical write-up, and the OdfSds program and its technical write-up, may be downloaded at no charge from http://www.gsu.edu/~psyrab/sg.htm or http://www.ub.es/comporta/sg.htm (select English and Download or Español and Descargar). The programs are written in Pascal using Borland’s Delphi Professional Version 7.0 and assume a Windows 95 or later environment.