Global Plant Checklist: Data Definitions
Global Plant Checklist: Data Definitions
IOPI DDS Working Group
Compiled by F.A. Bisby
in consultation with members of the Dataset Definition & Standards Working Group:
W. Berendsohn, G. F. Russell, K. L. Wilson and J. L. Zarucchi.
2.1. Author/Editor Team
2.2. "In" another citation
2.3. Year
2.4. Title, or Database Full Name
2.5. Periodical Abbreviation
2.6. Volume and/or number, or database edition number
2.7. Page range
2.8. Precise page(s) citation
2.9. Database acronym or short name
2.10. Database part or file
2.11. Database export date
3.1. Person Name and Initials
3.2. Author Recommended Form
3.3. Institutional Acronym
3.4. Team membership
4.1. Taxon name link
4.2. Taxonomic Note
4.3 . Note Reference
4.4. Taxonomic Co-ordinator Team
4.5. Date(s) of taxonomic co-ordination
5.1. Incoming Geographical Area Name
5.2. Nature of Incoming Area
5.3. Standardised Geographical Area Name
5.4. Derived data flag for 5.3
5.5. Incoming Occurrence Status
5.6. Occurrence Status System in Use
5.7. Standardised Occurrence Status
5.8. Derived data flag for 5.7
5.9. Incoming record source
5.10. Incoming Name Link
5.11. Current Taxon Name Link
5.12. IOPI Geographic Co-ordination Team
5.13. Date of geographic co-ordination
6.1. Occurrence in Standardised Continents [derived]
6.2. Global Native Distribution Phrase
6.3. Global Introduction/Cultivation Phrase
6.4. Global completeness flag
6.5. IOPI Geographic Co-ordination Team
6.6. Date of acceptance by geographic co-ordination team
This document will be developed through a number of versions to provide working botanical definitions of the fields used in the IOPI Global Plant Checklist. In practice there are at least three slightly different sets of fields to be defined - the data held in the main IOPI database or network of databases, the data to be supplied by participating centres and the data to be seen by a user, say in a printed checklist or in an electronic view of the database. These are referred to as the "IOPI dataset", the "incoming data" and the "output data". The incoming data and the output data should clearly be subsets of the IOPI dataset. The question os the precise structure, format and medium of the various datasets is not the subject of this document.
It is assumed that the Global Plant Checklist will be composed by uniting datasets coming from a variety of participating centres. Some of the incoming datasets may have been created with the IOPI Global Checklist data definitions in mind, but others may have been created with their own data standards differing by various degrees from those desired by IOPI. It is therefore important to distinguish the ideal IOPI dataset from the range of datasets it is willing to accept, both in the presence or absence of certain fields, the way in which they are connected, and in the definition of what they contain. Certain fields may be obligatory (without these the records cannot be accepted), and others optional (the data will be accepted if available). Similarly within one field there may be some acceptable tolerances for variant definitions and other variants that are not acceptable.
In general high quality synonymised taxon checklists have various integrity standards which may not be stated. A simple example would be that no species is listed twice. In compiling a Global Plant Checklist from a variety of incoming datasets IOPI will need to be careful that the necessary checks do apply to the composite checklist created. Later versions of this document will list some of these integrity checks appropriate to certain items.
Lastly, it must be stated clearly that the checklist output is a list of taxa, that is a list of the plant species thought to exist (or to have existed if extinct now). For each taxon (mostly species) there will be a single record. IOPI will provide an accepted name, in some cases one or more alternative names according to alternative classifications, and in many cases one or more synonyms for each.
The phrase "Full Name" is used to mean the complete entity of a full species, species aggregate, subspecies or botanical variety name including the latin names, the authors, and the applicable hybrid/aggregate/infraspecific markers and flags.
Because the taxa listed in the IOPI dataset are primarily species, most full names will be species binomials. But provision must be made for the occurrence of subspecies, botanical variety and other infraspecific trinomial names, species aggregates, and named hybrids.
1.1 Full Name Identifier
Identifier ( an internal and usually invisible arbitrary number) given by the software to represent the full name. This will be used in the checklist to link with the incoming name link (5.10) under which geographical data is first received. But in subsequent developments it will be used to link with the incoming name under which other types of botanical data are received (e.g. phytochemistry, germplasm etc.).
In the case of a preferred taxon name, or a provisional taxon name, this is the name identifier to which alternative taxon names and synonyms are linked.
1.2 Taxon Name Link
The software must provide links between the zero-many full names that are synonyms and the preferred taxon name or provisional taxon name of the species to which they apply. Botanical rules apply to these links.
-. each species must have exactly one full name which is a preferred or provisional taxon name.
-. each species may have from zero to many full names which are alternative taxon names
-. each species may have from zero to many full names which are synonyms in the loose sense.
1.3 Name Status
Incoming Data:. Obligatory.
IOPI Dataset:. Obligatory.
Form:. . i). Preferred taxon name
.. . ii). Provisional taxon name
.. . iii). Alternative taxon name
.. . iv). Synonym
Each full name must be given a name status: it is either a preferred taxon name, or provisional taxon name, an alternative taxon name or a synonym. The synonym category is used loosely to include misapplied names and orthographic variants, as well as true synonyms.
1.4 Taxon Usage Reference(s) (1-many)
IOPI Dataset: Obligatory for full names with preferred or provisional or alternative taxon name status in 1.3. Omitted for those with synonym status in 1.3.
Incoming Data: Optional. If absent IOPI dataset will list the name of the incoming dataset as both the source and the usage reference.
Multiple Entry
Form: Reference Citation.
Note: this is the citation of a source (or sources) that give the same taxon (that is, its circumscription) with this same preferred or accepted name status (that is, its nomenclature). Modern and widely available works, such as recent floras, are desirable.
1.5 Synonym Usage Reference(s)
IOPI Data: Obligatory for alternative taxon names and for synonyms.
Incoming Data: Desirable for alternative taxon names and for synonyms. Where absent in these cases IOPI should cite the incoming dataset as the reference.
Multiple Entry
Form: Reference Citation.
Note: this is the cited source (or sources) of the synonymic usage of the name where the name as a synonym for a taxon with the same preferred name or provisional name as used here by IOPI. Alternative taxon names should have one or more entries under 1.4 (references in which they are cited as preferred or accepted names) and one or more entries under 1.5 (references in which they are cited as synonyms of the preferred or provisional taxon name pointed to by 1.2).
1.6 Higher Taxon Name
Name of higher taxon using system selected by IOPI or Pointer to this name.
IOPI Dataset: Obligatory, each family (1.7) must be assigned to one higher taxon.
Incoming Datasets: Optional. Either included if donor has agreed the system in use with IOPI, or omitted and filled by IOPI when a dataset is imported.
Example: Incoming dataset for Compositae arrives without this data, IOPI enters "Angiospermae" for all the records.
1.7 Family Name
Name of family to which the genus belongs, initially using the Kew List of Genera (Brummitt 1992), but subsequently using the family assignment preferred by the taxonomic co-ordinators. This requires some higher level co-operation between co-ordinators,
to ensure that, for instance, an isolated genus is not excluded from both of its possible assignments.
IOPI Dataset: Obligatory, each genus (1.8) occurring in a preferred or provisional taxon name must be assigned to one family.
Incoming Dataset: Obligatory for multi-family dataset (eg. a flora dataset). Optional for a single family dataset. If not supplied for a single family dataset then filled by IOPI when the dataset is imported. (Example: within Compositae dataset there
is no data for family name, but on importation by IOPI, family name is filled for all taxa with "Compositae").
1.8 Genus name
Form: genus name as occurring in every full name, and including hybrid generic names. Generic synonyms and generic orthographic variants will only occur in the database if full names containing them have been entered.
IOPI Dataset: Obligatory.
Incoming Datasets: Obligatory. The genus name must be spelled out in full. Datasets containing abbreviated full names (e.g. P.sativum) cannot be imported in that form.
1.9 Intergeneric hybrid symbol
Form: a capital letter X. This is converted to a large multiplication sign in output, where possible. The reason for this is that most computers have no multiplication sign in the internal character set.
IOPI Dataset: Obligatory when applicable.
Incoming Dataset: Filled when applicable, optional in the sense that an incoming dataset may both lack this field and lack instances when it would be needed. Care should be taken to ensure that the X has not been included as the first letter of hybrid generic names.
1.10 Species epithet
Form: epithet.
IOPI Dataset: Obligatory.
Incoming Dataset: Obligatory.
1.11 Interspecific hybrid symbol
IOPI Dataset: When applicable, obligatory.
Incoming Data: When applicable, obligatory. Care should be taken to ensure that the x has not been included as the first letter of the epithet.
Form: A lower case alphabetic x in IOPI and incoming data, printed as a small multiplication sign in printed output where possible. The reason for this is that most computers have no multiplication sign in the internal character set. Only named interspecific hybrids will be included, and not hybrids given by formula.
1.12 Aggregate/sensu lato indicator
Form: the abbreviation "agg."
IOPI Dataset: When applicable, obligatory.
Incoming Datasets: When applicable, obligatory.
Checklist integrity rules: Full names differing only in this item may occur as the preferred name of two taxa in the database only if one is an aggregate and the other a species. A full name may occur as the preferred or provisional taxon name of only one species. Similarly, a full name may occur as the preferred or provisional name of only one species aggregate.
1.13 Aggregate membership links
Form: a pointer. In the full name of a species within a species aggregate, this provides a link to the full name of the species aggregate to which it belongs.
Checklist integrity rules: A species may belong to only one species aggregate.
1.14 Infraspecific category indicator
Form: One of the following abbreviations only
.. . "subsp." (but not "ssp.")
.. . "var."
.. . "f." (but not "forma")
IOPI Dataset: when applicable (when 1.15 is filled), obligatory.
Incoming Datasets: when applicable (when 1.15 is filled), obligatory.
Variants: "ssp." and "forma" may occur in incoming data. These are acceptable and converted to "subsp." and "f." by IOPI.
1.15 Infraspecific epithet
Form: epithet.
IOPI Dataset: when applicable, obligatory.
Incoming Datasets: when applicable, obligatory.
1.16 Combination author team
Data item: the combination author team is the set of validating authors for the combination.
Form: an ordered list of 1 - many individual authors constituting what is here called a "team". Each author will be referred to by the author recommended form using the TDWG/Kew Standard (Brummitt & Powell 1992).
IOPI Dataset: obligatory.
Incoming Datasets: obligatory.
Variants: incoming datasets will have author teams structured in many different ways. A major validating exercise will be undertaken as each dataset is imported. It is anticipated that four particular sets of abbreviations may be in use:
.. 1) Brummitt & Powell 1992, with diacritics.(The present TDWG Standard)
.. 2) Brummitt & Powell 1992, variants without diacritics.
.. 3) Meikle 1984, with diacritics, plus additions. (The former TDWG Standard)
.. 4) Meikle 1984, variants without diacritics, plus additions.
Further variations will occur between datasets that give all authors, and those that abbreviate teams of three or more to A et al. Some datasets may give author names in full, without abbreviation and with diacritics, and the post-1984 additions (see 3
& 4 above) will normally be in full, either with or without diacritics.
1.17 Parenthetical author team
Data item: in some cases a species was first described under a different name, the basionym. In such cases the original author team is usually written in parenthases after the epithet and before the validating author team.
Form: an ordered list of 1 - many individual authors constituting what is here called a "team". Each author will be referred to by the author recommended form using the TDWG/Kew Standard (Brummitt & Powell 1992).
IOPI Dataset: when applicable, desirable.
Incoming Datasets: when applicable, desirable.
Variants: as for the validating author team, above.
1.18 Reference(s) to type data
Data item: this is a reference to a work that includes data on the type specimen for this name. For the present, this is merely a pointer to where the data can be found: the data itself is not to be imported. However provision is being made to import such data at a later stage of the project.
Form: Reference citation to publication or database.
IOPI Dataset: optional.
Incoming Datasets: optional. Import if available in incoming data.
Variants: if type data itself is in an incoming dataset, do not include the data, but cite the incoming dataset as the reference.
1.19 Sensu Marker
Form: a marker that the word "sensu" should be printed preceding the combination author team in output. This indicates that the full name carrying the marker was at some time misapplied to a taxon other than the one to which the similar name is correctly
applied. The sensu version of the name is treated as if a synonym.
IOPI Dataset: when applicable, obligatory.
Incoming Datasets: when applicable, obligatory (or highly desirable).
Variants: some taxonomic databases do not account for misapplications.
Checklist integrity rules: Two or more versions of a full name, one without "sensu" and one or more others with "sensu", and also differing in their combination author teams, are treated as separate full names, each with its own record.
1.20 Misapplied name presence warning flag
Data item: a flag to warn that a name has been used in a different, misapplied sense elsewhere in the checklist. This warning is useful to people using the correct application of the name.
IOPI Dataset: Obligatory when applicable.
Incoming Data: Optional, desirable when applicable.
Variants: some taxonomic databases do not account for misapplications.
Checklist integrity rules: Misapplied names are treated in the IOPI Dataset as distinct full names and as a class of synonym.
1.21 Homonym flag
Data item: a flag to warn that a combination has been published by more than one author team. Usually such homonyms are represented by full names that differ in the combination author team. This warning enables people using one of the homonyms to know that the other(s) exist.
IOPI Dataset: Obligatory when applicable.
Incoming Datasets: Optional when applicable. They can be detected by IOPI on importation. Sometimes it is the bringing together of datasets that reveals the homonymy.
Note: In traditional nomenclatural parlance it is usual to refer to one or more later homonyms as a homonym. If the first occurrence on the name is for instance the accepted name of a taxon, this is not normally referred to as a homonym. Here we adopt
a different practice. So that the database can warn a user of the existence of homonyms (say if the user enters a name without authors), it is necessary to flag all homonyms, not just the later homonyms.
Integrity rules: Within the IOPI checklist a preferred or provisional combination must be unique amongst all combinations unless it is a misapplied name, a homonym, or the name of a species aggregate, in which cases the full names are distinguished by the entries in 1.19 (misapplied names,by sensu), 1.16 (homonyms, by author team) or 1.12 (aggregates, by "agg.").
1.22 Doubtful synonym flag
Data item: a flag to indicate that a synonym is a doubtful synonym.
Form: a flag set on or off.
IOPI Dataset: Obligatory where applicable.
Incoming Datasets: Optional, but unassigned names cannot be imported.
Output Datasets: Optional, software must allow choice as to whether doubtful synonyms are included in output.
Checklist integrity rules: this flag may only be set if 1.3 (name status) is "synonym".
1.23 Pro Parte synonym flag
Data item: It is traditional nomenclatural practice to use the phrase pro parte synonym only for the partial synonymies that do not involve the type. In such a case, the synonymy that involves the type is not labelled. In the IOPI dataset we adopt a different practice. All parts of a partial synonymy, including the part involving the type, are marked with this flag. Each part is treated as a separate full name and linked as a synonym. This allows the software to alert a user to all parts of the pro parte synonymy if the name is selected.
Form: a flag set on or off.
IOPI Dataset: obligatory when applicable.
Incoming datasets: optional, desirable when applicable.
Variants: some taxonomic databases do not account for pro parte synonyms. Some that do mark the pro parte synonyms apart from the one involving the type.
1.24 Orthographic variant flag
Data item: a flag used to mark an incorrect orthographic variant. A separate full name with the correct orthography should occur as the accepted name or as another synonym of the same taxon.
Form: a flag set on or off.
IOPI Dataset: obligatory where applicable.
Incoming Datasets: optional, desirable when applicable.
1.25 Name Source(s)
Form: reference citation(s), multiple entry.
IOPI Dataset: Obligatory.
Incoming Datasets: Optional. If present IOPI will give the double citation of the form "taxonomist x in database y". If absent IOPI will cite the database.
1.26 IOPI taxonomic co-ordinator team(s)
Data item: the set of 1 - many taxonomic co-ordinators responsible for the taxonomic view presented in the treatment of this name. New entries are made on the occasion of subsequent co-ordination by the same or another team.
Form: an ordered set of 1 - many people, where possible referred to using the author recommended form from the TDWG/Kew Standard (Brummitt & Powell 1992). Multiple entry linked to 1.27 (date).
IOPI Dataset: Obligatory from the start in route A families, defined as those handled by a family specialist organisation and imported from a family dataset(eg. Cactaceae, Leguminosae). In route B families, (those being imported only from regional data
sets) left blank when the taxon is first imported from a regional dataset, obligatory from the date of editing by the IOPI taxonomic co-ordinator team.
Incoming Datasets: Obligatory in members of route A families from family datasets. Not required for members of route B families when initially provided in a regional dataset.
1.27 Date(s) of completion by co-ordinator team(s)
Data item: date of completion of co-ordination of this taxon by the appropriate IOPI co-ordinator team. Use the date of completion, or the date of posting or handing over to IOPI.
Form: date, linked to 1.26 (IOPI taxonomic co-ordinator team).
IOPI Dataset: obligatory for members of route A families, and optional for members of route B families.
Incoming Datasets: desirable for members of route A families from family datasets. If absent, date of export of the family dataset used instead. Not required for members of route B families from regional datasets.
Variants: may be available only as a year from some datasets, which is acceptable.
Used to fill any reference citation, such as 1.4, 1.5, 1.18 1.25, 4.3 and 5.9. Use of item 2.2 allows any reference to refer to work within another reference, as is often used to cite a particular taxonomist's work within a flora or a database. The refe
rence citation can be used to cite articles, taxonomic contributions, books, databases, and personal communications or informal documents.
2.1 Author/editor team
Data item: the team of 1 - many people whose work is being cited.
Form: an ordered set of 1 - many people, each detailed in a person citation.
2.2 "In" another citation
Data item: this is a pointer to another reference within which the present reference occurs.
Form: reference citation.
2.3 Year
Data item: Unverified year of publication as given in the front matter of the publication unless modified in TL-2 as a result of verification. Use this item for printed and paper documents, but item 2.11 (database export date) for databases.
2.4 Title, or database full name
Data item: for older books standardise on the short titles in the TDWG/IAPT Standard,TL-2.
2.5 Periodical abbreviation
Form: Abbreviation according to the TDWG/Hunt Inst. Standard, BPH/S.
Variants: Other abbreviations, including the former TDWG/Hunt Inst. Standard, BPH, will be encountered.
2.6 Volume and/or Number, or database edition number
Data item: for publications give the appropriate volume and/or number. For databases give the edition number if available.
2.7 Page range
Form: Give the full range of pages for a reference.
2.8 Precise page(s) citation
Form: give the precise page or page range within a reference, when citing a reference within another using item 2.2 ("In" another citation).
2.9 Database acronym or short name
Form: give the acronym or short name for a database, giving punctuation, gaps and capitalisation as used in output and/or publicity materials of the database.
2.10 Database part or file
Form: give the part or file of the database from which the cited materials come.
2.11 Database export date
Form: give the date when the cited materials were seen or exported from the database.
Used to detail the people in the various "teams" listed under 1.26, 2.1, 4.4, 5.12 and 6.5.
3.1 Person name & initials
Form: Surname and initials of person as in the complete names of the TDWG/Kew Standard (Brummitt & Powell 1992). Unlisted persons are given using the principles used by Brummitt & Powell 1992.
IOPI Dataset: Obligatory.
Incoming Datasets: Optional, as incoming data may alternatively use author recommended forms as placed in 3.2.
Note: Care needed with diacritics, cyrillic names, chinese names, compound names of Spanish or Portuguese origin, prefixes in Dutch, Belgian, South African and other names, and with Ethiopian names.
3.2 Author recommended form
IOPI Dataset: Obligatory, use look up table from TDWG/Kew Standard (Brummitt & Powell 1992).
Incoming Datasets: Optional as incoming data may use complete names suitable for 3.1.
Note: As 3.1, care needed.
3.3 Institutional acronym
Data item: the institution at which the person is employed, or which functions as the person's main base.
Form: institution code from the TDWG/IAPT Standard, Index Herbariorum (8th Ed.).
IOPI Dataset: Optional.
Incoming Datasets: Optional.
3.4 Team membership
Data item: links giving the position and membership of the person in the teams listed under 1.26, 2.1, 4.4, 5.12, and 6.5.
Form: as below (4.1 - 4.5), multiple entry.
IOPI Dataset: optional.
Incoming datasets: optional.
Variants: variants with references, plant names or code numbers inside the notes cannot be imported.
4.1 Taxon name link
Data item: the taxon to which the note applies.
Form: pointer to full name identifier of the preferred taxon name.
IOPI Dataset: obligatory for each note.
Incoming Datasets: obligatory for each note.
4.2 Taxonomic note
Data item: brief free text note from incoming datasets or from co-ordinator team. One thought per note and one note per thought.
Form: Brief 1-line text note. Should not contain reference citations or plant names.
IOPI Dataset: obligatory for each note.
Incoming Datasets: obligatory for each note.
4.3 Note reference
Data item: reference(s) to the source(s) of information given or commented on in the note.
Form: reference(s), multiple entry.
IOPI Dataset: Optional.
Incoming Datasets: Optional. If absent from notes coming from incoming datasets, then the database cited as the source.
4.4 Taxonomic co-ordinator team
Data item: IOPI taxonomic co-ordinator team authorising continued use of the note.
IOPI Dataset: optional, linked to 4.5 (date(s) of taxonomic co-ordination).
Incoming Datasets: optional for taxa from route A families, not requested for taxa from route B families..
4.5 Date(s) of taxonomic co-ordination
Data item: date of authorisation of the note by IOPI taxonomic co-ordinator team.
Form: date, linked to 4.4 (taxonomic co-ordinator team).
5.1 Incoming geographical area name
Form: Name or code of geographical area as it appears in the incoming dataset. This will be kept unchanged.
IOPI Dataset: Obligatory for each individual record.
Incoming Datasets: Obligatory for each individual record.
Variants: It does not matter that these areas may be of widely different sorts in different incoming datasets provided that item 5.2 (nature of incoming area is also filled by IOPI, if not by the incoming dataset).
5.2 Nature of incoming area
Form: A label indicating one of the standardised systems of areas , one of the widely used systems, or a system unique to one of the incoming datasets,eg:
.. BRU. - Botanical Recording Units or "Brummitts" (Hollis & Brummitt Level 4, TDWG Standard).
.. BC. - Botanical Countries (Hollis & Brummitt Level 3, TDWG Standard).
.. ISO. - Political Countries, ISO 3166 (Hollis & Brummitt, TDWG Standard)
.. FE. - Flora Europaea System
.. MCh. - MedChecklist System
.. TRP. - TROPICOS System
IOPI Dataset: Obligatory for each individual record.
Incoming Datasets: Desirable for each individual record, as some datasets may contain mixtures of areas from different systems. If the operators of an incoming dataset offer a choice, then it would be much preferrable to receive all geographic records as BRU's. If the label is absent, or the system unique to the dataset, or the data all from one area, the label will be provided by IOPI.
5.3 Standardised geographical area name
Data item: this item records the occurrence in one of the TDWG standardised areas. The record may be generated by copying the record from 5.1 (incoming geographical area name) if 5.2 (nature of incoming area) shows that it is already in the form of the T
DWG standardised areas, that is if the label in 5.2 is BRU, BC or ISO. If the label in 5.2 is not one of these, then the record is generated by interpretation on the part of the appropriate IOPI geographical co-ordinator. In some cases the incoming area
may, despite a different label, be identical to a standardised area, eg "Switzerland" in FE is identical to "Switzerland" in BRU. In other cases the areas may not match, and the co-ordinator will have to select a standardised area that includes the incoming area, e.g. "Amazonas" in the Flora of Colombia is within "Colombia" in the BRU system.
Note: the BRU system of Hollis & Brummitt has been carefully devised so that if BRU records are available, BC (botanical country) and ISO (political country) records can be generated from them automatically. It is consequently much preferrable for IOPI
to receive data as BRU data, or to generate BRU data from the incoming records. However BRU data is more dissected than country data, and it is unrealistsic to think it will be available for large parts of the world. Also the process of interpretting non-standardised areas normally involves some degredation of the resolution, as say in the example of an FE record for "Spain", which because of the inclusion of Andorra and Gibraltar, cannot be pinned down to an exact BRU. Consequently early editions of the IOPI checklist database will undoubtedly contain an inconsistent mixture of areas. If in future years all non-BRU records could be reassessed to the precision of BRU records, then the inconsistencies could be gradually removed.
Form: name or code from one of the three TDWG-endorsed sets of areas:
.. BRU. - Botanical Recording Units or "Brummitts" (Hollis & Brummitt, Level 4, TDWG Standard)
.. BC. - Botanical Countries (Hollis & Brummitt Level 3 , TDWG Standard).
.. ISO. - Political Countries, ISO 3166 (Hollis & Brummitt, TDWG Standard).
IOPI Dataset: Optional.
Incoming Datasets: Not requested. (Incoming standardised data placed in 5.1, incoming geographical area name.)
Variants: no variants allowed.
5.4 Derived data flag for 5.3
Data item: a flag to mark if the data in 5.3 (standardised geographical area name) is derived data produced by interpretation of 5.1 (incoming geographical area name). If the flag is not set, then data in 5.3 has been copied from 5.1 without alteration.
Form: a flag set on or off.
IOPI Dataset: obligatory for each record in 5.3.
Incoming Datasets: not requested.
5.5 Incoming occurrence status
Form: Plant status symbol as contained in or given by the suppliers of the incoming dataset. This will be kept unchanged.
IOPI Dataset: obligatory.
Incoming Datasets: highly desirable. Can be filled in by IOPI if all records in the incoming dataset are known to be of the same occurrence status, eg "native" records only.
Variants: a wide variety of systems are to be expected, and are acceptable.
5.6 Occurrence status system in use
Form: a label indicating whether the incoming dataset uses status categories from the POSS system, from other widely used systems or of a system unique to this incoming dataset, eg:
.. POSS. . - Plant Occurrence and Status System (unpublished TDWG Standard)
.. MCh-SS. - MedChecklist status system
.. ILDIS-SS. - ILDIS status system
IOPI Dataset: Obligatory.
Incoming Dataset: highly desirable. If absent, may be filled in by IOPI if all records knoen to be of the same status.
5.7 Standardised occurrence status
Data item: a status from the standardised POSS system. This incorporates three elements - nativeness, whether introduced and cultivation status. The record may either be copied directly from 5.5 (incoming occurrence status) if the incoming occurrence system in use was POSS (as labelled in 5.6), or it may be assigned by the appropriate IOPI geographic
co-ordinator interpretting the incoming record.
Form: code from the TDWG Standard POSS system.
IOPI Dataset: Optional, usually added by IOPI.
Incoming Data: not requested. (Incoming occurrence status placed in item 5.5, incoming occurrence status.)
Variants: no variants allowed.
5.8 Derived data flag for 5.7
Data item: a flag to indicate if the status in 5.7 (standardised occurrence status) was derived by interpretation of the incoming record in 5.5 (incoming occurrence status). If the flag is not set, then the data in 5.7 has been copied from 5.5 without alteration.
Form: a flag set on or off.
IOPI Dataset: obligatory for each record in 5.7.
Incoming datasets: not requested.
5.9 Incoming record source
Data item: crediting the source of the geographic individual record. Where the incoming dataset has internal references to its sources, the intention is to create a double refernce such as publication x in database y. This is partly to allow credit both to the incoming dataset and the primary source, and to permit some checking where the same primary record is received from two incoming datasets.
Form: a reference citation.
IOPI Dataset: Obligatory, usually added automatically by IOPI.
Incoming Dataset: Optional. If dataset y credits source x, this becomes a reference x "in" y.
5.10 Incoming name link
Form: Pointer to the full name to which the incoming geographical record is linked in the incoming data. This remains unchanged.
IOPI dataset: obligatory.
Incoming Datasets: obligatory.
5.11 Current taxon name link
Data item: the currently preferred taxon name used by IOPI for the taxon to which this record applies.
Form: pointer to a full name identifier.
IOPI Dataset: Desirable.
Incoming Dataset: Not applicable. (the current taxon name used by the incoming dataset goes into 5.10, the incoming name link).
5.12 IOPI geographic co-ordinator team
Data item: the appropriate IOPI geographic co-ordinator team adopting this whole geographic individual record. In particular "adopting" means agreeing the area (5.3), the occurrence status (5.7) and the current taxon name (5.11).
Form: ordered list of 1-many person citations forming a "team".
IOPI Dataset: Desirable.
Incoming Dataset: Desirable for route A families from family datasets, but not applicable for route B families coming from regional datasets.
5.13 Date of geographic co-ordination
Data item: date of co-ordination of this record by the co-ordinator team.
Form: date.
IOPI Dataset: obligatory for each record filled in items 5.3, 5.7 and 5.11.
Incoming Datasets: desirable for route A families from family datasets. If absent from family datasets enter date of export from the database, as in 2.11. Not requested for route B families from regional datasets.
Variants: may be available only as a year from some family datasets, which is acceptable.
In early editions of the checklist the accumulated individual geographical records for many species will be patchy and complicated by the different area systems in use, and for widespread species very lengthy to display or print out. For many users of the checklist there will be an initial layer of geographic information wanted as a summary before any detail is wanted: corresponding to something like the synoptic phrases used in The Plant Book by Mabberley. The following synoptic data items are intended to provide such a summary.
6.1 Occurrence in standardised continents
Form: List of pointers to the ten standardised continents (Hollis and Brummitt Level 1, TDWG Standard) created by the system from data in the individual gepgraphic records, and edited or agreed by the appropriate IOPI geographic co-ordinator team. The list shows in which continents the taxon is thought to be present at the present day with whatever native, introduced or cultivated status.
Note: Care is needed if political country data is used where BRU data is not available -Spain, Portugal, Turkey, Japan, Egypt, Yemen and Mexico each span two continents. BRU (level 4) and botanical country (level 3) data are unambiguous for continents.
IOPI Dataset: Desirable for all taxa.
Incoming Datasets: Desirable for all route A families from family datasets. Not requested for route B families from regional datasets.
Variants: no variants allowed.
6.2 Global native distribution phrase
Form: Pointer to a global native distribution phrase from an IOPI list, selected by the IOPI geographic co-ordinator team, to characterise the native distribution of the taxon.
Examples:. Pantropical
.. . Widespread in S. America & W. Africa
.. . Mediterranean Islands
IOPI Dataset: optional.
Incoming datasets: desirable for route A families from family datasets. Not requested for route B families from regional datasets.
Variants: It is important that all co-ordinators adhere to a small set of phrases to be used in approximately similar cases. Similar or alternative phrases should not be admitted to the list. However genuinely different or special cases should be repres
ented by new phrases being added to the list.
6.3 Global introduction/cultivation phrase
Form: Pointer to a global introduction/cultivation phrase from an IOPI list, selected by the IOPI geographic co-ordinator team to characterise the introduced/cultivated distribution of the taxon.
Examples:. Widespread crop of humid tropics
.. . Temperate crop restricted to Europe
.. . Introduced and Naturalised throughout S. America
IOPI Dataset: optional.
Incoming datasets: desirable for route A families from family organisations. Not requested for route B families from regional datasets.
Variants: as for 6.2.
6.4 Global completeness flag
Data item: this flag is to indicate the IOPI geographical co-ordinator team's view that the distribution records contained in 5.3 are complete for the known global distribution of a species. Only for species in which this flag is set on can the database
be used to deduce that the species is endemic to the given set of areas. For online searching it may be useful to provide a warning message that "the geographical distribution data for this species may not be complete".
Form: a flag set on or off.
IOPI dataset: optional.
Incoming datasets: desirable for route A families coming from family datasets. Not requested for route B families from regional datasets.2. Reference Citation
3. Person Citation
4. Taxonomic note(s)
5. Geographical Distribution - individual record(s)
6. Geographical Distribution Summary