afhandeling soortenlijsten weergeven in resultaat

[ElsLommelen]

De behandeling van soorten in het LSVI-package (vertalen, aggregeren,...) is een zwarte doos waar een gebruiker geen zicht op heeft. Anderzijds blijken er nog fouten te zitten in de taxonomische boom (issues #207 en #208). Naar transparantie en om fouten eruit te halen, zou de afhandeling van de soortenlijsten best ook weergegeven worden in het resultaat.

Dit misschien best in een aparte tabel met volgende velden:

• ingevoerde naam + evt ook extra info, zoals taxonniveau, preferred name vs. junior synonym,...
• naam in LSVI (dus het taxonniveau waarop het in de LSVI-rapporten gedefinieerd is) + evt. ook het taxonniveau en andere info weergeven
• indicator in LSVI (en mss ook voorwaarde of hogere niveaus?)
• habitattype
• id van opname

[ElsLommelen]

Vraag aan de gebruikers van het package: welke info zou in deze tabel nuttig zijn voor jullie?

Sowieso denk ik eraan om volgende velden te geven:

• ingevoerde naam
• naar welke naam deze vertaald is (preferred name of accepted name ingeval de ingevoerde naam een junior synoniem is)
• en evt. ook de taxa die gehanteerd worden voor hogere taxonniveaus (genus, familie,...), ofwel het taxonniveau en de gbif-key zodat jullie deze info zelf kunnen opzoeken met package rgbif
• hoe de match tussen de ingevoerde soort en de vertaling is (goed, onzeker of er kan geen match gemaakt worden), zodat jullie gericht kunnen nakijken bij welke taxa het misschien misloopt

Een optie zou zijn om een tabel te maken waarin elke unieke ingevoerde naam eenmaal staat, en enkel bovenstaande info, dus geen info over de opname (id en habitattype) en geen info over de indicatoren van de LSVI waarin de soort voorkomt. Voordeel hiervan is dat de tabel kort is om (de probleemgevallen) na te kijken, nadeel is dat jullie deze zelf moeten koppelen aan de info van de opname of de soortenlijst uit LSVI als jullie specifieke berekeningen in detail willen uitpluizen.

Een andere optie is om de info over de opname (id + habitattype) toe te voegen, waardoor je geen moeite moet doen om te achterhalen waar je de soort gezien hebt, maar zeker bij veel opnames met dezelfde soorten, wordt dit een lange lijst wat minder handig is om (de probleemgevallen) na te kijken. Dit is met distinct() wel snel op te lossen, maar de vorige optie joinen met je opname kost eigenlijk even weinig moeite, dus het is kwestie van voorkeur en wat je het vaakst gaat gebruiken.

Nog een andere optie is om het habitattype en de gebruikte indicator toe te voegen. In dit geval hoeven niet alle hogere taxonniveaus vermeld te worden, maar kan per indicator specifiek het niveau vermeld worden dat bij de indicator in kwestie gebruikt is. In dit geval stel ik voor om ook de soorten te behouden die niet gebruikt worden bij de berekening van een indicator, om de simpele reden dat anders alle probleemgevallen zonder match ook wegvallen en die zijn net het belangrijkst om te controleren. Ook hier kan de tabel iets langer worden dan enkel een opsomming van de soorten, als bepaalde soorten bij meerdere indicatoren gebruikt zijn. (Maar als een soort voorkomt bij 10 opnamen van hetzelfde habitattype, zal ze bij deze optie maar 1 keer vermeld worden.)

En er is uiteraard ook een optie om de info over de opname te combineren met de info over de indicatoren. Nadeel is een heel lange lijst met herhaling van een soort per opname en per indicator, voordeel is dat je een volledige lijst hebt waar je uit kan halen wat je nodig hebt. Dus voor het snel nakijken van de probleemtaxa is dit minder ideaal, om de berekening van een specifieke opname na te kijken is het wel gemakkelijk.

Dus graag jullie feedback: welke optie heeft de voorkeur? Zijn er velden die minder nuttig zijn of jullie liever anders ingevuld zouden zien? Zijn er eventueel andere zaken waar jullie aan denken?

[hansvancalster]

Mijn voorkeur is optie 1: een lijst met evenveel rijen als er unieke ingevoerde soorten zijn. Kolommen lijkt me je voorstel goed en opteer ik voor taxonniveau en gbif-key + richtlijnen hoe je daarmee de soortenlijst bekomt van hogere taxonniveaus via rgbif.

[cecileherr]

Heel blij om te horen dat jullie hieraan werken! Info over de opname zelf heb ik niet nodig (hier dus geen voorstander van optie 2) maar ik herinner me dat ik in het verleden ook info over het habitattype + LSVI indicator gebruikte in mijn interpretatie van sommige taxa. Wat mij betreft dus toch een lichte voorkeur voor optie 3.

[anleyssen]

Ik heb ook een voorkeur voor optie 1: een tabel met elke unieke ingevoerde naam eenmaal vermeld; hogere taxonniveau's lijken me niet nodig; gbif-key best wel.

[ElsLommelen]

In verband met dit item heb ik nog wat bijkomende vragen:

• hoe de match tussen de ingevoerde soort en de vertaling is (goed, onzeker of er kan geen match gemaakt worden), zodat jullie gericht kunnen nakijken bij welke taxa het misschien misloopt

Allereerst is er al de vraag: wat vinden we goed of niet goed, m.a.w. welke taxonomie hanteren we om de match te maken en om te bepalen wat een juiste match is? Als we een systeem willen dat up-to-date gehouden wordt met de veranderende taxonomie, zie 2 opties:

• Florabank, dat de taxonomie van de Belgische flora volgt
• Gbif, waarvan ik niet goed weet welke taxonomie het gebruikt

Intussen is wel al duidelijk dat er verschilpunten zijn in taxonomische interpretaties, bv. Dactylorhiza praetermissa (Druce) Soó (Rietorchis) wordt door Gbif beschouwd als junior synoniem van Dactylorhiza majalis subsp. praetermissa (Druce) D.M.Moore & Soó, wat onder de soort Dactylorhiza majalis (Rchb.) P.F.Hunt & Summerh. (Brede orchis) zou vallen. Voor de Belgische flora en Florabank zijn dit 2 aparte soorten. En zo belanden we met de ontwikkeling van het LSVI-package onvermijdelijk in een taxonomische discussie, waar we liever buiten blijven. Al kunnen we er niet buiten om hier een keuze te maken over de werkwijze:

• gaan we Gbif volledig volgen en alle ingevoerde soorten opzoeken met rgbif::name_backbone() (Latijnse namen) of rgbif::name_lookup() (NL namen)? (Wat uiteraard ook als nadeel heeft dat wijzigingen in gbif direct doorwerken in het package, oftewel dat de naamgeving variabel is onafhankelijk van onze interne systemen en ook van gangbare taxonomische inzichten in België en omgeving.)
• of stellen we (scriptmatig!) een taxonlijst op die zich voor de taxonomie (en vooral synonymie) in de eerste plaats baseert op Florabank maar wel Gbif-keys en andere info uit Gbif overneemt (wat ons toelaat om via Florabank eigen inbreng te hebben zoals het onderscheid tussen Brede orchis en Rietorchis behouden). Dit kunnen we eventueel aanvullen met het opzoeken van soorten in Gbif als de naam niet in de taxonlijst staat, om toch wat flexibiliteit te behouden als de auteursnaam iets anders geschreven of afgekort is.

Afhankelijk van deze beslissing voor de werkwijze kunnen we dan beoordelen hoe goed de match is:

• Gbif geeft bij functies als rgbif::name_backbone() aan wat de 'confidence' is (waarde van 100 of lager), en ook het 'matchType' (EXACT, HIGHERRANK of NONE), wat aangeeft hoe goed Gbif de match inschat (maar niet altijd even betrouwbaar want ongekende woorden als 'auct. non' worden soms gewoon weggelaten terwijl de match als 'exact' met 'confidence' 100 aangegeven wordt).
• als we een eigen taxonlijst toevoegen, kunnen we bijkomend nog volgende criteria toevoegen:
  • een match is sowieso goed als de schrijfwijze 100% overeenkomt met de lijst
  • bij gebruik van Gbif kunnen we 2 werkwijzen uitvoeren:
    • key van taxon opzoeken of key van gelinkt accepted taxon opzoeken, en dan koppelen met info uit de eigen lijst
    • alle info uit Gbif halen en hierbij kunnen we ook telkens aangeven hoe Gbif de match beoordeelt

Dus de combinatie van de methode (join vs. opzoeking Gbif, en afkomst gegevens) en de geschatte betrouwbaarheid van de match door Gbif geeft wel redelijk wat info over hoe goed de match is (en hoe belangrijk is om dit te controleren), maar vraag is: hoe zou die info best op een eenvoudige manier weergegeven worden? Een cijfer of categorische schaal die aangeeft hoe goed/slecht de koppeling is en hoe belangrijk om te controleren? Of behouden we toch liever wat meer details over de gebruikte methode? Maar hoe het dan op een bevattelijke manier weergeven?

Alle suggesties en feedback hierover zijn welkom! (En in verband met de vorige vraag is feedback ook nog welkom, daarin heb ik nog geen definitieve beslissing genomen. Op basis van de 3 reacties zou het zijn: optie 1, en in de documentatie de code toevoegen om optie 3 te bekomen.)