EDIT

NaK:

anbei sind nochmal die drei Proposals. Ich glaube, dass Anton sie kannte, Andreas und Katja aber vermutlich nicht. Es sind drei Anträge (und formell auch drei getrennte Grants) für die drei Länder. Der Einleitungsteil ist immer identisch, die konkreten Arbeitspläne je nach Land leicht unterschiedlich.

Ziel sind Länder-Checklisten und der Aufbau eines Informationssystems in den jeweiligen Ländern, das war die Voraussetzung für die Anträge, es sind Infrastruktur-Proposals für die Partner.

In dem Zusammenhang hatten wir auch ausführlich diskutiert, dass es drei getrennte Datenbanken und Portale sein müssen, sie sind ein konkretes Deliverable des Projektes, nicht etwas, das nur im Antrag steht. Dass das so im Antrag steht, hat ja Gründe. Zum einen werden die Portale vom Inhalt und Auftritt je nach Land unterschiedlich sein, und auch sein müssen, zum Beispiel mit Texten in der Landessprache, Verbreitung in Provinzen oder anderen Einheiten im jeweiligen Land, etc.
Sie sind dann auch nicht inhaltsgleich mit E+M, es sollen zum Beispiel auch Typen enthalten sein, und für Armenien vermutlich auch Flechten.
Es ist außerdem geplant, dass auch die Wissenschaftler*Innen vor Ort editieren und das langfristig auch übernehmen. Schon wegen der bekannten Armenien-Aserbaidschan Problematik kann es keine gemeinsame Datenbank sein, in der Kolleg*Innen aus beiden Ländern editieren. Dieselben Arten heißen in den Ländern manchmal auch anders, die Kolleg*Innen sollen die Möglichkeit haben, das auch so umzusetzen, und das kann auch mal vom Backbone in E+M abweichen.

Maryam kann sicher für einige Wochen erstmal in E+M editieren, aber wir brauchen die getrennten Instanzen und Portale zeitnah, um mit den Partnern über die weiteren Schritte und Inhalte zu sprechen.

ERS:

danke, Nadja, für die ausführliche und zutreffende Darstellung des Hintergrundes. Aus E+M-Sicht und datenbanktechnisch bringt die festgelegte Vorgehensweise sicherlich einige Schwierigkeiten mit sich, die Proposals sind aber eindeutig. Das Ziel ist ja ausdrücklich der Aufbau von Daten-Infrastrukturen für die jeweiligen Länder, die unabhängig voneinander operieren und funktionieren sollen.

Kew/ILDIS:

ERS:

diese haben ja gar keine Verbreitungsangaben für die Südkaukasusländer, sondern nur für TCS. Sie helfen also in dem Punkt nicht viel weiter.
Eigentlich wollen wir ja auch Originaldaten hier haben.
In unseren Unpublished-Treatments der KEW/Ildis-Familien gibt es dagegen teilweise schon Daten für Armenien, Georgien und Aserbaidschan, die dann im Laufe des Projektes zu ergänzen wären.
Es wäre also sinnvoll, die Länderslices mit unseren unpublished treatments der Kew und Ildis-Famiien zu ergänzen, denke ich. Aber ich muss mir die daten vielleicht nochmal genauer ansehen.

WFO-IDs:

NaK:

wäre auf jeden Fall sinnvoll, und das Institut in Baku ist auch Teil des WFO Konsortiums.

Wenn wir die bald von Walter bekommen könnten wir warten, aber wenn nicht, dann könnten die IDs auch später importiert werden, oder auch ganz am Ende wenn die backbones fertig sind, weil in den Slices garantiert Taxa fehlen werden. Vielleicht deshalb besser nicht auf die IDs warten.

ERS:

scheint mir sinnvoll, wenn das zeitnah passieren kann

sec-refs:

ERS:

wahrscheinlich gibt es nicht viele Daten, aber wenn, sollten wir sie mit exportieren. Es ist noch nicht festgelegt, ob Hybriden aufgenommen werden sollen.

UUIDs:

ERS:

spricht was dagegen, die uuids für Namen gleich zu halten? Da erwarte ich kaum Abweichungen, oder? Bei Taxa oder Verbreitungsdaten könnte ich mir auch vorstellen, dass man teilweise die gleichen IDs hat, aber nicht für alle Fälle...

AM:

it is critical to keep the same uuids if they do not represent the exact same data even if they are stored in 2 different databases. As data will change over time we should not keep the uuids. This is maybe different for names but even there the related data may slightly change and using the same uuids is therefore dangerous. Also on name level we may have WFO-IDs as common identifiers.
At the same time data lineage might be easier if keeping uuids. However, this may not weigh out the disadvantages

AM:

derzeit werden ja noch die von E+M genommen. Ist das so gewollt oder soll das mal angepasst werden. Derzeit werden diese nicht angezeigt, daher ist das nicht wirklich akut relevant. Aber gab es dazu irgendwelche Überlegungen? Z.B. Anzeige ähnlich wie in E+M.
Oder zumindest übernahme einer einheitlichen sec wie in anderen Floren, z.B. Flora of Georgia 2023+, die für alle Taxa gesetzt wird.

NaK * ERS:

Wir hatten uns gegen sec-Referenzen entschieden, es soll eine einheitliche Referenz für alle Taxa geben. Wir die genau lautet, würde davon abhängen, wie die Checklisten publiziert werden, alos ob es eine separate Print-Publikation oder ein data paper geben wird, oder ob es bei der reinen Online-Checkliste bleiben soll.

AM:

dann wäre es gut, wenn ihr mal eine Referenz anlegt (die kann ja im Detail später noch geändert werden) und diese mit „set for subtree“ dem gesamten Baum hinzufügt. Eckhard, du weißt ja wie das geht von E+M, denke ich. Dann wären die „falschen“ sec-refs erstmal weg.

ERS:

ich habe jetzt erstmal in allen drei Südkaukasus-Instanzen die sec-Refs geändert und jeweils für den gesamten Baum gesetzt. Die heißen zunächst einmal „On-line checklist of vascular plants of Armenia (bzw. Azerbaijan bzw. Georgia) 2024). Autoren/Herausgeber gibt es noch keine.

AM:

Die Frage nach der Anpassung der UUIDs ist vermutlich schwer zu final zu beantworten. Zumindest für Taxa würde ich sie aber vielleicht doch anpassen, sonst wundert sich vielleicht doch mal jemand, warum das die gleichen UUIDs sind, obwohl die Taxa doch unterschiedlich aussehen. Allerdings würden dabei alle bisherigen Portallinks zu Taxa kaputt gehen. Würde das was ausmachen

NaK:

Das mit den UUIDs verstehe ich nicht ganz.

ERS:

Bei den UUIDs verstehe ich auch nicht, welche Portallinks zu Taxa unter welchen Bedingungen kaputtgehen würden, und ob das schadet oder nicht. Müssen wir vielleicht mal besprechen.

AM:

Zu den UUID clones: konkretes Beispiel C. intybus in Armenia https://portal.cybertaxonomy.org/armenia/cdm_dataportal/taxon/67bbde84-961e-4725-8879-ebadf4662efe und E+M https://www.europlusmed.org/cdm_dataportal/taxon/67bbde84-961e-4725-8879-ebadf4662efe benutzen die gleiche UUID 67bbde84-961e-4725-8879-ebadf4662efe obwohl da evtl. irgendwann mal ein anderes Konzept hinter steht und bereits jetzt die Synonymie unterschiedlich aussieht. Bei den Cichorieen ist es eine andere UUID obwohl auch dort der Name ja akzeptiert ist: https://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/4f6c68d0-63f2-4235-83c2-5bff14532f90
Soviel zur Erklärung, was gemeint ist. Wirklich problematisch ist das wie gesagt nicht, da ja die Domain eine andere ist. Es könnte nur irgendwann mal Probleme geben, wenn Daten aus beiden Datenbanken verglichen werden sollen. Oft werden solche Vergleiche an Hand der UUID gemacht, da man davon ausgeht, dass diese aufgrund der Länge global unique sein sollte, aber wenn man sie kopiert, wie hier, ist sie es eben doch nicht.
Da es aber auch mal Vorteile haben kann, wenn man für das gleiche akzeptierte Taxon die gleiche UUID verwendet, würde ich vorschlagen, das jetzt doch erstmal so zu lassen.