Project

General

Profile

Actions

task #10239

closed

Caucasus databases and portals available

Added by Andreas Müller over 1 year ago. Updated 3 months ago.

Status:
Closed
Priority:
Priority14
Category:
platform
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal

Description

This is kind of a master ticket for issues related to the 3 caucasus portals and the caucasus project.
Also use the 'caucasus' tag to search for caucasus related issues.

  • Import data from caucasus DB to E+M (#10236)
  • Create 3 portals
  • Create 3 databases => created and filled
  • Discuss which data to edit in E+M and when/how to fork see #10324
  • Distribution hierarchy handling in portal (e.g. #5807 and others) => areas have been defined and remaining hierarchy is simple, so this is not an issue here
  • URLs for the portals
  • Discuss:
    • which data to show in the slices (only for the country or for the entire caucasus) => see #10239#note-2
    • Kew/ILDIS taxa => see #10239#note-3
    • WFO-IDs: should we wait until WFO-IDs are imported => see #10239#note-4 , the import did run so this is obsolet
    • Hybrids: ERS: wahrscheinlich gibt es nicht viele Daten, aber wenn, sollten wir sie mit exportieren. Es ist noch nicht festgelegt, ob Hybriden aufgenommen werden sollen. => the import did run
    • which sec-references to use => see #10239#note-5 and #10239#note-17
    • uuids for names, taxa, distribution ..., should they be kept from E+M or created a new => see #10239#note-5 and #10239#note-18 , for now we keep them as they are

Related issues

Related to EDIT - task #10324: Export Caucasus dataClosedAndreas Müller

Actions
Related to EDIT - feature request #9197: Handle caucasus conspectus data in E+M and caucasus portalRejectedAndreas Müller

Actions
Actions #1

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

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.

Actions #2

Updated by Andreas Müller over 1 year ago

AM:

Verstehe ich es richtig, dass dann im Armenien Slice wirklich nur Taxa landen sollen, die in Armenien vorkommen, und dass auch die Verbreitungsdaten nur aus Armenien stammen sollen, nicht aus dem gesamten Kaukasus.

ERS:

Das hatten wir noch nicht im Detail festgelegt.

Sinnvoll wäre aus meiner Sicht:

1) ja, nur Taxa, die in Armenien vorkommen, aber

2) Verbreitungsdaten werden in Checklisten gerne auch für die Nachbarländer angegeben, sinnvoll wären in dem Fall alle Länder der Ökoregion Kaukasus, für die wir Daten haben (also die drei Südkaukasusländer jeweils mit ihren Unterarealen sowie Nordkaukasus und Türkei., und E+M gesamt zur Angabe über Endemismus).

Welche Daten genau in den Länderchecklisten enthalten sein sollen, ist ja auch in Absprache mit den Partnern noch im Detail festzulegen. Für die Arbeits-Slices sollten wir aber die Daten aus den Nachbarländern behalten.

Actions #3

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

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.

Actions #4

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

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

Actions #5

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

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.

Actions #6

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

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

Actions #7

Updated by Andreas Müller over 1 year ago

Meeting 2023-01-31:

  • Maryam will start entering data from conspectus with E+M areas to complete the taxonomic backbone
  • which areas to use needs to be discussed with project partners asap
Actions #9

Updated by Andreas Müller about 1 year ago

Actions #10

Updated by Andreas Müller about 1 year ago

Actions #11

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #12

Updated by Andreas Müller 3 months ago

  • Description updated (diff)
Actions #13

Updated by Andreas Müller 3 months ago

  • Description updated (diff)
Actions #14

Updated by Andreas Müller 3 months ago

  • Status changed from New to In Progress
  • Priority changed from New to Priority14
  • % Done changed from 0 to 50
Actions #15

Updated by Andreas Müller 3 months ago

  • Description updated (diff)
Actions #16

Updated by Andreas Müller 3 months ago

  • Target version changed from Release 5.44 to Release 5.43
Actions #17

Updated by Andreas Müller 3 months ago

  • Description updated (diff)

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.

Actions #18

Updated by Andreas Müller 3 months ago

  • Description updated (diff)

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.

Actions #19

Updated by Andreas Müller 3 months ago

  • % Done changed from 50 to 90
Actions #20

Updated by Andreas Müller 3 months ago

  • Description updated (diff)
  • Status changed from In Progress to Closed
  • Target version deleted (Release 5.43)
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF