Project

General

Profile

feature request #6041

Change the label of "Set as basionym of homotypical group"

Added by Katja Luther over 2 years ago. Updated 1 day ago.

Status:
In Progress
Priority:
Priority13
Category:
taxeditor
Target version:
Start date:
10/19/2016
Due date:
% Done:

0%

Severity:
normal

Description

Hallo,

wir waren bei früherer Gelegenheit schon einmal übereingekommen, dass dieser Kontext-Menu-Befehl in all den Fällen inkorrekt formuliert ist, in denen in einem homotypischen Block replacement names vorkommen. Denn das Basionym ist der legitime Name, an dem der Typus hängt und der gleichzeitig das Epitheton stiftet.

Eine Lösung des Problems ist auf terminologischer Ebene möglich, indem die Typus liefernde Funktion des ältesten Namens von der Epitheton liefernden getrennt wird:
Von "Set/Remove as basionym for homotypic group" kann der Befehl umbenannt werden in: "Set/Remove as type-providing [deutsche Übersetzung: "Typus liefernden"] name for homotypic group".

Ich habe das Problem und diese Lösung mit Nick Turland besprochen und er hat sie für gut befunden.

Beste Grüße,
Norbert

====

Hallo,

mir ist das ehrlichgesagt noch nicht so klar. Semantisch besteht ja ein klarer Unterschied. Die jetzige Funktion ist ein Shortcut, der Basionymbeziehungen zwischen einigen Namen erzeugt während „Typus liefernder Name“ ja eher eine Eigenschaft ist, die sich auf die Beziehung des Namens auf die ganze Gruppe bezieht. Bei der derzeitigen Implementierung mag sich das wie das gleiche Anfühlen, da sie eben sehr vereinfacht ist, datentechnisch und semantisch ist es aber was ziemlich anderes.

Ich hatte vor nicht allzu langer Zeit mal angefragt, ob die derzeitige Implementierung eigentlich ausreichend sei, da komplexere Sachverhalte damit ja nicht abgedeckt würden. Zu meinem Erstaunen schien damals kein größerer Bedarf an einer Änderung zu existieren. Begründung wenn ich mich recht entsinne: für die größere Menge der einfachen Fälle ist es hilfreich. Die komplexen Fälle muss man dann manuell eingeben (oder man hat nicht den Anspruch, sie darzustellen). Ist es diese Diskussion, auf die du dich beziehst, Norbert?

Eine reine Umbenennung des Befehls ist aus o.g. Grund nicht möglich.
Wir müssten diskutieren, ob wir „is type providing name for“ als Namensbeziehung etablieren wollen (wobei ich mir nicht sicher bin, ob das so stimmt), oder ob wir der homotypischen Gruppe als Ganzes ein neues Attribut hinzufügen wollen, wobei man dann klären muss, ob es wirklich IMMER nur einen solchen Namen pro Gruppe gibt.

Ist denn der Begriff „type providing name“ gängig bzw. vom Code/den Codes abgedeckt und versteht jeder das gleiche darunter?

Wichtig wäre v.a. auch zu klären, wozu wir die jeweils unterschiedlichen Informationen (Basionymbeziehung, Replaced Synonym Beziehung, Typus lieferender Name, etc.) wirklich brauchen, und welche Information davon 1) in Publikationen irgendwie visualisiert werden soll und welche 2) im Editor leicht eingebbar sein soll.

Denn das Basionym ist der legitime Name, an dem der Typus hängt und der gleichzeitig das Epitheton stiftet.
Das scheint mir nicht ganz korrekt zu sein, da es in komplexeren Fällen ja auch mehrere Basionyme innerhalb einer Homotypischen Gruppe geben kann. Es stimmt also nur für den ältesten legitimen Namen (der nicht mal ein Basionym sein muss).

Das scheint mir ein Thema für ein Usermeeting zu sein?

Viele Grüße,
Andreas M.

====

Hallo,

die jetzige Shortcut-Funktion erzeugt eine Basionymbeziehung zwischen einem und allen(!) anderen Namen einer homotypischen Gruppe und ihre Bedeutung besteht darin, dass sie festlegt, welcher Name (a) den Typus für die homotypischen Gruppe und (b) das Epitheton liefert. Letzteres ist auch schon aus den Taxonnamen mit Autoren selbst ersichtlich, deshalb eigentlich der weniger wichtige Teil der Funktion. Ersteres ist absolut wesentlich, da die homotypische Gruppe ja genau dadurch definiert ist, dass sich alle Namen in ihr letztlich auf einen einzigen und dessen Typus beziehen, also dessen und zueinander homotypische Synonyme sind. Da Ersteres immer, Letzteres aber wg. der replacement names nur eingeschränkt für die Namen einer homotypischen Gruppe gilt, zielt mein Vorschlag nur darauf ab, Ersteres ohne die in vielen Fällen unzutreffende Verallgemeinerung des Letzteren zu erhalten. Deshalb sehe ich nicht, worin der klare semantische Unterschied bestehen soll.

Wie gesagt, habe ich Sachverhalt und Begriff "type providing name" mit Nick Turland aus dem engsten Kreis der Editoren des Codes besprochen. Den Begriff "type providing name" gibt es nicht als expliziten Terminus im Code. Mit dem Begriff "homotypisches Synonym" gibt es zwar einen allgemeinen Begriff für alle Namen, die sich auf denselben Typus liefernden Namen beziehen, für die hier benötigte komplementäre Beziehung fehlt aber ein (Basionyme und replaced synonyme umfassenden) Überbegriff. "Type providing name" ist selbsterklärend und die Wendung "a name / taxon x provides the type of a name y" als solche ist sehr wohl im Gebrauch bei Taxonomen die nomenklatorisch korrekt formulieren.

Als Du letztens anfragtest, ob die gegenwärtige Implementierung ausreicht, war uns wohl bewusst, dass die sehr praktische Basionymbeziehungs-Funktion wie implementiert wegen der replacement names eigentlich nicht ganz korrekt ist. Wir wollten aber weder auf diese wichtige Funktion verzichten, noch das Ganze unnötig komplizieren. Nur deshalb haben wir eine Lösung vertagt und keinen Handlungsbedarf angemeldet.

Die Bezeichnung von Basionymbeziehungen muss damit ja nicht wegfallen, sondern ließe sich, etwas mühseliger eben, direkt über die Name relations eingeben, vielleicht lässt sich auch eine Short-cut-Funktion konstruieren, die vorher ausgewählte Namen einer homotypischen Gruppe einem Basionym zuordnet ....

Beste Grüße,
Norbert


Subtasks

bug #6136: Implement type providing name in homotypical groupNewAndreas Müller

feature request #6187: [DISCUSS] Ask W.Greuter about "type providing name"NewAndreas Müller

feature request #6188: Make "Set as basionym of homotypical group" an optional functionNewKatja Luther

Associated revisions

Revision 6e572e21 (diff)
Added by Katja Luther over 2 years ago

ref #6041: revert the changes and wait for the decision of the user meeting

History

#1 Updated by Katja Luther over 2 years ago

  • Tracker changed from bug to feature request

#2 Updated by Katja Luther over 2 years ago

  • Status changed from New to Resolved

#3 Updated by Katja Luther over 2 years ago

  • % Done changed from 0 to 50

Applied in changeset edit-svn|r28863.

#4 Updated by Katja Luther over 2 years ago

  • Assignee changed from Katja Luther to Andreas Müller

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

  • Description updated (diff)
  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • Priority changed from New to Highest
  • Target version set to Release 4.3

I am not convinced yet that this is correct. Therefore I think we need to discuss this during the next user meeting.

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

  • Parent task set to #5595

#7 Updated by Katja Luther over 2 years ago

This needs to be discussed in User Meeting, move it to Release 4.4 and decide then if we change it or not.

#8 Updated by Katja Luther over 2 years ago

  • Target version changed from Release 4.3 to Release 4.4

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

But first revert the already existing changes!!!

#10 Updated by Katja Luther over 2 years ago

Andreas Müller wrote:

But first revert the already existing changes!!!

It is already reverted see Revision 6e572e21

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

Katja Luther wrote:

Andreas Müller wrote:

But first revert the already existing changes!!!

It is already reverted see Revision 6e572e21

Ahh, yes, sorry I had overseen this change

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

  • Assignee changed from Katja Luther to Andreas Müller

Conclusion of the discussion:

  • The current functionality can not simply be relabeled
  • The current functionality might become an optional function that is switched off by default (not finally decided)
  • Required model change: Homotypic groups do get a new attribute "type providing name"
  • A new function is created "Set/Remove as type-providing name for homotypic group
  • Ask W. Greuter if this is correct

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

  • Blocked by bug #6136: Implement type providing name in homotypical group added

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

  • Target version changed from Release 4.4 to Unassigned CDM tickets

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

Set back to unassigned CDM tickets as first child tickets have to be resolved.

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

  • Status changed from Feedback to In Progress

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)