Complete locality entries also include a number of lists -- information fields that may contain more than one value. The lists for a locality include references, sedimentary structures & taphonomic detail, museums housing the specimens, collecting methods, other names (synonyms) for the locality, and, most importantly, a species list.
Reference List
Each time data enters the database, either upon initial entry of a locality (or species) or upon updating (adding or replacing data for a locality or species that is already in the database), one must give one or more references for the source of the information, or for the work upon which inferences were based. See the separate section on the Reference List Data Fields.
Sedimentary Structures and Taphonomic Detail List
Each locality may have associated with it a large variety of sedimentological and taphonomic observations and details, none of which are mutually exclusive. It seems most efficient to present these as a list for each locality. Thus the Sedimentary Structures and Taphonomic Detail List contains miscellaneous data on sedimentary structures, assemblage composition, bone damage characteristics, and even the existence at the locality of organismic remains that were essentially ignored by the investigators. In principle, a locality could possess almost all of the characteristics listed below, but most will not.
The list consists of one or more individual entries, which are predefined character strings chosen from the list below; none exceed 20 characters in length (the maximum width of the field in the database). The meanings should for the most part be self-evident.
ALLOWED VALUES
Museums List
This is a list of the museums in which major collections of material from the locality are housed. This list can be, but does not need to be exhaustive. The point is to give the researcher some idea of where to go next if consideration of individual specimens is required. Use museum acronyms (a standard list is not yet available, though we should conform to standards once they are adopted).
Collecting Methods List A list of the primary collecting method(s) employed at the locality that generated the collection(s) upon which our entry is based. Currently valid values are:
anthills
dry_screen
quarry
screen
spoils
surface
wet_screen
Synonyms List
A list of other names or designations for the locality. Localities are kept separate by their unique ID numbers (assigned automatically by the data-entry interface when the locality is first entered). Localities have an "official" name, the one that is recorded in the "name" field of the locality data table (loc.name). This is the name that will be displayed on the Graphics Interface screen maps. However, all names associated with a locality are listed in a separate table (syn_loc), whose entries are keyed to the localities to which they pertain. Thus, a locality can be searched for by any of its names. Names need not be unique.
Species List
Species are associated with localities by the software when the operator types their names into the appropriate sections of a locality record. New species records may enter the database this way, and both taxonomic and ecomorphic characters may be added to new species. The species-specific fields are described in the sections on the vertebrate species data fields, terrestrial arthropod species data fields, mollusc and other invertebrate species data fields and plant species data fields.
There are a few points to remember. When the operator enters a species list, he or she types in the Linnean binomen (genus and species), plus the "Unique" field (see the data field sections for a full explanation of this field). The computer then searches the database for that triple combination. Attention to spelling is of great importance! If that combination is found, the species' unique (internal, already assigned) ID number is associated with the current locality (i.e., the species is automatically added to the species list for the locality, with no further work from the person performing data-entry). If the combination is not found, a new species entry is created in the database. The data-entry operator is asked, before leaving the session, whether additional (ecological or morphological) data are to be added for the species at this time. If not, the species exists in the database, but only as a taxonomic entity and a name in one or more species lists. Thus, there will be many species that are "only names" if workers do not regularly provide complete ecomorphic data for species when they are entered for the first time. However, it's unreasonable to expect people ordinarily to provide such complete information, or to keep track of which species have ecomorphic data and which do not. Furthermore, working up a locality for the database is a different sort of research activity than working up a species, and we will certainly benefit from division of labor along these lines. For this reason, the Research Groups will periodically be provided with lists of species that are in the database and in need of ecomorphic data. This will also help track down those "species" that exist as separate entities in the database solely because they were entered with typographical errors.
Some attention to organization of the species list will speed data entry and prevent errors. It is important that it is clear to the data-entry operator whether a species is a vertebrate, invertebrate, or plant. Also, grouping species hierarchically by higher taxa, while not a requirement, will allow more rapid and error-free entry, as in such a situation the data-entry operator will have to type the higher taxa only once (they automatically repeat until changed).
Abundance Data
For each entry in a species list there are spaces to record absolute or relative abundance values, if available. We recognize five different methods of expressing abundances of species at a locality:
* Count Abundances (NIS): The number of identifiable specimens at a locality. Usually, each element of a species is counted separately. However, in practice, obviously associated material is sometimes counted as one specimen. This is the field in which to record all abundances that are simply counts of specimens at a locality. Data type: Integer. Stored as: nis.nis.
* Percent Abundances: Abundances expressed as a percent. In many cases this field plus the Exact Number of Specimens field will allow conversion to count abundances, and vice versa. However, complete information is not always reported, and percentages are not always based upon total number of specimens, but upon some other sampling or counting scheme. In such cases, the general comment field should note the circumstances. Abundances expressed as proportions should also be multiplied by 100 and recorded here. Data type: Real Number. Stored as: pct.pct.
* Quadrat Counts: Abundances may be expressed as the number of quadrats or other standard sampling units in which the species occurs. Recording this value is straightforward, but there is usually no way from the quadrat counts themselves to work backward to the total number of sampling units examined. Thus, the total number of quadrats (or other sampling units) must be recorded in the Number of Quadrats field of the locality record. Other details concerning the nature of the sampling units should be recorded in the general comment field for the locality. Data type: Integer. Stored as: quad.quad.
* Minimum Number of Individuals (MNI, MCE, etc.): For many fossil taxa, identifiable specimens may be represented by any of a number of body parts, and thus some individuals might be represented in the collection by more than one specimen. The aim of MNI procedures is to reduce the recorded abundance of a species to the lowest number of individuals necessary to account for the collected specimens. MNI represents here a family of similar procedures that differ in minor details (such as whether association of material in the field is relevant, or whether attempts at matching specimens are undertaken). See, for example, Badgley (1986), Damuth (1982), and Grayson (1978) for discussion of MNI in various contexts. Data type: Integer. Stored as: mni.mni.
* Qualitative Abundance: Sometimes relative abundance information will be available in nonquantitative form. We allow recording the strings a, c, r, or v (for abundant, common, rare, and very rare, respectively). Data type: 1 character. Stored as: qua.qua.
Relative abundance values that are derived from any of these five types (such as abundances expressed in logarithms) should be translated into the appropriate units.
Projects
Each species or locality may be associated, optionally, with one or more formally named "projects". A project is an ETE-sponsored organization or source that is larger in scope than a single data coordinator, or it may be an external formal project under whose umbrella data were prepared for the ETE Database (or perhaps originally for some other database). For example, the assignment of localities to projects permits the permanent recording of which localities were compiled under the aegis of particular grants or institutions. Such accounting may be required by external funding sources, or there may be implications for access to the data depending upon the project(s) with which they are associated. In contrast, a data coordinator is a single person or small research group that may be active in a number of different projects at various times.