Project

General

Profile

Actions

task #9228

open

Adaptations to allow editing Centaurea in Flora of Greece

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

Status:
In Progress
Priority:
Highest
Category:
data
Target version:
Start date:
09/21/2020
Due date:
% Done:

30%

Estimated time:
Severity:
critical

Description

It has been decided to edit Centaurea data in Flora of Greece. For making this possible a couple of issues need to be solved in cdmlib, TaxEditor and in the data portals/web services.

This ticket is meant to be a master ticket for collecting issues that need to be solved.

  • generell

    • inform Panayotis and discuss details (AM) - Mail sent 2020-12-01 => agreed
    • introduction to TaxEditor and EDIT Platform (NK)
  • cdmlib

    • test cloning of subtrees (AM) - #4866, #2470, #4867 => no reuse for taxa and names (s. discussion below)
  • TaxEditor

  • Dataportal

  • Ontology

    • copy additivity ontology to ontology master and to FoG DB
    • discuss and implement synchronisation with master ontology
    • discuss usage of default character tree <-> separate character tree

Related issues

Related to Edit - bug #9357: Advanced search shows selection for all classification even if only 1 classification is available for a dataportalNewAndreas Kohlbecker12/11/2020

Actions
Blocked by Edit - feature request #4866: Implement clone method for complete classificationsClosedAndreas Müller04/30/2015

Actions
Actions #1

Updated by Andreas Müller over 1 year ago

  • Description updated (diff)
Actions #2

Updated by Andreas Müller about 1 year ago

  • Status changed from New to In Progress
  • Priority changed from New to Highest
Actions #3

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
  • Category changed from cdmlib to devOps
  • Assignee deleted (Andreas Müller)
  • Target version deleted (Release 5.18)
  • Severity changed from normal to blocker
Actions #4

Updated by Andreas Müller about 1 year ago

  • Assignee set to Andreas Müller
  • Target version set to Release 5.18
  • % Done changed from 0 to 20
  • Severity changed from blocker to critical
Actions #5

Updated by Andreas Müller about 1 year ago

  • Category changed from devOps to data
Actions #6

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #7

Updated by Andreas Müller about 1 year ago

AM: ...

Ich würde den Subtree jetzt clonen, d.h. für jedes Taxon eine Kopie anlegen, in der alle Daten (Synonyme, Fakten, Bilder und Konzeptrelationen -nur MAN soweit ich weiß- drin sind) . Diese können bei Bedarf einzeln in der Hauptflora übernommen werden.
Details die es zu klären gibt:

  • soll die Secundum-Referenz übernommen werden? Die lautet derzeit lediglich Dimopoulos & al. 2013, also die erste Version der Flora von Gr., was sowieso nicht ganz stimmt, da es ja bereits einige Korrekturen gab, auch die publizierte von 2016. Da man im Nachhinein auch immer noch eine Sec für den ganzen geclonten Subtree aus dem Editor heraus vergeben kann, denke ich, dass wir erstmal die alte Sec nehmen können, und dann bei Bedarf anpassen.
  • Wiederverwendung von Namen: da bin ich nicht mehr ganz sicher, was besprochen wurde, ich würde aber jetzt erstmal davon ausgehen, dass Namen wiederverwendet werden, d.h. dass Änderungen von Konstantina an den Namen dann sofort auch in der FoG Klassifikation erscheinen. Das müsste aber evtl. noch mit Panayotis besprochen werden. Bislang gibt es ja v.a. noch keine nom. Referenzen in der DB, d.h. es gäbe dann einige wenige Namen, die eine solche haben. Vielleicht nicht so schön.
  • Ich würde die Classifikation „Centaurea“ nennen, oder gibt es einen anderen Wunsch?

====

NK:

  • ja, sehe ich auch so, die alten Sec.-Referenzen sind erst mal OK.
  • Wiederverwendung von Namen: Konstantina hatte kürzlich länger mit Panayotis gesprochen, ihr Projekt vorgestellt und verschiedene Fragen geklärt, aber ich glaube, diese Frage war nicht dabei. Konstantina geht davon aus, dass sie eine nicht öffentlich sichtbare Parallelbearbeitung macht; nur soweit hatte ich das mit ihr besprochen. Wenn ich Dich richtig verstehe, entsteht die eigentliche Hauptflora neben der Checkliste, also in einer eigenen Instanz (als Klon der Checklist treatments??) und nicht direkt aus der Checklist heraus. Wenn dem so ist, dann erschiene es mir auch für Centaurea besser, die Namen nicht in der Checklist wiederzuverwenden, um (a) Uneinheitlichkeiten (mit nomenklatorischer Referenz ohne) innerhalb der Checkliste zu vermeiden, (b) vorläufige Änderungen in der Klassifikation (etwa hinsichtlich Rangstufe von Taxa) nicht sichtbar werden zu lassen [oder würde dies das FoG-Treatment nicht tangieren?, überblicke ich gerade nicht] und (c) vorläufig editorischen Fragen hinsichtlich der Gestaltung aus dem Weg zu gehen (etwa Abweichung von der Code-widrigen Behandlung von in-Referenzen in der Checklist). Was mir nicht klar ist: Was würde bei aktivierter Wiederverwendung mit Namen geschehen, die nicht in der FoG-Klassifikation sind (etwa weil nicht im Gebiet?).
  • Centaurea als Bezeichnung für die Klassifikation ist OK.
  • die Additivity-Ontologie wird sehr bald benötigt, da Konstantina schon dabei ist, Characters + States zu definieren. Dazu müssen wir aber auch noch das Verfahren zwischen Ontologie-Master und Ontologie-Kopien klären: V.a. wo erfolgen die Ergänzung/Ausarbeitung des Structure-Tree und das Anlegen neuer Terme. Zweckmäßigerweise ja wahrscheinlich im Master(?), für das es ja noch keine eigene Instanz gibt (?) ...

=====

AM:

ja, vermutlich hast du Recht und es ist besser, auch die Namen nicht wiederzuverwenden. Es besteht dann zwischen den beiden Treatments in der DB zwar kein Bezug mehr (außer wir erstellen jetzt bei der Kopie Konzeptbeziehungen zwischen den, das wäre problemlos möglich, aber ich weiß nicht ob es sinnvoll ist), aber bei so relativ wenig Taxa ist das vermutlich auch nicht notwendig, da das spätere Austauschen da dann ja auch ohne größeren Aufwand per Hand geschehen kann.

Was mir nicht klar ist: Was würde bei aktivierter Wiederverwendung mit Namen geschehen, die nicht in der FoG-Klassifikation sind (etwa weil nicht im Gebiet?).

Wenn sie bislang gar nicht im System sind, müssten sie neu eingegeben werden, wenn sie hingegen zu den relativ vielen excluded Taxa gehören, können sie als Namen problemlos wiederverwendet werden, da das excluded ja eine Eigenschaft des Taxons/Placements ist, nicht des Namens.
Aber wenn wir auch Namen nicht wiederverwenden, erübrigt sich das ja sowieso.

Ich würde dann Panayotis über dieses Vorgehen informieren und hoffe, dass ich zeitnah eine positive Antwort bekomme. Dann können wir direkt mit dem Clone starten.

Zur Ontology: Ok, dann müssen wir das wohl wirklich bald mal angehen. Das Kopieren des Masters in eine eigene Instanz sollte dabei vergleichsweise einfach sein. Ich denke, das können wir noch im Dezember fertigstellen. Auch das Kopieren in die FoG Instanz sollte dann kein wirklich größeres Problem sein.
Schwieriger wird es aber natürlich bei der Synchronization. Da müssen wir nochmal in uns gehen, wie wir das am besten machen. Es gibt ja eine Reihe Ideen dazu, aber noch nichts abgeschlossenes und auch keine finalen Entscheidungen. Auch hier hoffe ich, dass ich zumindest im Dezember einen Entwurf machen kann, den wir dann im Januar diskutieren können. Bis dahin könnte Constantina aber vielleicht zumindest schon mal mit den bestehenden Structures/Properties/States arbeiten, die ja den bei weitem größten Teil abdecken sollten.
Zu entscheiden wäre aber natürlich auch noch, ob ebenfalls der Character Tree von Caryo_spp übernommen werden soll. Ich glaube, wir hatten das mal so diskutiert, dass wir mit dem Master zumindest auch einen Default Character Tree mitgeben wollten. Das können wir natürlich machen, aber hier wird es natürlich schwieriger sein, den synchron zu halten, insbesondere wenn es nicht nur darum gehen sollte, Characters lediglich hinzuzufügen.

Actions #8

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #9

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #10

Updated by Andreas Müller about 1 year ago

Actions #11

Updated by Andreas Müller about 1 year ago

  • Target version changed from Release 5.18 to Release 5.19

After running the import it became clear that not reusing names is not a good idea as

  • handling name relationships is difficult if name duplicates exist
  • handling nameUsedInSource is difficult if name duplicates exist
  • cloning taxa with name cloning is difficult as cloned names need to be deduplicated for the cloned subtree (see #9349)
Actions #12

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #13

Updated by Andreas Müller about 1 year ago

  • Description updated (diff)
Actions #14

Updated by Andreas Müller about 1 year ago

  • % Done changed from 20 to 30
Actions #15

Updated by Andreas Müller about 1 year ago

  • Target version changed from Release 5.19 to Release 5.21
Actions #16

Updated by Andreas Müller 11 months ago

  • Target version changed from Release 5.21 to Release 5.22
Actions #17

Updated by Andreas Müller 10 months ago

  • Target version changed from Release 5.22 to Release 5.25
Actions #18

Updated by Andreas Müller 7 months ago

  • Target version changed from Release 5.25 to Release 5.29
Actions #19

Updated by Andreas Müller 7 months ago

  • Related to bug #9357: Advanced search shows selection for all classification even if only 1 classification is available for a dataportal added
Actions

Also available in: Atom PDF