Build a Darwin Core archive
build_dwc_archiveA file this tool reads, sent or fetched from the address given, is read as one dropped on our website: what the read finds (column headings, the shape of its rows, the terms they became, refusal codes) is kept so the reader learns, never the file or its values. Names and contacts are dropped or replaced by a code, and protected species' locations are made coarser. How do I publish a species file on GBIF? A Darwin Core archive (DwC-A) for GBIF, built from a species occurrence or checklist file (CSV, TSV, Excel, a zipped shapefile, ...) given as file_url (a public https address the door fetches) or content_base64, or from a list of names (species: a checklist). The converter is the one behind map_to_darwin_core: it maps every column, checks every value and writes occurrence.txt (or taxon.txt), meta.xml and eml.xml. The answer: archive (core, records, rows read and lost, terms, bytes, sha256, publishable with what GBIF still needs); the zip itself, as an embedded resource when it is at most 32 KB (a larger one comes whole, as base64, from POST /api/v1/dwc/archive with the same arguments); could_not_read = each thing the converter would not guess, coded (a column no term carries, a row with no date or position, a 0,0 coordinate, a name the naming authority does not match, repeated rows), with what it costs; and notices (records of species a conservation register lists, at the precision filed). GBIF indexes an archive only with a title, an abstract, a licence and a creator and a contact (given name, surname, organisation, email): give them in metadata, nothing is filled in. chapman_category (1-4: the data holder's own sensitivity category under Chapman 2020) coarsens the coordinates of listed species and says so in the archive. columns names the column for a term where your user decided it (map_to_darwin_core's reading, corrected); the converter still checks the values and refuses what they contradict. Our counter keeps how the file came, the core and the counts. When your user confirmed columns and you send columns_confirmed_by_user: true, each confirmed column's words and its term (never a value) are also read as a label to teach the converter, and the answer's learned says so. Large files take a minute.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "build_dwc_archive"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| core | No | occurrence (default for a file: one row an observation) or checklist (one row a taxon; the default for species). | |
| columns | No | Optional, with a file: {Darwin Core term: the column that carries it} where your user decided (e.g. {"scientificName": "Espèce", "eventDate": "Date relevé"}). A choice, not an order: the values are still checked. | |
| species | No | Instead of a file: scientific names, one an entry, for a checklist archive (Taxon core). | |
| file_url | No | A public https address of the file; the door fetches it (at most 10 MB). Not with content_base64 or species. | |
| filename | No | The file's name with its extension (survey.xlsx, sites.zip): it tells the converter how to read the bytes. Taken from file_url when omitted. | |
| metadata | No | The dataset's metadata for eml.xml, as the data holder states it. | |
| content_base64 | No | The file's bytes as base64 (at most 10 MB decoded). Not with file_url or species. | |
| chapman_category | No | Optional: your sensitivity category under Chapman 2020 (1 = least, 4 = most withheld). Coordinates of species a conservation register lists are generalised to its grid, and the archive says so in dataGeneralizations. | |
| columns_confirmed_by_user | No | true only when your user read and confirmed every entry of `columns` themselves (not your own reading). Each confirmed column's words and term are then kept to teach the converter; nothing else of the file is. |