OBS (OBservationS)

Each row represents an event that occurred. Events may be recorded as part of a follow, at the feeding station, or on some other, more ad-hoc, basis.

OBS rows are EVENTS rows, but extended with the date, AnimID, and other information found on WATCHES.

The OBS view is convienent when writing queries, instead of having to JOIN EVENTS with WATCHES every time behavior is queryed.

For example, below is a query that returns all the arrivals and departures from the feeding station attendance records, showing bananas eaten.

Arrivals/departures at the feeding station with banana count

SELECT obs.wid, obs.eid, obs.date
     , obs.focal AS animid
     , obs.start AS arrived, obs.stop AS departed
     , arrivals_a.bananas
  FROM obs
    JOIN arrivals_a ON (arrivals_a.eid = obs.eid)
  ORDER BY obs.focal, obs.date, obs.start;

It is important to remember that the AnimID value presented, the OBS.Focal column, is the value found in WATCHES.Focal. This is not always the individual observed to have exhibited some behavior or otherwise participated in the event. That individual is found in a related ROLES row, in the ROLES.Participant column.

For example, grooming information is recorded in B-Record follows. So the OBS.Focal is the focal of the follow, not necessarily the individual doing the grooming. To find every (unique) grooming event, from the groomings recording during B-Record interval scanning, and the individual doing the grooming, whether or not the grooming is reciprocal, the ROLES.Participant column must be used[1], as in the following query:

Unique B-Record interval scan groomers

SELECT obs.wid, obs.eid, obs.date
     , obs.start AS time
     , roles.participant AS animid
  FROM obs
    JOIN roles ON (roles.eid = obs.eid)
    JOIN groom_scans_b ON (groom_scans_b.eid = obs.eid)
  WHERE (roles.role = 'Actor'
         OR roles.role = 'Mutual')
        AND NOT groom_scans_b.duplicate
  ORDER BY roles.participant, obs.date, obs.start;

The following query returns every day every individual was observed exhibiting a behavior[2]:

Individuals observed, per day, some sexual swelling excepted

SELECT obs.date, roles.participant AS animid
  FROM obs
    JOIN roles ON (roles.eid = obs.eid)
  GROUP BY roles.participant, obs.date
  ORDER BY roles.participant, obs.date;

The OBS.Focal column contains the chimpanzee who, in some sense, is the reason why the observers were present. Often this is the focal of the follow that was ongoing when the event occurred.[3] (Hence the name OBS.Focal.) Feeding station attendance observations have for their OBS.Focal value, the individual who arrived at the feeding station.[4] Other kinds of events, distinguished by their OBS.Behavior values, have other rules regarding the identity of the individual recorded in the OBS.Focal column. See the documentation of the EVENTS table for more information.

Many events are expected to have the unknown individual, UNK, as their OBS.Focal value – indicating that the field team had no particular intention to conduct an observation but, instead, happened to observe the event. An example of this could be a pantgrunt event observed while the field researchers were on some errand.

Definition

CREATE OR REPLACE VIEW obs (
  wid
 ,date
 ,focal
 ,type
 ,commid
 ,eid
 ,behavior
 ,start
 ,stop
 ,certainty
 ,notes
 ,event_notes
  )
  AS
    SELECT
      watches.wid
     ,watches.date
     ,watches.focal
     ,watches.type
     ,watches.commid
     ,events.eid
     ,events.behavior
     ,events.start
     ,events.stop
     ,events.certainty
     ,watches.notes
     ,events.notes
     FROM watches
       JOIN events
            ON (events.wid = watches.wid);

ER Diagram

OBS

Columns of the OBS View

The columns of the OBS view

Column	From	Description
WID	WATCHES.WID	Identifier of the related WATCHES row
Date	WATCHES.Date	Date of the event
Focal	WATCHES.Focal	Focal of follow, or focal of a non-existant follow, or an un-interesting AnimID
Type	WATCHES.Type	Category of observation, often determining the data collection protocol: follow, feeding station attendance, groom scans, etc.
CommID	WATCHES.CommID	The community identifier associated with the Date/Focal/Type
EID	EVENTS.EID	Identifier of the EVENTS row
Behavior	EVENTS.Behavior	Code designating the type of event observed
Start	EVENTS.Start	Time the event started (inclusive)
Stop	EVENTS.Stop	Time the event finished (inclusive)
Certainty	EVENTS.Certainty	Certainty of the event observation, when meaningful
Notes	WATCHES.Notes	Textual notes on the observation for the Date/Focal/Type
Event_Notes	EVENTS.Notes	Textual notes on the event

Operations Allowed

INSERT

INSERTing a row into OBS inserts a row into EVENTS, and will also INSERT a row into WATCHES if no row already exists that matches the data supplied.

If a WID is supplied, the identified WATCHES table row must already exist.

If a WID is not supplied, the Date, Focal, and Type columns must be supplied. Their values are matched to existing database content. If an existing WATCHES row matches, the new EVENTS row is related to the WATCHES row so discovered.

In either case, whether or not a WID is supplied, when a matching WATCHES row exists the (non-NULL) data values supplied must match the values that already exist.

The WID and EID columns do not have their values inserted into new rows. If non-NULL values are supplied for these columns they must match the values already existing in, or inserted into, the database.

UPDATE

UPDATEing an OBS row updates the underlying tables.

DELETE

Deleting an OBS row deletes the underlying EVENTS row. If the underlying WATCHES row then has no related EVENTS rows, it too is deleted.

Footnotes

[1]

In the case of groomings, because they are dyadic interctions, it can be more convienient to use the DYADS view. When using DYADS it is no longer necessary to test for the role played by the individual performing the grooming because the view places the individual who groomed in the Actor column.

Unique B-Record interval scan groomers

SELECT dyads.wid, dyads.eid, dyads.date
     , dyads.start AS time
     , dyads.actor AS animid
  FROM dyads
    JOIN groom_scans_b ON (groom_scans_b.eid = dyads.eid)
  WHERE NOT groom_scans_b.duplicate
  ORDER BY dyads.actor, dyads.date, dyads.start;

[2]

Not observed under any conditions, because the SWELLING_SOURCES table contains data on female sexual swelling obtained from other data sources.

[3]

Some data recorded in the old, MS Access, database purported to be collected during a follow, but no follow existed. Rather than discard this data, or have to research what actually happened, much of this data was converted into SokweDB by creating rows on WATCHES that record the date and focal – as if there were a follow – even though there was no actual follow. These sorts of rows have their own WATCHES.Type value that distinguish them from “normal” follows.

[4]

The individual arriving at/departing from the feeding station is also recorded in a related ROLES row, in the ROLES.Participant column.

The ROLES.Participant column is the recommened column to obtain event participant information from, only because you don’t need to be aware of all the rules regarding what might be in the OBS.Focal column. The ROLES.Participant column is always there no matter the kind of event.

That said, it is sometimes convenient to use OBS.Focal. The point is, care must be taken when querying to ensure that the query actually retrieves the information that it is expected to. Familarity with the database structure, the data itself, the procedures used to collect and record the data, and how all of this changed over time is critical for accurate results.

Page last generated: 2026-07-01 00:11:55 UTC