Stipa Data Collection Protocol

Stipa is an easy to use and highly adaptable data collection solution for mobile devices. Stipa’s versatility arises from an XML document called the Stipa Data Collection Protocol. This document specifies what information will be collected during a particular data collection effort. It is human-readable and can be edited using a basic text editor (although more sophisticated graphical user interfaces are also available for that purpose).

A Data Collection Protocol is constructed from seven core XML elements. Figure 1 illustrates the hierarchical structure of these core elements and how they should be arranged in the XML document. All other elements used in a Data Collection Protocol (some are required; others are optional) have been omitted from Figure 1 for clarity, but a full description of them can be found in subsequent figures and tables.

Protocol. This is the root element of the Data Collection Protocol. It is identified by a universally unique identifier (UUID) that should remain unchanged even if the protocol is modified. The protocol ID is specified in the ID child element. Subsequent modifications to the protocol should be identified using the Version child element. The date of the most recent modification should be documented using the LastModified element. Unique identifiers help to facilitate proper matching of data to metadata, as well as ingestion of data into external databases.

Form. Each protocol must contain one or more Form element. Form elements are listed as child elements of Forms, which is a direct descendent of Protocol. Forms provide a way of logically organizing observations that will be performed on subjects during a data collection effort.

Attribute. Each Form element must contain one or more Attribute element. Attribute elements are listed as child elements of Attributes, which is a direct descendent of Form. Attributes are used to specify which characteristics of a subject need to be measured or observed. They also define how observations should be recorded; for example, as free-form text, selections from a list, numbers within a range, and so on.

ObservationSet. Optionally, each Form element can contain one or more ObservationSet element. ObservationSet elements are listed as child elements of ObservationSets, which is a direct descendent of Form. ObservationSet elements can be used to specify how forms should be repeated for the same study subject. For example, the same attributes may need to be measured at multiple points along a line transect. Or, the same information may need to be collected for multiple horizons within a soil excavation. If multiple ObservationSets are listed for a single Form, the latter ObservationSets are interpreted as being nested within the former, in the order they are listed.

Observation. Each ObservationSet must contain one or more Observation element. Observation elements are listed as child elements of Observations, which is a direct descendent of ObservationSet. If a form is completed multiple times for the same study subject, observations are used to identify these replicate entries. In some data entry scenarios, it may be desirable to have a static, pre-defined set of observations. In other cases, it may not be possible to predict how many times a form will be completed during data collection (for example, how many horizons a particular soil profile will contain). If the ability to add and remove observations is desirable, the Mutable child element of ObservationSet should be set to yes. Observation sets are considered immutable by default.

SharedList. Optionally, each protocol can contain one or more SharedList element. SharedList elements are listed as child elements of SharedLists, which is a direct descendent of Protocol. SharedList elements can be used to define categories that apply to more than one Attribute. Referencing a SharedList, rather than replicating the same Category list for different Attributes, can help to reduce the size and complexity of the data collection protocol.

Category. Optionally, each Attribute can contain one or more Category element. Category elements are listed as child elements of Categories, which is a direct descendent of Attribute or SharedList. Category elements can be used to define the choices available for a particular Attribute. Categories should be listed only for attributes that are of the “category” type.

The code sample below illustrates the hierarchical structure of all required and optional XML elements in a Data Collection Protocol document. Stipa does not enforce the ordering of child elements, but imitating the order shown below will heighten the document's readability.