EDIT

Hallo,

ich sehe eigentlich nicht, warum die aufgeführten Fälle 1) und 2) nicht mit der "is blocking name for"-Beziehung zu bedienen sind.

Es ist ja nicht so, dass in diesen Fällen weniger Beziehung zwischen den Namen existiert als im Fall 3). Der einzige Unterschied, den ich sehe, ist, dass im Fall 1) ein potenziell blocking names aufgeführt ist für einen ggf. zu validierenden Namen.

Fall 2) ist direkt analog zu 3), da hier die Kombination von C. verrucosum Griseb. (1866) in Miconia blockiert ist durch M. verrucosum Cogn. (1891), weshalb O. costata (1926) als ältestes verfügbares Basionym in Miconia neu kombiniert wurde. Ich würde in beiden Fällen die Beziehung des blocking name zum (potenziell) replaced name setzen, also in 1) zum nom. inval., in 2) zu Calycogonium verrucosum Griseb. (und damit ein weiteres Argument dafür, die "blocking name for" Beziehung grundsätzlich nicht zum replacement name sondern zum replaced synonym aufzubauen).

Oder habe ich einen Denkfehler?

Schöne Grüße,

Norbert

====

Hallo Norbert,

ok, jetzt verstehe ich das teilweise besser. Wenn bei 1) der Verweis auf die mögliche Blockierung bei eventuell späterer Validierung des Namens im Vordergrund steht, hast du natürlich Recht. Ich dachte es wäre ein allgemeiner Hinweis darauf, dass hier nicht Smilax lanceifolia Roxb. gemeint ist.

Bei 2) war ich davon ausgegangen, dass die Tatsache, dass es sich um 2 verschiedene Typen / homotypische Gruppen handelt erstmal keinen Namen blockiert, wenn man für die erste Gruppe einen Namen in Miconia kreiert. Aber ich merke gerade, dass ich mich da taxonomisch nicht wirklich auskenne, auf welchen Typus man sich bevorzugt bezieht, wenn man für ein Taxon mit mehreren Typen einen Namen in einer neuen Gattung braucht.

Du leitest daraus zusammen mit 3) ab, dass es eben doch gut ist, den blocking name auf das replaced synonym zu beziehen und nicht auf den replacement name. Das macht natürlich einen gewissen Sinn, wenn man eine potentielle Blockierung eines Namens bei Rekombination in eine andere Gattung darstellen will.

Gleichzeitig hatten wir aber bei unserem Treffen bei Walter festgestellt, dass das "non" im Text doch eher hinter dem replacement name und NICHT hinter dem replaced synonym erwartet würde, was wiederum für die Gegenthese spricht. Wenn ich mich recht entsinne haben dem alle (?) zugestimmt.

Mir ist es letztlich egal, stelle aber fest, dass es da evtl noch Klärungsbedarf gibt, den wir demnächst mal angehen sollten.

Viele Grüße,

Andreas M.

===

Hallo,

noch mal zur Position des blocking names: ist es denn überhaupt nötig, dass wir uns auf eine Position festlegen??

Die aktuelle Implementierung lässt doch beide Positionen zu, oder? Falsch ist m.E. grundsätzlich keine der beiden Möglichkeit, und damit ist es eine Frage des Geschmacks bzw. der leichteren Verständlichkeit und beides ist fallabhängig. Ich fände es, z.B. aus Sicht nomenklatorisch weniger interessierter Nutzer irritierend, wenn hinter dem replacement name als akzeptiertem Namen eines Taxons so ein "...." auftaucht, mit dem sonst eben auch illegitime jüngere Homonyme gekennzeichnet werden.

Schöne Grüße,

Norbert

===

Hallo Norbert,

grundsätzlich ist das natürlich dem Datenkurator überlassen, was er jeweils macht.

Mir ging es mehr um die Semantik der Beziehung. Eine Beziehung die „is blocking name for“ heisst, bedeutet eben streng genommen etwas anderes als eine Beziehung „is not“ oder „could block a potential new combination“ oder „is later homonym“ oder was auch immer.

Im Portal sieht man das eben nicht, weil es da in der Kurzform „(non xxx)“ ausgegeben wird.

Grundsätzlich ist es eben unschön, wenn semantisch „falsche“ Daten angelegt werden, nur weil sie erstmal richtig aussehen.

Wenn jemand später herkommt (nur als Beispiel) und sagt, gibt mir mal alle blocking names der Datenbank und da kommen völlig unterschiedliche Sachen bei raus, je nachdem, ob es sich um ein akzeptiertes Taxon oder ein Synonym handelt, ist das nicht so schön. Daher eben meine Idee, evtl. weitere Namensbeziehungen zu verwenden, die dann jeweils für den einzelnen Fall passen und den Sachverhalt auch exakt ausdrücken, und/oder eine generische Relation, die einfach nur „is not“ heißt und somit gar nicht den Anspruch hat, semantisch spezifisch zu sein.

Auch bei der Validierung von Daten würde das helfen, da man dann über gewisse Regeln evtl. Fehler leichter finden würde.

Ich kann selber aber nicht einschätzen, wie wichtig das letztlich wäre.

Viele Grüße,

Andreas M.

===

Hallo Andreas,

OK, verstehe.

Dann ist aber der status quo doch der: Die Beziehung „is blocking name for“ fordert in meinem Verständnis eindeutig, dass sie zum replaced synonym angelegt wird (dessen Epitheton ist doch blockiert) (was ich im Übrigen immer noch bevorzuge). „is blocking name for“ schließt in meinen Augen „could block a potential new combination of“ ein. Wenn man die non-Beziehung an den replacement name hängen möchte, bedürfte es folglich einer anderen Beziehung in der Art von "is replacement name enforced by"

Wenn ich das recht überblicke, gibt es ja nur sehr wenige unterschiedliche Beziehungen dieser Art. Deshalb bin ich für spezifische und ziemlich gegen eine unspezifische "is not" Beziehung: die non-Beziehung sollte v.a. nicht missbraucht werden dürfen, um auf irgendwelche vermeintlichen Verwechslungsgefahren hinzuweisen (in großen Gattungen sind sich Namen nicht selten recht ähnlich und das böte viel Raum für inflationäre Anwendung).

Beste Grüße,

Norbert

I added "is non" to dataportal output cdm-dataportal|bf522fd0e17. Can you please check for cdmlight and close this ticket if it works (or fix it)?

I created a temporary example page at https://test.e-taxonomy.eu/dataportal/preview/cyprus/cdm_dataportal/taxon/336a8807-05e1-4922-b5c9-a6e43f1e02da/synonymy

This should be fixed, open issues moved to related tickets.