These support tables are used throughout Babase.
The different parts of the body examined for ticks when darting. These are not necessarily mutually exclusive. If, e.g., ticks are at times counted on the left foreleg and at times counted on the inner left foreleg and the outer left foreleg then this table would contain 3 rows, one for the entire leg and one each for the inner and outer portions.
Each combination of Bodyside, Innerouter, and Bodyregion must be unique.
BODYPARTS defines values for TICKS.Bodypart and WP_AFFECTEDPARTS.Bodypart.
Whether the bodypart is on the left side, right side,
center, or unspecified/not applicable. The corresponding
values are L,
R,
C and
N.
Whether the bodypart is on the inner (anterior) part
of the body, the outer (posterior) part of the body, or
whether this is unspecified/not applicable. The
corresponding values are I,
O, and
N.
The code for the part of the body of which the given part is a component -- a BODYPARTS.Bpid value. This column allows the establishment of a hierarchical relationship between the different parts of the body.[231]
This column may not be NULL. Body part rows that represent the highest
level of aggregation should reference their own Bpid value.
Contains one row for each person involved with the creation of data that was generated via laboratory techniques and procedures. This is a separate list[232] from that of the personnel involved with the observing of data, who are recorded in OBSERVERS.
Only the Babase administrator can create LAB_PERSONNEL rows with Initials values that the NUCACIDS view cannot reliably distinguish. See the portion of the NUCACIDS documentation which describes the ability of the view to distinguish one creator from another. Unless it can be assured that such indistinguishable creators will never simultaneously create nucleic acid samples then creating such Initials is not recommended.
LAB_PERSONNEL defines vocabulary for the HYBRIDGENE_ANALYSES.Analyzed_By, NUCACID_CREATORS.Creator, and WBC_COUNTS.Counted_By columns.
Initials
The initials of the person. This is used to uniquely identify the person, so may not be the person's actual initials if there is ever a conflict with a pre-existing value.
This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.
The person's real name.
This column may not be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
Textual remarks regarding when the person was doing lab work. Usually a date range.
This column may be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
Any miscellaneous notes about the person. For example you may wish to record that the person is John Smith the graduate student, not John Smith the President of Kenya who asked to help with a DNA extraction and actually did so one day.
This column may be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
Contains one row for each person who records data that was seen/witnessed/observed. This table may include people who assist the data collection process, whether in our out of the field and whether or not their initials appear in those database columns for which the OBSERVERS table provides a validation vocabulary because the initials of all these people may appear in paper or unvalidated electronic records.
OBSERVERS is unusual in that, in some sense, it has two key columns: Initials and OldGPSInititals. Which key is used in the field depends upon the data collection protocols. When entered into Babase all OldGPSInititals values are translated into their respective Initials values, so it is the Initials values that Babase always uses to reference the individual.
Only the Babase administrator can create OBSERVERS rows with Initials values that the SWERB_UPLOAD view cannot reliably distinguish. See the portion of the SWERB_UPLOAD documentation which describes the ability of the view to distinguish one observer from another. Unless it can be assured that such indistinguishable observers will never simultaneously collect SWERB data then creating such Initials is not recommended.
Likewise, only the Babase administrator can create OBSERVERS rows with Initials values that the WP_REPORTS_OBSERVERS view cannot reliably distinguish. See the portion of the WP_REPORTS_OBSERVERS documentation which describes the ability of the view to distinguish one observer from another. Unless it can be assured that such indistinguishable observers will never simultaneously collect Wounds and Pathologies data then creating such Initials is not recommended.
OBSERVERS defines vocabulary for INTERACT_DATA.Observer, SAMPLES.Observer, WREADINGS.WRperson, RGSETUPS.RGSPerson, CROWNRUMPS.CRobserver, CHESTS.Chobserver, ULNAS.Ulobserver, HUMERUSES.Huobserver, and SWERB_OBSERVERS.Observer.
Initials
The initials of the person. This is used to uniquely identify the person, so may not be the person's actual initials if there is ever a conflict with a pre-existing value.
This column may not be empty, it must contain characters, and it must contain at least one non-whitespace character.
The initials, or notes regarding the initials, used to identify the person when recording GPS data.
This column exists because of a historical inconsistency between the initials used in the collection of GPS data and the initials used in the collection of other data. It is strongly recommended that new observers use the same initials when collecting either sort of data.
This column may be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
The person's real name.
This column may not be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
Textual remarks regarding when the observer was recording Babase data. Usually a date range.
This column may be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
Any notes you may wish to make on the person. For example you may wish to record that the person is John Smith the graduate student, not John Smith the, for example, President of Kenya who asked to be able to collect data and actually did so for a day.
This column may be NULL. This column may not be empty, it must contain characters,
and it must contain at least one non-whitespace character.
The role the person has filled in regards to data collection. Must be a value on the OBSERVER_ROLES table.
This column must not be NULL.
The SWERB_OBSERVERS.Role value to use when the observer is identified in the first line of SWERB data supplied to the SWERB_UPLOAD view. Must be a value on the OBSERVER_ROLES table.
This column must not be NULL.
The SWERB_OBSERVERS.Role value to use when the observer is identified in the second line of SWERB data supplied to the SWERB_UPLOAD view. Must be a value on the OBSERVER_ROLES table.
This column must not be NULL.
One row for every role a person may have in data collection.
OBSERVER_ROLES defines vocabulary for OBSERVERS.Role and SWERB_OBSERVERS.Role..
The different reasons why a focal individual's neighbor is unable to be identified during focal point sampling or the code(s) used to identify lone males when recording SWERB other group observations.
A Unksname value must not appear as a BIOGRAPH.Sname value.
UNKSNAMES defines vocabulary for the Unksname column of the NEIGHBORS table. It is also used by the SWERB_UPLOAD view to identify unknown lone males.
A boolean. When TRUE the Unksname value is used to indicate
that an unknown lone male was observed during a SWERB other
group observation; FALSE otherwise.
This column may not be NULL.
[231] Although Babase allows for a hierarchy of body parts it does not require one, and in fact has no support for querying such a hierarchy in a fashion similar to that for the group hierarchy supported by the MEMBERS.Supergroup column. The Bodyregion column can be used as a simple classification column supporting a single level of body part aggregation.
[232] Separate by definition, not necessarily separate in terms of contents. In practice, some people are likely to be listed on both tables.