Florabank taxon ID met meerdere NBN keys

[hansvancalster]

Er zijn een aantal soorten met dezelfde wetenschappelijke naam en toch meerdere NBN keys. Misschien iets om eens nader te bekijken:

Hier is code om deze id's te vinden:

QuerySoorten <-
  "SELECT TaxonSynoniem.FloraNaamNederlands AS NedNaam,
          TaxonSynoniem.CanonicalNameWithMarker AS Canonicalname,
          Taxon.NbnTaxonVersionKey AS NBNTaxonVersionKey, Taxon.TaxonTypeId,
          Taxon.FloraTaxonId AS TaxonID
      FROM TaxonSynoniem INNER JOIN Taxon
        ON TaxonSynoniem.TaxonId = Taxon.Id
      WHERE Taxon.NbnTaxonVersionKey IS NOT NULL"
taxonlijst_lsvi <-
  DBI::dbGetQuery(LSVI::maakConnectiePool(), QuerySoorten) %>%
  as_tibble()
# Er zijn 11 gevallen met 2 NBN keys voor zelfde TaxonID
taxonlijst_lsvi %>%
  filter(!is.na(TaxonID)) %>%
  distinct(TaxonID, NBNTaxonVersionKey) %>%
  group_by(TaxonID) %>%
  filter(n() > 1)

[ElsLommelen]

In de nieuwe versie van het package zal niet meer met NBN-keys gewerkt worden, dus moest dit al ooit een probleem geweest zijn, dan zou het binnenkort opgelost zijn.

Maar vermits die query sterk afwijkt van de manier waarop de databank bevraagd hoort te worden, denk ik niet dat er bij de berekening van de LSVI ooit een probleem geweest is. (Die synoniementabel wordt enkel gebruikt ingeval de gebruiker een onbekend junior synoniem ingevoerd heeft; de basislijst van gebruikte taxa voor de berekeningen zit in tabel Taxon en voor de berekeningen zullen ook enkel NBN-keys uit tabel Taxon gebruikt worden, nooit uit TaxonSynoniem want die heeft enkel als doel om omwille van compatibiliteit zoveel mogelijk namen en keys te bevatten.) Ik weet niet waar die query/code vandaan komt of gebruikt is in het package en ik snap niet waarom dit een probleem zou kunnen (geweest) zijn?

[hansvancalster]

Het is lang geleden, maar ik vermoed dat ik dit tegen ben gekomen bij het klaarmaken van https://zenodo.org/records/10561497. Mogelijk heb ik toen onterecht gedacht dat dit een probleem was.

[ElsLommelen]

Is er eigenlijk een reden dat je in die lijst alle junior synoniemen wil opnemen? Mij lijkt het eerlijk gezegd veel gemakkelijker om enkel de accepted names aan te bieden, dat vermijdt mogelijk dat een hele hoop dubieuze synoniemen gebruikt gaan worden omdat niet elke gebruiker even goed weet welke naam hij precies moet kiezen.

[hansvancalster]

Is er eigenlijk een reden dat je in die lijst alle junior synoniemen wil opnemen? Mij lijkt het eerlijk gezegd veel gemakkelijker om enkel de accepted names aan te bieden, dat vermijdt mogelijk dat een hele hoop dubieuze synoniemen gebruikt gaan worden omdat niet elke gebruiker even goed weet welke naam hij precies moet kiezen.

Het was inderdaad de bedoeling om enkel accepted names in de lijst te hebben. Ik heb je een mail doorgestuurd waarin dit staat. Mogelijk zijn er een paar door de mazen van het net geglipt.

[ElsLommelen]

Het is lang geleden, maar ik vermoed dat ik dit tegen ben gekomen bij het klaarmaken van https://zenodo.org/records/10561497. Mogelijk heb ik toen onterecht gedacht dat dit een probleem was.

Het was inderdaad de bedoeling om enkel accepted names in de lijst te hebben. Ik heb je een mail doorgestuurd waarin dit staat. Mogelijk zijn er een paar door de mazen van het net geglipt.

Euh, dan snap ik al helemaal niet meer waarom je bovenstaande query zou gebruikt hebben waarmee je die hele synoniemenlijst bevraagt en niet gewoon de tabel Taxon met accepted names. Misschien toch voor de zekerheid best even nakijken waarom je deze toch wel wat vreemde query gebruikt hebt? Want als de databank op die manier gebruikt gaat worden, is de kans uiteraard groot dat dit tot foute interpretaties of aannames leidt. (Maar misschien moet ik die synoniementabel binnenkort uit de databank zwieren om dit soort misinterpretaties te vermijden.)

[hansvancalster]

Euh, dan snap ik al helemaal niet meer waarom je bovenstaande query zou gebruikt hebben waarmee je die hele synoniemenlijst bevraagt en niet gewoon de tabel Taxon met accepted names. Misschien toch voor de zekerheid best even nakijken waarom je deze toch wel wat vreemde query gebruikt hebt? Want als de databank op die manier gebruikt gaat worden, is de kans uiteraard groot dat dit tot foute interpretaties of aannames leidt. (Maar misschien moet ik die synoniementabel binnenkort uit de databank zwieren om dit soort misinterpretaties te vermijden.)

Die query komt letterlijk uit het LSVI package:

LSVI/R/invoercontroleData_soortenKenmerken.R

Lines 124 to 130 in c709f03

	QuerySoorten <-
	"SELECT TaxonSynoniem.FloraNaamNederlands AS NedNaam,
	TaxonSynoniem.CanonicalNameWithMarker AS Canonicalname,
	Taxon.NbnTaxonVersionKey AS NBNTaxonVersionKey, Taxon.TaxonTypeId
	FROM TaxonSynoniem INNER JOIN Taxon
	ON TaxonSynoniem.TaxonId = Taxon.Id
	WHERE Taxon.NbnTaxonVersionKey IS NOT NULL"

Mijn bedoeling was om het excelbestand met de florabanklijst zonder synoniemen, die me door Gert werd bezorgd en op zenodo moest geplaatst worden, te vergelijken met de hoe het LSVI package gebruikt wordt. Ik heb daarvoor gekeken hoe het LSVI package omgaat met soorten (cf de query soorten hierboven) en dan beide lijsten met elkaar vergeleken om te zien of er problemen waren. Cf doorgestuurde email waar er drie problemen gemeld worden:

• 1063 taxa zitten in deze export maar niet in de lijst van het LSVI R package (zie bijlage ontbrekend_in_lsvi; wellicht geen probleem voor het LSVI package omdat ze niet in de soortenlijsten van LSVI voorkomen)
• 34 taxa zitten in LSVI package, maar ontbreken in de export (zie ontbrekend_in_export)
• Er zijn 11 gevallen met 2 NBN keys voor zelfde Florabank TaxonID (zie florataxonid_meerdere_nbnkeys)

De eerste was niet problematisch. De tweede heb jij toen in detail bekeken en de nodige oplossingen bezorgd aan Gert (zie je follow-up e-mail). Het derde is waar dit issue over gaat.

[ElsLommelen]

Ah, oei, ik had vrijdag niet gezien dat die NbnTaxonVersionKey uit Taxon kwam en niet uit TaxonSynoniem. Dan was dit wel relevant, maar bij de huidige aanpassingen zal het niet meer helemaal van toepassing zijn.

In de nieuwe versie van het package zal die query nl. vervangen worden door het ophalen van een csv 'Taxonlijst'. Voor deze tabel wacht ik nog op databeheer, maar ik ben toevallig net (n.a.v. het opnieuw testen van de voorbeeldcode van issue #225) een unittest aan 't schrijven om te testen of in deze tabel de GbifUsageKey uniek is bij het negeren van verschillende (schrijfwijzen van) taxonnamen. Maar n.a.v. dit issue zal ik het script nog wat grondiger uitpluizen en indien nodig extra testen schrijven om gelijkaardige problemen zeker te vermijden.