Neotoma Paleoecology Database¶

Whence Neotoma¶

In the original NSF proposal, this database was called a “Late Neogene Terrestrial Ecosystem Database.” At the time this proposal was written, the Neogene Period included the Miocene, Pliocene, Pleistocene, and Holocene epochs. However, a proposal before the International Commission on Stratigraphy would elevate the Quaternary to a System or Period following the Neogene and terminate the Neogene at the end of Pliocene.

Because this proposal renders the Neogene description of this database obsolete, a new name was sought. Numerous names and companion acronyms were considered, but none engendered enthusiastic support. B. Brandon Curry proposed the name Neotoma, and this name struck a fancy. Neotoma is the genus for the packrat. Packrats are prodigious collectors of anything in their territory, and moreover they are collectors of fossil data. They collect plant macrofossils and bones, and pollen is preserved in their amberat—hardened, dried urine, which impregnates their middens and preserves them for millennia.

Rationale¶

Paleobiological data from the recent geological past have been invaluable for understanding ecological dynamics at timescales inaccessible to direct observation, including ecosystem evolution, contemporary patterns of biodiversity, principles of ecosystem organization, particularly the individualistic response of species to environmental gradients, and the biotic response to climatic change, both gradual and abrupt. Understanding the dynamics of ecological systems requires ecological time series, but many ecological processes operate too slowly to be amenable to experimentation or direct observation. In addition to having ecological significance, fossil data have tremendous importance for climatology and global change research. Fossil floral and faunal data are crucial for climate-model verification and are essential for elucidating climate-vegetation interactions that may partly control climate.

Basic paleobiological research is site based, and paleobiologists have devoted innumerable hours to identifying, counting, and cataloging fossils from cores, sections, and excavations. These data are typically published in papers describing single sites or small numbers of sites. Often, the data are published graphically, as in a pollen diagram, and the actual data reside on the investigator’s computer or in a file cabinet. These basic data are similar to museum collections, costly to replace, sometimes irreplaceable, and their value does not diminish with time. Also similar to museum collections, the data require cataloging and curation. Whereas physical specimens of large fossils, such as animal bones, are typically accessioned into museums, microfossils, such as pollen, are not accessioned, and the digital data are the primary objects, and their loss is equivalent to losing valuable museum specimens. The integrated database that we propose ensures safe, long-term archiving of these data.

Large independent databases exist for fossil pollen, plant macrofossils, and mammals: the Global Pollen Database (GPD), the North American Plant Macrofossil Database (NAPMD), and FAUNMAP. In addition, a database of fossil beetles (BEETLE) has been assembled, but it is not yet publicly available. These databases have become essential cyberinfrastructure. Nevertheless, they were developed as standalone databases in the early 1990’s with PC database software. GPD and NAPMD are in Paradox®; FAUNMAP is in Access. Since initial database development, emphasis has been placed on ingest of new and legacy data. However, database and Internet technology have advanced greatly in the past 15 years, and the current relational database software, ingest programs, data retrieval algorithms, output formats, and analysis tools are outdated and minimal. Moreover, the databases are not linked, so that integrated analyses are difficult.

Although GPD, NAPMD, and FAUNMAP were developed independently, they have much in common. The basic data of all three databases as well as BEETLE are essentially lists of taxa from cores, excavations, or sections, often with quantitative measures of abundance. The three databases include similar metadata. The objective of Neotoma is to build a unified data structure that will incorporate all of these databases. The database will initially incorporate pollen, plant macrofossil, mammal, and beetle data. However, the database designed facilitates the incorporation of all kinds of fossil data.

Various teams of investigators have developed databases for paleobiological data that have been project or discipline based, including the four databases to be integrated in this project. However, long-term maintenance and sustainability have been problematic because of the need to secure continuous funding. Nevertheless, these databases have become the established archives for their disciplines and, new data are continuously contributed. However, because of funding hiatuses, long spells may intervene between times of data contribution and their public availability. For example, the plant macrofossil database has not incorporated any new data since 1999. The number of different databases and disciplines exacerbates the problem, because each database requires a database manager. Consolidation of informatics technology helps address this overhead issue. However, specialists are still essential for management and supervision of data collection and quality control for their disciplines or organismal groups.

The purposes of Neotoma are (1) to facilitate studies of ecosystem development and response to climate change, (2) to provide the historical context for understanding biodiversity dynamics, including genetic diversity, (3) to provide the data for climate-model validation, (4) to provide a safe, long-term, low-cost archive for a wide variety of paleobiological data. Site-based studies are invaluable in their own right, and they are the generators of new data. However, much is gained by marshalling data from geographic arrays of sites for synoptic, broad-scale ecosystem studies. In order to carry out such studies efficiently, a queryable database is required. Thus, it is much more than an archive; it is essential cyberinfrastructure for paleoenvironmental research. The database facilitates integration, synthesis, and understanding, and it promotes information sharing and collaboration. The individual databases have been extensively used for scientific research, with several hundred scientific publications directly based upon data drawn from these databases. This project will enhance those databases and will continue their public access. By integrating these databases and by simplifying the contributor interface, we can reduce the number of people necessary for community-wide database maintenance, and thereby help ensure their long-term sustainability and existence.

Who Will Use Neotoma?¶

The existing databases have been used widely for a variety of studies. Because the databases have been available on-line, precise determination of how many publications have made use of them is difficult. In addition, the databases are widely used for instructional purposes. Below are examples of the kinds of people who have used these databases and who we expect will find the new, integrated database even more useful.

• Paleoecologists seeking to place a new record into a regional/continental/global context (e.g., Bell and Mead 1998, Czaplewski et al. 1999, Bell and Barnosky 2000, Newby et al. 2000, Futyma and Miller 2001, Gavin et al. 2001, Czaplewski et al. 2002, Schauffler and Jacobson 2002, Camill et al. 2003, Rosenberg et al. 2003, Willard et al. 2003, Pasenko and Schubert 2004, and many others).
• Synoptic paleoecologists interested in mapping regional to sub-continental to global patterns of vegetation change (e.g., Jackson et al. 1997, Williams et al. 1998, Jackson et al. 2000, Prentice et al. 2000, Thompson and Anderson 2000, Williams et al. 2000, Williams et al. 2001, Williams 2003, Webb et al. 2004, Williams et al. 2004, Asselin and Payette 2005).
• Synoptic paleoclimatologists building benchmark paleoclimatic reconstructions for GCM evaluation (e.g., Bartlein et al. 1998, Farrera et al. 1999, Guiot et al. 1999, Kohfeld and Harrison 2000, CAPE Project Members 2001, Kageyama et al. 2001, Kaplan et al. 2003).
• Paleontologists trying to understand the timing, patterns, and causes of extinction events (e.g., Jackson and Weng 1999, Graham 2001, Barnosky et al. 2004, Martínez-Meyer et al. 2004, Wroe et al. 2004).
• Evolutionary biologists mapping the genetic legacies of Quaternary climatic variations (e.g., Petit et al. 1997, Fedorov 1999, Tremblay and Schoen 1999, Hewitt 2000, Comps et al. 2001, Good and Sullivan 2001, Petit et al. 2002, Kropf et al. 2003, Lessa et al. 2003, Petit et al. 2003, Hewitt 2004, Lascoux et al. 2004, Petit et al. 2004, Whorley et al. 2004, Runck and Cook 2005).
• Macroecologists interested in temporal records of species turnover and biodiversity and historical controls on modern patterns of floristic diversity (e.g., Silvertown 1985, Qian and Ricklefs 2000, Brown et al. 2001, Haskell 2001).
• Archeologists who are studying human subsistence patterns and interactions with their environment (e.g., Grayson 2001, Grayson and Meltzer 2002, Cannon and Meltzer 2004, Grayson in press).
• Natural resource managers who need to know historical ranges and abundances of plants and animals for designing conservation and management plans (e.g., Graham and Graham 1994, Cole et al. 1998, Noss et al. 2000, Owen et al. 2000, Committee on Ungulate Management in Yellowstone National Park 2002, Burns et al. 2003)
• Scientists trying to understand the potential response of plants, animals, biomes, ecosystems, and biodiversity to global warming (e.g., Bartlein et al. 1997, Davis et al. 2000, Barnosky et al. 2003, Burns et al. 2003, Kaplan et al. 2003, Schmitz et al. 2003, Jackson and Williams 2004, Martínez-Meyer et al. 2004)
• Teachers who use the databases for teaching purposes and class exercises.

Sites, Collection Units, Analysis Units, Samples, and Datasets¶

Fossil data are site based. A Site has a name, latitude-longitude coordinates, altitude, and areal extent. In Neotoma, Sites are designated geographically as boxes with north and south latitude coordinates and east and west longitude coordinates. If the areal extent is not known, the box collapses to a point, with the north and south latitudes equal and the east and west longitudes equal. Most of the legacy sites in Neotoma currently have point coordinates. The lat-long box can circumscribe the site, for example a lake, or it may circumscribe a larger area in which the site lies either because the exact location of the site is not known or because the exact location is purposely kept vague. In the case of many legacy sites, the exact location is not know precisely; for example, it may have been described as «on a gravel bar 5 miles east of town». The exact locations of some sites have purposely been kept vague to prevent looting and vandalism.

A Collection Unit is a unit from a site from which a collection of fossils or other data have been made. Typical Collection Units are cores, sections, and excavation units. A site may have several Collection Units. A Collection Unit is located spatially within a site and may have precise GPS latitude-longitude coordinates. Its definition is quite flexible. For pollen data, a Collection Unit is typically a core, a section, or surface sample. A Collection Unit can also be a composite core comprised of two or more adjacent cores pieced together to form a continuous stratigraphic sequence. A Collection Unit can also be an excavation unit. For faunal data, a Collection Unit could be as precise as an excavation square, or it could be a group of squares from a particular feature within a site. For example, consider a pit cave with three sediment cones, each with several excavation squares. Collection Units could be defined as the individual squares, or as three composite Collection Units, one from each sediment cone. Another example is an archaeological site, from which the reported Collection Units are different structures, although each structure may have had several excavation squares. The precision in the database depends on how data were entered or reported.

For many published sites, the data are reported from composite Collection Units. If faunal data are reported from a site or locality without explicit Collection Units, then data are assigned to a single Collection Unit with the name «Locality». This is a «quote».

Different kinds of data may have been collected from a single Collection Unit, for example fauna and macrobotanicals from an excavation, or pollen and plant macrofossils from a lake-sediment core. A composite Collection Unit may include data from different milieus, which, nevertheless, are associated with each other, for example a diatom sample from surficial lake sediments and an associated lake-water sample for water-chemistry measurements.

The Collection Unit is equivalent to the Entity in the Global Pollen Database but was not defined in FAUNMAP. When the FAUNMAP data were imported into Neotoma, most localities were assigned a single «Locality» Collection Unit. However, for some localities, the data were assigned to different Collection Units that were clearly identifiable in FAUNMAP (see Figure 1).

An Analysis Unit is a stratigraphic unit within a Collection Unit and is typically defined in the vertical dimension. An Analysis Unit may be a natural stratigraphic unit with perhaps irregular depth and thickness or it may be an arbitrary unit defined by absolute depth and thickness. An excavation may have been dug in arbitrary units, for example 10 cm levels, or it may have followed natural stratagraphic boundaries, for example the «red zone» or a feature in an archaeological site. Although Analysis Units could be designated by an upper depth and lower depth, in Neotoma they are designated by their midpoint depth and thickness, which is more convenient for developing age models. Pollen and other microfossils are typically sampled at arbitrary depths, and although these samples have thicknesses corresponding to the thickness of the sampling device (usually 1 cm or less), these thicknesses are often not reported, just the depths. Different kinds of samples may have been taken from a single analysis unit, for example pollen, diatoms, and ostracodes. The Analysis Unit links these various samples together.

In larger excavations, natural stratigraphic Analysis Units may cut across excavation squares or Collection Units, and the data are reported by Analysis Unit rather than by Collection Unit. In this case, the fossil data are assigned to a generic composite Collection Unit named «Locality», which has the explicitly defined Analysis Units. If the Analysis Units are not described or reported, then the data are assigned to a single Analysis Unit with the name «Assemblage». Thus, for a locality published with only faunal list, the fauna are assigned to a Collection Unit named «Locality» and to an Analysis Unit named «Assemblage».

In FAUNMAP, Analysis Units are the primary sample units, and fauna are recorded by Analysis Unit. In the GPD, Analysis Units correspond to samples.

Samples are of a single data type from an Analysis Unit. For example, there may be a vertebrate faunal sample and a macrobotanical sample from the same Analysis Unit; or there may be a pollen sample and an ostracode sample from the same Analysis Unit. There can be multiple samples of the same data type from an Analysis Unit, for example two pollen samples counted by different analysts. Normally, vertebrate fossils from an Analysis Unit comprise a single sample; however, if the fossils are of mixed age, individually dated bones may be treated as separate samples, each with a precise age. In addition to fossils, samples may also be used for physical measurements, such as loss-on-ignition. Geochronologic measurements, such as radiocarbon dates, are made on geochronologic samples.

A Dataset is a set of Samples of a single data type from a Collection Unit. For example the pollen data from a core comprise a pollen Dataset. The geochronologic samples from a Collection Unit form a geochronologic Dataset. Every Sample is assigned to a Dataset, and every Dataset is assigned to a Collection Unit. Samples from different Collection Units cannot be assigned to the same Dataset (although they may be assigned to Aggregate Datasets).

Figure 1. Diagram showing the relationships between tables in Neotoma, the Pollen Database, and FAUNMAP. Because the pollen database has only pollen, no need exists for Analysis Units, which may have multiple data types. FAUNMAP does not make a hierarchical distinction between Collection Units and Analysis Units, and the data for both Analysis Units and fauna are contained in the Faunal table, although within the Faunal table, implicit one-to-many relationships exist between Localities and Analysis Units and between Analysis Units and faunal data.

Taxa and Variables¶

In general, a sample in Neotoma has a list of taxa with some measure of abundances. The Data table in Neotoma has fields for SampleID, VariableID, and Value. Variables, which are listed in the Variables table, consist of a Taxon, referenced in the Taxa table, as well as the identified Element, measurement Units, Context, and Modification. A Taxon is generally a biological Taxon, but a Taxon may also be a physical attribute such as loss-on-ignition.

For biological taxa, the Element is the organ or skeletal element. Typical faunal Elements are bones, teeth, scales, and other hard body parts. Bone and tooth Elements may be specifically identified (e.g. «tibia» or even more precisely «tibia, distal, left», «M2, lower, left»). Some soft Elements also occur in the database (e.g. «hair» and «dung»). For mammals, an unspecified element is «bone/tooth». Elements for plant macrofossils are the organs identified (e.g. «seed», «needle», «cone bract»). Pollen and spores are treated simply as taxon Elements. Thus, Picea seeds, Picea needles, and Picea pollen are three different Variables. All three refer to a single entry in the Taxa table for Picea.

• Variable Units are the measurement units. For faunal data, the most common are «present/absent», «number of individual specimens» (NISP), and «minimum number of individuals» (MNI). Plant macrofossils have many different quantitative and semi-quantitative measurement Units, including concentrations and relative abundance scales. Measurement Units for pollen are NISP (counts) and «percent». For pollen the preferred measurement Unit is NISP, but for some sites only percentage data are available. Picea pollen NISP and Picea pollen percent are two different Variables.
• Variable Contexts for fauna include «articulated», «intrusive», and «redeposited». A context for pollen is «anachronic», which refers to a pollen type known to be too old for the contemporary sedimentary deposit. Most Variables do not have a specified context.
• Variable Modifications include various modifications to fossils or modifiers to Variables, including human modifications to bones (e.g. «bone tool», «human butchering», «burned») and preservational and taphonomic modifications (e.g. «carnivore gnawed», «fragment»). Modifications for pollen include preservational classifications such as «corroded» and «degraded».

Taxonomy and Synonymy¶

Neotoma does not change or question identifications from original sources, although taxonomic names may be synonymized to currently accepted names. Thus, for example, the old (although still valid) non-standard plant family names such as Gramineae and Compositae are synonimized to their standard family names terminated with «-aceae», viz. Poaceae and Asteraceae. Neotoma has not attempted to establish complete or comprehensive synonymies. However, the Synonyms table lists commonly encountered synonyms. The descriptions of the SynonymTypes and Taxa tables contain fuller discussions of synonymiztions made in Neotoma.

An important feature of Neotoma is that the Taxa table is hierarchical. Each Taxon has a HigherTaxonID, which is the TaxonID of the next higher taxonomic rank. Thus, data are stored at the highest taxonomic resolution reported by the original investigators, but can be extracted at a higher taxonomic level.

Synonymy presents a challenge for any organismal database, particularly for one such as Neotoma, which archives data collected for over a century and which archives extinct taxa, often for which few and fragmentary specimens exist. Many changes are due to increased understanding of the diversity within taxonomic groups and of the phylogenetic relationships within and among groups. Other changes are due purely to taxonomic rules or conventions set by the International Code of Botanical Nomenclature (McNeill et al. 2006) and the International Code of Zoological Nomenclature (International Commission on Zoological Nomenclature 1999). Working groups representing the different taxonomic groups included in Neotoma have established appropriate taxonomic authorities:

• Plants – There is no worldwide authority. The International Plant Names Index [3] lists validly published names, but a listed name is not necessarily the accepted name for a given taxon. For families, Neotoma follows the Angiosperm Phylogeny Group II (2003) and Stevens (2007+), which follows and updates APG II. The APG is an international consortium of plant taxonomists, and the APG classification utilizes the great quantity of phylogenetic data generated in recent years. For lower taxonomic ranks, the various pollen database cooperatives follow appropriate regional floras:
• North American Pollen Database/North American Plant Macrofossil Database: Insofar as possible, follows the Flora of North America (Flora of North America Editorial Committee 1993+); about half of the planned FNA volumes have been published. Otherwise, appropriate regional floras are followed.
• European Pollen Database: The EPD has a Taxonomy Support Group. In general, nomenclature follows Flora Europaea (Tutin 1964-1993).
• African Pollen Database: The APD has a Committee for Nomenclature, which has produced a list of pollen types with misspellings, synonymy, and nomenclature corrected [4]. APD nomenclature follows Enumération des plantes à fleurs d’Afrique Tropicale (Lebrun and Stork 1991-1997).
• Latin American Pollen Database: has a tremendously rich and diverse flora and no comprensive flora is available. Various regional floras are followed.
• Indo-Pacific Pollen Database: For Australia and adjacent areas follows the Australian Plant Name Index (Chapman 1991). For other regions, appropriate regional floras are followed.
• Pollen Database for Siberia and the Russian Far East Follows Vascular Plants of Russia and Adjacent States (Czerepanov 1995).
• Mammals – For extant taxa, the authority is Wilson and Reeder’s (2005) Mammal Species of the World . Original sources are followed for extinct species, and the database is considered authoritative.
• Birds – For North America, the authority is the American Ornithologists’ Union Check-list of North American Birds (American Ornithologists’ Union 1983).
• Fish – Follows the Catalog of Fishes (Eschmeyer 1998).
• Mollusks – For North America, follows Common and Scientific Names of Aquatic Invertebrates from the United States and Canada: Mollusks (Turgeon et al. 1998).
• Beetles – Comprehensive manuals do not exist. Original taxonomic authorities are cited, and the database is considered authoritative.

Taxa and Ecological Groups¶

In the Taxa table, each taxon is assigned a TaxaGroupID, which refers to the TaxaGroupTypes table. These are major taxonomic groups, such as «Vascular plants», «Diatoms», «Testate amoebae», «Mammals», «Reptiles and amphibians», «Fish», and «Molluscs». Also included are «Charcoal» and «Physical variables». Ecological Groups are groupings of taxa within Taxa Groups, which may be ecological or taxonomic. Ecological Groups are assigned in the EcolGroups table, in which taxa are assigned an EcolGroupID, which links to the EcolGroupTypes table, and an EcolSetID, which links to the EcolSetTypes table. Ecological Groups are commonly used to organize taxa lists and diagrams. For any taxonomic group, more than one Ecological Set may be assigned. For example, beetles may be assigned to a set of ecological groups, such as dung and bark beetles, and to second set based on taxonomy. Vascular plants are assigned to a «Default plant» set comprised of groups such as «Trees and Shrubs», «Upland Herbs», and «Terrestrial Vascular Cryptogams». Default pollen diagrams can then be generated based on a pollen sum of these three groups. Mammals are assigned to a «Vertebrate orders» set.

Chronology¶

Neotoma stores both the archival data used to reconstruct chronologies as well as interpreted chronologies derived from the archival data. The basic data used to reconstruct chronologies occurs in three tables: Geochronology, Tephrachronology, and RelativeChronology. The Geochronology table includes geophysical measurements such as radiocarbon, thermoluminescence, uranium series, and potassium-argon dates. This table also includes dendrochronological dates derived from tree-ring chronologies, for example logs in archaeological structures. The Tephrachronology table records tephras in Analysis Units. This table refers to the Tephras lookup table, which stores the ages for known tephras. The RelativeChronology table stores relative age information for Analysis Units. Relative age scales include the archaeological time scale, geologic time scale, geomagnetic polarity time scale, marine isotope stages, North American land mammal ages, and Quaternary event classification. For example, diagnostic artifacts from an archaeological site may have cultural associations with a known age ranges, which can be assigned to Analysis Units. The faunal assemblage from an Analysis Unit may be assignable to particular land mammal age, which places it within a broad time range. Sedimentary units may be assigned to particular geomagnetic chrons, marine isotope stages, or Quaternary events, such as a particular interglacial. Many of these relative ages have rather broad time spans, but do provide some chronologic control.

Actual Chronologies are constructed from the basic chronologic data in the Geochronology, Tephrachronology, and RelativeChronology tables. These chronologies are stored in the Chronologies table. A Chronology applies to a Collection Unit and consists of a number of Chron Controls, which are ages assigned to Analysis Units. A Chron Control may be an actual geochronologic measurement, such as a radiocarbon date, or it may be derived from the actual measurement, such as a radiocarbon date adjusted for an old carbon reservoir or calibrated to calendar years. A Chron Control may by an average of several radiocarbon dates from the same Analyis Unit. Different kinds of basic chronologic data may be used to assign an age to an Analysis Unit, for example radiocarbon dates and diagnostic archaeological artifacts. Some relative Chron Controls are not from one of the established relative time scales. Examples of these are local biostratigraphic controls, which may be based on dated horizons from nearby sites. A familiar example in is the Ambrosia-rise, which marks European settlement. The exact date varies regionally, depending on when settlement occurred locally. For a given site, the date assigned to the Ambrosia-rise may be based on historical information about when settlement occurred or possibly on geophysical dating (e.g. ²¹⁰Pb) of a nearby site.

For continuous stratigraphic sequences, such as cores, not every Analysis Unit may have a direct date. Therefore, ages are commonly interpolated between dated Analysis Units. In this case, the ChronControls are the age-depth control points for an age model, which may be linear interpolation between Chron Controls or a fitted curve or spline.

Figure 2. Smoothed quick radiocarbon calibration curve. At the scale of this figure the difference is mostly less than the line thickness.

Age is measured in different time scales, the two most commn being radiocarbon years before present (¹⁴C yr BP) or presumed calendar years before present (cal yr BP). For a calibrated radiocarbon date, «cal yr BP» technically stands for «calibrated years before present», i.e. calibrated to calendar years. In Neotoma, «cal yr BP» is used for both calibrated radiocarbon years and for other ages scales presumed to be in calendar years, viz. dendrochronologic years and other geochronlogic ages believed to be in calendar years. The zero datum for any «BP» age is ad 1950, regardless of its derivation. Thus, BP ages younger than ad 1950 are negative—ad 2000 = ‑50 BP.

Ages may be reported in ad/bc age units, in which case bc years are stored as negative values. If ages are reported with a datum other than ad 1950 for BP years, the ages must be converted to an ad 1950 datum or to the ad/bc age scale before entry into Neotoma. For example, ²¹⁰Pb dates are often reported relative to the year of analysis; these must be converted to either ad/bc or «cal yr BP» with an ad 1950 datum.

Figure 3. An enlarged portion of Figure 2 showing the monontonic smoothed curve

Radiocarbon years can be calibrated to calendar years with a calibration curve. The current calibration curve for ≤26,000 cal yr BP (=21,341 ¹⁴C yr BP) is the INTCAL04 calibration curve (Reimer et al. 2004). Various programs, both online and standalone, are available for calibrating individual radiocarbon dates, two of the more popular are CALIB [5] (Stuiver and Reimer 1993) and OxCal [6] (Bronk Ramsey 1995, 2001), both available online for download. Calibration of radiocarbon years beyond the INTCAL04 curve is more controversial. However, the Fairbanks0107 curve is available for calibration of radiocarbon dates to 50,000 cal yr BP, the practial limit of radiocarabon dating (Fairbanks et al. 2005, Chiu et al. 2007), with an online application [7].

Figure 4. Sample ages calculated from the Neotoma quick calibraton curve vs. ages calculated from traditional age models.

Calibrated radiocarbon dates better represent the true time scale and the true errors and probability distributions of the age estimates. In addition, other important paleo records, notably the ice cores and tree-ring records, have calendar-year time-scales. Therefore, for comparison among proxies and records, it is clearly desirable to place all records on the same time-scale, viz. a calendar-year time-scale. Although this goal is laudable, most of the data ingested into Neotoma from other databases is on a radiocarbon time scale. The majority of assigned ages and almost all the ages from the pollen database are interpolated ages derived from age models. The proper method for deriving calibrated ages is to calibrate the radiocarbon dates and then reinterpolate new ages between these calibrated dates.

Virtually all age models are problematic. A key problem is that most age models linearly interpolate between age-depth points or fit functions or splines to points. However, radiocarbon ages are not points, but probability distributions. Moreover, the probability distributions of calibrated ages are non-Gaussian. Each calibrated age has a unique probability distribution, and many are bimodal or multimodal. Various investigators have used different points, including the intercepts of the radiocarbon age with the calibration curve and the midpoint of the 1σ or 2σ probability distributon. The former is particularly inappropriate (Telford et al. 2004b). The 50% median probability is probably the best single point; however, because of multimodality, this particular point may, in fact, be very unlikely. Nevertheless, if it falls between more-or-less equally probable modes, it may still be the best single point. Most age models for cores are based on relataively few radiocarbon dates, and the uncertainties of the interpolated ages are unknown and large (Telford et al. 2004a). Indeed, chronology is perhaps the greatest challenge for future research with this database.

Figure 5. Anomalies (Sample ages from Neotoma default calendar-year age models minus ages calculated with the Neotoma quick calibration curve) vs. time.

Given the need for a common age scale and the enormity of the task to properly develop new age models, a RadiocarbonCalibration conversion table was developed to quickly convert sample ages in radiocarbon years to calendar years. These calibrated ages are for perusal and data exploration; however, the differences between these ages and those calculated with traditional age models are relatively small. The table contains radiocarbon ages from -100 to 45,000 in 1-year increments with corresponding calibrated values. The table was generated by smoothing the INTCAL04 calibration curve with an FFT filter so that the curve is monotonically increasing, i.e. so that there are no age reversals in calibrated age. The INTCAL04 curve is in 5-yr increments from -5 to 12,500 ¹⁴C yr BP, 10-yr increments from 12,500 to 15,000 ¹⁴C yr BP, and 20-yr increments from 15,000 to 26,000 ¹⁴C yr BP. The FFT filter was 50 points (250 yr) for the first interval, 25 points (250 yr) for the second interval, and 10 points (200 yr) for the third interval. For the calibration beyond 26,000 ¹⁴C yr BP, a calibrated age was determined with the Fairbanks0107 calibration curve every 100 years with a standard deviation of ±100 years from 20,000±100 ¹⁴C yr BP to 46,700±100 ¹⁴C yr BP. These were then smoothed with a 5-sample (500-yr) FFT filter. The curve kinks sharply after 45,000 ¹⁴C yr BP, so the quick calibration curve was terminated at this date. The Fairbanks0107 curve diverges somewhat from the INTCAL04 curve for the portion they overlap in age. From 20,000 to 26,000 ¹⁴C yr BP, the difference was prorated linearly from zero divergence from the INTCAL04 curve at 20,000 ¹⁴C yr BP to zero divergence from the Fairbanks0107 curve at 26,000 ¹⁴C yr BP. Figure 2 shows the smoothed curve, and Error! Reference source not found. shows an enlargement of part of the curve.

An analysis was made to assess the deviation between ages derived from traditionally calibrated age models and ages derived from the quick calibration curve. From the database, 57 default Chronologies in calibrated radiocarbon years were selected. The Chron Controls were all calibrated radiocarbon dates, except for top dates, European settlement dates, and ²¹⁰Pb dates in the uppermost portions of the cores. A few Chronologies used the Zdanowicz et al. (1999) calendar-year age from the GISP2 ice core. Ages beyond the reliable age limit (Chronologies.AgeBoundOlder) were not used. These 57 Chronologies had a total of 1945 Sample Ages in calibrated radiocarbon years. Figure 4 shows graph of ages from the Neotoma age models vs. the ages calculated with the quick calibration curve. Error! Reference source not found. shows the anomalies vs. time and Figure 6 shows a histogram of the distribution of anomalies. Nearly half (47%) of the anomalies are <25 years, 86% are <100 years, 97% are <200 years, and 99.4% are <300 years. The average absolute anomaly is 49.2 years, and the median is 29 years. Thus, the quick calibration curve provides remarkably good results. The ages have no confidence limits, but neither do the interpolated ages of most age models.

Figure 6. Binned distribution of anomalies between Neotoma default calendar-year age models and ages calculated with the Neotoma quick calibration curve.

Sediment and Depositional Environments¶

Several tables deal with depositional environments, depositional agents, and sediment descriptions. In Neotoma, the Depositional Environment refers to the Depositional Environment of the site today, for example, «», «Fen», «Cave», «Colluvial Fan». Depositional Environments may vary within a Site. For example, a lake with a marginal fen has lake and fen Depositional Environments. Thus, Depositional Environments are an attribute of Collection Units and are assigned in the CollectionUnits table. Depositional Environments are listed in the in the DepEnvtTypes lookup table, and they are hierarchical, for example:

Glacial Lacustrine

Any of these Depositional Environments may be assigned to a Collection Unit, but because they are hierarchical, Collection Units may be grouped at higher levels, for example, all Collection Units from natural lakes. The top level Depositional Environments, with some examples, are:

• Archaeological burials, middens, mounds
• Biological packrat middens, dung, moss polsters
• Estuarine mangrove swamps, salt marshes
• Lacustrine lakes and ponds
• Marine deep sea benthic, coastal bars
• Palustrine wetlands including fens, bogs, and marshes
• Riverine river channels, point bars, natural levees
• Sampler Tauber traps for modern pollen samples
• Spring tufa deposits, spring conduits
• Terrestrial caves, rock shelters, colluvium, volcanic deposits, soils

The Depositional Environment may change through time. For example, as a basin fills with sediment, it may convert from a lake to a fen and perhaps later to a bog. A colluvial slope may have alluvial sediments at depth. A modern playa lake may have a buried paleosol. Thus, a sediment section may have units with different facies and depositional agents. The Facies is the sum total of the characteristics that distinguish a sedimentary unit. Facies are listed in the FaciesTypes lookup table and are assigned to Analysis Units in the AnalysisUnits.FaciesID field. A sedimentary unit may have one or more agents of deposition. For example, a cave deposit may be partly owing to human habitation and partly to carnivore activity. Depositional Agents are listed in the DepAgentTypes lookup table and are assigned to Analysis Units in the DepAgents table.

Whereas Facies and Depositional Agents are both keyed to Analysis Units, the Lithology table is keyed to Collection Units. Analysis Units, especially from cores, may not be contiguous but be placed at discrete intervals down section. Lithologic units are defined by depth in the Collection Unit. Whereas Facies have short descriptions and are keyed to the FaciesTypes lookup table, the Lithology.Description field is a memo, and lithologic descriptions much more detailed than Facies descriptions. FAUNMAP, which was built around Analysis Units, stores Facies and Depositional Agent data; whereas the pollen database, which was centered on Collection Units, stores lithologic data.

Date Fields¶

Neotoma uses date fields in several tables. Dates are stored internally as a double precision floating point number, which facilitates calculations and functions involving dates. The disadvantage is that complete dates must be stored, i.e. year, month, and day; whereas in many cases only the year or month are known, for example the month a core was collected. Neotoma had adapted the convention that if only the month is known, the day is set to the first of the month; if only the year is known, the month and day are set to January 1. Thus, «June 1984» is set to «June 1, 1984»; and «1984» is set to «January 1, 1984». The drawback, of course, is that these imprecise dates cannot be distinguished from precise dates on the first of the month. However, it was determined that the advantages of the date fields outweighed this disadvantage.

SQL Example¶

The following SQL example lists the number of sites by GeoPoliticalID (the name of the country) for and GeoPoliticalID that is defined as a country.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

SELECT
        COUNT(sites.SiteName),
        gpu.GeoPoliticalName,
        gpu.GeoPoliticalUnit
FROM
        (
                SELECT
                        *
                FROM
                        GeoPoliticalUnits
                WHERE
                        geopoliticalunits.GeoPoliticalUnit = "country"
        ) AS gpu
INNER JOIN (
        Sites
        INNER JOIN SiteGeoPolitical ON Sites.SiteID = SiteGeoPolitical.SiteID
) ON gpu.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID
GROUP BY
        gpu.GeoPoliticalID,
        gpu.GeoPoliticalUnit;

Table Keys¶

Within tables there are often Keys. A Key may be a Primary Key (PK), which acts as a unique identifier for individual records within a table, or they may be a Foreign Key (FK) which refers to a unique identifier in another table. Primary Keys and Foreign Keys are critical to join tables in a SQL query. In the above example we can see that the

Data Types¶

In the table descriptions in the following section, the SQL Server data types are given for field descriptions. The equivalent Access data types are given in the following table.

Site Related Tables¶

Tables for key geographic information relating to the dataset. Specifically geographic coordinates, geo-political units and any situational information such as images of the site itself.

SiteImages, Sites, SiteGeoPolitical, GeoPoliticalUnits

Dataset & Collection Related Tables¶

Tables related to complete datasets, or collections of samples. These include Collection information, but only refer to sites, since, as described in the Design Concepts, datasets are conceptually nested within sites, even if a site contains only a single dataset.

AggregateDatasets, AggregateOrderTypes, CollectionTypes, CollectionUnits, DatasetPublications, Datasets, DatasetSubmissions, DatasetSubmissionTypes, DatasetTypes, DatasetPIs, DepEnvtTypes, Lithology, Projects.

Chronology & Age Related Tables¶

Information about the age models and chronological controls used to assess sample ages. Includes secondary information on tephras, and geochronological data types.

AgeTypes, AggregateChronologies, ChronControls, ChronControlTypes, Chronologies, AggregateSampleAges, Geochronology, GeochronPublications, GeochronTypes, RelativeAgePublications, RelativeAges, RadiocarbonCalibration, RelativeAgeScales, RelativeAgeUnits, RelativeChronology, Tephrachronology, Tephras.

Sample Related Tables¶

Information relating to individual samples or analysis units. This includes the age of the sample, the data content of the sample, and information relating to the physical condition or situation of the samples themselves.

AnalysisUnits, Data, DepAgents, DepAgentTypes, SampleAges, SampleAnalysts, SampleKeywords, Samples, AggregateSamples, FaciesTypes, Keywords.

Taxonomy Related Tables¶

Tables related to taxonomic information, phylogenetic information and ecological classifications. These tables also include hierarchy based on morphological or phylogenetic relationships.

EcolGroups, EcolGroupTypes, EcolSetTypes, Synonyms, SynonymTypes, Taxa, TaxaGroupTypes, Variables, VariableContexts, VariableElements, VariableModifications, VariableUnits.

Individual Related Tables¶

Tables associated with individuals, institutions and organizations.

Collectors, Contacts, ContactStatuses

Publication Related Tables¶

Information relating to the publication of primary or derived data within the Neotoma Paleoecological Database.

PublicationAuthors, PublicationEditors, Publications, PublicationTypes

AgeTypes¶

Lookup table of Age Types or units. This table is referenced by the Chronologies and Geochronology tables.

AgeTypeID (Primary Key)

An arbitrary Age Type identification number.

AgeType

Age type or units. Includes the following:

• Calendar years AD/BC
• Calendar years BP
• Calibrated radiocarbon years BP
• Radiocarbon years BP
• Varve years BP

AggregateChronologies¶

This table stores metadata for Aggregate Chronologies. An Aggregate Chronology refers to an explicit chronology assigned to a sample Aggregate. The individual Aggregate Samples have ages assigned in the AggregateSampleAges table. An Aggregate Chronology would be used, for example, for a set of packrat middens assigned to an AggregateDatasets. The Aggregate Chronology is analsgous to the Chronology assigned to samples from a single Collection Unit.

An Aggregate may have more than one Aggregate Chronology, for example one in radiocarbon years and another in calibrated radiocarbon years. One Aggreagate Chronology per Age Type may be designated the default, which is the Aggregate Chronology currently preferred by the database stewards.

AggregateChronID (Primary Key)

An arbitrary Aggregate Chronology identification number.

AggregateDatasetID (Foreign Key)

Dataset to which the Aggregate Chronology applies. Field links to the AggregateDatasets table.

AgeTypeID (Foreign Key)

Age type or units. Field links to the AgeTypes table.

IsDefault

Indicates whether the Aggregate Chronology is a default or not. Default status is determined by a Neotoma data steward. Aggregate Datasets may have more than one default Aggregate Chronology, but may have only one default Aggregate Chronology per Age Type.

ChronologyName

Optional name for the Chronology.

AgeBoundYounger

The younger reliable age bound for the Aggregate Chronology. Younger ages may be assigned to samples, but are not regarded as reliable. If the entire Chronology is considered reliable, AgeBoundYounger is assigned the youngest sample age rounded down to the nearest 10. Thus, for 72 BP, AgeBoundYounger = 70 BP; for -45 BP, AgeBoundYounger = -50 BP.

AgeBoundOlder

The older reliable age bound for the Aggregate Chronology. Ages older than AgeOlderBound may be assigned to samples, but are not regarded as reliable. This situation is particularly true for ages extrapolated beyond the oldest Chron Control. . If the entire Chronology is considered reliable, AgeBoundOlder is assigned the oldest sample age rounded up to the nearest 10. Thus, for 12564 BP, AgeBoundOlder is 12570.

Notes

Free form notes or comments about the Aggregate Chronology.

ChronControls¶

This table stores data for Chronology Controls, which are the age-depth control points used for age models. These controls may be geophysical controls, such as radiocarbon dates, but include many other kinds of age controls, such as biostratigraphic controls, archaeological cultural associations, and volcanic tephras. In the case of radiocarbon dates, a Chronology Control may not simply be the raw radiocarbon date reported by the laboratory, but perhaps a radiocarbon date corrected for an old carbon reservoir, a calibrated radiocarbon date, or an average of several radiocarbon dates from the same level. A common control for lake-sediment cores is the age of the top of the core, which may be the year the core was taken or perhaps an estimate of 0 BP if a few cm of surficial sediment were lost.

ChronControlID (Primary Key)

An arbitrary Chronology Control identification number.

ChronologyID (Foreign Key)

Chronology to which the ChronControl belongs. Field links to the Chronolgies table.

ChronControlTypeID (Foreign Key)

The type of Chronology Control. Field links to the ChronControlTypes table.

Depth

Depth of the Chronology Control in cm.

Thickness

Thickness of the Chronology Control in cm.

Age

Age of the Chronology Control.

AgeLimitYounger

The younger age limit of a Chronology Control. This limit may be explicitly defined, for example the younger of the 2-sigma range limits of a calibrated radiocarbon date, or it may be more loosely defined, for example the younger limit on the range of dates for a biostratigraphic horizon.

AgeLimitOlder

The older age limit of a Chronology Control.

Notes

Free form notes or comments about the Chronology Control.

ChronControlTypes¶

Lookup table of Chronology Control Types. This table is referenced by the ChronControls table.

ChronControlTypeID (Primary Key)

An arbitrary Chronology Control Type identification number.

ChronControlType

The type of Chronology Control object. Chronology Controls include such geophysical controls as radiocarbon dates, calibrated radiocarbon dates, averages of several radiocarbon dates, potassium-argon dates, and thermoluminescence dates, as well as biostratigraphic controls, sediment stratigraphic contols, volcanic tephras, archaeological cultural associations, and any other types of age controls. In general these are calibrated or calendar year dates Before Present. Some ChronControlTypes are in Radiocarbon Years, so caution must be exercised.

Chronologies¶

This table stores Chronology data. A Chronology refers to an explicit chronology assigned to a Collection Unit. A Chronology has Chronology Controls, the actual age-depth control points, which are stored in the ChronControls table. A Chronology is also based on an Age Model, which may be a numerical method that fits a curve to a set of age-depth control points or may simply be individually dated Analysis Units.

A Collection Unit may have more than one Chronology, for example one in radiocarbon years and another in calibrated radiocarbon years. There may be a Chronology developed by the original author and another developed by a later research project. Chronologies may be stored for archival reasons, even though they are now believed to have problems, if they were used for an important research project. One Chronology per Age Type may be designated the default Chronology, which is the Chronology currently preferred by the database stewards.

Based upon the Chronology, which includes the Age Model and the Chron Controls, ages are assigned to individual samples, which are stored in the SampleAges table.

A younger and older age bounds are assigned to the Chronology. Within these bounds the Chronology is regarded as reliable. Ages may be assigned to samples beyond the reliable age bounds, but these are not considered reliable.

ChronologyID (Primary Key)

An arbitrary Chronology identification number.

CollectionUnitID (Foreign Key)

Collection Unit to which the Chronology applies. Field links to the CollectionUnits table.

AgeTypeID (Foreign Key)

Age type or units. Field links to the AgeTypes table.

ContactID (Foreign Key)

Person who developed the Age Model. Field links to the Contacts table.

IsDefault

Indicates whether the Chronology is a default chronology or not. Default status is determined by a Neotoma data steward. Collection Units may have more than one default Chronology, but may have only one default Chronology per Age Type. Thus, there may be a default radiocarbon year Chronology and a default calibrated radiocarbon year Chronology, but only one of each. Default Chronologies may be used by the Neotoma web site, or other web sites, for displaying default diagrams or time series of data. Default Chronologies may also be of considerable use for actual research purposes; however, users may of course choose to develop their own chronologies.

ChronologyName

Optional name for the Chronology. Some examples are:

• COHMAP chron 1 A Chronology assigned by the COHMAP project.
• COHMAP chron 2 An alternative Chronology assigned by the COHMAP project
• NAPD 1 A Chronology assigned by the North American Pollen Database.
• Gajewski 1995 A Chronology assigned by Gajewski (1995).

DatePrepared

Date that the Chronology was prepared.

AgeModel

The age model used for the Chronology. Some examples are: linear interpolation, 3^rd order polynomial, and individually dated analysis units.

AgeBoundYounger

The younger reliable age bound for the Chronology. Younger ages may be assigned to samples, but are not regarded as reliable. If the entire Chronology is considered reliable, AgeBoundYounger is assigned the youngest sample age rounded down to the nearest 10. Thus, for 72 BP, AgeBoundYounger = 70 BP; for -45 BP, AgeBoundYounger = -50 BP.

AgeBoundOlder

The older reliable age bound for the Chronology. Ages older than AgeOlderBound may be assigned to samples, but are not regarded as reliable. This situation is particularly true for ages extrapolated beyond the oldest Chron Control. . If the entire Chronology is considered reliable, AgeBoundOlder is assigned the oldest sample age rounded up to the nearest 10. Thus, for 12564 BP, AgeBoundOlder is 12570.

Notes

Free form notes or comments about the Chronology.

1
2
3
4
5
6
7
8
9

SELECT Sites.SiteName, Chronologies.ChronologyName,
Chronologies.IsDefault, AgeTypes.AgeType

FROM AgeTypes INNER JOIN ((Sites INNER JOIN CollectionUnits ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN Chronologies ON
CollectionUnits.CollectionUnitID = Chronologies.CollectionUnitID) ON
AgeTypes.AgeTypeId = Chronologies.AgeTypeID

WHERE (((Sites.SiteName)=""));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

SELECT ChronControls.Depth, ChronControls.Age,
ChronControls.AgeLimitYounger, ChronControls.AgeLimitOlder,
ChronControlTypes.ChronControlType

FROM ChronControlTypes INNER JOIN ((AgeTypes INNER JOIN ((Sites INNER
JOIN CollectionUnits ON Sites.SiteID = CollectionUnits.SiteID) INNER
JOIN Chronologies ON CollectionUnits.CollectionUnitID =
Chronologies.CollectionUnitID) ON AgeTypes.AgeTypeId =
Chronologies.AgeTypeID) INNER JOIN ChronControls ON
Chronologies.ChronologyID = ChronControls.ChronologyID) ON
ChronControlTypes.ChronControlTypeID = ChronControls.ChronControlTypeID

WHERE (((Sites.SiteName)="Wolsfeld Lake") AND
((Chronologies.IsDefault)=True) AND ((AgeTypes.AgeType)="Calibrated
radiocarbon years BP"));

AggregateSampleAges¶

This table stores the links to the ages of samples in an Aggregate Dataset. The table is necessary because samples may be from Collection Units with multiple chronologies, and this table stores the links to the sample ages desired for the Aggregate Dataset.

AggregateDatasetID (Primary Key, Foreign Key)

Aggregate Dataset identification number. Field links to the AggregateDatasets table.

AggregateChronID (Primary Key, Foreign Key)

Aggregate Chronology identification number Field links to the AggregateChronologies table.

SampleAgeID (Primary Key, Foreign Key)

Sample Age ID number. Field links to the SampleAges table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

SELECT AggregateSamples.SampleID, SampleAges.Age

FROM SampleAges INNER JOIN ((AggregateDatasets INNER JOIN
AggregateSampleAges ON AggregateDatasets.AggregateDatasetID =
AggregateSampleAges.AggregateDatasetID) INNER JOIN AggregateSamples ON
AggregateDatasets.AggregateDatasetID =
AggregateSamples.AggregateDatasetID) ON (AggregateSamples.SampleID =
SampleAges.SampleID) AND (SampleAges.SampleAgeID =
AggregateSampleAges.SampleAgeID)

WHERE (((AggregateDatasets.AggregateDatasetName)=""));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT AggregateSamples.SampleID, SampleAges.Age

FROM AgeTypes INNER JOIN (Chronologies INNER JOIN (SampleAges INNER JOIN
((AggregateDatasets INNER JOIN AggregateSampleAges ON
AggregateDatasets.AggregateDatasetID =
AggregateSampleAges.AggregateDatasetID) INNER JOIN AggregateSamples ON
AggregateDatasets.AggregateDatasetID =
AggregateSamples.AggregateDatasetID) ON (AggregateSamples.SampleID =
SampleAges.SampleID) AND (SampleAges.SampleAgeID =
AggregateSampleAges.SampleAgeID)) ON Chronologies.ChronologyID =
SampleAges.ChronologyID) ON AgeTypes.AgeTypeId = Chronologies.AgeTypeID

WHERE (((AggregateDatasets.AggregateDatasetName)="") AND
((AgeTypes.AgeType)="Radiocarbon years BP"));

Geochronology¶

This table stores geochronologic data. Geochronologic measurements are from geochronologic samples, which are from Analysis Units, which may have a depth and thickness. Geochronologic measurments may be from the same or different Analysis Units as fossils. In the case of faunal excavations, geochronologic samples are typically from the same Analysis Units as the fossils, and there may be multiple geochronologic samples from a single Analysis Unit. In the case of cores used for microfossil analyses, geochronologic samples are often from separate Analysis Units; dated core sections are often thicker than microfossil Analysis Units.

| GeochronID | Long Integer | PK |   | +—————————-+—————-+——+————————+ | SampleID | Long Integer | FK | Samples | +—————————-+—————-+——+————————+ | GeochronTypeID | Long Integer | FK | GeochronTypes | +—————————-+—————-+——+————————+ | AgeTypeID | Long Integer | FK | AgeTypes | +—————————-+—————-+——+————————+ | Age | Double | |   | +—————————-+—————-+——+————————+ | ErrorOlder | Double | |   | +—————————-+—————-+——+————————+ | ErrorYounger | Double | |   | +—————————-+—————-+——+————————+ | Infinite | Yes/No | |   | +—————————-+—————-+——+————————+ | Delta13C | Double | |   | +—————————-+—————-+——+————————+ | LabNumber | Text | |   | +—————————-+—————-+——+————————+ | MaterialDated | Text | |   | +—————————-+—————-+——+————————+ | Notes | Memo | |   | +—————————-+—————-+——+————————+

GeochronID (Primary Key)

An arbitrary Geochronologic identificantion number.

SampleID (Foreign Key)

Sample identification number. Field links to Samples table.

GeochronTypeID (Foreign Key)

Identification number for the type of Geochronologic analysis, e.g. «Carbon-14», «Thermoluminescence». Field links to the GeochronTypes table.

AgeTypeID (Foreign Key)

Identification number for the age units, e.g. «Radiocarbon years BP», «Calibrated radiocarbon years BP».

Age

Reported age value of the geochronologic measurement.

ErrorOlder

The older error limit of the age value. For a date reported with ±1 SD or σ, the ErrorOlder and ErrorYounger values are this value.

ErrorYounger

The younger error limit of the age value.

Infinite

Is «True» for and infinite or “greater than” geochronologic measurement, otherwise is «False».

Delta13C

The measured or assumed δ¹³C value for radiocarbon dates, if provided. Radiocarbon dates are assumed to be normalized to δ¹³C, and if uncorrected and normalized ages are reported, the normalized age should be entered in the database.

LabNumber

Lab number for the geochronologic measurement.

Material Dated

Material analyzed for a geochronologic measurement.

Notes

Free form notes or comments about the geochronologic measurement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT AnalysisUnits.Depth, AnalysisUnits.Thickness,
GeochronTypes.GeochronType, Geochronology.Age, Geochronology.ErrorOlder,
Geochronology.ErrorYounger, Geochronology.Delta13C,
Geochronology.LabNumber, Geochronology.MaterialDated,
Geochronology.Notes

FROM GeochronTypes INNER JOIN ((((Sites INNER JOIN CollectionUnits ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN AnalysisUnits ON
CollectionUnits.CollectionUnitID = AnalysisUnits.CollectionUnitID) INNER
JOIN Samples ON AnalysisUnits.AnalysisUnitID = Samples.AnalysisUnitID)
INNER JOIN Geochronology ON Samples.SampleID = Geochronology.SampleID)
ON GeochronTypes.GeochronTypeID = Geochronology.GeochronTypeID

WHERE (((Sites.SiteName)="Montezuma Well"));

GeochronPublications¶

Publications in which Geochronologic measurements are reported. Many older radiocarbon dates are reported in the journal Radiocarbon. Dates may be reported in multiple publications. The “publication” could be a database such as the online Canadian Archaeological Radiocarbon Database.

GeochronID (Primary Key, Foreign Key)

Geochronologic identification number. Field links to the Geochronology table.

PublicationID (Primary Key, Foreign Key)

Publication identification number. Field links to the Publications table.

GeochronTypes¶

Lookup table for Geochronology Types. Table is referenced by the Geochronology table.

GeochronTypeID (Primary Key)

Geochronology Type identification number.

GeochronType

Type of Geochronologic measurement.

RelativeAgePublications¶

This table stores Publications in which Relative Ages are reported for CollectionUnits.

RelativeAgeID (Primary Key, Foreign Key)

Relative Ages identification number. Field links to the RelativeAges table.

PublicationID (Primary Key, Foreign Key)

Publication identification number. Field links to Publications table.

RelativeAges¶

Lookup table of RelativeAges. Table is referenced by the RelativeChronology table.

RelativeAgeID (Primary Key)

An arbitrary Relative Age identification number.

RelativeAgeUnitID (Foreign Key)

Relative Age Unit (e.g. «Marine isotope stage», «Land mammal age»). Field links to the RelativeAgeUnits lookup table.

RelativeAgeScaleID (Foreign Key)

Relative Age Scale (e.g. «Geologic time scale», «Marine isotope stages»). Field links to the RelativeAgeScales lookup table.

RelativeAge

Relative Age (e.g. «Rancholabrean», a land mammal age; «MIS 11», marine isotope stage 11).

C14AgeYounger

Younger age of the Relative Age unit in ¹⁴C yr B.P. Applies only to Relative Age units within the radiocarbon time scale.

C14AgeOlder

Older age of the Relative Age unit in ¹⁴C yr B.P. Applies only to Relative Age units within the radiocarbon time scale.

CalAgeYounger

Younger age of the Relative Age unit in calendar years.

CalAgeOlder

Older age of the Relative age unit in calendar years.

Notes

Free form notes or comments about Relative Age unit.

1
2
3
4
5
6
7

SELECT RelativeAges.RelativeAge, RelativeAges.CalAgeYounger,
RelativeAges.CalAgeOlder

FROM RelativeAgeScales INNER JOIN RelativeAges ON
RelativeAgeScales.RelativeAgeScaleID = RelativeAges.RelativeAgeScaleID

WHERE (((RelativeAgeScales.RelativeAgeScale)="North American land mammal ages"));

RadiocarbonCalibration¶

Radiocarbon calibraton table. This table is intended for quick calibraton of age-model radiocarbon dates. These calibrated dates are for perusal and data exploration only. Please see Section 2.5 for a full discussion.

C14yrBP

Age in radiocarbon years BP. The range is -100 to 45,000 by 1-year increments.

CalyrBP

Age in calibrated radiocarbon years BP.

RelativeAgeScales¶

Lookup table of Relative Age Scales. Table is referenced by the RelativeAges table.

RelativeAgeScaleID (Primary Key)

An arbitrary Relative Age Scale identification number.

RelativeAgeScale

Relative Age Scale. The table stores the following Relative Age Scales:

• Archaeological time scale
• Geologic time scale
• Geomagnetic polarity time scale
• Marine isotope stages
• North American land mammal ages
• Quaternary event classification

RelativeAgeUnits¶

Lookup table of RelativeAgeUnits. Table is referenced by the RelativeAges table.

RelativeAgeUnitID (Primary Key)

An arbitrary Relative Age Unit identification number.

RelativeAgeUnit

Relative Age Unit. Below are the Relative Age Units for the «Geologic time scale» with an example Relative Age.

«Period», «Epoch», and «Stage» are defined by the International Commission on Statigraphy. An «Informal stage» is defined in Neotoma.

RelativeChronology¶

This table stores relative chronologic data. Relative Ages are assigned to Analysis Units, The Relative Age data along with any possible Geochronology and Tephrachronology data are used to create a chronology.

RelativeChronID (Primary Key)

An arbitrary Relative Chronology identification number.

AnalysisUnitID (Foreign Key)

Analysis Unit identification number. Field links to the AnalysisUnits table.

RelativeAgeID (Foreign Key)

Relative Age identification number. Field links to the RelativeAges lookup table.

Notes

Free form notes or comments.

Tephrachronology¶

This table stores tephrachronologic data. The table relates Analysis Units with dated tephras in the Tephras table. These are tephras with established ages that are used form a chronology. The tephras are typically not directly dated at the Site of the Analysis Unit, but have been dated at other sites. A directly dated tephra, e.g. an argon-argon date, belongs in the Geochronology table.

TephrachronID (Primary Key) An arbitrary Tephrachronology identification number.

AnalysisUnitID (Foreign Key) Analysis Unit identification number. Field links to the AnalysisUnits table. The tephra may be contained within the AnalysisUnit, especially in excavations, or the AnalysisUnit may be assigned specifically to the tephra, particulary with cores.

TephraID (Foreign Key) Tephra identification number. Field links to the Tephras table.

Notes Free form notes or comments about the tephra.

Tephras¶

Tephras lookup table. This table stores recognized tephras with established ages. Referenced by the Tephrachronology table.

TephraID (Primary Key)

An arbitrary Tephra identification number.

TephraName

Name of the tephra, e.g. «Mazama».

C14Age

Age of the tephra in ¹⁴C yr BP. For example, Hallett et al. (1997) provide an estimate of the age of the Mazama tephra based on radiocarbon dating of plant macrofossils in lake sediments encasing the tephra.

C14AgeYounger

Younger age estimate of the tephra in ¹⁴C yr BP.

C14AgeOlder

Older age estimate of the tephra in ¹⁴C yr BP.

CalAge

Age of the tephra in cal yr BP, either calibrated radiocarbon years or estimated calendar years derived from another dating method. For example, Zdanowicz et al. (1999) identified the Mazama tephra in the GISP2 ice core and estimated the age from layer counts.

CalAgeYounger

Younger age estimate of the tephra in cal yr BP.

CalAgeOlder

Older age estimate of the tephra in cal yr BP.

Notes

Free form notes or comments about the tephra.

AggregateDatasets¶

Aggregate Datasets are aggregates of samples of a particular datatype. Some examples:

• Plant macrofossil samples from a group of packrat middens collected from a particular valley, mountain range, or other similarly defined geographic area. Each midden is from a different Site or Collection Unit, but they are grouped into time series for that area and are published as single dataset.
• Samples collected from 32 cutbanks along several kms of road. Each sample is from a different site, but they form a time series from 0 – 12,510 ¹⁴C yr BP, and pollen, plant macrofossils, and beetles were published and graphed as if from a single site.
• A set of pollen surface samples from particular region or study that were published and analyzed as a single dataset and submitted to the database as a single dataset.
• The examples above are datasets predefined in the database. New aggregate datasets could be assembled for particular studies, for example all the pollen samples for a given time slice for a given geographic region.

AggregateDatasetID (Primary Key)

An arbitrary Aggregate Dataset identification number.

AggregateDatasetName

Name of Aggregate Dataset.

AggregateOrderTypeID (Foreign Key)

Aggregate Order Type identification number. Field links to the AggregateOrderTypes lookup table.

Notes

Free form notes about the Aggregate Order Type.

AggregateOrderTypes¶

Lookup table for Aggregate Order Types. Table is referenced by the AggregateDatasets table.

AggregateOrderTypeID (Primary Key)

An arbitrary Aggregate Order Type identification number.

AggregateOrderType

The Aggregate Order Type.

Notes

Free form notes or comments about the Aggregate Order Type.

The Aggregate Order Types are:

• Latitude: AggregateDataset samples are ordered by, in order of priority, either (1) CollectionUnits.GPSLatitude or (2) the mean of Sites.LatitudeNorth and Sites.LatitudeSouth.
• Longitude AggregateDataset samples are ordered by, in order of priority, either (1) CollectionUnits.GPSLongitude or (2) the mean of Sites.LongitudeWest and Sites.LongitudeEast.
• Altitude AggregateDataset samples are ordered by Sites.Altitude`.
• Age AggregateDataset samples are ordered by SampleAges.Age, where SampleAges.SampleAgeID is from AggregateSampleAges.SampleAgeID.
• Alphabetical by site name AggregateDataset samples are ordered alphabetically by Sites.SiteName.
• Alphabetical by collection unit name AggregateDataset samples are ordered alphabetically by CollectionUnits.CollUnitName.
• Alphabetical by collection units handle AggregateDataset samples are ordered alphabetically by CollectionUnits.Handle.

CollectionTypes¶

This table is a lookup table of for types of Collection Units, or Collection Types. Table is referenced by the CollectionUnits table.

CollTypeID (Primary Key)

An arbitrary Collection Type identification number.

Colltype

The Collection Type. Types include cores, sections, excavations, and animal middens. Collection Units may be modern collections, surface float, or isolated specimens. Composite Collections Units include different kinds of Analysis Units, for example a modern surface sample for ostracodes and an associated water sample.

CollectionUnits¶

This table stores data for Collection Units.

CollectionUnitID (Primary Key)

An arbitrary Collection Unit identification number.

SiteID (Foreign Key)

Site where CollectionUnit was located. Field links to Sites table.

CollTypeID (Foreign Key)

Type of Collection Unit. Field links to the CollectionTypes table.

DepEnvtID (Foreign Key)

Depositional environment of the CollectionUnit. Normally, this key refers to the modern environment. For example, the site may be located on a colluvial slope, in which case the Depositional Environment may be Colluvium or Colluvial Fan. However, an excavation may extend into alluvial sediments, which represent a different depositional environment. These are accounted for by the Facies of the AnalysisUnit. Field links to the DepEnvtTypes table.

Handle

Code name for the Collection Unit. This code may be up to 10 characters, but an effort is made to keep these to 8 characters or less. Data are frequently distributed by Collection Unit, and the Handle is used for file names.

CollUnitName

Name of the Collection Unit. Examples: Core BPT82A, Structure 9, P4A Test 57. If faunal data are reported from a site or locality without explicit Collection Units, then data are assigned to a single Collection Unit with the name «Locality».

CollDate

Date Collection Unit was collected.

CollDevice

Device used for obtain Collection Unit. This field applies primarily to cores, for example «Wright square-rod piston corer (5 cm)».

GPSLatitude

Precise latitude of the Collection Unit, typically taken with a GPS, although may be precisely measured from a map.

GPSLongitude

Precise longitude of the Collection Unit, typically taken with a GPS, although may be precisely measured from a map.

GPSAltitude

Precise altitude of the Collection Unit, typically taken with a GPS or precisely obtained from a map.

GPSError

Error in the horizontal GPS coordinates, if known.

WaterDepth

Depth of water at the Collection Unit location. This field applies mainly to Collection Units from lakes.

SubstrateID (Foreign Key)

Substrate or rock type on which the Collection Unit lies. Field links to the RockTypes table. This field is especially used for rodent middens.

SlopeAspect

For Collection Units on slopes, the horizontal direction to which a slope faces measured in degrees clockwise from north. This field is especially used for rodent middens.

SlopeAngle

For Collection Units on slopes, the angle of slope from horizontal. field is especially used for rodent middens.

Location

Short description of the location of the Collection Unit within the site.

Notes

Free form notes or comments about the Collection Unit.

DatasetPublications¶

This table lists the publications for datasets.

DatasetID (Primary Key, Foreign Key)

Dataset identification number. Field links to Datasets table.

PublicationID (Primary Key, Foreign Key)

Publication identification number. Field links to Publications table.

PrimaryPub

Is «True» if the publication is the primary publication for the dataset.

Datasets¶

This table stores the data for Datasets. A Dataset is the set of samples for a particular data type from a Collection Unit. A Collection Unit may have multiple Datasets for different data types, for example one dataset for pollen and another for plant macrofossils. Every Sample is assigned to a Dataset, and every Dataset is assigned to a Collection Unit. Samples from different Collection Units cannot be assigned to the same Dataset (although they may be assigned to AggregateDatasets).

DatasetID (Primary Key)

An arbitrary Dataset identification number.

CollectionUnitID (Foreign Key)

Collection Unit identification number. Field links to the CollectionUnits table.

DatasetTypeID (Foreign Key)

Dataset Type identification number. Field links to the DatasetTypes lookup table.

DatasetName

Optional name for the Dataset.

Notes

Free form notes or comments about the Dataset.

1
2
3
4
5
6
7
8

SELECT Sites.SiteName, DatasetTypes.DatasetType

FROM DatasetTypes INNER JOIN ((Sites INNER JOIN CollectionUnits ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN Datasets ON
CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) ON
DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID

WHERE (((Sites.SiteName)=""));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

SELECT Sites.SiteName, Taxa.TaxonName

FROM DatasetTypes INNER JOIN (Taxa INNER JOIN (Variables INNER JOIN
((((Sites INNER JOIN CollectionUnits ON Sites.SiteID =
CollectionUnits.SiteID) INNER JOIN Datasets ON
CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) INNER JOIN
Samples ON Datasets.DatasetID = Samples.DatasetID) INNER JOIN Data ON
Samples.SampleID = Data.SampleID) ON Variables.VariableID =
Data.VariableID) ON Taxa.TaxonID = Variables.TaxonID) ON
DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID

GROUP BY Sites.SiteName, DatasetTypes.DatasetType, Taxa.TaxonName

HAVING (((Sites.SiteName)="Bear River No. 3") AND
((DatasetTypes.DatasetType)="plant macrofossils"));

DatasetSubmissions¶

Submissions to the database are of Datasets. Submissions may be original submissions, resubmissions, compilations from other databases, or recompilations. See the description of the DatasetSubmissionTypes table.

SubmissionID (Primary Key)

An arbitrary submission identification number.

DatasetID (Foreign Key)

Dataset identification number. Field links to the Datasets table. Datasets may occur multiple times in this table (e.g. once for the original compilation into a different database and a second time for the recompilation into Neotoma).

ProjectID (Foreign Key)

Database project responsible for the submission or compilation.

ContactID (Foreign Key)

Contact identification number. Field links to the Contacts table. The Contact is the person who submitted, resubmitted, compiled, or recompiled the data. This person is not necessarily the Dataset PI; it is the person who submitted the data or compiled the data from the literature.

SubmissionDate

Date of the submission, resubmission, compilation, or recompilation.

SubmissionTypeID (Foreign Key)

Submission Type identification number. Field links to the DatasetSubmissionTypes table.

Notes

Free form notes or comments about the submission.

DatasetSubmissionTypes¶

Lookup table of Dataset Submission Types. Table is referenced by the DatasetSubmissions table.

SubmissionTypeID (Primary Key)

An arbitrary Submission Type identification number.

SubmissionType

Type of submission. The database has the following types:

• Original submission from data contributor
• Resubmission or revision from data contributor
• Compilation into a flat file database
• Compilation into a another relational database
• Recompilation or revisions to a another relational database
• Compilation into Neotoma from another database
• Recompilation into Neotoma from another database
• Compilation into Neotoma from primary source
• Recompilation into or revisions to Neotoma: The initial development of Neotoma involved merging the data from several existing databases, including FAUNMAP, the Global Pollen Database, and the North American Plant Macrofossil Database. Thus original compilation of Datasets was into one of these databases, which were then recompiled into Neotoma. The original compilation and the recompilation into Neotoma are separate submissions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

SELECT DatasetTypes.DatasetType, Projects.ProjectName,
DatasetSubmissions.SubmissionDate,
DatasetSubmissionTypes.SubmissionType, DatasetSubmissions.Notes

FROM Sites INNER JOIN (Projects INNER JOIN (DatasetTypes INNER JOIN
(DatasetSubmissionTypes INNER JOIN ((CollectionUnits INNER JOIN Datasets
ON CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) INNER
JOIN DatasetSubmissions ON Datasets.DatasetID =
DatasetSubmissions.DatasetID) ON DatasetSubmissionTypes.SubmissionTypeID
= DatasetSubmissions.SubmissionTypeID) ON DatasetTypes.DatasetTypeID =
Datasets.DatasetTypeID) ON Projects.ProjectID =
DatasetSubmissions.ProjectID) ON Sites.SiteID = CollectionUnits.SiteID

WHERE (((Sites.SiteName)="Bear River No. 3"))
ORDER BY DatasetSubmissions.SubmissionDate;

DatasetTypes¶

Lookup table for Dataset Types. Table is referenced by the Datasets table.

DatasetTypeID (Primary Key)

An arbitrary Dataset Type identification number.

DatasetType

The Dataset type, including the following:

• geochronologic
• loss-on-ignition
• pollen
• plant macrofossils
• vertebrate fauna
• mollusks

DatasetPIs¶

This table lists the Principle Investigators for Datasets.

DatasetID (Primary Key, Foreign Key)

Dataset identification number. Field links to Dataset table.

ContactID (Primary Key, Foreign Key)

Contact identification number. Field links to Contacts table.

PIOrder

Order in which PIs are listed.

DepEnvtTypes¶

Lookup table of Depostional Environment Types. Table is referenced by the CollectionUnits table.

DepEnvtID (Primary Key)

An arbitrary Depositional Environment Type identification number.

DepEnvt

Depositional Environment.

DepEnvtHigherID

The Depositional Environment Types are hierarchical. DepEnvtHigherID is the DepEnvtID of the higher ranked Depositional Environment. See following table gives some examples.

1
2
3
4
5
6

SELECT DepEnvtTypes.DepEnvtID, DepEnvtTypes.DepEnvt,
DepEnvtTypes.DepEnvtHigherID

FROM DepEnvtTypes INNER JOIN DepEnvtTypes AS DepEnvtTypes\_1 ON
(DepEnvtTypes.DepEnvt = DepEnvtTypes\_1.DepEnvt) AND
(DepEnvtTypes.DepEnvtHigherID = DepEnvtTypes\_1.DepEnvtID);

1
2
3
4
5
6
7

SELECT DepEnvtTypes\_1.DepEnvtID, DepEnvtTypes\_1.DepEnvt,
DepEnvtTypes\_1.DepEnvtHigherID

FROM DepEnvtTypes INNER JOIN DepEnvtTypes AS DepEnvtTypes\_1 ON
DepEnvtTypes.DepEnvtID = DepEnvtTypes\_1.DepEnvtHigherID

WHERE (((DepEnvtTypes.DepEnvt)="Terrestrial"));

Lithology¶

This table stores the lithologic descriptions of Collection Units.

LithologyID (Primary Key)

An arbitrary identification number for a lithologic unit.

CollectionUnitID (Foreign Key)

Collection Unit identification number. Field links to the CollectionUnits table.

DepthTop

Depth of the top of the lithologic unit in cm.

DepthBottom

Depth of the bottom of the lithologic unit in cm.

LowerBoundary

Description of the nature of the lower boundary of the lithologic unit, e.g. «gradual, over ca. 10 cm».

Description

Description of the lithologic unit. These can be quite detailed, with Munsell color or Troels-Smith descriptions. Some examples:

• interbedded gray silt and peat
• marly fine-detritus copropel
• humified sedge and Sphagnum peat
• sedge peat 5YR 5/4
• gray sandy loam with mammoth and other animal bones
• grey-green gyttja, oxidizing to gray-brown
• Ag 3, Ga 1, medium gray, firm, elastic
• nig3, strf0, elas2, sicc0; Th2 T12 Tb+
• Ld°4, , Dg+, Dh+

Projects¶

This table stores a list of database projects that have supplied data to Neotoma. These include the databases that were merged in the initial development of Neotoma as well as other independent projects that continue to assemble data for a particular region or data type. Some of these projects have developed relational databases, whereas others have compiled data in flat files. This table is referenced by the DatasetSubmissions table.

ProjectID (Primary Key)

An arbitrary Project identification number.

ProjectName

Name of the Project, e.g. «Cooperative Holocene Mapping Project», «North American Pollen Database», «FAUNMAP».

ContactID (Foreign Key)

Contact person for the project. Field links to the Contacts table.

URL

Web site address for the project.

AnalysisUnits¶

This table stores the data for Analysis Units.

AnalysisUnitID (Primary Key)

An arbitrary Analysis Unit identification number.

CollectionUnitID (Foreign Key)

Collection Unit ID number. Field links to CollectionUnits table. Every Analysis Unit belongs to a Collection Unit.

AnalysisUnitName

Optional name for an Analysis Unit. Analysis Units are usually designated with either a depth or a name, sometimes both.

Depth

Optional depth of the Analysis Unit in cm. Depths are typically designated for Analysis Units from cores and for Analysis Units excavated in arbitrary (e.g. 10 cm) levels. Depths are normally the midpoints of arbitrary levels. For example, for a level excavated from 10 to 20 cm or for a core section from 10 to 15 cm, the depth is 15. Designating depths as midpoints and thicknesses facilitates calculation of ages from age models that utilize single midpoint depths for Analysis Units rather than top and bottom depths. Of course, top and bottom depths can be calculated from midpoint depths and thicknesses. For many microfossil core samples, only the midpoint depths are known or published; the diameter or width of the sampling device is often not given.

Thickness

Optional thickness of the Analysis Unit in cm. For many microfossil core samples, the depths are treated as points, and the thicknesses are not given in the publications, although 0.5 to 1.0 cm would be typical.

FaciesID

Sedimentary facies of the Analysis Unit. Field links to the FaciesTypes table.

Mixed

Indicates whether specimens in the Analysis Unit are of mixed ages, for example Pleistocene fossils occurring with late Holocene fossils. Although Analysis Units may be mixed, samples from the Analysis Unit may not be, for example individually radiocarbon dated specimens.

IGSN

International Geo Sample Number. The IGSN is a unique identifier for a Geoscience sample. They are assigned by the SESAR, the System for Earth Sample Registration (www.geosamples.org), which is a registry that provides and administers the unique identifiers. IGSN’s may be assigned to all types of geoscience samples, including cores, rocks, minerals, and even fluids. Their purpose is to facilitate sharing and correlation of samples and sample-based data. For data in Neotoma, their primary value would be for correlation various samples from the same Analysis Units, for example pollen, charcoal, diatoms, and geochemical analyses. Conceivably, the AnalysisUnitID could be used for this purpose; however, IGSN’s could be assigned by projects before their data are submitted to the database. Moreover, AnalysisUnitID’s are intended to be internal to the database. Although IGSN’s could be assigned to Neotoma Collection Units and Samples, their primary value lies in their assignment to Analysis Units. IGSN’s are not yet assigned to Neotoma Analysis Units; however, that may change after consultation with SESAR.

Notes

Free form notes or comments about the Analysis Unit.

Data¶

The primary data table in the database. Each occurrence of a Variable in a sample comprises a record in the Data table.

SampleID (Primary Key, Foreign Key)

Sample identification number. Field links to Samples table.

VariableID (Primary Key, Foreign Key)

Variable identification number. Field links to Variables table.

Value

The value of the variable.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

SELECT
  AnalysisUnits.AnalysisUnitName,
  Taxa.TaxonName,
  VariableUnits.VariableUnits,
  `Data.Value`

FROM
  VariableUnits
INNER JOIN (
  AnalysisUnits
  INNER JOIN (
    DatasetTypes
    INNER JOIN (
      Taxa
      INNER JOIN (
        `Variables`
        INNER JOIN (
          (
            (
              (
                Sites
                INNER JOIN CollectionUnits ON Sites.SiteID = CollectionUnits.SiteID
              )
              INNER JOIN Datasets ON CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID
            )
            INNER JOIN Samples ON Datasets.DatasetID = Samples.DatasetID
          )
          INNER JOIN `Data` ON Samples.SampleID = `Data.SampleID`
        ) ON `Variables.VariableID` = `Data.VariableID`
      ) ON Taxa.TaxonID = `Variables.TaxonID`
    ) ON DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID
    AND (DatasetTypes.DatasetType) = "vertebrate fauna"
  ) ON (
    CollectionUnits.CollectionUnitID = AnalysisUnits.CollectionUnitID
  )
  AND (
    AnalysisUnits.AnalysisUnitID = Samples.AnalysisUnitID
  )
) ON VariableUnits.VariableUnitsID = `Variables.VariableUnitsID`

LIMIT 5;

DepAgents¶

Deposition Agents for Analysis Units. Individual Analysis Units may be listed multiple times with different Deposition Agents.

AnalysisUnitID (Primary Key)

Analysis Unit identification number. Field links to AnalysisUnits table.

DepAgentID

Deposition Agent identification number. Field links to DepAgentTypes table.

DepAgentTypes¶

Lookup table of Depositional Agents. Table is referenced by the DepAgents table.

DepAgentID (Primary Key)

An arbitrary Depositional Agent identification number.

DepAgent

Depostional Agent.

SampleAges¶

This table stores sample ages. Ages are assigned to a Chronology. Because there may be more than one Chronology for a Collection Unit, samples may be assigned different ages for different Chronologies. A simple example is one sample age in radiocarbon years and another in calibrated radiocarbon years. The age units are an attribute of the Chronology.

SampleAgeID (Primary Key)

An arbitrary Sample Age identification number.

SampleID (Foreign Key)

Sample identification number. Field links to the Samples table.

ChronologyID (Foreign Key)

Chronology identification number. Field links to the Chronologies table.

Age

Age of the sample

AgeYounger

Younger error estimate of the age. The definition of this estimate is an attribute of the Chronology. Many ages do not have explicit error estimates assigned.

AgeOlder

Older error estimate of the age.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SELECT
   s.SiteName,
   -- From the Sites table
   c.Handle,
   -- From the CollectionUnits table
   sa.Age,
   -- From the SampleAges table
   a.AgeType -- From the AgeTypes table
FROM
   AgeTypes AS a
INNER JOIN (
   (
      (
         Sites AS s
         INNER JOIN CollectionUnits AS c ON s.SiteID = c.SiteID
      )
      INNER JOIN Chronologies AS ch ON c.CollectionUnitID = ch.CollectionUnitID
   )
   INNER JOIN SampleAges AS sa ON ch.ChronologyID = sa.ChronologyID
) ON a.AgeTypeId = ch.AgeTypeID
WHERE
   (s.SiteName) = "Muskox Lake"
AND (ch.IsDefault) = TRUE;

SampleAnalysts¶

This table lists the Sample Analysts.

AnalystID (Primary Key)

An arbitrary Sample Analyst identification number.

SampleID (Foreign Key)

Sample identification number. Field links to the Samples table.

ContactID (Foreign Key)

Contact identification number. Field links to the Contacts table.

AnalystOrder

Order in which Sample Analysts are listed if more than one (rare).

SampleKeywords¶

This table links keywords to samples. For example, it identifies modern pollen surface samples.

SampleID (Primary Key, Foreign Key)

Sample identification number. Field links to the Samples table.

KeywordID (Primary Key, Foreign Key)

Keyword identification number. Field links to the Keywords lookup table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

SELECT Samples.SampleID, Sites.SiteName, CollectionTypes.CollType,
Contacts.ContactName, DepEnvtTypes.DepEnvt

FROM DepEnvtTypes INNER JOIN (Contacts INNER JOIN ((CollectionTypes
INNER JOIN (GeoPoliticalUnits INNER JOIN ((Sites INNER JOIN
(CollectionUnits INNER JOIN (DatasetTypes INNER JOIN (Datasets INNER
JOIN (Samples INNER JOIN (Keywords INNER JOIN SampleKeywords ON
Keywords.KeywordID = SampleKeywords.KeywordID) ON Samples.SampleID =
SampleKeywords.SampleID) ON Datasets.DatasetID = Samples.DatasetID) ON
DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID) ON
CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN SiteGeoPolitical ON
Sites.SiteID = SiteGeoPolitical.SiteID) ON
GeoPoliticalUnits.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID) ON
CollectionTypes.CollTypeID = CollectionUnits.CollTypeID) INNER JOIN
DatasetPIs ON Datasets.DatasetID = DatasetPIs.DatasetID) ON
Contacts.ContactID = DatasetPIs.ContactID) ON DepEnvtTypes.DepEnvtID =
CollectionUnits.DepEnvtID

WHERE (((Keywords.Keyword)="modern sample") AND
((DatasetTypes.DatasetType)="pollen") AND
((GeoPoliticalUnits.GeoPoliticalName)=""))

ORDER BY CollectionTypes.CollType;

Samples¶

This table stores sample data. Samples belong to Analysis Units, which belong to Collection Units, which belong to Sites. Samples also belong to a Dataset, and the Dataset determines the type of sample. Thus, there could be two different samples from the same Analysis Unit, one belonging to a pollen dataset, the other to a plant macrofossil dataset.

SampleID (Primary Key)

An arbitrary Sample identification number.

AnalysisUnitID (Foreign Key)

Analysis Unit identification number. Field links to the AnalysisUnits table.

DatasetID (Foreign Key)

Dataset identification number. Field links to the Datasets table.

SampleName

Sample name if any.

AnalysisDate

Date of analysis.

LabNumber

Laboratory number for the sample. A special case regards geochronologic samples, for which the LabNumber is the number, if any, assigned by the submitter, not the number assigned by the radiocarbon laboratory, which is in the Geochronology table.

PreparationMethod

Description, notes, or comments on preparation methods. For faunal samples, notes on screening methods or screen size are stored here.

Notes

Free form note or comments about the sample.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT CollectionUnits.CollUnitName, AnalysisUnits.AnalysisUnitName,
DatasetTypes.DatasetType, Samples.PreparationMethod

FROM DatasetTypes INNER JOIN ((((Sites INNER JOIN CollectionUnits ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN AnalysisUnits ON
CollectionUnits.CollectionUnitID = AnalysisUnits.CollectionUnitID) INNER
JOIN Samples ON AnalysisUnits.AnalysisUnitID = Samples.AnalysisUnitID)
INNER JOIN (Datasets.DatasetID = Samples.DatasetID) AND
(CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID)) ON
DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID

WHERE (((Sites.SiteName)=""))

ORDER BY CollectionUnits.CollUnitName, AnalysisUnits.AnalysisUnitName;

AggregateSamples¶

This table stores the samples in Aggregate Datasets.

AggregateDatasetID (Primary Key, Foreign Key)

An arbitrary Aggregate Dataset identification number. Field links to the AggregateDatasets table.

SampleID (Primary Key, Foreign Key)

Sample ID number. Field links to the Samples table.

FaciesTypes¶

Lookup table of Facies Types. Table is referenced by the AnalysisUnits table.

FaciesID (Primary Key)

An arbitrary Facies identification number.

Facies

Short Facies description.

Keywords¶

Lookup table of Keywords referenced by the SampleKeywords table. The table provides a means to identify samples sharing a common attribute. For example, the keyword «modern sample» identifies modern surface samples in the database. These samples include individual surface samples, as well as core tops. Although not implemented, a «pre-European settlement» keyword would be a means to identify samples just predating European settlement.

KeywordID (Primary Key)

An arbitrary Keyword identification number.

Keyword

A keyword for identifying samples sharing a common attribute.

SiteImages¶

This table stores hyperlinks to jpeg images of sites.

SiteImageID (Primary Key)

An arbitrary Site Image identification number.

SiteID (Foreign Key)

Site identification number. Field links to the Sites table.

ContactID (Foreign Key)

Contact identification number for image attribution from the Contacts table.

Caption

Caption for the image.

Credit

Credit for the image. If null, the credit is formed from the ContactID.

Date

Date of photograph or image.

SiteImage

Hyperlink to a URL for the image.

Sites¶

The Sites table stores information about sites or localities, including name, geographic coordinates, and description. Sites generally have an areal extent and can be circumscribed by a latitude-longitude box. However, site data ingested from legacy databases have included only point locations. The lat-long box can be used either to circumscribe the areal extent of a site or to provide purposeful imprecision to the site location. Site location may be imprecise because of the original description was vague, e.g. «a gravel bar 5 miles east of town», or because the investigators, land owner, or land management agency may not want the exact location made public, perhaps to prevent looting and vandalism. In the first case, the lat-long box can be made sufficiently large to encompass the true location and in the second case to prevent exact location.

SiteID (Primary Key)

An arbitrary Site identification number.

SiteName

Name of the site. Alternative names, including archaeological site numbers, are placed in square brackets, for example:

• New #4 [Lloyd’s Rock Hole]
• Modoc Rock Shelter [11RA501]

A search of the SiteName field for any of the alternative names or for the archaeological site number will find the site. Some archaeological sites are known only by their site number.

Modifiers to site names are placed in parentheses. Authors are added for generic sites names, especially for surface samples, that are duplicated in the database, for example:

• Site 1 (Heusser 1978)
• Site 1 (Delcourt et al. 1983)
• Site 1 (Elliot-Fisk et al. 1982)
• Site 1 (Whitehead and Jackson 1990)

For actual site names duplicated in the database, the name is followed by the 2-letter country code and state or province, for example:

• (US:)
• (CA:)
• (US:)
• (US:)

LongitudeEast

East bounding longitude for a site.

LatitudeNorth

North bounding latitude for a site.

LongitudeWest

West bounding longitude for a site.

LatitudeSouth

South bounding latitude for a site.

Altitude

Altitude of a site in meters.

Area

Area of a site in hectares.

SiteDescription

Free form description of a site, including such information as physiography and vegetation around the site.

Notes

Free form notes or comments about the site.

SiteGeoPolitical¶

This table lists the GeoPolitical units in which sites occur.

SiteGeoPoliticalID (Primary Key)

An arbitrary Site GeoPolitical identification number.

SiteID (Foreign Key)

Site identification number. Field links to the Sites table.

GeoPoliticalID (Foreign Key)

GeoPolitical identification number. Field links to the GeoPoliticalUnits lookup table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

SELECT Sites.SiteName, GeoPoliticalUnits.GeoPoliticalName,
GeoPoliticalUnits\_1.GeoPoliticalName,
GeoPoliticalUnits\_2.GeoPoliticalName

FROM GeoPoliticalUnits AS GeoPoliticalUnits\_2 INNER JOIN
(SiteGeoPolitical AS SiteGeoPolitical\_2 INNER JOIN ((SiteGeoPolitical
AS SiteGeoPolitical\_1 INNER JOIN (GeoPoliticalUnits INNER JOIN (Sites
INNER JOIN SiteGeoPolitical ON Sites.SiteID = SiteGeoPolitical.SiteID)
ON GeoPoliticalUnits.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID)
ON SiteGeoPolitical\_1.SiteID = Sites.SiteID) INNER JOIN
GeoPoliticalUnits AS GeoPoliticalUnits\_1 ON
SiteGeoPolitical\_1.GeoPoliticalID =
GeoPoliticalUnits\_1.GeoPoliticalID) ON SiteGeoPolitical\_2.SiteID =
Sites.SiteID) ON GeoPoliticalUnits\_2.GeoPoliticalID =
SiteGeoPolitical\_2.GeoPoliticalID

WHERE (((Sites.SiteName)="") AND ((GeoPoliticalUnits.Rank)=1) AND
((GeoPoliticalUnits\_1.Rank)=2) AND ((GeoPoliticalUnits\_2.Rank)=3));

1
2
3
4
5
6
7

SELECT Sites.SiteName, GeoPoliticalUnits.GeoPoliticalName

FROM Sites INNER JOIN (GeoPoliticalUnits INNER JOIN SiteGeoPolitical ON
GeoPoliticalUnits.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID) ON
Sites.SiteID = SiteGeoPolitical.SiteID

WHERE (((GeoPoliticalUnits.Rank)=1));

1
2
3
4
5
6
7

SELECT Sites.SiteName, GeoPoliticalUnits.GeoPoliticalName

FROM Sites INNER JOIN (GeoPoliticalUnits INNER JOIN SiteGeoPolitical ON
GeoPoliticalUnits.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID) ON
Sites.SiteID = SiteGeoPolitical.SiteID

WHERE (((GeoPoliticalUnits.Rank)=2));

1
2
3
4
5
6
7

SELECT Sites.SiteName, GeoPoliticalUnits.GeoPoliticalName

FROM Sites INNER JOIN (GeoPoliticalUnits INNER JOIN SiteGeoPolitical ON
GeoPoliticalUnits.GeoPoliticalID = SiteGeoPolitical.GeoPoliticalID) ON
Sites.SiteID = SiteGeoPolitical.SiteID

WHERE (((GeoPoliticalUnits.Rank)=3));

1
2
3
4
5
6
7

SELECT GeoPol1.SiteName, GeoPol1.GeoPoliticalName,
GeoPol2.GeoPoliticalName, GeoPol3.GeoPoliticalName

FROM (GeoPol1 LEFT JOIN GeoPol2 ON GeoPol1.SiteName = GeoPol2.SiteName)
LEFT JOIN GeoPol3 ON GeoPol2.SiteName = GeoPol3.SiteName

WHERE (((GeoPol1.SiteName)="Lofty "));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

SELECT GeoPol1.SiteName, GeoPol1.GeoPoliticalName,
GeoPol2.GeoPoliticalName, GeoPol3.GeoPoliticalName,
DatasetTypes.DatasetType

FROM (DatasetTypes INNER JOIN ((Sites INNER JOIN CollectionUnits ON
Sites.SiteID = CollectionUnits.SiteID) INNER JOIN Datasets ON
CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) ON
DatasetTypes.DatasetTypeID = Datasets.DatasetTypeID) INNER JOIN
((GeoPol1 LEFT JOIN GeoPol2 ON GeoPol1.SiteName = GeoPol2.SiteName) LEFT
JOIN GeoPol3 ON GeoPol2.SiteName = GeoPol3.SiteName) ON Sites.SiteName =
GeoPol1.SiteName

GROUP BY GeoPol1.SiteName, GeoPol1.GeoPoliticalName,
GeoPol2.GeoPoliticalName, GeoPol3.GeoPoliticalName,
DatasetTypes.DatasetType

HAVING (((GeoPol1.GeoPoliticalName)="" Or (GeoPol1.GeoPoliticalName)="")
AND ((GeoPol2.GeoPoliticalName)="" Or (GeoPol2.GeoPoliticalName)="") AND
((DatasetTypes.DatasetType)="pollen"))

ORDER BY GeoPol1.GeoPoliticalName, GeoPol2.GeoPoliticalName,
GeoPol3.GeoPoliticalName, DatasetTypes.DatasetType;

GeoPoliticalUnits¶

Lookup table of GeoPoliticalUnits. Table is referenced by the SiteGeoPolitical table. These are countries and various subdivisions. Countries and subdivisions were acquired from the U.S. Central Intelligence Agency World Factbook [8] and the ISO 3166-1 and ISO 3166-2 databases [9].

Each GeoPolitical Unit has a rank. GeoPolitical Units with Rank 1 are generally countries. There are a few exceptions, including Antarctica and island territories, such as , which although a Danish territory, is geographically separate and distinct. Rank 2 units are generally secondary political divisions with various designations: e.g. states in the , provinces in , and regions in . For some countries, the secondary divisions are not political but rather distinct geographic entities, such as islands. The secondary divisions of some island nations include either groups of islands or sections of more highly populated islands; however, the actual island on which a site is located is more important information. Some countries also have Rank 3 units, e.g. counties in the and metropolitan departments in . In addition to purely political units, various other administrative regions and geographic entities can be contained in this table. Examples of administrative regions are National Parks and Forests. It might be quite useful, for example, to have a record of all the sites in . These additional units are Rank 4, and they can be added to the database as warranted.

GeoPoliticalID (Primary Key)

An arbitrary GeoPolitical identification number.

GeoPoliticalName

Name of the GeoPolitical Unit, e.g. , .

GeoPoliticalUnit

The name of the unit, e.g. country, state, county, island, governorate, oblast.

Rank

The rank of the unit.

HigherGeoPoliticalID

The GeoPoliticalUnit with higher rank, e.g. the country in which a state lies.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT GeoPoliticalUnits\_2.Rank, GeoPoliticalUnits\_2.GeoPoliticalUnit,
GeoPoliticalUnits\_2.GeoPoliticalName

FROM (GeoPoliticalUnits AS GeoPoliticalUnits\_2 RIGHT JOIN
(GeoPoliticalUnits AS GeoPoliticalUnits\_1 RIGHT JOIN GeoPoliticalUnits
ON GeoPoliticalUnits\_1.HigherGeoPoliticalID =
GeoPoliticalUnits.GeoPoliticalID) ON
GeoPoliticalUnits\_2.HigherGeoPoliticalID =
GeoPoliticalUnits\_1.GeoPoliticalID) LEFT JOIN GeoPoliticalUnits AS
GeoPoliticalUnits\_3 ON GeoPoliticalUnits\_2.GeoPoliticalID =
GeoPoliticalUnits\_3.HigherGeoPoliticalID

WHERE (((GeoPoliticalUnits.GeoPoliticalName)="") AND
((GeoPoliticalUnits\_1.GeoPoliticalName)=""));

EcolGroups¶

Taxa are assigned to Sets of Ecological Groups. A taxon may be assigned to more than one Set of Ecological Groups, representing different schemes for organizing taxa.

TaxonID (Primary Key, Foreign Key)

Taxon identification number. The field links to the Taxa table.

EcolSetID (Primary Key, Foreign Key)

Ecological Set identification number. Field links to the EcolSetTypes table.

EcolGroupID (Foreign Key)

A four-letter Ecological Group identification code. Field links to the EcolGroupTypes table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

SELECT
   Taxa.TaxaGroupID,
   EcolGroups.EcolGroupID,
   EcolSetTypes.EcolSetName,
   EcolGroupTypes.EcolGroup
FROM
   EcolSetTypes
INNER JOIN (
   EcolGroupTypes
   INNER JOIN (
      Taxa
      INNER JOIN EcolGroups ON Taxa.TaxonID = EcolGroups.TaxonID
   ) ON EcolGroupTypes.EcolGroupID = EcolGroups.EcolGroupID
) ON EcolSetTypes.EcolSetID = EcolGroups.EcolSetID
GROUP BY
   Taxa.TaxaGroupID,
   EcolGroups.EcolGroupID,
   EcolSetTypes.EcolSetName,
   EcolGroupTypes.EcolGroup
HAVING
   (((Taxa.TaxaGroupID) = "VPL"));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

SELECT
   EcolGroupTypes.EcolGroup,
   Taxa.TaxonName
FROM
   EcolGroupTypes
INNER JOIN (
   Taxa
   INNER JOIN EcolGroups ON Taxa.TaxonID = EcolGroups.TaxonID
) ON EcolGroupTypes.EcolGroupID = EcolGroups.EcolGroupID
WHERE
   (
      (
         (EcolGroupTypes.EcolGroup) = "Sirenia"
      )
   );

EcolGroupTypes¶

Lookup table of Ecological Group Types. The table is referenced by the EcolGroups table.

EcolGroupID (Primary Key)

An arbitrary Ecological Group identification number.

EcolGroup

Ecological Group.

EcolSetTypes¶

Lookup table of Ecological Set Types. The table is referenced by the EcolGroups table.

EcolSetID (Primary Key)

An arbitrary Ecological Set identification number.

EcolSetName The Ecological Set name.

Synonyms¶

This table lists common synonyms for taxa in the Taxa table. No effort has been made to provide a complete taxonomic synonymy, but rather to list synonyms commonly used in recent literature.

SynonymID (Primary Key)

An arbitrary synonym identification number.

SynonymName

Name of the synonym.

TaxonID (Foreign Key)

The accepted taxon name in Neotoma. This field links to Taxa table.

PublicationID (Foreign Key)

Published authority for synonymy. Field links to Publications table.

SynonymTypeID (Foreign Key)

Type of synonym. Field links to the SynonymTypes lookup table.

Notes

Free form notes or comments about the synonymy.

SynonymTypes¶

Lookup table of Synonym Types. Table is referenced by the Synonyms table.

SynonymTypeID (Primary Key)

An arbitrary Synonym Type identification number.

SynonymType

Synonym type. Below are some examples:

nomenclatural, homotypic, or objective synonym

a synonym that unambiguously refers to the same taxon, particularly one with the same description or type specimen. These synonyms are particularly common above the species level. For example, Gramineae = Poaceae, Clethrionomys gapperi = Myodes gapperi. The term «objective» is used in zoology, whereas «nomenclatural» or «homotypic» is used in botany.

taxonomic, heterotypic, or subjective synonym

a synonym typically based on a different type specimen, but which is now regarded as the same taxon as the senior synonym. For example, Iva ciliata = Iva annua. The term «subjective» is used in zoology, whereas «taxonomic» or «heterotypic» is used in botany.

genus merged into another genus

heterotypic or subjective synonym; a genus has been merged into another genus and has not been retained at a subgeneric rank. This synonymy may apply to either the generic or specific level, for example: Petalostemon = Dalea, Petalostemon purpureus = Dalea purpurea.

family merged into another family

Heterotypic or subjective synonym; a family has been merged into another family and has not been retained at a subfamilial rank. For example, the Taxodiaceae has been merged with the Cupressaceae. This synonymy creates issues for data entry, because palynologically the Taxodiaceae sensu stricto is sometimes distinguishable from the Cupressaceae sensu stricto. If a pollen type was identified as «Cupressaceae/Taxodiaceae», then synonymizing to «Cupressaceae» results in no loss of information. However, synonymizing «Taxodiaceae» to «Cupressaceae» potentially does. In this case, consultation with the original literature or knowledge of the local biogeography may point to a logical name change that will retain the precision of the original identification. For example, in the southeastern , «Taxodiaceae» can be changed to «Taxodium» or «Taxodium-type» in most situations. If «Cupressaceae» was also identified, then it should be changed to «Cupressaceae undiff.» or possibly «Juniperus-type» if other Cupressaceae such as Chamaecyperus are unlikely.

rank change: species reduced to subspecific rank

heterotypic or subjective synonym; a species has been reduced to a subspecies or variety of another species. These synonyms may be treated in two different ways, depending on the situation or protocols of the contributing data cooperative: (1) The taxon is reduced to the subspecific rank (e.g. Alnus fruticosa = Alnus viridis subsp. fruticosa, Canis familiaris = Canis lupus familiaris), either because the fossils can be assigned to the subspecies based on morphology, as is likely the case with the domestic dog, Canis lupus familiaris, or because the subspecies can be assigned confidently based on biogeography. (2) The taxon is changed to the new taxon and the subspecific rank is dropped because the fossil is not distinguishable at the subspecific level. For example, Alnus rugosa = Alnus incana subsp. rugosa, but may simply be changed to Alnus incana because the pollen of A. incana subsp. rugosa and A. incana subsp. incana are indistinguishable morphologically.

rank change: genus reduced to subgenus

heterotypic or subjective synonym; a genus has been reduced to subgeneric rank in another family. At the generic level, this synonymy is clear from the naming conventions, e.g. Mictomys = Synaptomys (Mictomys); however, at the species level it is not, e.g. Mictomys borealis = Synaptomys borealis.

rank change: family reduced to subfamily

heterotypic or subjective synonym; a family has been reduced to subfamily rank in another family. By botanical convention the family name is retained, e.g. Pyrolaceae = Ericaceae subf. Monotropoideae; whereas by zoological convention it is not, e.g. Desmodontidae = Desmodontinae.

rank change: subspecific rank elevated to species

heterotypic or subjective synonym; a subspecies or variety has been raised to the species rank, e.g. Ephedra fragilis subsp. campylopoda = Ephedra foeminea.

rank change: subgeneric rank elevated to genus

heterotypic or subjective synonym; a subgenus or other subgeneric rank has been raised to the generic rank. At the subgeneric level, this synonymy is clear from the naming conventions, e.g. Potamogeton subg. Coleogeton = Stuckenia; however, at the species level it is not, e.g. Potamogeton pectinatus = Stuckenia pectinata.

rank change: subfamily elevated to family

heterotypic or subjective synonym; a subfamily has been raised to the family rank, e.g. Liliaceae subf. Amaryllidoideae = Amaryllidaceae, Pampatheriinae = Pampatheriidae.

rank elevated because of taxonomic uncertainty

because the precise taxonomic identification is uncertain, the rank has been raised to a level that includes the universe of possible taxa. A common cause of such uncertainty is taxonomic splitting subsequent to the original identification, in which case the originally identified taxon is now a much smaller group. For example, the genus Psoralea has been divided into several genera; the genus Psoralea still exists, but now includes a much smaller number of species. Consequently, in the database Psoralea has been synonymized with Fabaceae tribe Psoraleeae, which includes the former Psoralea sensu lato. A zoological example is Mustela sp. The genus Mustela formerly included the minks, which have now been separated into the genus Neovison. Consequently, Mustela sp. = Mustela/Neovison sp.

globally monospecific genus

Although identified at the genus level, specimens assigned to this genus can be further assigned to the species level because the genus is monospecific.

globally monogeneric family

although identified at the family level, specimens assigned to this family can be further assigned to the genus level because the family is monogeneric.

1
2
3
4
5
6
7

SELECT Synonyms.SynonymName, Taxa.TaxonName, Publications.Citation,
Synonyms.Notes

FROM Publications INNER JOIN (Taxa INNER JOIN Synonyms ON Taxa.TaxonID =
Synonyms.TaxonID) ON Publications.PublicationID = Synonyms.PublicationID

WHERE (((Synonyms.SynonymName)="Bison alleni"));

Taxa¶

This table lists all taxa in the database. Most taxa are biological taxa; however, some are biometric measures and some are physical parameters.

TaxonID (Primary Key)

An arbitrary Taxon identification number.

TaxonCode

A code for the Taxon. These codes are useful for other software or output for which the complete name is too long. Because of the very large number of taxa, codes can be duplicated for different Taxa Groups. In general, these various Taxa Groups are analyzed separately, and no duplication will occur within a dataset. However, if Taxa Groups are combined, unique codes can be generated by prefixing with the TaxaGroupID, For example, VPL:Cle (Clethra) and MAM:Cle (Clethrionomys)

A set of conventions has been established for codes. In some cases conventions differ depending on whether the organism is covered by rules of botanical nomenclature (BN) or zoological nomenclature (ZN).

Genus

Three-letter code, first letter capitalized, generally the first three unless already used: Ace (Acer) or Cle (Clethrionomys).

Subgenus

The genus code plus a two-letter subgenus code, first letter capitalized, separated by a period: Pin.Pi (Pinus subg. Pinus) or Syn.Mi (Synaptomys (Mictomys)).

Species

The genus code plus a two-letter, lower-case species code, separated by a period: Ace.sa (Acer saccharum), Ace.sc (Acer saccharinum), or Cle.ga (Clethrionomys gapperi)

Subspecies or variety

The species code a two-letter, lower-case subspecies code, separated by a period: Aln.vi.si (Alnus viridis subsp. sinuata), or Bis.bi.an (Bison bison antiquus)

Family

Six-letter code, first letter capitalized, consisting of three letters followed by «eae» (BN) or «dae» (ZN): Roseae (Rosaceae), or Bovdae (Bovidae)

Subfamily or tribe

(BN) Family code plus two-letter subfamily code, first letter capitalized, separated by a period. (ZN) Six-letter code, first letter capitalized, consisting of three letters followed by «nae»: Asteae.As (Asteraceae subf. Asteroideae), Asteae.Cy (Asteraceae tribe Cynarea), or Arvnae Arvicolinae.

Order

(BN) Six-letter code, first letter capitalized, consisting of three letters followed by «les». (ZN) Six-letter code, first letter capitalized, consisting of three letters, followed by the last three letters of the order name, unless the order name is ≤6 letters long, in which case the code = the order name. Zoological orders do not have a common ending: Ercles (Ericales), Artyla (Artiodactyla), or Rodtia (Rodentia).

Taxonomic levels higher than order

Six-letter code, first letter capitalized, consisting of three letters, followed by the last three letters of the order name, unless the order name is ≤6 letters long, in which case the code = the order name: Magida (Magnoliopsida), Magyta (Magnoliophyta), or Mamlia (Mammalia).

Types

The conventional taxon code followed by «-type»: Aln.in-t (Alnus incana-type), Amb-t (Ambrosia-type)

cf.

«cf. » is placed in the proper position: Odc.cf.he (Odocoileus cf. O. hemionus), cf.Odc.he (cf. Odocoileus hemionus), or cf.Odc (cf. Odocoileus).

aff.

«aff. » is abbreviated to «af. »: af.Can.di (aff. Canis dirus)

?

«?» is placed in the proper position. ?Pro.lo (?*Procyon lotor*)

Alternative names

A slash is placed between the conventional abbreviations for the alternative taxa: Ost/Cpn (Ostrya/Carpinus), or Mstdae/Mepdae (Mustelidae/Mephitidae)

Undifferentiated taxa

(BN) «.ud» is added to the code. (ZN) «.sp » is added to the code: Aln.ud (Alnus undiff.), Roseae.ud (Rosaceae undiff.), Mms.sp (Mammuthus sp.), or Taydae.sp (Tayassuidae sp.).

Parenthetic modifiers

The conventional taxon code with an appropriate abbreviation for the modifier separated by periods. Multiple modifiers also separated by periods. Abbreviations for pollen morphological modifiers follow Iversen and Troels-Smith (1950): Raneae.C3 (Ranunculaceae (tricolpate)), Raneae.Cperi (Ranunculaceae (pericolpate)), Pineae.ves.ud (Pinaceae (vesiculate) undiff.), Myteae.Csyn.psi (Myrtaceae (syncolpate, psilate)), Bet.>20µ (Betula (>20 µm))

Non-biological taxa

Use appropriate abbreviations: bulk.dens (Bulk density), LOI Loss-on-ignition, Bet.pol.diam (Betula mean pollen-grain diameter).

TaxonName

Name of the taxon. Most TaxonNames are biological taxa; however, some are biometric measures and some are physical parameters. In addition, some biological taxa may have parenthetic non-Latin modifers, e.g. «Betula (>20 µm)» for Betula pollen grains >20 µm in diameter. In general, the names used in Neotoma are those used by the original investigator. In particular, identifications are not changed, although Dataset notes can be added to the database regarding particular identifications. However, some corrections and synonymizations are made.

These include:

• Misspellings are corrected.
• Nomenclatural, homotypic, or objective synonyms may be applied. Because these synonyms unambiguously refer to the same taxon, no change in identification is implied. For example, the old family name for the grasses «Gramineae» is changed to «Poaceae».
• Taxonomic, heterotypic, or subjective synonyms may be applied if the change does not effectively assign the specimen to a different taxon. Although two names may have been based on different type specimens, if further research has shown that these are in fact the same taxon, the name is changed to the accepted name. These synonymizations should not cause confusion. However, uncritical synonymization, although taxonomically correct, can result in loss of information, and should be avoided. For example, although a number of recent studies have shown that the Taxodiaceae should be merged with the Cupressaceae, simply synonymizing Taxodiaceae with Cupressaceae may expand the universe of taxa beyond that implied by the original investigator. For example, a palynologist in the southeastern United States may have used «Taxodiaceae» to imply «Taxodium», which is the only genus of the family that has occurred in the region since the Pliocene, but used the the family name because, palynologically, Taxodiuim cannot be differentiated from other Taxodiaceae. However, well preserved Taxodium pollen grains can be differentiated from the other Cupressaceous genera in the regin, Juniperus and Chamaecyperus. Thus, the appropriate synonymization for «Taxodiaceae» in this region would be «Taxodium» or «Taxodium-type», which would retain the original taxonomic precision. On the other hand, the old «TCT» shorthand for «Taxodiaceae/Cupressaceae/Taxaceae» now becomes «Cupressaceae/Taxaceae» with no loss of information.
• For alternative taxonomic desginations, the order may be changed. For example, «Ostrya/Carpinus» would be substituted for «Carpinus/Ostrya».

The database has a number of conventions for uncertainty in identification. The uncertainty is included in the taxon name. Thus, «Acer pensylvanicum» and «Acer cf. A. pensylvanicum» are two different taxa.

cf.

Latin confer, which means compare. In taxonomy «cf. » generally means that the specimen compares well to or is similar to the type referred, but the identification is uncertain. Uncertainty may arise for a number of reasons. The specimen may not be well preserved. It may be nondescript. There may be other similar taxa that can not be ruled out. The analyst may not have access to a complete reference or comparative collection for the group, so other related taxa cannot be excluded with certainty.

For uncertainty at the species level, the convention in Neotoma is, for example, «Odocoileus cf. O. hemionus», not «Odocoileus cf. hemionus». Placement of «cf. » is important, because it indicates the taxonomic level of uncertaintly. For example, «Odocoileus cf. O. hemionus» implies that the identification of Odocoileus is secure, but that the species identification is not; whereas «cf. Odocoileus hemionus» implies that not even the genus identification is certain. A further implication in the latter example is that if the genus identification is correct, then the the specimen must also be that species, perhaps because of biogeographic considerations. Although commonly overlooked, it is also important to indicate the proper level of uncertainly in family-genus identifications. For example, «Brassicaceae cf. Brassica» implies that assignment to the Brassicaceae is secure; whereas simply «cf. Brassica» does not indicate that even the family identification is certain.

In FAUNMAP, the uncertainty is recorded in a separate field from the taxon name, and for species it is not discernable whether the uncertainty is at the genus or species level. When data were imported from FAUNMAP, the «cf. » uncertainty was conservatively assigned to the genus level. Thus, if «Bison bison» was indicated to have «cf. » uncertainty, this record was imported as «cf. Bison bison» rather than «Bison cf. B. bison». However, in many cases, the uncertainty in the original data was probably at the species level.

aff.

«aff. » Latin affinis, which means having affinity with, but distinct from, the referred taxon. This desgination is often applied to a taxon thought to be undescribed. Thus, «aff. Canis dirus» implies an affinity to Canus dirus, but the specimen is likely from another species.

?

«?» is used to designate a questionable identification. It may indicate even less certainty than «cf. ». An example is «?Procyon lotor».

Types

Many pollen taxa are designated as types, e.g. «Ambrosia-type». A type denotes a morphological type that is consistent with the referred taxon, but also includes other taxa that are palynologically indistinguishable. For example, «Ambrosia-type» includes Ambrosia and Iva axillaris. The referred name commonly indicates the sporophyte taxon thought to be the most probable source of the pollen. An analyst may choose a «-type» designation referring to a lower taxonomic rank rather than an inclusive higher taxonomic rank because the referred taxon is thought to be the source taxon with very high probability. For example, in eastern , Pinus strobus is the only species of Pinus subg. Strobus, although several other species of this subgenus occur in western . Consequently, some analysts refer to «Pinus strobus-type» rather than «Pinus subg. Strobus». Ideally, a type would comprise a well defined universe of taxa, but in practice types are often vaguely defined. For example, in eastern «Populus balsamifera-type» includes a large proportion of P. balsamifera and probably smaller proportions of P. tremuloides, P. grandidentata, and P. deltoides; whereas «Populus tremuloides-type» includes larger proportions of these latter three species and a smaller proportion of P. balsamifera. However, these proportions are ill-defined.

Alternative taxonomic designations

In some cases, fossil specimens of two taxa are indistinguishable and are more-or-less equally likely. The names can then be separated by a slash, e.g. «Ostrya/Carpinus», «Mustelidae/Mephitidae». If one taxon is more likely, the analyst may choose to use a «-type» designation instead, e.g. «Ostrya-type». Although the order of alternative names may be changed by the database, a «-type» designation is not substituted for alternatives. However, the use of more two alternatives is discouraged. In cases in which taxonomic revisions have reduced the number of speices within a taxon, the original universe of species may be retained with the slash designation. An example is «Mustelidae», which in older literature included the skunks, which have now been placed in their own family the Mephitidae; thus «Mustelidae/Mephitidae» retains the original set of possible taxa.

Undifferentiated taxa

Lower taxonomic ranks may not be differentiated. The convention among palynologists is to specify these by the suffix «undiff. ». Thus, «Rosaceae undiff.» designates undifferentiated Rosaceae. However, palynologists have inconsistently applied the «undiff.» appellation, and the pollen databases established a convention that taxa must be mutually exclusive within a dataset. Thus, if a higher-rank taxon is present in a dataset, the «undiff.» suffix is applied only if lower-rank taxa are also present. For example, if «Spiraea» occurs in a dataset, «Rosaceae» would be changed to «Rosaceae undiff.», because Spiraea is a genus in the family Rosaceae. On the other hand, if «Rosaceae undiff.» occurs with no other Rosaceae, then «Rosaceae undiff.» is changed to simply «Rosaceae»; it is implicit that the family is not differentiated.

Faunal analysts customarily use the appellation «sp.» to designate undifferentiated taxa. Thus, «Microtus sp.» indicates undifferentiated Microtus. In addition, faunal analysts regularly use the «sp.» designation even when no lower-rank taxa are identified. The «sp.» appellation is most frequently used with genera. The principle of taxonomic mutual exclusivity has not been applied to fauanl datasets, although it should probably be considered.

Author

Author(s) of the name. Neither the pollen database nor FAUNMAP stored author names, so these do not currently exist in Neotoma for plant and mammal names. These databases follow standard taxonomic references (e.g. Flora of North America, Flora Europaea, Wilson and Reeder’s Mammal Species of the World), which, of course, do cite the original authors. However, for beetles, the standard practice is to cite original author names; therefore, this field was added to Neotoma.

HigherTaxonID

The TaxonID of the next higher taxonomic rank, for example, the HigherTaxonID for «Bison» is the TaxonID for «Bovidae». For «cf.’s» and «-types», the next higher rank may be much higher owing to the uncertainty of the identification; the HigherTaxonID for «cf. Bison bison» is the TaxonId for «Mammalia». The HigherTaxonID implements the taxonomic hierarchy in Neotoma.

Extinct

Boolean (True/False) variable. The value is True if the taxon is extinct, False if extant.

TaxaGroupID (Foreign Key)

The TaxaGroupID facilitates rapid extraction of taxa groups that are typically grouped together for analysis. Some of these groups contain taxa in different classes or phyla. For example, vascular plants include the Spermatophyta and Pteridophyta; the herps include Reptilia and Amphibia; the testate amoebae include taxa from different phyla. Field links to the TaxaGroupTypes table.

PublicationID (Foreign Key)

Publication identification number. Field links to the Publications table.

Notes

Free form notes or comments about the Taxon.

TaxaGroupTypes¶

Lookup table for Taxa Group Types. This table is referenced by the Taxa table.

TaxaGroupID (Primary Key)

A three-letter Taxa Group code.

TaxaGroup

The taxa group. Below are some examples:

TaxaGroupID	TaxaGroup
AVE	Birds
BIM	Biometric variables
BRY	Bryophytes
BTL	Beetles
...	...
FSH	Fish

Variables¶

This table lists Variables, which always consist of a Taxon and Units of measurement. Variables can also have Elements, Contexts, and Modifications. Thus, the same taxon with different measurement units (e.g. present/absent, NISP, MNI) are different Variables.

VariableID (Primary Key)

An arbitrary Variable identification number.

TaxonID (Foreign Key)

Taxon identification number. Field links to the Taxa table.

VariableElementID (Foreign Key)

Variable Element identification number. Field links to the VariableElements lookup table.

VariableUnitsID (Foreign Key)

Variable Units identification number. Field links to the VariableUnits lookup table.

VariableContextID (Foreign Key)

Variable Context identification number. Field links to the VariableContexts lookup table.

VarialbeModificationID (Foreign Key)

Variable Modification identification number. Field links to the VariableModifications lookup table.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

SELECT Taxa.TaxonName, VariableElements.VariableElement,
VariableUnits.VariableUnits

FROM VariableUnits INNER JOIN (VariableElements INNER JOIN (Taxa INNER
JOIN Variables ON Taxa.TaxonID = Variables.TaxonID) ON
VariableElements.VariableElementID = Variables.VariableElementID) ON
VariableUnits.VariableUnitsID = Variables.VariableUnitsID

GROUP BY Taxa.TaxonName, VariableElements.VariableElement,
VariableUnits.VariableUnits

HAVING (((Taxa.TaxonName)="Zea mays"));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

SELECT Taxa.TaxonName, VariableElements.VariableElement, Sites.SiteName

FROM VariableElements INNER JOIN (Sites INNER JOIN (CollectionUnits
INNER JOIN (Datasets INNER JOIN (Samples INNER JOIN ((Taxa INNER JOIN
Variables ON Taxa.TaxonID = Variables.TaxonID) INNER JOIN Data ON
Variables.VariableID = Data.VariableID) ON Samples.SampleID =
Data.SampleID) ON Datasets.DatasetID = Samples.DatasetID) ON
CollectionUnits.CollectionUnitID = Datasets.CollectionUnitID) ON
Sites.SiteID = CollectionUnits.SiteID) ON
VariableElements.VariableElementID = Variables.VariableElementID

GROUP BY Taxa.TaxonName, VariableElements.VariableElement,
Sites.SiteName

HAVING (((Taxa.TaxonName)="Zea mays") AND
((VariableElements.VariableElement)="pollen"));