feature request #9836
closedMake nameUsedInSource available for secundum references
100%
Description
For some reason probably during #9549 the nameUsedInSource field for secundum references is not visible in the TaxEditor. However, it is an important requirement as the below request shows. It should be at least configurable to show and make editable this field. Maybe also the other fields should be visible by configuration but with default "don't show". But most important is nameUsedInsource and it should be available by default.
NaK:
es war doch angedacht, für die Secundum-Referenz eine name in source – Funktion hinzuzufügen, und ich wollte mal fragen, ob das für irgendwann demnächst geplant ist?
Die wäre wirklich super wichtig und hilfreich für uns und wird deshalb sehnlichst gewünscht
Related issues
Updated by Andreas Müller almost 3 years ago
- Related to feature request #9549: Reduce visible fields for nomenclatural source and secundum source in TaxEditor added
Updated by Andreas Müller almost 3 years ago
- Related to feature request #9328: Adapt Editor to switch to originalSource for taxon secundum added
Updated by Andreas Müller almost 3 years ago
- Target version changed from Unassigned CDM tickets to Release 5.28
Updated by Andreas Müller almost 3 years ago
Maybe the secundum source should get an own section similar to nomenclatural source so it becomes clearer what belongs together and if not needed it can be collapsed. But it could be a subsection within "Taxon" similar to "scientific name" in "Name"
Updated by Andreas Müller almost 3 years ago
We should also think about improved structuring for the preference page of the name/taxon details view preferences. Currently it is more or less a list and it does not always follow the order in the view itself.
Also some field or subfields are missing. And structuring elements like rectangles for groups, ...
Updated by Katja Luther almost 3 years ago
- Status changed from New to In Progress
As a first step the name in Source field was added. We have to decide whether we want to have the own section in this release or next.
Updated by Katja Luther almost 3 years ago
Andreas Müller wrote:
We should also think about improved structuring for the preference page of the name/taxon details view preferences. Currently it is more or less a list and it does not always follow the order in the view itself.
Also some field or subfields are missing. And structuring elements like rectangles for groups, ...
Added this to #9835 because it is more about the preference page than the details view itself.
Updated by Andreas Müller almost 3 years ago
AM:
... ich wollte allerdings gerne nochmal klären, ob wir bei der Semantik des Feldes übereinstimmen.
Aus meiner Sicht ist das der Name der verwendet wurde, wenn bei der Beschreibung des Konzepts ein anderes Taxon akzeptiert war als das in der vorliegenden Datenbank akzeptierte. Das Konzept hängt also nicht am akzeptierten Namen sondern ist von diesem unabhängig.
Stimmt diese Definition mit eurer (Nadja, Walter) Definition überein?
Daraus würde folgen, dass wir für Synonyme so ein Feld eigentlich i.d.R. nicht brauchen, da die syn. sec. ja lediglich die Zugehörigkeit eines Namens zu einem Konzept definiert. Somit ist klar welcher Name hier verwendet wird, nämlich der in der DB genannte. Einzige für mich vorstellbare Ausnahme: orthographische Varianten die von der in der DB genannten abweichen. Kommt sowas vor? Ansonsten würde ich vorschlagen, das Feld für Synonyme erstmal wieder auszuschalten (zumindest als Defaulteinstellung).
Eine weiterführende Idee zu dem Thema hatte ich ja mal in einem nicht zu Ende geführten Email Thread angedacht, nämlich beim akzeptierten Namen auch klar zwischen Konzeptreferenz (sec.) und der Referenz, die die Zugehörigkeit des reinen Namens zum Konzept definiert (also das gleiche wie syn. sec. aber eben für den akzeptierten Namen) zu unterscheiden. Das würde dann auch solche Operationen wie swap (akzeptiert <-> Synonym) deutlich vereinfachen, weil die sec. dann immer beim Konzept bleibt, während die andere Referenz immer mit dem Namen wandert. Das würde ich gerne irgendwann nochmal aufgreifen.
Updated by Katja Luther almost 3 years ago
mail NaK:
nach meiner Erfahrung bisher ist das name in source vor allem wichtig wenn das Taxon in der sec. Referenz akzeptiert wird, aber eben unter einem homotypischen Synonym, also meistens in einer anderen Gattung. Die Umschreibung ist davon aber nicht betroffen, nur die Zugehörigkeit zur Gattung.
Beispiel
Wir wollen akzeptieren
Lobivia bridgesii, sec. Kiesling & al. 2014
Aber bei Kiesling et al. ist diese Art noch nicht in der Gattung Lobivia, sondern noch in der Gattung Echinopsis.
Und hier bräuchte man eben die Möglichkeit, das name in source anzugeben
Lobivia bridgesii, sec. Kiesling & al. 2014, name in source Echinopsis bridgesii
Das ist ein hypothetisches Beispiel, nicht die wirklich verwendete secundum-Referenz.
Wenn wirklich ein anderes Taxon, also eines der hetereotypischen Synonyme in der sec. Ref. akzeptiert war, und dieses Taxon jetzt nicht mehr akzeptiert wird, ist das name in source eigentlich auch sinnvoll, dieser Fall ist aber sicher seltener, könnte aber für regionale Treatments sehr wichtig sein. Ich versuche mal, das zu durchdenken
Angenommen,
akzeptiert: Lobivia bridgesii (1849)
= Echinopsis coronata (1962)
in einer Bolivien-Checkliste wird nur Lobivia bridgesii akzeptiert und in einer Argentinien-Checkliste nur Echinopsis coronata
(das denke ich mir gerade aus, nicht nachprüfen!)
Und wir sind uns sicher, die beiden Namen sind Synonyme, und der ältere, deshalb gültige Name ist L. bridgesii, den man akzeptieren muss, also könnte man das so angeben
Lobivia bridgesii, sec. “Argentinien-Checkliste”, name in source Echinopsis coronata
Für die Zuordnung von E. coronata als Synonym zu L. bridgesii müsste es dann natürlich noch eine weitere sec. Referenz geben.
Andreas, um Deine Frage zu beantworten, ich denke, für Synonyme bräuchte man das Feld tatsächlich als Default nicht, nur für akzeptierte Namen.
WGB:
Erste Frage: Ja.
Zweite Frage: Klar nein, brauchen wir nicht, ein Name (hier: Synonym) kann nicht unter einem anderen Namen genannt werden.
Aber es gibt die Frage einer indirekten Synonymzuordnung, das ist eine andere – es ist das Taxon, unter dem das Synonym stand, wenn dieses verschieden von unserem ist. Also: In einer Publikation (Q) gibt es einen akzeptierten Namen (A), dem ein heterotypisches Synonym (Z) zugeordnet wurde. Der akz. Name (A) ist bei uns als Synonym eines Taxons (B) vorhanden. Wir ordnen das Synonym (Z) unserem akzeptierten Namen (B) aufgrund der Synonymisierung in der Quelle (Q) zu. Gegenwärtig wird die Synonym (Z) bei uns als syn. sec. Q geführt. Mir reicht das so.
Updated by Andreas Müller almost 3 years ago
- % Done changed from 0 to 20
@Katja, can you remove the nameUsedInSource for synonyms then?
Updated by Katja Luther almost 3 years ago
Andreas Müller wrote:
@Katja, can you remove the nameUsedInSource for synonyms then?
this is already implemented with defbfd3c9e98eef4c421beb69bb33772eaf34be6
Updated by Katja Luther almost 3 years ago
- Status changed from In Progress to Resolved
- Assignee changed from Katja Luther to Andreas Müller
Can this be closed?
Updated by Andreas Müller almost 3 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
Currently it also does not show up for accepted taxa. This needs to be fixed before release.
Updated by Katja Luther almost 3 years ago
Andreas Müller wrote:
Currently it also does not show up for accepted taxa. This needs to be fixed before release.
Sorry, something went wrong and the line was removed. Now it should work as expected.
Updated by Andreas Müller almost 3 years ago
- Status changed from Feedback to Closed
- % Done changed from 20 to 100
This works now.