audit_archive

io.github.kedu21-beep/passage-data · Verify this server

A 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. What is wrong with a Darwin Core archive already published on GBIF? The defects in a published Darwin Core archive, found by the audit our website runs on an archive dropped on it: give a GBIF dataset key (the archive is fetched from the endpoint GBIF's registry lists), the archive's address, or the archive itself as base64. Each defect is coded (FS_...), with the check that found it (each check's words once, in `checks`; a finding names it by index), its count over the rows read, and the file and lines it stands on (at most 5 lines a finding; `not_located` says why when a check names neither a cell nor a row). `bdq` names every test of TDWG's BDQ TG2 suite: ran, with compliant and not_compliant counts and lines, or not run under a code (bdq.terms_absent, bdq.authority_absent, bdq.does_not_reproduce, bdq.not_implemented): a test not run is not a test passed. `annex: true` adds the audit as a markdown document to attach to a report. A large archive answers `pending` with a `call_id`: call again with only that call_id to collect it. Refusals are coded: dataset.not_found, dataset.no_archive, archive.unreachable, archive.not_dwca, archive.too_large, url.refused.