Species Mapping

[geofranzi]

map species from primary data to a versioned list.
use name resolver to get parts
use global name verifier, if not found
gbif: every 6 months new Version

Useful links/sources:

• https://data-blog.gbif.org/post/gbif-backbone-taxonomy/
• https://data-blog.gbif.org/post/2022-02-01-the-world-checklist-of-vascular-plants-fabaceae/
• https://www.checklistbank.org/
• https://www.catalogueoflife.org/data/source-datasets (Not Found)
• https://www.catalogueoflife.org/about/colpipeline (Not Found)
• https://besjournals.onlinelibrary.wiley.com/doi/10.1111/2041-210X.13802 (Harmonizing taxon names in biodiversity data: A review of tools, databases and best practices)
  • this contains a useful listing of sources and strategies
• Allison BA repository
• Issue related MIRO Board
• CLB repository
• CLB MatchTypes.java
• CLB guide
• GBIF BackBone (good test data)

To do

• add StepId to SpeciesMatchingResult
  • the idea is -1 means name-based, and 0+ means file-based match and identifies the specific step inside mapping_progress.json
  • needs to be adapted in the AcceptMatches route
• Complete IApiOptions
  • make matching request on progress overview more clear
  • better ui for selecting options for different APIs
  • IApiOptions resolving and hand over as abstract parameter into MatchAsync
  • use IApiOptions in CLBApi (and document how to use it in MatchBaseApi
  • store chosen IApiOptions (if valid) inside matching_progress.json
  • provide streamlined functions to read/write/validate IApiOptions easily
• diff visualization for data cleaning changes
  • add diff vis. for editedName also (and better indicator for if a change actually will be submited)
• dataset-version based matching
  • when starting a new matching process with a newer dataset-version, only use the remaining (not yet existing in Matching table) individual names
• case out / replace possible null values in table data
  • null values in table data crash table when column is defined (shows as no table data)
• better/transparent error handling in frontend code
• name based matching API abstraction
• adapt data cleaning routine
  • data cleaning for TRY test data is way too much. we need something much simpler and robust
  • use the LCVP data cleaning routine for now
• add selectable dataset_keys for CLB Api which can be changed/added in settings
• ordered and readable table headers on all pages
• file based matching API abstraction
• refactor mapping_progress to matching_progress (because it is confusing)
• add MatchSource (for CLB this is dataset sourceKey for now), TimeStamp (when match request is sent)
  • adding the api information to matching_progress is required first
• better overview of results according to match-type
  • this means implementing a strategy with a low level understanding of the semantics of match-types for each implemented API
• show results split into multiple tables (e.g. 'Work in Progress', 'Done', 'Currently Accepted')
  • since match-type 'None' (or similar) results can not be accepted by the user, find a better way to visualize them (same table does not really make sense)
  • result page progress bar