barbalex / ae3 Goto Github PK

Es gibt einen wahrscheinlich unerwünschten Effekt. Beispiel Alytes obstetricans (Geburtshelferkröte):

Das Taxon bzw. dessen Synonyme existieren in zwei Taxonomien:

• CSCF (2009): https://www.arteigenschaften.ch/Arten/aed47d40-7b0e-11e8-b9a5-bd4f79edbcc4/aedf52b1-7b0e-11e8-b9a5-bd4f79edbcc4/aee40daa-7b0e-11e8-b9a5-bd4f79edbcc4/aef3c522-7b0e-11e8-b9a5-bd4f79edbcc4/fe3a527f-867e-4dea-9f8b-772482360fe0
  Diesem Taxon wurde 2000 der frühere Artwert zugewiesen. Der 2019 aktualisierte Artwert erscheint hier als Eigenschaft seines Synonyms.
• CSCF (2022): https://www.arteigenschaften.ch/Arten/62a9144f-c0cd-4d31-8bf0-cf808ebcc832/d0cd85c5-82b0-4faa-98b1-25e9752c7952/e5b3c092-35f8-11ed-86c7-c77fac01c776
  Diesem Taxon wurde der aktuelle Artwert zugewiesen. Der Artwert aus 2000 erscheint hier als Eigenschaft seines Synonyms.

Soweit so gut. Das ist erwartet und macht Sinn (meine ich). Ersteres ist im Formular wenig problematisch, weil der Betrachter beide Artwerte sieht. Und beim Export kann er wählen, aus welcher Eigenschaftensammlung der Artwert exportiert werden soll (2000, 2019 oder aktuell).

Das Problem besteht in der zusammenfassenden Eigenschaftensammlung "ZH Artwert (aktuell)". Hier sind beide Taxa enthalten. Will heissen:

• Beim Taxon aus CSCF (2022) erscheint der aktuelle Artwert
• Beim Taxon aus CSCF (2009) erscheint der Artwert aus dem Jahr 2000. Denn wenn eine Eigenschaft beim eigenen Taxon und beim Synonym existieren, wird (aktuell) die eigene priorisiert. Das gleiche Problem gibt es beim Export: Werte für Synonyme werden nur geliefert, wenn kein eigener existiert

Letzteres ist wohl nicht sinnvoll. Eigentlich sollte beim Synonym aus CSCF (2009) der aktuelle Artwert erscheinen (als Eigenschaft seines Synonyms). Z.B. wenn jemand eine Artliste auswerten würde, welche die ältere Taxonomie verwendet.
(Theoretisch gibt es auch Taxonomien, die nicht eindeutig als "älter" oder "neuer" bezeichnet werden können, praktisch haben sie in arteigenschaften.ch bisher keine grosse Bedeutung, beim GBIF hingegen schon)

Das gleiche Problem gibt es immer, wenn eine zusammenfassende Eigenschaftensammlung aktualisiert wird und zwischenzeitlich eine neue Taxonomie existiert. Also z.B. auch bei allen Flora-Arten und deren "ZH Artwert Flora (2020)". Am Beispiel von Pulsatilla vulgaris kann man es z.B. auch nachvollziehen.

Zusammenfassende Eigenschaftensammlungen gibt es bisher bei: Artwerten und Roten Listen.

Das Problem lässt sich lösen, wenn in zusammenfassenden Eigenschaftensammlungen entweder:

1. Die Priorisierung bei der Auswertung (in Formular und Export) geändert wird: Priorisiert würde neu der Wert aus der jüngsten Eigenschaftensammlung. Bedingt aber, dass bei Eigenschaftensammlungen Informationen über deren Datenstand enthalten sein müssen, das müsste ergänzt werden. Im konkreten Beispiel würde das heissen:
   1. Bei der Geburtshelferkröte aus CSCF (2022) wird die Eigenschaft aus "ZH Artwert Fauna (2019)" gewählt, weil sie jünger ist, als diejenige des Synonyms aus "ZH Artwert (2000)"
   2. Dito bei der Geburtshelferkröte aus CSCF (2009). Bingo, Ziel erreicht
2. Die Priorisierung beim Import in zusammenfassende Eigenschaften-Sammlungen erzwungen wird: Es wird ein Mechanismus eingebaut, der gewährleistet, dass ein Taxon immer nur Informationen für ein einziges Synonym enthält. Konkret: Vor dem Import prüft apflora für jedes Taxon in den Importdaten, ob in dieser Eigenschaftensammlung bereits Datensätze von Synonymen dieses Taxons existieren. Der Benutzer muss dann entscheiden, ob er die neu importierten Daten priorisiert (d.h. die alten werden während dem Import der neuen entfernt). Oder ob er die bereits enthaltenen Daten priorisiert (d.h. bei diesen Taxa wird nicht importiert)

Der erste Ansatz ist einfach zu verstehen. Er ist auch resilient gegenüber Änderungen von Beziehungen zwischen Taxa, also wenn z.B. Synonymie neu beurteilt wird. Und: Ein Benutzer kann heute beim Export wählen, Informationen von Synonymen zu ignorieren. Das wäre dann immer noch möglich. Beim zweiten Ansatz müsste diese Option wohl entfernt werden, weil sie nicht mehr richtig funktionieren würde.

Der zweite Ansatz benötigt keine Anpassung der Datenstruktur. Dafür müssen die aktuellen Daten von zusammenfassenden Eigenschaftensammlungen von mir kontrolliert und angepasst werden. Sowie der Importvorgang neu programmiert werden. Und wenn es mal vorkommen sollte, dass In einer Taxonomie Beziehungen (Synonymie) verändert werden, müsste bei allen zusammenfassenden Eigenschaftensammlungen die Daten geprüft und angepasst werden. Wenn das vergessen wird, werden falsche Daten angezeigt und exportiert. Dieser Ansatz könnte auch versagen, wenn manuell (an der dafür programmierten Funktionalität vorbei) importiert wird.

Beide Ansätze sind aufwändig umzusetzen.

Ich würde daher den ersten Ansatz wählen. Umsetzung:

1. Neues Feld bei den Eigenschaftensammlungen "date" kennzeichnet das Aktualitätsdatum
2. Das neue Feld bei allen Eigenschaftensammlungen nachführen
3. Sicherstellen, dass das existierende Feld "property_collection_of_origin" in Eigenschaften zusammenfassender Eigenschaftensammlungen immer nachgeführt ist (es verknüpft zur ursprünglichen Eigenschaftensammlung um das Aktualitätsdatum auszulesen)
4. Priorisierung nach Aktualitätsdatum implementieren

Der Aufwand ist leider recht gross. Geschätzt vier Arbeitstage.

Andreas Lienhard schrieb am 12.4.2023:

Ich erhalte beim Versuch die Lebensräume als Tabelle zu exportieren keine Datensätze,

die Trockenwiesen funktionieren auch nicht alleine, evtl. wegen des zu langen Namens?

Alex antwortete am selben Tag:

du hast recht, es lag an den langen Namen.

Ich habe es in der neuen Version 3.0.20 repariert, indem beim SQL-Aufruf Zeichenfolgen in den Namen ersetzt werden: https://github.com/barbalex/ae3/blob/main/src/sql/exportFunction.sql#L62
Die Reparatur läuft natürlich unter Unterhalt.

Das funktioniert. Jetzt. Mit den aktuell existierenden Lebensräumen bzw. ihren Namen. Das Problem kann aber sehr rasch wieder auftreten, wenn neue Taxonomien importiert werden. Denn dass irgendwo im SQL-Code Namen gekürzt werden müssen, ist nicht so intuitiv...

Besser bzw. nachhaltiger wäre folgende Lösung:

• In der Taxonomie (hier: https://www.arteigenschaften.ch/Lebensr%C3%A4ume/b15210c7-7bad-4dd1-a12f-a30833e0f7f5) gibt es ein neues, zusätzliches Feld. Z.B. "Kurzname"
• Dieser Name wird jeweils beim Import gesetzt (bzw. bei der Implementation für die bestehenden Taxonomien von mir). Er kann auch von Benutzern mit Login direkt verändert werden (dieses Formular ist heute schon bearbeitbar)
• Im Formular und im SQL-Code bei den Tabellen-Definitionen wird erklärt, dass er benutzt wird, um beim Export möglichst kurze, prägnante Feldnamen zu erzeugen
• In der Export-Abfrage (https://github.com/barbalex/ae3/blob/main/src/sql/exportFunction.sql#L76-L508) wird dieser Name verwendet statt des vollen Namens

Diese Anpassung erachte ich als Erweiterung. Dafür bräuchte ich ca. 6 Stunden und einen entsprechenden Zusatzauftrag. Es pressiert natürlich nicht, jedenfalls nicht befor neue Lebensräume importiert werden.