Pollen Database Manual EUROPEAN POLLEN DATABASE NORTH AMERICAN POLLEN DATABASE 03 August 1993 1. Introduction 1 1.1. Overview 1 1.2. History 1 1.3. Database Administration 2 1.3.1. European Pollen Database 2 1.3.2. North American Pollen Database 3 1.4. Cooperating Database Projects in Europe 3 2. The Database Management System: Paradox 3 2.1. Overview of Paradox 3 2.1.1. Features 4 2.1.1.1. PC based, hardware requirements 4 2.1.1.2. Forms, reports, scripts 4 2.1.1.3. Table creation, naming tables and fields 4 2.1.2. Data types 5 2.1.3. Keys 5 2.1.4. Configuration to International Sort Order 5 2.1.5. Limitations 5 2.1.6. Common disk directory structure 6 3. The entry of pollen data using Tilia 6 3.1. Requirements, source, and cost 6 3.2. The Tilia Software Package 7 3.2.1. Data entry and importation of data into Tilia 7 3.2.2. Using a master dictionary to create a taxon list 7 3.3. Transferring data between the database and Tilia 8 4. Conventions adopted for the databases 8 4.1. Place names 8 4.2. IGCP-type regions (EPD) 8 4.3. Bibliographic conventions 9 4.4. Alphanumeric data storage 9 4.5. Typographical errors 9 4.6. Italic and bold text 9 4.7. Special characters 9 4.8. Dummy values 9 4.9. The use of terminating punctuation 9 4.10. "Notes" tables 9 5. Differences between the European and North American databases 9 5.1. Internal code numbers 9 5.2. Taxonomy, nomenclature, and synonymy 9 5.3. Restrictions on the use of data 11 6. Overview of the Pollen Database Structure 11 6.1. Categories of Tables 11 6.2. Pollen v. Macrofossil data 11 6.3. Core Tables 11 7. References 12 8. Database Tables and Field Descriptions 12 8.1. Archival Tables 13 WORKERS 13 ADDRESS 13 SITELOC 14 SITEDESC 15 SITEINFO 15 ENTITY 16 P_ENTITY 17 COREDRIV 18 SECTION 18 ENTITY&& 19 GEOCHRON 19 AAR 20 C14 20 ESR 21 FT 21 KAR 22 PB210 22 TL 23 USERIES 23 SYNEVENT 24 EVENT 24 ALSEGS 25 P_ANLDPT 25 DATING&& 26 P_PREP&& 26 P_VARS 27 P_SAMPLE 28 P_COUNTS 29 LITHOLGY 30 LOI 30 PUBL 31 PUBLCIT 31 PUBLENT 32 AUTHORS 32 8.2. Lookup and Referral Tables 33 POLDIV1 33 POLDIV2 33 POLDIV3 33 INFOTYPE 34 DESCR 35 RATIONAL 36 IGCPTYPE 36 8.3. Research Tables 37 P_GROUP 37 GROUPS 37 CHRON 38 AGEBASIS 38 CHRON&& 39 P_AGEDPT 39 P_VTRANS 40 8.4. System Tables 41 SYSIDN 41 SYSCAT 41 SYSCOL 41 SYSIDX 42 SYSFKS 42 DBLOG 43 DBACT 43 DBENT 43 8.5. Views 44 P_VARIS 44 DESCRIS 44 DATATYPS 45 1. Introduction 1.1. Overview This manual is guide to the European and North American Pollen Databases (EPD and NAPD). Initiatives to develop pollen databases on the two continents began about the same time, and close collaboration has developed to make the two databases compatible. As a result of this collaboration, the databases have the same file structure, and are designed so that any software developed will work with either database. The databases, however, have independent internal numbering systems for sites, variables (pollen- types), and other items. Thus, a pollen-type such as Quercus, which occurs on both continents, has different system numbers in the two databases. The database software is Paradoxr from Borland International, which runs on IBM PC or compat- ible computers. The databases are intended to be both archives of pollen and associated data as well as important research tools for studies in pa- laeoecology and palaeoclimatology. 1.2. History Before the initiation of the NAPD/EPD, Thompson Webb III at Brown University had already assembled a substantial database of pollen counts from North America as part of the Cooperative Holocene Mapping Project (COHMAP). In Europe, Brian Huntley and John Birks had assembled pollen-percentage data at given time intervals, which they used for their atlas (Huntley and Birks 1983). These databases have been used for many valuable palaeoclimatic and palaeoecological studies, culminating in the COHMAP paper in Science (COHMAP Members 1988). Such studies have demonstrated not only the extreme value of the pollen databases, but also the need for greater accessibility and completeness. Also of concern are the long-term archiving and curation of pollen data, which are usually published in only summary or graphical form and whose collection is highly labor intensive. These needs and concerns fostered the creation of the North American and European Pollen Databases. The need for a European pollen database was discussed during the closing session of the Inter- national Geological Correlation Programme (IGCP) 158B project in Krakow, Poland, in June 1988. Following these preliminary discussions, Bjrn Berglund (Lund, Sweden) and George Jacobson (University of Maine, USA), who was on sabbatical in Lund, agreed to coordinate a workshop to discuss the establishment of a Euro- pean database. Independently, participants in a meeting of the European Commission Palaeocli- mate Program reached a similar conclusion in Le Puy, France, in September 1987. Joel Guiot (Marseille, France), Brian Huntley (Durham, England) and Colin Prentice (Uppsala, Sweden) agreed to initiate the process. In North America, Eric Grimm (Illinois State Museum) had been having conversations with Tom Webb concerning the curation and fate of the COHMAP pollen da- tabase, including preliminary discussions of a grant proposal, although no action had been taken. In May 1989, Berglund, Grimm, Guiot, Huntley, and Jacobson met and organized a meeting for the following August in Frostavallen, Sweden, which palynologists from 18 European countries attended. Although the participants agreed upon the importance of a database, several researchers brought forth a variety of practical and ethical problems, some of which had been discussed the previous June at the 12th European Quaternary Botanists meeting in Czechoslovakia. The Frostavallen meeting also discussed practical problems concerning the housing and financial support of such a database. Armand Pons and colleagues Joel Guiot and Jacques-Louis de Beaulieu (Marseille) presented a proposal, which was subsequently adopted, for housing the database at a new Centre Universitaire d'Arles in the Monastery of St. Trophime in Arles, near Marseille. The meeting appointed an Executive Committee, composed of Brigitta Ammann (Bern, Switzerland), Armand Pons, and W. A. Watts (Dublin, Ireland), who were primarily responsible for seeking funds. An Advisory Board was also appointed to help with regional and taxonomic questions and to consider the ethics of the use of data in the database. Armand Pons succeeded in obtaining finan- cial support for a database from the European Commission's EPOCH Program, which is focused upon global climate change during the last 30,000 years. The funding period is July 1990 to July 1993 and a sum of 105,000 ECU was obtained by the University of Marseille to develop a centre at Arles. The Marseille group also obtained from the Conseil Regional de Provence-Cote d'Azur approximately 250,000 FFr for the purchase of computer and office equipment. Independently, Brian Huntley received a grant from the U. K. Natural Environment Research Council to support data compilations in Durham for the late-glacial and in Cambridge for the last interglacial. These compilations were intended to be contributions towards the central database and would be carried out in close collaboration with the database centre in Arles. Additional funds from the EPOCH program would also facilitate this collaboration. In addition, Brigitta Ammann and colleagues from the Alpine region had organized an Alpine Pollen Database with funds from a Swiss NSF project on long-term vegetation dy- namics in the Alps. The EPD Advisory Board and Executive Committee met in Wilhelmshaven, Germany, in September 1990. The aims of this meeting were to resolve some of the practical problems in- volved in starting the database, to discuss further the ethical problems raised at Frostavallen, and to propose an organisational structure and protocols for the database. Discussions centered on the structure of the database, taxonomy, synonymy, evaluation of radiocarbon dates, linguistic difficulties, and the motivation for the database development. It was agreed that the central database would cooperate with those desiring to develop regional databases, and that these in turn would serve as conduits to the central database. At the end of the meeting, Armand Pons and W. A. Watts resigned from the Executive Committee and nominated Jacques- Louis de Beaulieu and Brian Huntley as their successors, which the Advisory Board accepted. In the United States, the National Oceanic and Atmospheric Administration (NOAA) initiated a Paleoclimatology Program in its agency the National Geophysical Data Center (NGDC) as part of its Climate and Global Change Program. NOAA/NGDC appointed a Paleoclimate Advisory Panel, whose mission was to make recommendations for the future of the Paleoclimatology Program. The Panel met for the first time in June 1989 and recommended that acquisition of palaeoclimate proxy data be a major priority. It further recommended that experts in the various fields should manage the data acquisition, rather than NGDC itself. The Panel identified the following data areas: (1) pollen/packrat midden/macrofossil data, (2) tree-ring data, (3) marine and lacustrine sediments, (4) documentary and long instrumental data sets, (5) ice core and glacier records, (6) paleoclimate model output, and (7) hydrology/stream/lake-level data. Pursuant to these recommendations, NOAA/NGDC solicited proposals for development of databases. Eric Grimm submitted a successful proposal for the development of the North American Pollen Database. The project began in August 1990. John Keltner was employed as the Database designer/programmer, and he has had major responsibility for development of database software for both the NAPD and EPD. The NAPD also has an Advisory Board of palynologists representing different geographic regions and with a broad range of expertise. Keltner and Grimm created an initial design for the database, which they presented to the first NAPD Advisory Board Meeting in November 1990. In January 1991, Grimm and Keltner met with several technical advisors and coordinators of the EPD (Brigitta Ammann, J.-L. de Beaulieu, John Birks, Sytze Bottema, Mike Field, Annabel Gear, Joel Guiot, Brian Huntley, Steve Juggins) in Arles. This workshop resulted in substantial modification of the database structure to accommodate both North American and European idiosyncrasies, as well as to accommodate other kinds of data, such as plant macrofossils, and diatoms. The participants agreed that any future modifications would be made to both databases after joint consultation. 1.3. Database Administration 1.3.1. European Pollen Database Location Centre Universitaire d'Arles, Arles, France Coordinators J.-L. de Beaulieu Joel Guiot Postdoctoral Scientist Rachid Cheddadi Executive Committee J.-L. de Beaulieu, Marseille, France Brian Huntley, Durham, England Brigitta Ammann, Bern, Switzerland Advisory Board Karl-Ernst Behre, Wilhelmshaven, Germany H. J. B. Birks, Bergen, Norway Elizaveta Bozilova, Sofia, Bulgaria Maria Follieri, Rome, Italy M.-J. Gaillard-Lemdahl. Lund, Sweden George L. Jacobson Jr., Orono, Maine, USA C. R. Janssen, Utrecht, Netherlands Meilute Kabailiene, Vilnius, Lithuania M. Ralska-Jasiewiczowa. Cracow, Poland 1.3.2 North American Pollen Database Location Illinois State Museum, Springfield, Illinois Administrator Eric C. Grimm Designer/Programmer John Keltner Advisory Board Konrad J. Gajewski, Universit Laval George L. Jacobson Jr., University of Maine Glen M. MacDonald, McMaster University Louis J. Maher, University of Wisconsin Vera Markgraf, INSTAAR Pierre Richard, Universit de Montral Thompson Webb III, Brown University Cathy Whitlock, University of Oregon 1.4. Cooperating Database Projects in Europe 1. Eastern Mediterranean database coordinated by Sytze Bottema (Groningen) as part of the EPOCH project on Global climate change of the last 30,000 years. 2. 9000-15,000 B.P. ('late-glacial') of Europe coordinated by Annabel Gear and Brian Huntley (Durham) as part of their project on European Palaeoclimate during the last deglaciation. 3. Last interglacial of Europe coordinated by Mike Field (Cambridge), Phil Gibbard (Cambridge) and Brian Huntley, as part of their project on Palaeoclimate and vegetation develop- ment during the last interglacial in Europe. 4. The Alpine Database, which is part of a larger project focused on long-term vegetational dynamics in the Alps and immediate surroundings coordinated by Brigitta Ammann, H. J. B. Birks, Otto Hegg (Bern), Steve Juggins (London), Felix Kienast (Zurich), and Pim van der Knapp (Bern). This database was conceived before the EPD and was not originally designed to be an integral component of it. However, it is attempting to achieve compatibility with the EPD in terms of database design and software, 2. The Database Management System: Paradoxr 2.1. Overview of Paradox Paradox from Borland International is a Re- lational Database Management System (RDBMS) for MS-DOS based microcomputers. An RDBMS is one that claims adherence to the relational model of data management (see Codd 1970, 1985, 1990; Date 1990). Users of an RDBMS perceive their data as a set of tables, and only as a set of tables. Tables represent classes of real-world objects; they are the familiar two-dimensional structures consisting of columns (or fields) that contain exactly one type of information and rows (or records) that represent individual instances of the table class. For example, a table designed to store information about sites and their locations might contain columns for the site's name, its latitude, and its longitude. Individual rows in this table would then store the name, latitude, and longitude for a single site; each row is an instance of the site-location class. Every row in an RDBMS table should be unique. Thus, some set of values, drawn from one or more columns, should distinguish each row from all other rows. The set of columns whose values uniquely identify each row in a table defines the primary key for that table. The combination of table name, column name, and primary key gives each cell in a table a unique address. The columns comprising the primary key are specified when a table is first created. With Paradox, this is done by listing the primary key columns in sequence at the top of the table and adding an asterisk to each column's data type specification (see below). If a primary key is subsequently modified, any duplicate rows (rows with identical values in each of their primary key columns) are removed from that table and placed in a new table named, KEYVIOL. This last point illustrates a fundamental prop- erty of an RDBMS, namely that all operations produce new tables from old ones. To create or modify a table, you specify its structure in a STRUCT table. Modifying the structure of a table may, as noted above, produce a KEYVIOL table. Viewing a table produces a read-only copy of that table. Editing a table produces a copy of that table that will replace the existing table when you make the changes final (when you DO_IT!, in Paradox). Querying a database produces an ANSWER table. Deleting rows from a table using a query form produces a new table with the deleted rows removed to a DELETED table. Any of these tables, except STRUCT, may be empty (contain zero rows). 2.1.1. Features 2.1.1.1. PC based, hardware requirements Paradox version 3.5 runs on any 100% IBM- compatible personal computer with one hard disk and a floppy drive, with >= 512 kb or more of internal memory (RAM), MS-DOS >= 2.0 and a monochrome or colour monitor. 2.1.1.2. Forms, reports, scripts Paradox provides tools for organising the collection, retrieval, and display of data. These tools include report and forms generators, and a programming language that is an extension of the Paradox interface and whose scripts (programs) are played (run) from the interface. Forms allow a user to see only the data needed for a particular task, whether that task is data entry, editing, or merely viewing. This keeps the actual complexity of the database out of sight and out of the way. A form may contain selected information from one or more tables, text for titles or prompts, display only or calculated fields. With forms, the presentation of the database becomes more consistent and reli- able. Reports are the means for producing printed output of selected data in the database. Paradox reports may be arranged in almost any manner. They may include titles and other text, calculated fields, groupings, and much more. Users can de- sign custom reports or use defaults. Custom re- ports can be saved and reused or modified. Scripts are executable programs written in PAL (the Paradox Application Language). Play- ing a script may invoke a complete, complex application or a simple, keystroke-saving macro. The former is created using a text editor and PAL commands, whereas the latter are usually created using Paradox's macro recording capabilities. Scripts have an important role in providing an interface between the user and the underlying database. Common tasks should always be placed under the control of tested and trusted scripts. Like forms, scripts provide the user with a consistent and helpful interface that restricts the view of the database to just those data required to complete a given task. With scripts, data can be filtered (for example, converted to all uppercase) where appropriate, saving the user from having to remember details of data formatting. Scripts have a further role in database maintenance: they can help protect the database from inadvertent errors. Simple changes often have side-effects that are easily overlooked when directly manipulating the tables. Scripts are the best way to remember such side-effects. Lastly, although a poorly written script can corrupt the database as thoroughly as any user, repairing the damage caused by a script is easier since the nature of the damage is more readily assessed. All routine interactions with the database should be mediated with PAL scripts. 2.1.1.3. Table creation, naming tables and fields A table is created by assigning it a name and then listing the names and data types of each of its columns. To Paradox, table names are one to eight, alphanumeric characters, and follow the rules for MS-DOS file names; case is ignored. Column names may be up to 25 alphanumeric characters in length, embedded spaces are al- lowed; again, names are not case sensitive. 2.1.2. Data types The database structure is documented table by table in section 8, below. For each table the fields are listed, along with an indication of their data type and brief indication of what they contain. Data types (also called field types) must be one of the following: S = a short integer (-32766 <= x <= 32767). N = a floating point number (15 significant digits, 10-307 <= x <= 10+308 ) An = an alphanumeric string with a fixed length of n characters (1 <= n <= 255). The string can include letters, numbers, and special symbols. D = a date between 1 Jan 100 and 31 Dec 9999. $ = currency. These differ from floating point numbers only in their default display. 2.1.3. Keys All tables in the database have a Primary key. Additionally, some tables have Alternate and Foreign keys. Primary keys uniquely identify each row in a table; an Alternate key is any other column (or combination of columns) that could also uniquely identify each row; it is an alternate primary key. A Foreign key is any column (or combination of columns) whose non- null values are constrained to be values in the primary key of some table (possibly the same table). By way of example, the Pollen Database site location table (SITELOC) has a primary key made up of a single, integer-valued column (Site#). Paradox guarantees that the value in this column for every row in the table will be unique. SITELOC has a column for site name, whose values should also be unique; SiteName is an Al- ternate key. SITELOC also has a column, PolDiv1, that stores a code for the country where a site is located (e.g. USA). The non-null values in the PolDiv1 column are constrained to be values that currently exist as the primary key of some row in table POLDIV1 (i.e. there must be a record for USA in table POLDIV1). Column PolDiv1 is designated a foreign key referencing table POLDIV1. A table that meets all foreign key constraints is said to have referential integrity. Unfortunately, Paradox provides no direct support for maintaining alternate keys and referential integrity. 2.1.4. Configuration to International Sort Order Paradox arranges or selects records in a cer- tain order, which must be either: ASCII, Nor- wegian/Danish, Swedish/Finnish or International. By agreement, all pollen databases use International sort order. "In this sort order, capital, lowercase and special characters are combined into a unified sequence. This means that records are sorted according to their alphanumeric positions, regardless of case or diacritical marks. Characters representing ligatures are also sorted correctly (that is, as "ue")" p. 279 Paradox 3.5 Users Guide. Sort or- der affects the primary key ordering of records in a table, the ordering of records in the ANSWER table, the result of using the SORT command, and the answers to queries that use selection operators (<,>, <=, >=). It is essential that Paradox is configured to the International sort order during installation (see p. 31 of the Paradox 3.5 Users Guide) and that it is not changed thereafter. 2.1.5. Limitations Although Paradox has great advantages such as widespread availability, low-cost, and ease-of- use, it is not without its limitations as well. Chief among these are the lack of a central system catalogue for the database, no support for main- taining the consistency of alternate and foreign keys, and no provision for transaction logging or rollback. Unfortunately, these highly desirable features are currently available only on mini- and mainframe systems, and at a considerable price. The alternative to having such features built into an RDBMS is to emulate them with external software and to use this software diligently to check the status of the database. A system catalogue stores information about each table in the database. It stores information on the names, data types, and domains for each column. It stores information on a table's primary key as well as information on any alternate and foreign keys that a table has. A set of system tables (e.g. SYSCAT) have been created for the Pollen Database to stand-in for a DBMS-managed system catalogue. These tables, in conjunction with a set of system scripts provide Pollen Database administrators with the ability to check alternate and foreign key integrity, as well as the specifications of primary keys and column data types. Database Directory Structure C:\ |--... |--PDB ;parent directory for pollen database |--DB ;database tables (e.g. SITELOC.DB) |--DBV ;database views (e.g. P_VARIS.DB) |--DOC ;documentation files (e.g. PDM.DOC) |--EXE ;DOS executables (e.g. PD2TIL.EXE) |--SC ;parent directory for scripts |--CMN ;script modules used by many scripts (e.g. DTYPE.SC) |--DB ;base table scripts (e.g. PD2TIL.SC) |--... |--SYS ;system table scripts (e.g. CHECK_DB.SC) |--... |--SYS ;system tables (e.g. SYSCAT.DB) |--TMP ;temporary tables, error report files Transaction logging means keeping a record of all actions that affect the content of the data- base: every insertion, deletion, or update. The existence of such a log, obviously, greatly facilitates recovery from simple data entry errors or such catastrophes as power failures and file damage. A transaction is any series of actions on a database that must occur in its entirety or not at all. Should a transaction fail, for whatever reason, rollback means playing the log in reverse until the database is returned to its pre- transaction state. Implementing transaction logging and rollback in application software would be both complicated and time-consuming. Adding such a facility may be worth considering for the most routinely used or critical applications. Alternatively, frequent, incremental backups of the database may be a more appropriate and achievable solution - the worst catastrophes may then be limited to a few days lost work. 2.1.6. Common disk directory structure The database uses a standard directory struc- ture (the actual disk drive used is not mandated). 3. The entry of pollen data using Tilia 3.1. Requirements, source, and cost While the totality of pollen data is best man- aged using an RDBMS, the data for a single site are much more conveniently manipulated and displayed using the MS-DOS-based applications, Tilia and Tilia graph, written by Dr. Eric Grimm. This software requires an IBM PC or compatible computer, MS-DOS 3.0 or higher, 640 kb of conventional memory, and a graphics display for Tilia graph. Tilia is available free of charge; Tilia graph costs 250 US$. Both are available from Eric Grimm at the Illinois State Museum, Research and Collections Center, 1920 South 10 Street, Springfield, IL 62703, USA. 3.2. The Tilia Software Package The Tilia Software Package consists of a set of programs for manipulating, analyzing, and graphing stratigraphic data. The programs are particularly designed for pollen data, but can be used for a wide variety of stratigraphic, geologic, and ecological data. The programs are all menu driven. Tilia is a spreadsheet program designed es- pecially for stratigraphic data. Data can be en- tered, deleted, and easily rearranged. The user can define up to 26 different sums or groups, and percentages can be based on any sum. The program can read and write a variety of different ASCII formats, and the program will assign ages to levels by one of three options: linear interpolation, fitting a polynomial, or a spline curve. Radiocarbon or other ages can be entered. The program can also calculate concentrations and accumulation rates. A standard dictionary of variable names can be maintained. The dictionary can be loaded or linked, so that variable lists do not have to be repeatedly reentered. CONISS carries out cluster analysis according to the incremental sum of squares method (also known as Ward's method, minimum variance, error sums of squares). The analysis can be stratigraphically constrained and, therefore, a method for numerical zonation. The program is accessible from Tilia. CA performs correspondence analysis and detrended correspondence analysis. The program is accessible from Tilia. Tilia graph plots pollen diagrams or other stratigraphic data, and is accessible from Tilia. The program has a default format, and a spread- sheet of pollen frequencies can be viewed as a pollen diagram with only a few keystrokes. The user has a high degree control over the diagram format. Graphs may be plotted as silhouette curves, histograms, presence/absence, or raw numbers. Curves can be filled with a variety of patterns or depth bars, and exaggerated curves can also be plotted (the exaggeration is defined by the user). The user can define the width of histogram bars, which can be filled with a pattern. Cumulative or overlaid graphs can also be plotted. The user can scale both the horizontal and vertical axes; define major, minor, and labeled tic marks; and enter axis labels. If the data are plotted against depth, the program will optionally plot an age axis correctly scaled, or vice versa. Graph names can be plotted at any angle from 0 to 90 . Zone boundaries and labels can be plotted. A variety of fonts are available. 3.2.1. Data entry and importation of data into Tilia Tilia is able to read files that are in any of the following formats: Brown, Cambridge (POLLDATA output), Marseille, Minnesota and Wisconsin and WK1 or WKS. In addition, Ian Shennan of Durham University (England) has written a program that converts files input using his pollen program into Tilia format. The following instructions briefly describe how data that have previously been entered in POLLDATA format can be loaded into Tilia and assigned either the EPD or NAPD variable numbers (Var#): 1. At the DOS prompt type Tilia. 2. At the main menu choose option [D] "Load data file", [C] "Cambridge format", "Name of input file", e.g. MORRONE.CAM. 3. Option [E] "Load dictionary", [B] "Match dictionary to data", "Name of input file", e.g. EPD.DIC, and then [A] "Match to variable names". 4. Option [G] "Edit dictionary", edit the diction- ary inserting the correct numeric codes for synonyms, etc. Then use F4 to save the dic- tionary to a file, e.g. SITEDIC. After this step all numeric codes should be consistent with the EPD. 5. Option [E], "Load dictionary", "Name of dic- tionary", e.g. EPD.DIC, [B] "Match dictionary to data", [D] "Match numeric codes". 3.2.2. Using a master dictionary to create a pollen taxon list Before pollen data for an individual site can be entered into Tilia a pollen variable list needs to be compiled. Master dictionaries exist that include all the pollen variables listed in either the EPD (presently >1000 pollen variables) or the NAPD, and their associated numeric, 8 and 2 character codes. As most sites contain fewer than 120 pollen variables the spread sheet would be too cumbersome if these dictionaries were loaded into the spreadsheet. Providing that a master dictionary is present (e.g. EPD.DIC) then by using the following pro- cedures the necessary pollen variable names and their associated codes can be quickly compiled from the master dictionary for individual sites: 1. At the DOS prompt type Tilia. 2. At the main menu choose option [F] "Link dictionary". This does not actually load the dictionary into the spreadsheet, but makes it available to it. 3. Option [A] "Link TILIA dictionary", "Name of dictionary", e.g. EPD. 4. Option [A] "Spreadsheet". 5. To add a pollen type to the current spreadsheet, press F9, then either (1) enter the two-letter code, or (2) press F9, then either (a) enter the two-letter code, or (b) hit F9 again and a scrolling window appears for selecting the variable. The variable is then added to the spreadsheet with all its information, i.e. group code, name, etc. when you press Enter. 6. When in the current spread sheet use Ctrl + D to edit the dictionary. 3.3. Transferring data between the data- base and Tilia Paradox scripts are available for moving data between the Pollen Database and Tilia. These scripts, titled PD2TIL and TIL2PD, directly read data to and from Tilia .TIL file format. Note that TIL2PD uses the data in the .TIL file to replace existing data in the database, and that once re- placed, the existing information is not retrievable; no backups are made. Consult the latest Pollen Database Scripts Catalogue (PDSC) for announcements of current releases. 4. Conventions adopted for the data- bases 4.1. Place names Country names and codes follow the ISO standard (3166) for the representation of names of countries, dependencies and areas of special sovereignty and have been entered into table POLDIV1. In addition, GER has been assigned for Germany until a new code is officially as- signed by the Swiss National Bureau of Stan- dards. Codes for the new states in eastern Europe will be added when they become available. The NAPD second political subdivisions are states or provinces. Two character codes have been assigned from the U.S. Department of Commerce FIPS PUB 10-3. In Europe a list is currently being compiled of all the major political subdivisions of countries (i.e. Vice Counties in the UK., Dpartments in France etc.) and a map is being prepared that will depict the boundaries between each of these areas. Two character codes have begun to be assigned to these subdivisions and can be looked up in table POLDIV2. The NAPD third political subdivisions are counties or census areas. In Europe, minor politi- cal subdivisions (parishes, townships etc.) are so numerous that they are only being entered into the database as necessary. These codes can be found in table POLDIV3. 4.2. IGCP type regions (EPD) The International Geological Correlation Programme Project 158B subdivided the following countries into "type regions, which are uniform areas as regards geology, morphology, climate and biota" (Magdalena Ralska- Jasiewiczowa, 1986 p. 1): Austria, Belgium, Bulgaria, Czechoslovakia, Denmark, Finland, France, Germany, Great Britain, Greenland, The Netherlands, Norway, Poland, Sweden, Switzerland, and some areas of the USSR including Kola, Karelian, Estonia, Latvia, Lithuania, Belarus, Ukraine and Moldavia. The IGCP catalogue includes a series of maps which indicate the type region boundaries, and a set of codes which uniquely identify each region. These codes are cross-referenced to the look-up table IGCPTYPE. 4.3. Bibliographic conventions Bibliographic references will be entered and formatted following the conventions used in the journal Ecology. The Council of Biology Editors Style Manual is followed for details of style and presents "rules, rationale, principles, definitions and examples to assist in formulating biblio- graphic references from a wide variety of materi- als" (p. 55). 4.4. Alphanumeric data storage Alphanumeric codes (e.g. field PolDiv1 of table SITELOC) are uppercase. 4.5. Typographical errors Typographical errors in published data will be corrected when entered into the database. For example, a sampling device described as a "modified Livingston", will be entered as "modified Livingstone". 4.6. Italic and bold text Italic and bold text are presently unavailable in Paradox. To enter bibliographic references in Ecology format, italic or bold entries will be flagged as follows: Italic text: alt 174 et al alt 175 Bold text: alt 169 and alt 170. 4.7. Special characters It is sometimes necessary to use special char- acters when entering text or workers' names. A list of the ASCII special characters that are avail- able for data entry can be found on p. 280 of the Paradox 3.5 Users Guide. Notes are being made of characters that are not available . 4.8. Dummy values When data are not available the field may be temporarily flagged with a dummy or nominal value (e.g. "0" for latitude or longitude). 4.9. The use of terminating punctuation It is best that punctuation at the end of an en- try be omitted, as this can easily be inserted by the use of a script. This applies, for example, to the period at the end of the last line of the address. 4.10. "Notes" tables The Pollen Database provides several tables for storing general, catchall information that is otherwise not provided for in the design of the database. The names of these tables end with "&&". Notes are any number of 60 character lines of text, keyed to an entity. 5. Differences between the European and North American databases 5.1. Internal code numbers The database structure is the same for both the NAPD and the EPD. However, internal code numbers for sites (Site#), entities (E#), pollen variables (Var#), worker names (Worker#), and publications (Publ#) are independently assigned from Arles for the EPD and from Springfield for the NAPD. 5.2. Taxonomy, nomenclature, and synon- ymy Three kinds of synonymy exist: nomenclatu- ral, syntactic, and morphological. The Database has nomenclatural and syntactic conventions, and will substitute nomenclatural or syntactic syno- nyms for contributors' names that do no conform to these conventions. In general, the Database will not change names based on morphological synonymy. Nomenclatural synonymy refers to botanical nomenclature. The NAPD follows Cronquist (1981) and floras conforming to this authority, including Gleason and Cronquist (1991) and Flora of the Great Plains (1986), which cover the northeastern and central parts of the continent. The nomenclature of these floras has precedence over those used for other parts of the continent. Examples of nomenclatural synonymy in North America are Poaceae = Gramineae, Asteracae subfam. Asteroideae = Compositae subfam. Tubuliflorae, and Alnus incana = Alnus rugosa. The EPD follows Flora Europaea (Tutin et al. 1964-1980) for the Pteridophyta and Spermatophyta, with the exception of taxa that are not native to Europe, which follow Willis (1985), Smith (1980, 1990) for the Bryophyta, Prescott (1969) for the green and red algae, and Ainsworth et al. (1973, 1983) for the Eumycota. Syntactic synonymy refers to nomenclatural syntax and applies particularly to the non-Latin parts of pollen-type names. The language of the database will be English. Some examples of syn- tactic conventions are: Ambrosia-type rather than Ambrosia type or Am- brosia (type) Ostrya/Carpinus rather than Ostrya-Carpinus Pinguicula cf. P. villosa rather than Pinguicula cf. villosa Morphological synonymy refers to different but valid nomenclatural and syntactic names ap- plied to the same morphological pollen type. Morphological synonyms often have a geographi- cal ingredient. Examples in North America are Fraxinus nigra-type = Fraxinus quadrangulata- type and Larix = Pseudotsuga. No attempt has been made to determine pol- len-morphological synonyms. It is recognized that the association of a pollen-morphological taxon with a particular plant taxon, or group of taxa, is a matter of subjective interpretation, because it is unlikely that the present biogeography had prevailed in the past. Nevertheless, it is common to apply different nomenclature to morphologically indistinguishable pollen taxa when working in different geographical regions because the asso- ciated plant taxa had limited geographical ranges. As a matter of principle as much information is being preserved as possible, even at the expense of long taxon lists that contain many pollen-mor- phological synonyms. In the interest of somewhat limiting the number of morphological synonyms, the database administrator may suggest possible morphological synonyms to data contributors for their approval. The ultimate decision on morpho- logical taxonomy is that of the contributor, how- ever. The development of a uniform taxonomy and nomenclature for the North American and European pollen-morphological taxa is perhaps a desirable long-term goal, but in the short-term only botanical nomenclatural and syntactic con- ventions are being imposed. Both databases have adopted the following syntactic conventions Type Type should always be hyphenated e.g. - type. Exceptions: Armeria (type A), Armeria (type B), Artemisia norvegica (type 1) cf. Form is Genus cf. Genus species, but Family cf. Genus. For example, Betula cf. B. nana and Oleaceae cf. Phillyrea Genus/Genus-type is not acceptable For example, Malus/Mespilus-type should be either Malus/Mespilus or Malus-type or Mespilus-type. Genus-type/Genus-type is not acceptable Genus indeterminable or Genus indet. is not acceptable For example, Plantago indeterminable = Plantago undiff. spp. is not acceptable Genus undiff. or family name (having checked with the author where necessary) s.l. (sensu lato) Elymus s.l. = Elymus-type 5.3. Restrictions on the use of data EPD data will be classified as restricted or unrestricted. Although all data will be distributed, that marked as restricted can only be used with the permission of the originator. 6. Overview of the Pollen Database Structure 6.1. Categories of Tables The Pollen Database is ambitious in the scope of data it seeks to archive. Furthermore, good database design favors a larger number of tables each with a few fields, rather than a smaller number of tables each with many fields. Tables are then linked together by like fields for data retrieval. The Pollen Database presented below comprises over 300 fields of data organized into approximately 60 tables, with each table containing a different kind of data. Although such numbers must at first seem daunting, understanding the database is simplified by an awareness of the relationships between the different categories of tables, and the realisation that the core data are stored in a relatively small number of tables. Five categories of table can be distinguished: Archival, Look-up, Research, System, and View. Archival tables store the data reported on each site, data that are not expected to change once entered into the database, except to add missing information or to correct errors. SITELOC is an Archival table that stores the locational information on sites. Look-up tables save space and reduce errors in the database by collecting repeatedly used items in a single place. Other tables then reference these items using short numbers or codes. For example, the POLDIV1 table contains names and three character codes for all countries. Space is saved in the SITELOC and WORKERS tables by storing just the country code and not the full country name. Research tables store data that are derived by manipulation from the Archival tables or else are of an interpretive or subjective nature. Such data are expected to change or be supplemented. Users are likely to develop a va- riety of research tables, apart from those initially provided for, according to the requirements of their projects. It is envisaged that applications software be developed initially to allow a few ba- sic research tables to be generated by the user, but that in Europe the distributed database will not be accompanied by any centrally-developed research tables. P_AGEDPT is an example of a Research table, it stores the estimated ages for samples in a profile calculated from the radiocarbon or other age determinations. System tables are used by application programs to help maintain the integrity of the data in the database. They store a description of the structure of the Pollen Database, including the names of all tables and columns, and the composition of primary, alternate, and foreign keys. The SYSCAT table stores the name and category of each table in the Pollen Database. Views contain information that is derived from other existing tables or views, making it more convenient to access. Pollen Database tables such as P_VARS and DESCR store hierarchical information that is subsequently used to derive views for the quick retrieval of hierarchical relationships (P_VARIS and DESCRIS). 6.2. Pollen v. Macrofossil data A set of parallel tables that store analogous data have been designed to allow for the recording of plant and macrofossil data. Where available, this information will be included in the EPD. These tables are distinguished by the prefixes "P_" for pollen data, and "M_" for macrofossil data. For example, both the P_ENTITY and M_ENTITY tables hold additional information about an entity (e.g. a core). Two tables are used rather than one because P_ENTITY stores pollen-specific data and M_ENTITY stores macrofossil-specific data (e.g. the year that the analysis was completed for a given entity, which might not be the same where both types of data were analyzed). 6.3. Core Tables The Archival tables form the core of the database. The most important and frequently used of these are: SITELOC stores the name and location of the site. ENTITY stores the name and description of the entity (i.e. core, section, or surface sample). GEOCHRON stores the depths and the material dated for geochronological dates. C14 stores the reported radiocarbon dates. P_SAMPLE stores the sample depths. P_COUNTS stores the pollen counts. P_VARS stores the names and codes of all Pollen Database variables. PUBLCIT stores the full bibliographic citations. WORKERS stores the names of workers - persons responsible for data, analysts, etc. Research tables store the product of the database. The most important of these are: CHRON stores the name of the preparer of the chronology, the date it was prepared, and the model used to derive the age-depths. AGEBASIS stores the complete dating informa- tion used to produce the age-depth curve. P_AGEDPT stores the pollen age-depths and deposition times derived from the selected age-model. 7. References Ainsworth, G. C., F. K. Sparrow, and A. S. Sussman. 1973. The fungi: an advanced trea- tise. Academic Press, London, England. Ainsworth, G. C. 1983. Dictionary of fungi. Seventh edition. Commonwealth Mycological Institute, Kew. Borland International. 1990. Paradox 3.5 User's Guide. Borland International, Scotts Valley, CA, USA. Codd, E. F. 1970. A relational model of data for large shared data banks. Communications of the Association for Computing Machinery 13:377-387. Codd, E. F. 1985. Is your DBMS really rela- tional? Computerworld, October 14 and 21. Codd, E. F. 1990. The Relational Model for Database Management. Version 2. Addison- Wesley, Reading, Massachusetts, USA. COHMAP Members. 1988. Climatic changes of the last 18,000 years: observations and model simulations. Science 241:1043-1052. Council of Biology Editors 1983. The CBE Style Manual. Fifth edition. American Institute of Biological Sciences, Washington, D.C., USA. Cronquist, A. 1981. An integrated system of classification of flowering plants. Columbia University Press, New York, New York, USA. Date, C. J. 1990. An Introduction to Database Systems. Fifth edition. Addison-Wesley, Reading, Massachusetts, USA. Gleason, H. A., and A. Cronquist. 1991. Manual of vascular plants of northeastern United States and adjacent Canada. Second edition. New York Botanical Garden, Bronx, New York, USA. Great Plains Flora Association. 1986. Flora of the Great Plains. University Press of Kansas, Lawrence, Kansas, USA. Huntley, B., and H. J. B. Birks. 1983. An atlas of past and present pollen maps for Europe 0-13,000 years ago. Cambridge University Press, Cambridge, England. Prescott, G. W. 1969. The algae: a review. Nel- son, London, England. Ralska-Jasiewiczowa, M., editor. 1985. Palaeohydrological changes in the temperate zone in the last 15,000 years. Subproject B. Lake and Mire Environments. International Geological Correlation Programme Project 158B. Smith, A. G. 1980. The moss flora of Britain and Ireland. Cambridge University Press, Cambridge, England. Smith, A. G. 1990. The liverworts of Britain and Ireland. Cambridge University Press, Cam- bridge, England. Tutin, T.G. 1964-1980. Flora Europaea. Cam- bridge University Press, Cambridge, England. Willis, J. C. 1985. A dictionary of the flowering plants and ferns. Cambridge University Press, Cambridge, England. 8. Database Tables and Field Descriptions 8.1. Archival Tables TABLE WORKERS Names of workers. The WORKERS table is an Archival table that stores the names of all workers known to the Pollen Database. The mailing addresses of workers are stored separately, in the ADDRESS table. FIELDS ( Worker# S WorkerIs# S Status A1 LastName A30 Initials A10 FirstName A15 Suffix A5 Title A10 Country A3 Phone A20 Fax A20 EMailAddr A40 ) PRIMARY KEY ( Worker# ) FOREIGN KEY ( Country ) references POLDIV1. ( WorkerIs# ) references WORKERS. Worker# Unique identifier for the name of each worker. WorkerIs# Identifier for the name currently used by the worker. This number is the same as Worker#, except where the worker has changed his or her name. Status One character code for the status of worker. It must be one of the following: A=Active, I=Inactive, D=Deceased, U=Unknown. LastName Last name of the worker. Name prefixes, particles, articles, and prepositions will be retained and placed in Ecology style according to guidelines suggested by the 5th edition of the CBE Style Manual. Initials Full initials of the worker, without spacing (e.g. "E.C."). FirstName First name of the worker. Suffix Suffix for the worker's name (e.g. "III"). Title Title of the worker (e.g. "Dr."). Country Three character code for the worker's country of residence. Phone Telephone number, including the international code (e.g. "44 091 3743741"). Fax FAX number, including the international code (e.g. "33 90 939803"). EMailAddr Electronic mail address. TABLE ADDRESS Addresses of workers. The ADDRESS table is an Archival table that stores addresses of workers. Addresses are stored as any number of 65 character lines of text. FIELDS ( Worker# S Line# S Address A65 ) PRIMARY KEY ( Worker#, Line# ) FOREIGN KEY ( Worker# ) references WORKERS. Worker# Identifier for the worker. Line# Unique identifier for each line of the address. Address Text of the address line. TABLE SITELOC Site location information. The SITELOC table is an Archival table that stores information on sites, their names and locations. FIELDS ( Site# S SiteName A40 SiteCode A14 SiteExists A5 PolDiv1 A3 PolDiv2 A2 PolDiv3 A3 Latitude N Longitude N UTM A13 Elevation S AreaOfSite N ) PRIMARY KEY ( Site# ) ALTERNATE KEY ( SiteName ) ( SiteCode ) FOREIGN KEY ( PolDiv1 ) references POLDIV1. ( PolDiv1, PolDiv2 ) references POLDIV2. ( PolDiv1, PolDiv2, PolDiv3 ) references POLDIV3. Site# Unique identifier for the site. SiteName Unique name by which the site is generally known (e.g. "La Grande Pile"). Modifiers are added in square brackets, if necessary, to make the site name unique. Political division names are preferred as modifiers (e.g. "Devils Lake [Wisconsin]"). Where an author's SiteName is general or nonspecific, the author's name and the year of publication, in square brackets, will preface the SiteName (e.g. "[Mott & Camfield 1969] Site 3"). SiteCode Coded name for site, in 3 divisions: country, 2nd and 3rd political subdivisions, and site (e.g. "USA-MN053-WOLS"). SiteExists Year that the site was last known to exist or not to exist (e.g. "Y1985" or "N1977"). PolDiv1 Code for the first political subdivision - country. PolDiv2 Code for the second political subdivision (USA = state). The value "00" will be entered where the second political subdivision is unspecified or unknown. PolDiv3 Code for the third political subdivision (USA = county). The value "000" will be entered where the third political subdivision is unspecified or unknown. Latitude Stored in pseudodecimal format (ddd.mmss). Negative values indicate latitudes south of the equator. Digits to the right of the seconds represent decimal fractions of seconds. (Examples: 44 22'11" is stored as 44.2211; -37 50' is stored as -37.5; 40 20'10" is stored as 40.201; 6 31'15.5" is stored as 6.31155). Longitude Stored in pseudodecimal format (ddd.mmss). Negative values indicate longitudes west of the Greenwich meridian. Digits to the right of the seconds represent decimal fractions of seconds. (Examples: -100 50'25" is stored as -100.5025; 32 00'10" is stored as 32.001; 10 5'2.5" is stored as 10.05025). UTM Universal Transverse Mercator designation for the site (e.g. "18RTE36653775"). Elevation Elevation (altitude) of the site in meters above sea level. AreaOfSite Approximate area of the present site in hectares (i.e. the open area of a lake). TABLE SITEDESC Site descriptions. The SITEDESC table is an Archival table that stores textual descriptions of a site. This table is a subtype of table SITELOC. FIELDS ( Site# S SiteDescript A40 Physiography A40 SurroundVeg A40 VegFormation A40 IGCPtype A8 ) PRIMARY KEY ( Site# ) FOREIGN KEY ( Site# ) references SITELOC. ( IGCPtype ) references IGCPTYPE. Site# Identifier for the site. SiteDescript Brief description of the present nature of the site (e.g. "lake with marginal fen"). Physiography Physiographic description (e.g. "rolling stagnation moraine"). SurroundVeg Vegetation surrounding the coring site. VegFormation Vegetation formation (e.g. "boreal forest"). The vegetation formation in Europe is defined as the unit depicted on the Map of the Natural Vegetation of the member countries of the European Community and the Council of Europe (1987). If a site is not located within one of these countries then an appropriate vegetation formation is assigned (e.g. "Quercus/Fraxinus woods"). IGCPtype IGCP type region code (e.g. "F-x", for the Forez, Velay and Aubrac region). TABLE SITEINFO Sites and associated published information. The SITEINFO table is an Archival table that stores information that cross-references sites and the published information on them. FIELDS ( Site# S ICode A3 Publ# S ) PRIMARY KEY ( Site#, ICode, Publ# ) FOREIGN KEY ( Site# ) references SITELOC. ( ICode ) references INFOTYPE. ( Publ# ) references PUBL. Site# Identifier for the site. ICode Three character identifier for the type of information present in the publication (e.g. ALG=algae, COL=coleopterans, POL=pollen). These identifiers and their descriptions are stored in table INFOTYPE. Publ# Identifier for the publication. TABLE ENTITY Entity identification and description. The ENTITY table is an Archival table that stores the description of an entity. An entity is either a core, a section, or a surface sample that is associated with exactly one site. The entity is the unit of organization of the database. FIELDS ( E# S Site# S Sigle A8 Name A30 IsCore A1 IsSect A1 IsSSamp A1 Descriptor A4 HasAnLam A1 EntLoc A40 LocalVeg A40 Coll# S SampDate A10 DepthAtLoc N IceThickCM S SampDevice A30 CoreDiamCM N C14DepthAdj N ) PRIMARY KEY ( E# ) ALTERNATE KEY ( Sigle ) FOREIGN KEY ( Site# ) references SITELOC. ( Descriptor ) references DESCR. ( Coll# ) references WORKERS. E# Unique identifier for the base data entity (core, section, etc.). Site# Identifier for the site. Sigle Unique code name for the entity. The Sigle is any unique combination of uppercase letters, numbers, and certain special characters. These special characters include those that are legal DOS filename characters. Name Any modifier of the site name as published on the pollen diagram (e.g. "core B" or "boring 16A"). For NAPD, where none is given, Name is left blank (null). An entity is a core, which may include a series of segments, a section, or a surface sample, or any combination thereof. IsCore "Y" if the entity is a core, otherwise "N". IsSect "Y" if the entity is a section, otherwise "N". IsSSamp "Y" if the entity is a modern surface sample, otherwise "N". Descriptor Identifier for the description of modern entity site. These identifiers and their descriptions are listed in table DESCR. HasAnLam Code describing the type of analyzed annual laminations: T=annually laminated to top, P=laminated, but not to top, N=no laminations or laminations not analyzed. The term 'varve' is reserved for varves sensu stricto (i.e. glacial varves). [Applies to Cores and Sections only.] EntLoc Location where the sample or core was taken (e.g. "north side of lake"). LocalVeg Local vegetation at the collection site. Coll# Identifier of the worker who took the core or collected the surface sample. SampDate Date that the sample or core was collected. Enter date as yyyy-mm-dd (e.g. "1977-08- 25", or where the day is not reported, "1962-01-00", or if no date, "0000-00-00"). DepthAtLoc Water depth at the coring location (cm). [Applies to Cores and Surface Samples only.] IceThickCM Thickness of the ice through which a sample was taken (cm). SampDevice Name of the sampling or coring device (e.g. "Livingstone piston sampler"). CoreDiamCM Diameter of the core (cm). [Applies to cores only.] C14DepthAdj Adjustment for C14 depths needed to relate the depth of the dated samples to the pollen or other samples. This is necessary since depths cited for samples taken for radiocarbon and other geochronological dates may have been measured from a different datum than those for pollen and other samples (cm). (See also, table GEOCHRON.) [Applies to Cores and Sections only.] TABLE P_ENTITY Pollen-specific entity data. The P_ENTITY and M_ENTITY tables are Archival tables that store additional information about the entity including the source and form of the data, and its use status. These tables are subtypes of table ENTITY. FIELDS ( E# S Contact# S DataSource A80 DataForm A2 UseStatus A1 ) PRIMARY KEY ( E# ) FOREIGN KEY ( E# ) references ENTITY. ( Contact# ) references WORKERS. E# Identifier for the entity. Contact# Identifier for the worker responsible for the data, the contact person. DataSource Source of the data (e.g. "publication", "originator", "COHMAP"). DataForm Two character code indicating the form of the data. It must be one of the following: RC=raw counts, RP=raw percentages, DC=digitized counts, DP=digitized percentages. The EPD protocols require that all data be of form RC. UseStatus One character code indicating the use status of the data. It must be one of the following: USA: P=published, U=unpublished; EUR: F=free, R=restricted. The EPD will distribute all data, restricted and unrestricted. Restricted data can be viewed by the user, but can only be used with the permission of the originator. TABLE M_ENTITY Macrofossil-specific entity data. FIELDS ( E# S Contact# S DataSource A80 UseStatus A1 ) PRIMARY KEY ( E# ) FOREIGN KEY ( E# ) references ENTITY. ( Contact# ) references WORKERS. E# Identifier for the entity. Contact# Identifier for the worker responsible for the data, the contact person. DataSource Source of the data (e.g. "publication", "originator", "COHMAP"). UseStatus One character code indicating the use status of the data. It must be one of the following: USA: P=published, U=unpublished; EUR: F=free, R=restricted. TABLE COREDRIV Core drive identification and description. The COREDRIV table is an Archival table that stores information on core-drives. FIELDS ( E# S Drive# S DriveLabel A10 DriveTopCM N DriveBotCM N InfTopCM N InfBotCM N RecoveryCM N ) PRIMARY KEY ( E#, Drive# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Drive# Unique identifier for the drive. DriveLabel Label given to the drive (e.g. "4B") DriveTopCM Depth at which the drive for the core segment started (cm). DriveBotCM Depth at which the drive for the core segment stopped or bottomed (cm). InfTopCM Inferred depth of the top of the core segment, according to the data originator, when account has been made for any compaction or sediment disturbance (cm). InfBotCM Inferred depth of the bottom of the core segment (cm). RecoveryCM Length of the segment recovered (cm). TABLE SECTION Section identification and description. The SECTION table is an Archival table that stores information related to the identification of the sections taken for an entity. FIELDS ( E# S Section# S SectionLabel A60 SectionTopCM N SectionBotCM N ) PRIMARY KEY ( E#, Section# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Section# Unique identifier for the section. SectionLabel Label given to the section. SectionTopCM Depth of the top of the section relative to datum (cm). SectionBotCM Depth of the bottom of the section relative to datum (cm). TABLE ENTITY&& Notes on entity. The ENTITY&& table is an Archival table that stores notes on an entity. Notes on an entity are stored as any number of 60 character lines of text. FIELDS ( E# S Line# S Text A60 ) PRIMARY KEY ( E#, Line# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Line# Unique identifier for the line. Text Notes on the description of the entity (notes are any number of 60 character lines of text). TABLE GEOCHRON Analytically determined dates. The GEOCHRON table is an Archival table that stores geochronological information that is common to all of the different types of geochronological dates (e.g. radiocarbon or fission track dates). This common information includes depth, material dated, and a reference to the published description of the event. The GEOCHRON table is the super-type to tables that store information for a particular geochronological dating method (e.g. tables C14 and FT). FIELDS ( E# S Sample# S Method A1 DepthCM N Thickness N MaterialDated A30 Publ# S ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E# ) references ENTITY. ( Publ# ) references PUBL. E# Identifier for the entity. Sample# Unique identifier for the dated sample. Method A one character code indicating the method used to date the material. It must be one of the following: A=AAR, C=14C, E=ESR, F=FT, K=KAR, P=210Pb, T=TL, U=USERIES. DepthCM Reported depth of the midpoint of the sample (cm). Subtract the value of C14DepthAdj (table ENTITY) from the reported depth to correlate geochronological with fossil depths. Thickness Thickness of the sample (cm). MaterialDated Type of material and fraction dated. This should be defined as precisely as possible (e.g. "gyttja", "wood (Pinus sylvestris)", "shell (Arctica islandica)"). Publ# Bibliographic citation for the dating information for this sample. TABLE AAR Amino Acid Racemization dating information. The AAR table is an Archival table that stores Amino Acid Racemization dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N TaxonDated A30 LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the reported age. TaxonDated Taxonomic classification of the dated material (e.g. Arctica islandica). LabNumber Laboratory number assigned to the sample. TABLE C14 Carbon-14 dating information. The C14 table is an Archival table that stores Radiocarbon dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N AgeSDUp N AgeSDLo N GrThanAge A1 Basis A1 Enriched A1 LabNumber A10 DeltaC13 N ) PRIMARY KEY ( E#, Sample# ) ALTERNATE KEY ( LabNumber ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP (= 1950 using the Libby half-life). AgeSDUp Upper standard deviation of this age. AgeSDLo Lower standard deviation of this age. GrThanAge "Y" if the determination is stated as being 'greater than', otherwise "N" (the default). Basis A one character code indicating the method used to make the radiocarbon determination. It must be one of the following: A=accelerator, G=gas decay count, L=decay count liquid scintillation, U=decay count method unknown. Enriched "Y" if the sample was enriched, otherwise "N". LabNumber Laboratory number assigned to the sample (e.g. "St-1050"). DeltaC13 Value of delta Carbon-13. TABLE ESR Electron Spin Resonance dating information. The ESR table is an Archival table that stores Electron Spin Resonance dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the age determination. LabNumber Laboratory number assigned to the sample. TABLE FT Fission Track dating information. The FT table is an Archival table that stores Fission Track dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the age determination. LabNumber Laboratory number assigned to the sample. TABLE KAR Potassium/Argon dating information. The KAR table is an Archival table that stores Potassium/Argon dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the age determination. LabNumber Laboratory number assigned to the sample. TABLE PB210 Lead-210 dating information. The PB210 table is an Archival table that stores 210Pb dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeAD N AgeSDUp N AgeSDLo N GrThanAge A1 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeAD Age determination of the sample in years AD. AgeSDUp Upper standard deviation of the age determination. AgeSDLo Lower standard deviation of the age determination. GrThanAge "Y" if the determination is stated as being 'greater than', otherwise "N" (the default). TABLE TL Thermoluminescence dating information. The TL table is an Archival table that stores Thermoluminescence dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N GrainSize A10 LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the age determination. GrainSize Range of grain size of the dated sediments in microns (e.g. "2-10"). LabNumber Laboratory number assigned to the sample. TABLE USERIES Uranium-series dating information. The USERIES table is an Archival table that stores Uranium-series dating information. This table is a subtype of table GEOCHRON. FIELDS ( E# S Sample# S AgeBP N ErrorLimits N LabNumber A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E#, Sample# ) references GEOCHRON. E# Identifier for the entity. Sample# Identifier for the dated sample. AgeBP Age determination of the sample in years BP. ErrorLimits Error () in the age determination. LabNumber Laboratory number assigned to the sample. TABLE SYNEVENT Dates from synchronous events. The SYNEVENT table is an Archival table that stores information on ages associated with an entity based on evidence from synchronous events. The description of the event is stored in the EVENT table. FIELDS ( E# S Event# S DepthCM N Thickness N ) PRIMARY KEY ( E#, Event# ) FOREIGN KEY ( E# ) references ENTITY. ( Event# ) references EVENT. E# Identifier for the entity. Event# Identifier for the event (event names are stored in table EVENT). DepthCM Depth of the midpoint of the event (cm). Thickness Thickness of the event (cm). TABLE EVENT Event names and dates. The EVENT table is an Archival look-up table that stores the description of an event. The description includes its name, age, the uncertainty in the age, and a reference to the published description of the event. FIELDS ( Event# S Event A1 Name A30 AgeBP N AgeUncertUp N AgeUncertLo N Publ# S ) PRIMARY KEY ( Event# ) FOREIGN KEY ( Publ# ) references PUBL. Event# Unique identifier for the event. Event One character code for the type of the event that is being used to date or correlate the core: T=tephra, C=137Cs, ... Name Name of the event (e.g. "China Hat" for a tephra; "Vedde ash bed"). AgeBP Estimated age of the event in 14C years BP. AgeUncertUp Upper bound of range of uncertainty in the age of the event. AgeUncertLo Lower bound of range of uncertainty in the age of the event. Publ# Bibliographic citation for the age of the event. TABLE ALSEGS Annual laminations segments description. The ALSEGS table is an Archival table that stores information on annual lamination segments. A segment is defined as a continuous stratigraphic sequence of annual laminations. An entity can have any number of segments. Depths and counts are stored in the P_ANLDPT or M_ANLDPT tables. FIELDS ( E# S Seg# S DepthTopCM N DepthBotCM N ) PRIMARY KEY ( E#, Seg# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Seg# Unique identifier for the segment. DepthTopCM Depth of the top of the annually laminated segment (cm). DepthBotCM Depth of the bottom of the segment (cm). TABLE P_ANLDPT Pollen annual laminations depths information. The P_ANLDPT and M_ANLDPT tables are Archival tables that store information on annual laminations for each of an entity's segments (segment descriptions are stored in table ALSEGS). These tables store the lamination counts and depths of samples within a segment. FIELDS ( E# S Seg# S Sample# S DepthCM N Thickness N CountTop N CountBot N ) PRIMARY KEY ( E#, Seg#, Sample# ) FOREIGN KEY ( E#, Seg# ) references ALSEGS. E# Identifier for the entity. Seg# Identifier for the annual lamination segment. Sample# Unique identifier for the sample. DepthCM Depth of the midpoint of the sample (cm). Thickness Thickness of the sample (cm). CountTop Annual laminations count at the top of the sample. CountBot Annual laminations count at the bottom of the sample. TABLE M_ANLDPT Macrofossil annual laminations depths information. FIELDS ( E# S Seg# S Sample# S DepthCM N Thickness N CountTop N CountBot N ) PRIMARY KEY ( E#, Seg#, Sample# ) FOREIGN KEY ( E#, Seg# ) references ALSEGS. E# Identifier for the entity. Seg# Identifier for the annual lamination segment. Sample# Unique identifier for the sample. DepthCM Depth of midpoint of the sample (cm). Thickness Thickness of the sample (cm). CountTop Annual laminations count at the top of the sample. CountBot Annual laminations count at the bottom of the sample. TABLE DATING&& Notes on dating. The DATING&& table is an Archival table that stores notes on dating, including both geochronological and synchronous event dates. Notes for an entity are stored as any number of 60 character lines of text. FIELDS ( E# S Line# S Text A60 ) PRIMARY KEY ( E#, Line# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Line# Unique identifier for the line. Text Additional notes on dating (notes are any number of 60 character lines of text). TABLE P_PREP&& Notes on pollen sample preparation. The P_PREP&& and M_PREP&& tables are Archival tables that store notes on sample preparation, including sample treatments and exceptions. Notes for an entity are stored as any number of 60 character lines of text. FIELDS ( E# S Line# S Text A60 ) PRIMARY KEY ( E#, Line# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Line# Unique identifier for the line. Text Additional notes on pollen sample preparation (notes are any number of 60 character lines of text). TABLE M_PREP&& Notes on macrofossil sample preparation. FIELDS ( E# S Line# S Text A60 ) PRIMARY KEY ( E#, Line# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Line# Unique identifier for the line. Text Additional notes on macrofossil sample preparation (notes are any number of 60 character lines of text). TABLE P_VARS Look-up table for pollen variable names. The P_VARS and M_VARS tables are Archival tables that store the names, codes and hierarchy information for each pollen variable recognized by the Pollen Database, including synonyms. FIELDS ( Var# S AccVar# S SynType A1 VarCode A8 VarName A60 HVar# S Auth# S ) PRIMARY KEY ( Var# ) ALTERNATE KEY ( VarCode ) ( VarName ) FOREIGN KEY ( AccVar# ) references P_VARS. ( HVar# ) references P_VARS. ( Auth# ) references PUBL. Var# Unique identifier for the variable. AccVar# Identifier of the accepted Var# for this variable. AccVar# = Var# where VarName is the senior synonym. SynType One-character code indicating the type of synonym. It must be one of the following: M=morphological; N=nomenclatural; 1=name of a globally-monospecific genus (e.g. Zea); 2=name of a genus that is monospecific within a continent, but not globally (e.g. Tilia americana in North America); or for accepted variables. VarCode Eight character code for the pollen variable name. VarName Name of the pollen type or variable, including Linnean and non-Linnean names (Acer saccharum-type, Cerealea, Avena/Triticum), or non-pollen (microspheres). HVar# Var# of the next higher taxon of which the pollen type is a member. (Special cases: if HVar# = Var#, then name is valid and it is the highest taxon recognized. HVar# is null for non-accepted variables.) Auth# Identifier for the publication cited as authority for a pollen variable name. For NAPD this will be the authority for the Latin portion of the pollen variable's name (e.g. Gleason and Cronquist 1991 is the authority for Dalea purpurea in Dalea purpurea-type). TABLE M_VARS Look-up table for macrofossil variable names. FIELDS ( Var# S AccVar# S SynType A1 VarCode A8 VarName A60 HVar# S Auth# S ) PRIMARY KEY ( Var# ) ALTERNATE KEY ( VarCode ) ( VarName ) FOREIGN KEY ( AccVar# ) references P_VARS. ( HVar# ) references P_VARS. ( Auth# ) references PUBL. Var# Unique identifier for the variable. AccVar# Identifier of the accepted Var# for this variable. AccVar# = Var# where VarName is the senior synonym. SynType One-character code indicating the type of synonym. It must be one of the following: M=morphological; N=nomenclatural; 1=name of a globally-monospecific genus (e.g. Zea); 2=name of a genus that is monospecific within a continent, but not globally (e.g. Tilia americana in North America); or for accepted variables. VarCode Eight character code for the macrofossil variable named. VarName Name of the pollen type or variable, including Linnean and non-Linnean names (Acer saccharum-type, Cerealea, Avena/Triticum), or non-pollen (microspheres). HVar# Var# of the next higher taxon of which the pollen type is a member. (Special cases: if HVar# = Var#, then name is valid and it is the highest taxon recognized. HVar# is null for non-accepted variables.) Auth# Identifier for the publication cited as authority for a macrofossil variable name. TABLE P_SAMPLE Pollen sample depths and thicknesses. The P_SAMPLE and M_SAMPLE tables are Archival tables that store the sample depths for an entity. This table also stores an identifier for the worker who analyzed the sample. FIELDS ( E# S Sample# S DepthCM N Thickness N Analyst# S AnalyDate A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E# ) references ENTITY. ( Analyst# ) references WORKERS. E# Identifier for the entity. Sample# Unique identifier for the sample. DepthCM Depth of the midpoint of the sample (cm). Thickness Thickness of the sample (cm). Analyst# Identifier of the worker who counted the pollen sample. AnalyDate Date that the pollen analysis was completed. Enter date as yyyy-mm-dd (e.g. "1977-08- 25", or where the day is not reported, "1962-01-00", or if no date, "0000-00-00"). TABLE M_SAMPLE Macrofossil sample depths and thicknesses. FIELDS ( E# S Sample# S DepthCM N Thickness N Analyst# S AnalyDate A10 ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E# ) references ENTITY. ( Analyst# ) references WORKERS. E# Identifier for the entity. Sample# Unique identifier for the sample. DepthCM Depth of the midpoint of the sample (cm). Thickness Thickness of the sample (cm). Analyst# Identifier of the worker who counted the macrofossil sample. AnalyDate Date that the macrofossil analysis was completed. Enter date as yyyy-mm-dd (e.g. "1977-08-25", or where the day is not reported, "1962-01-00", or if no date, "0000-00- 00"). TABLE P_COUNTS Pollen counts. The P_COUNTS and M_COUNTS tables are Archival tables that store the pollen counts for an entity. This table stores the non-zero counts for each combination of variable and sample depth (the depths values are stored in table P_SAMPLE). FIELDS ( E# S Sample# S Var# S Count N ) PRIMARY KEY ( E#, Sample#, Var# ) FOREIGN KEY ( E#, Sample# ) references P_SAMPLE. ( Var# ) references P_VARS. E# Identifier for the entity. Sample# Identifier for the sample. Var# Identifier for the variable. Count Pollen count. It must be a positive number. TABLE M_COUNTS Macrofossil counts. FIELDS ( E# S Sample# S Var# S Count N ) PRIMARY KEY ( E#, Sample#, Var# ) FOREIGN KEY ( E#, Sample# ) references M_SAMPLE. ( Var# ) references M_VARS. E# Identifier for the entity. Sample# Identifier for the sample. Var# Identifier for the variable. Count Macrofossil count. It must be a positive number. TABLE LITHOLGY Sediment lithology. The LITHOLGY table is an Archival table that stores sediment lithology information for an entity. FIELDS ( E# S Lith# S Descript A40 DepthTopCM N DepthBotCM N LoBoundary A40 ) PRIMARY KEY ( E#, Lith# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Lith# Unique identifier for the lithological unit. Descript Description of the lithological unit. DepthTopCM Depth of the top of the lithological unit (cm). DepthBotCM Depth of the bottom of the lithological unit (cm). LoBoundary Description of the nature of the lower boundary. TABLE LOI Loss-on-ignition information. The LOI table is an Archival table that stores Loss-on-ignition information for an entity. FIELDS ( E# S Sample# S DepthCM N Thickness N TempLo S LOILo N TempHi S LOIHi N BulkDens N ) PRIMARY KEY ( E#, Sample# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Sample# Unique identifier for the sample. DepthCM Depth of the midpoint of the sample (cm). Thickness Thickness of the sample (cm). TempLo Low loss-on-ignition temperature in C (e.g. 500). LOILo Loss-on-ignition value, low temperature (organics), as a percentage of dry mass. TempHi High loss-on-ignition temperature in C (e.g. 1000). LOIHi Loss-on-ignition value (carbonates), as a percentage of dry mass. BulkDens Dry mass of the sample in g/cm3. TABLE PUBL Publications and their library accession numbers. The PUBL table is an Archival table that stores publication and library accession numbers. FIELDS ( Publ# S Acc# S YearOfPubl A4 ) PRIMARY KEY ( Publ# ) ALTERNATE KEY ( Acc# ) Publ# Unique identifier for the publication. Acc# A local library accession number (these are assigned as consecutive short integers). The absence of a value implies no local reprint of the publication. YearOfPubl Year of publication. TABLE PUBLCIT Full bibliographic citations (in Ecology style). The PUBLCIT table is an Archival table that stores the complete bibliographic citation for a publication, in the style of the journal Ecology. Citations are stored as any number of 60 character lines of text. FIELDS ( Publ# S Line# S Text A60 ) PRIMARY KEY ( Publ#, Line# ) FOREIGN KEY ( Publ# ) references PUBL. Publ# Identifier for the publication. Line# Unique identifier for the line. Text Sixty characters for each line of the bibliographic citation, using formatting conventions of the journal Ecology and The CBE Style Manual. Since Paradox 3.5 does not support text formatting such as italics and boldface in fields, the following additional conventions will be used: text between extended ASCII characters 174 and 175 (decimal) is understood to indicate italics; text between extended ASCII characters 169 and 170 is understood to indicate boldface. TABLE PUBLENT Publications cross-referenced by entity. The PUBLENT table is an Archival table that cross-references publications and the entities on which they report. This table may be used to find the entities associated with any publication, or the publications associated with any entity. FIELDS ( Publ# S E# S ) PRIMARY KEY ( Publ#, E# ) FOREIGN KEY ( Publ# ) references PUBL. ( E# ) references ENTITY. Publ# Identifier for the publication. E# Identifier for the entity. TABLE AUTHORS Publications cross-referenced by authors. The AUTHORS table is an Archival table that cross-references authors to their publications. This table may be used to find the publications authored by a worker. FIELDS ( Author# S Publ# S Order S ) PRIMARY KEY ( Author#, Publ# ) FOREIGN KEY ( Author# ) references WORKERS. ( Publ# ) references PUBL. Author# Identifier for the name of the author. Publ# Identifier for the publication. Order An integer that identifies the ordering of authorship (1,2,3,...,n) in a publication. 8.2. Lookup and Referral Tables TABLE POLDIV1 Look-up table of country names. The POLDIV1 table is a Look-up table of 1st political subdivision names. These correspond to the names of countries. FIELDS ( PolDiv1 A3 Name A40 ) PRIMARY KEY ( PolDiv1 ) ALTERNATE KEY ( Name ) PolDiv1 ISO/ANSI three-letter country codes (source: U.S. Department of Commerce FIPS PUB 104-1). Note that GER will be used for the unified Germany until an ISO standard code is announced. Name Name of the country (spellings used are those specified by the ISO 3166 standard). TABLE POLDIV2 Look-up table of 2nd political subdivision names. The POLDIV2 table is a Look-up table of 2nd political subdivision names. The 2nd political division in the United States is the state, it is the province or territory in Canada. FIELDS ( PolDiv1 A3 PolDiv2 A2 PostCode A2 Name A25 ) PRIMARY KEY ( PolDiv1, PolDiv2 ) FOREIGN KEY ( PolDiv1 ) references POLDIV1. PolDiv1 Three letter country codes. PolDiv2 Two digit codes for 2nd political subdivision. In North America these are states or provinces (source: U.S. Department of Commerce FIPS PUB 10-3). In Europe a list is currently being compiled of all the major political subdivisions of countries (i.e. Vice Counties in the U.K., dpartments in France, etc.). A map will eventually be prepared that will depict the boundaries between each of these areas. PostCode Two letter postal code. Name Name of the political subdivision. TABLE POLDIV3 Look-up table of 3rd political subdivision names. The POLDIV3 table is a Look-up table of 3rd political subdivisions names. These correspond, generally, to county names in the United States. FIELDS ( PolDiv1 A3 PolDiv2 A2 PolDiv3 A3 Name A40 ) PRIMARY KEY ( PolDiv1, PolDiv2, PolDiv3 ) FOREIGN KEY ( PolDiv1, PolDiv2 ) references POLDIV2. PolDiv1 Three letter country codes. PolDiv2 Two digit 2nd political subdivision code. PolDiv3 Three digit codes for 3rd political subdivision. In North America these are counties or census divisions (source: U.S. Department of Commerce FIPS PUB 6-4 and Statistics Canada, Geography Division, Geography Attributes File 1986). In Europe, the minor political subdivisions (parishes, townships, etc.) are so numerous that they are only being entered into the database as necessary. Name Name of the political subdivision. TABLE INFOTYPE Look-up table for information type names. The INFOTYPE table is a Look-up table that stores the full names for the three character information type codes. FIELDS ( ICode A3 InfoType A30 ) PRIMARY KEY ( ICode ) ICode Unique three character identifier for the information type. InfoType Name for the type of information (e.g. "algae", "dendrochronology"). ICode InfoType ------- ------------------------ AAR amino acid racemization ALG algae ARC archaeology C14 radiocarbon CES cesium-134, cesium-137 CHA charcoal CHI chironomids CLA cladocerans COL coleopterans DEN dendrochronology DIA diatoms ESR electron spin resonance FIS fission track FOR foraminiferans GEO geochemistry GRA granulometry INS other insects ISO other stable isotopes KAR potassium/argon LED lead-210 LOI loss on ignition LUM thermoluminescence MAC macrofossils MAG palaeomagnetism MOL molluscs OST ostracods OTH other OXY stable oxygen isotopes POL pollen RAD radon-226 RHI rhizopods TEF tephra URA u-series TABLE DESCR Look-up table for entity site-descriptions. The DESCR table is a Look-up table that stores the descriptions associated with each of the four character descriptor codes. FIELDS ( Descriptor A4 HigherDescr A4 Description A40 ) PRIMARY KEY ( Descriptor ) Descriptor Unique four character identifier for the entity site-descriptions. HigherDescr Identifier of the next higher descriptor in the hierarchy. HigherDescr=Descriptor at the top level of the hierarchy. Description Description of the modern entity site (e.g. "lacustrine", "mire"). Descr Description (indentation indicates hierarchy) -------- ----------------------------------------------------- AERI aerial AAIR air pollen sampler ARCH archaeological COAS coastal CEST estuarine FLUV fluvial LACU lacustrine LART artificial open-water LOTH other (e.g. Norfolk Broads) LRES reservoir LSTK stock pond LDRA drained lake LNAT natural open water LFLU fluvial origin (e.g. oxbow lake) LGLA glacial origin LPER periglacial origin LSOL solution hollow LUNK origin unknown LPRO pro-glacial lake LPLY playa LTRA pollen trap (e.g. Tauber trap in or on a lake) MARI marine OTHR other TERR terrestrial TCAV cave sediment TLUS loess TMIR mire (= peatland, > 30cm peat) TBOG bog TBLA blanket bog TRAI raised bog TFEN fen TVAL valley mire TSOL soligenous (mineraltrophic) mire TOWT open-water transition mire TFLO floating mire TFLP flood plain mire TSWA swamp (= forested peatland = forested wetland) TMOS moss polster TMSH marsh TSOI soil TMOR mor humus TTRA pollen trap (e.g. Tauber trap on terrestrial surface) TABLE RATIONAL Look-up table for dating rationales. The RATIONAL table is a Look-up table that stores the descriptions of the dating rationales (e.g. Tsuga decline) associated with each 3 character rationale code. FIELDS ( RCode A3 Rationale A60 ) PRIMARY KEY ( RCode ) RCode Unique three character identifier for the dating rationale. Rationale Description of the rationale for the date assignment. RCode Rationale -------- ------------------------------------ AMR Ambrosia rise ANL annual laminations BOT bottom of core C13 corrected for isotopic fractionation with C13 C14 uncorrected radiocarbon date CAJ adjusted for ancient carbon CAV averaged radiocarbon date CCA calibrated radiocarbon date CGT radiocarbon greater than date COM corrected for compaction DEN C14 date with dendrochronological correction ESH European settlement horizon GUE guess INT interpolated date OTH other POL pollen stratigraphic date SED sediment stratigraphic date TEF tephra date TOP top of core TSD Tsuga decline TABLE IGCPTYPE Look-up table for IGCP type region codes. The IGCPTYPE table is a Look-up table that stores the names and codes for the IGCP type regions. The IGCP catalogue includes a series of maps that indicate the type region boundaries, and a set of codes that uniquely identify each region. FIELDS ( IGCPtype A8 RegionName A80 ) PRIMARY KEY ( IGCPtype ) IGCPtype IGCP type region code. RegionName Name of the IGCP type region. 8.3. Research Tables TABLE P_GROUP Major group to which a pollen variable is assigned. Tables P_GROUP and M_GROUP are Research tables that store the group to which each pollen variable is assigned. These tables enable the user to define taxa into groups based on the life form and habitat of each taxon (e.g. trees, aquatics). The organisation of these tables allows for multiple sets of groupings. FIELDS ( Set# S Var# S GroupId A4 ) PRIMARY KEY ( Set#, Var# ) FOREIGN KEY ( Var# ) references P_VARS. ( GroupId ) references GROUPS. Set# Unique identifier for the group set. Var# Identifier for the pollen variable. GroupId Four-character identifier of the major group to which the pollen variable belongs (e.g. "AQUA" for aquatics). TABLE M_GROUP Major group to which a macrofossil variable is assigned. FIELDS ( Set# S Var# S GroupId A4 ) PRIMARY KEY ( Set#, Var# ) FOREIGN KEY ( Var# ) references M_VARS. ( GroupId ) references GROUPS. Set# Unique identifier for the group set. Var# Identifier for the macrofossil variable. GroupId Four-character identifier of the major group to which the macrofossil variable belongs. TABLE GROUPS Names for major groups. The GROUPS table is a Research table that acts as a look-up table for the names and codes for variable groups. FIELDS ( GroupId A4 GroupCode A1 GroupName A60 ) PRIMARY KEY ( GroupId ) ALTERNATE KEY ( GroupCode ) GroupId Unique four-character identifier for the major group (e.g. "UPHE" for upland herbs). GroupCode One character code for the major group. GroupName Name of the major group (e.g. "trees", "aquatics", "nonpollen"). TABLE CHRON Registers the chronologies developed for each entity. The CHRON table is a Research table that registers each chronology developed for an entity. This table also stores the name of the model used to derive the sample ages, the name of the person who prepared the chronology, and the date the chronology was last modified. FIELDS ( E# S Chron# S Preferred A1 Name A20 PreparedBy A30 DatePrepared A10 Model A60 ) PRIMARY KEY ( E#, Chron# ) FOREIGN KEY ( E# ) references ENTITY. E# Identifier for the entity. Chron# Unique identifier for the developed chronology. Preferred "Y" if the chronology is designated the preferred chronology for that entity, otherwise "N". Name Name given to the chronology (e.g. "author's preferred"). PreparedBy Name of the person who prepared the chronology. DatePrepared Date the chronology was prepared or last modified. Enter date as yyyy-mm-dd (e.g. "1977-08-25", or where the day is not reported, "1962-01-00", or if no date, "0000-00- 00"). Model Name of the model used to derive the chronology (e.g. "cubic spline curve"). TABLE AGEBASIS Dates used to establish age-depth. The AGEBASIS table is a Research table that stores the data used to derive the age-depth curve for each chronology created for an entity (see table P_AGEDPT and M_AGEDPT). FIELDS ( E# S Chron# S Sample# S DepthCM N Thickness N Age N AgeUp N AgeLo N RCode A3 ) PRIMARY KEY ( E#, Chron#, Sample# ) FOREIGN KEY ( E#, Chron# ) references CHRON. ( RCode ) references RATIONAL. E# Identifier for the entity. Chron# Identifier for the chronology. Sample# Unique identifier for the dated sample. DepthCM Depth of the sample (cm). Thickness Thickness of the sample (cm). Age Estimated age of the sample. AgeUp Upper bound for the estimated age. AgeLo Lower bound for the estimated age. RCode Three character code for the description of the rationale for the age. TABLE CHRON&& Notes on age-depth construction, including model used. The CHRON&& table is a Research table that stores notes on the derivation of the age-depth data (stored in tables P_AGEDPT and M_AGEDPT) for any of an entity's chronologies. The name of the age-model used should be recorded in this table. Notes for a given entity and chronology are stored as any number of 60 character lines of text. FIELDS ( E# S Chron# S Line# S Text A60 ) PRIMARY KEY ( E#, Chron#, Line# ) FOREIGN KEY ( E#, Chron# ) references CHRON. E# Identifier for the entity. Chron# Identifier for the chronology. Line# Unique identifier for the line. Text Additional notes on the chronology (notes are any number of 60 character lines of text). TABLE P_AGEDPT Pollen age-depths derived from age models. The P_AGEDPT and M_AGEDPT tables are Research tables that store fitted age estimates for the sample depths for each chronology specified for an entity. Names for each chronology are stored in the CHRON table. The age-depth data are generated by applying the age-model to the data in the AGEBASIS table. FIELDS ( E# S Chron# S Sample# S AgeBP N AgeUp N AgeLo N DepTime N ) PRIMARY KEY ( E#, Chron#, Sample# ) FOREIGN KEY ( E#, Chron# ) references CHRON. ( E#, Sample# ) references P_SAMPLE. E# Identifier for the entity. Chron# Identifier for the chronology. Sample# Identifier for the depth of the sample. AgeBP Age of the sample in years BP. AgeUp Upper bound of the age. AgeLo Lower bound of the age. DepTime Deposition time (yr/cm). TABLE M_AGEDPT Macrofossil age-depths derived from age models. FIELDS ( E# S Chron# S Sample# S AgeBP N AgeUp N AgeLo N DepTime N ) PRIMARY KEY ( E#, Chron#, Sample# ) FOREIGN KEY ( E#, Chron# ) references CHRON. ( E#, Sample# ) references P_SAMPLE. E# Identifier for the entity. Chron# Identifier for the chronology. Sample# Identifier for the depth of the sample. AgeBP Age of the sample in years BP. AgeUp Upper bound of the age. AgeLo Lower bound of the age. DepTime Deposition time (yr/cm). TABLE P_VTRANS Pollen variable name translation table. The P_VTRANS and M_VTRANS tables are Research tables that store variable names in alternate or preferred style to that stored in P_VARS. This alternate style is then available for data output. FIELDS ( Var# S TranslatesTo A60 ) PRIMARY KEY ( Var# ) FOREIGN KEY ( Var# ) references P_VARS. Var# Identifier for the pollen variable. TranslatesTo Alternate or preferred name for this pollen variable (e.g. "Betula (arbustif)"). TABLE M_VTRANS Macrofossil variable name translation table. FIELDS ( Var# S TranslatesTo A60 ) PRIMARY KEY ( Var# ) FOREIGN KEY ( Var# ) references M_VARS. Var# Identifier for the macrofossil variable. TranslatesTo Alternate or preferred name for this macrofossil variable. 8.4. System Tables TABLE SYSIDN Database identification table. The SYSIDN table is a System table that stores the identity of a database. There will be exactly one record in this table. FIELDS ( Id A10 Name A60 Place A60 Type A1 ) PRIMARY KEY ( Id ) Id Unique identifier for the database. It can be up to 10 characters in length (e.g. "EPD"). Name Full name of the database. Place Place where the database is located (e.g. "Montreal, Canada"). Type Type of database. It must be either C=Central or R=Regional. TABLE SYSCAT Names of database tables. The SYSCAT table stores the name and category of every table in the Pollen Database. Table categories are System, Base, and View. The Base tables are further divided into Archival, Lookup, and Research subcategories. The purpose of this table is to enable programs to access information on the structure or keys of a table given its name or its category. FIELDS ( T# S TableName A8 Category A20 ) PRIMARY KEY ( T# ) ALTERNATE KEY ( TableName ) T# Unique identifier for the table (T#'s less than 100 are reserved for the system tables). TableName Name of the table. Category Category of the table. It must be one of the following: "system", "base-archival", "base-lookup", "base-research", or "view". TABLE SYSCOL Names and data types of database columns. The SYSCOL table stores the name, data type, and domain type for each column (field) of each table in the Pollen Database. The column name is the name of the Paradox field, and data type is the Paradox data type (e.g. A20). Domain is not currently implemented. FIELDS ( T# S C# S ColumnName A20 DataType A4 Domain A20 ) PRIMARY KEY ( T#, C# ) FOREIGN KEY ( T# ) references SYSCAT. T# Identifier for the table. C# Unique identifier for the column. ColumnName Name of the column. DataType Type of data in the column (S=short integer, N=floating point number, An=alphanumeric, where 1 <= n <= 255). Domain Describes the range of valid values allowed in the column. TABLE SYSIDX Identifies table columns that comprise primary, alternate, or foreign keys. The SYSIDX table stores the keys that exist on each table in the Pollen Database. Key types that are recognized include, primary, alternate, and foreign. This table records each column comprising the key. FIELDS ( KeyType A1 T# S C# S ) PRIMARY KEY ( KeyType, T#, C# ) FOREIGN KEY ( T#, C# ) references SYSCOL. KeyType Identifier for the type of the key (P=primary, A=alternate, F=foreign). T# Identifier for the table. C# Identifier for the column. TABLE SYSFKS Identifies foreign keys - their attributes and the tables they reference. The SYSFKS table stores the columns comprising each foreign key in the Pollen Database and the table that is referenced by each foreign key. FIELDS ( FK# S T# S C# S RefT# S ) PRIMARY KEY ( FK#, T#, C# ) FOREIGN KEY ( T#, C# ) references SYSCOL. ( RefT# ) references SYSCAT. FK# Unique identifier for the foreign key. T# Identifier for the table. C# Identifier for the column. RefT# Identifier for the table referenced by the foreign key. TABLE DBLOG Data compilation history. Table DBLOG stores a record of the compilation history of the database: when data or the database structure were modified, how, and by whom. FIELDS ( Date D Action# S Compiler A2 ) PRIMARY KEY ( Date, Action# ) FOREIGN KEY ( Action# ) references DBACT. Date Date the compilation or modification was performed. Action# Identifier for the action performed. Compiler Initials of the data compiler. TABLE DBACT Data compilation history - actions taken. The DBACT table stores a record of the actions performed on the database. FIELDS ( Action# S Action A255 ) PRIMARY KEY ( Action# ) Action# Unique identifier for the action performed. Action Description of the action performed. TABLE DBENT Data compilation history - entities affected. The DBENT table stores a record of the entities affected by a given action. FIELDS ( Date D Action# S E# S ) PRIMARY KEY ( Date, Action# ) FOREIGN KEY ( Action# ) references DBACT. ( E# ) references ENTITY. Date Date the compilation or modification was performed. Action# Identifier for the action performed. E# Identifier for the entity affected. 8.5. Views TABLE P_VARIS View on P_VAR - pollen variable taxonomic hierarchy. The P_VARIS and M_VARIS tables are Views that store the taxonomic hierarchy of variables in the Pollen Database. These views can be used to query at any level in the hierarchy (e.g. Juglans includes J. cinerea, J. nigra, and J. undiff.). FIELDS ( Var# S IsAlso# S ) PRIMARY KEY ( Var#, IsAlso# ) FOREIGN KEY ( Var# ) references P_VARS. ( IsAlso# ) references P_VARS. Var# Identifier for the variable. IsAlso# Identifier for the variable that Var# is also one of (e.g. "Acer rubrum" is also an "Acer"). TABLE M_VARIS View on M_VAR - macrofossil variable taxonomic hierarchy. FIELDS ( Var# S IsAlso# S ) PRIMARY KEY ( Var#, IsAlso# ) FOREIGN KEY ( Var# ) references M_VARS. ( IsAlso# ) references M_VARS. Var# Identifier for the variable. IsAlso# Identifier for the variable that Var# is also one of. TABLE DESCRIS Description-Is-Also hierarchy: view on table DESCR. The DESCRIS table is a Look-up table that stores the hierarchy of modern entity site-descriptors. This table can be used to query any level in the descriptor hierarchy (e.g. to query for bogs, or to query for mires, which include bogs, fens, and swamps). FIELDS ( Descriptor A4 IsAlsoA A4 ) PRIMARY KEY ( Descriptor, IsAlsoA ) FOREIGN KEY ( Descriptor ) references DESCR. ( IsAlsoA ) references DESCR. Descriptor Identifier for the entity site-description. IsAlsoA Identifier that the Descriptor is also one of (e.g. a "fen" is also a "mire"). TABLE DATATYPS Data types: view on tables SYSCAT and SYSCOL. The DATATYPS table is a view based on tables SYSCAT and SYSCOL that contains the table name, column name, and data type for each column in the Pollen Database. This view is used by software to generate or check a data type, making software less susceptible to changes in Pollen Database structure. FIELDS ( TblName A8 ColName A20 DataType A4 ) PRIMARY KEY ( TblName, ColName ) TblName Name of a Pollen Database table. ColName Name of a column in that table. DataType Data type of that column. Pollen Database Manual i