Project

General

Profile

feature request #5794

Move other invalid names to the end

Added by Andreas Müller over 5 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Priority14
Category:
cdmlib
Target version:
Start date:
05/23/2016
Due date:
% Done:

100%

Severity:
normal

Description

Split from #3046

In #3046 only nom. inval. and nom. nud. were put to the end with nom. nude. comes after nom. inval.

We also need to move other invalid names to the end like provisional, comb. inval., comb. ined. and opp. utique oppr.

Comb. inval. and comb. ined. will usually exist only in homotypic groups, so we need to assure they are put to the end of the group, not to end of the synonymy.

Provisional can stand alone, for opp. utique oppr. we need information from taxonomists.

Comb. ined. is not yet an existing status in CDM. Do we need it? #5795

see also #3062 and #3338

Update: see also #9272 and #5794#note-23 for further discussion which status to put to the end and for including name relationships


Related issues

Related to Edit - feature request #9272: Add missing nomenclatural status Closed 11/03/2020
Related to Edit - feature request #5795: [DISCUSS] Do we need comb. ined. as a nomenclatural status? Closed 05/23/2016
Related to Edit - bug #9440: Invalid designation sign missing for some invalid designations in data portal New 02/01/2021
Related to Edit - feature request #9282: Add nomenclatural standing Closed 11/06/2020
Copied to Edit - bug #9441: Move names with invalid designation name relationships to the end in taxon comparator Closed 02/01/2021

Associated revisions

Revision 0edc55f4 (diff)
Added by Andreas Müller 11 months ago

ref #9272, ref #5794 adapt taxon ordering to nomenclatural standing

History

#1 Updated by Andreas Müller over 5 years ago

  • Target version changed from Release 4.1 to Release 4.2

#2 Updated by Andreas Müller over 5 years ago

  • Target version changed from Release 4.2 to Release 4.3

#3 Updated by Andreas Müller about 5 years ago

  • Target version changed from Release 4.3 to Release 4.4

#4 Updated by Andreas Müller almost 5 years ago

  • Target version changed from Release 4.4 to Release 4.5

#5 Updated by Andreas Müller almost 5 years ago

  • Target version changed from Release 4.5 to Release 4.6

#6 Updated by Andreas Müller over 4 years ago

  • Description updated (diff)
  • Target version changed from Release 4.6 to Release 4.9

#7 Updated by Andreas Müller over 4 years ago

  • Target version changed from Release 4.9 to Release 4.10

#8 Updated by Andreas Müller about 4 years ago

  • Target version changed from Release 4.10 to Release 4.12

#9 Updated by Andreas Müller almost 4 years ago

  • Target version changed from Release 4.12 to Release 4.13

#10 Updated by Andreas Müller over 3 years ago

  • Target version changed from Release 4.13 to Release 4.14

#11 Updated by Andreas Müller over 3 years ago

  • Target version changed from Release 4.14 to Release 5.0

#12 Updated by Andreas Müller over 3 years ago

  • Target version changed from Release 5.0 to Release 5.1

#13 Updated by Andreas Müller over 3 years ago

  • Target version changed from Release 5.1 to Release 5.2

#14 Updated by Andreas Müller about 3 years ago

  • Target version changed from Release 5.2 to Release 5.3

#15 Updated by Andreas Müller about 3 years ago

  • Target version changed from Release 5.3 to Release 5.5

#16 Updated by Andreas Müller over 2 years ago

  • Target version changed from Release 5.5 to Release 5.6

#17 Updated by Andreas Müller over 2 years ago

  • Target version changed from Release 5.6 to Reviewed Next Major Release

#18 Updated by Andreas Müller 11 months ago

#19 Updated by Andreas Müller 11 months ago

#20 Updated by Andreas Müller 11 months ago

  • Private changed from Yes to No

#21 Updated by Andreas Müller 11 months ago

  • Status changed from New to Resolved
  • Target version changed from Reviewed Next Major Release to Release 5.18

Needs to be checked against new implementations within #9272 and #9282 , does comparator work accordingly. Also add discussion to one of the tickets.

#22 Updated by Andreas Müller 9 months ago

  • Description updated (diff)

#23 Updated by Andreas Müller 9 months ago

AM:

derzeit versuchen wir (also v.a. Walter und ich) die nomenklatorischen Status und v.a. die Namen, die lediglich Designations sind, ein bisschen aufzuräumen, insbesondere auch in Richtgung cdmlight/printPublication Ausgabe.

Dabei bin ich auch auf das Ticket https://dev.e-taxonomy.eu/redmine/issues/3046 gestoßen, bei der es um die Sortierung von Namen geht. In der Description steht, dass du, Norbert, mal gesagt hättest, dass nur nom. inval. und nom. nudum. ans Ende gesetzt werden müssten.
Aus #9272 geht aber hervor, dass wir eine Reihe mehr Status und Namensrelationstypen haben, die dazu führen, dass eine Name lediglich eine Designation ist.
Daher die Frage für die anderen Status, ob die entsprechend ans Ende sortiert werden sollen, oder die Anforederungen von #3046 wirklich nicht gelten, also insbesondere

  • comb. inval.
  • nom. prov.
  • op. utique oppr.
  • In pro syn.
  • published with alternative name

aber auch

  • later isonym
  • later citation
  • nom. rej.
  • nom. utique rej.
  • nom. confus.
  • nom ined.
  • nom. ambig.
  • orth. var.

Grundsätzlich würde ich ja denken, dass alle Namen, die eigentlich keine sind, nach unten geschoben werden sollten, aber da mag ich falsch liegen.

====

NK:

ich denke, ans Ende sollen alle Bezeichnungen, die keine gültigen Namen im nomenklatorischen Sinne sind und deshalb auch mit einem dash statt Identitätszeichen versehen sind.

Das sind alle in der ersten Liste unten, aber mit Einschränkung des letzten, denn Veröffentlichung mit Alternativname macht beide erst seit 1.1. 1953 invalide, siehe Art. 36.3!

Die zweite Liste ist inhomogener:

  • later isonym und later citation sind eigentlich das gleiche die durch den älteren zu ersetzen sind, sollten gar nicht aufgeführt werden, aber wenn doch dann mit dash, also in erste Liste
  • nom. rej. und nom. utique rej. sind nachträglich ungültig erklärt worden und können im Allgemeinen wie die in der ersten Liste behandelt werden
  • nom. ined. gehört klar in die erste Liste

  • nom. confus. & nom. ambig. sind eigentlich warnende Kennzeichnungen für gültige Namen (s. 57.1. für nom. confus.) mit Problemen die noch einer Lösung zugeführt werden müssen (durch Sanktionierung), können nicht einfach nach hinten gereiht werden

  • orth. var. sollte doch mit der gültigen Variante zitiert werden und nicht als eigene Namen, oder sehe ich das falsch?

===

WGB:

Da war ich zu schnell

Veröffentlichung mit Alternativname macht beide erst seit 1.1. 1953 invalide, siehe Art. 36.3!7

Muss ich mir noch mal ansehen – erstmal als gültig einreihen, kann man dann ja als nom. inval. in die Strich-Liste verbannen.

nom. confus. & nom. ambig. sind eigentlich warnende Kennzeichnungen für gültige Namen (s. 57.1. für nom. confus.) mit Problemen die noch einer Lösung zugeführt werden müssen (durch Sanktionierung), können nicht einfach nach hinten gereiht werden

Muss ich mir noch mal ansehen – ich glaube, Nick meinte, sie sollten als „not to be used“ bei den other designations eingereiht werden, aber ich zweifle auch. Erstmal als Namen lassen, denke ich.

orth. var. sollte doch mit der gültigen Variante zitiert werden und nicht als eigene Namen, oder sehe ich das falsch?

Wenn sie (per editorial decision) als Synonyme geführt werden, dann als designations, nicht als Namen s.str.

===

AM:

vielen Dank für die Antworten.

Es herrscht also wohl Einigkeit darüber, dass Designations nur den Dash bekommen und dann auch grundsätzlich ans Ende sollen.

Abweichend von meiner Ausführung unten werden nom. confus. und nom. ambig. nicht als Designations behandelt sondern sind, wenn nicht anderweitig eingeschränkt, erstmal als normale Namen zu behandeln.

„published with alternative name“ gibt es im CDM bislang nicht, soll aber hinzugefügt werden. Erstmal ohne einen abweichenden Status zu begründen. Man könnte natürlich auch eine explizite Beziehung „published with alternative name (after 1952)“ einfügen, die das Handling klarer machen würde. Alternativ wäre auch denkbar, dass in diesem Fall die Jahreszahl der nom. ref. ausgewertet wird, wenn vorhanden. Programmierseitig aber die komplexere Lösung.

3 weitere Status/Relationen:
Es gibt noch einige wenige weitere Status/Relationen, die ich gestern noch nicht erwähnt hatte, da sie in Walters Liste ursprünglich noch nicht standen.

  • comb. ined.
  • in sched. (Stand in erster Liste, wurde beim Schreiben der Mail aber verschluckt)
  • orth. rej.

Insbesondere beim 3. Fall bin ich mir nicht sicher. Wie seht ihr das?

===

NK:

  • comb. ined. + in sched. : Das sind Spezialfälle von nom. ined. und zu behandeln wie diese
  • orth. rej.: wenn ich richtig verstehe, was damit gemeint ist, dann sind das die Fälle, in denen eine bestimmte Schreibweise per Beschluss konserviert wurde und damit die alternative Schreibweise explitzit zurückgewiesen wurde, wäre dann zu behandeln wie nom. rej.

===

AM:

Danke, also alle 3 mit Dash und ans Ende.

Gibt es eigentlich innerhalb der Designations noch eine Reihenfolge zu beachten, oder kann ich da die „normale“ Sortierung anwenden, also Jahreszahl und/oder Alphabet?

===

WGB:

Jahreszahl würde ich gerne anwenden.

===

ich sehe gerade, dass im bisherigen Code wohl eine Sortierung existierte, dass erst

  • nom. prov.,
  • dann nom./comb. inval bzw. op. utique oppr.
  • und dann als letztes nom. nud.

kam. Würde ich erstmal so lassen, da es vermutlich einen Grund gibt dafür, können wir aber nochmal diskutieren.

===

WGB:

erschließt sich mir nicht – ist aber eher ein marginales Problem.

#24 Updated by Andreas Müller 9 months ago

  • Related to bug #9440: Invalid designation sign missing for some invalid designations in data portal added

#25 Updated by Andreas Müller 9 months ago

missing invalid designation sign (dash) in data portal moved to #9440

#26 Updated by Andreas Müller 9 months ago

  • Copied to bug #9441: Move names with invalid designation name relationships to the end in taxon comparator added

#27 Updated by Andreas Müller 9 months ago

  • Description updated (diff)

missing handling of invalid designation name relationships moved to #9441

#28 Updated by Andreas Müller 9 months ago

  • Description updated (diff)

#29 Updated by Andreas Müller 9 months ago

  • Description updated (diff)
  • Status changed from Resolved to Closed
  • % Done changed from 50 to 100

Open issues moved to new tickets.

#30 Updated by Andreas Müller 9 months ago

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)