Project

General

Profile

feature request #5655

[DISCUSS] Do we need further "non xxx" relations?

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

Status:
Resolved
Priority:
Highest
Category:
cdm
Target version:
Start date:
03/17/2016
Due date:
% Done:

50%

Severity:
normal
Tags:

Description

duplicate for #5640

Liebe Taxonomen,

hier nochmal 1-2 vermutlich letzte Frage(n), die sich aus dem Import der Cuba Checklist von Greuter und auch anderen Importen (z.B. eFloras) für mich ergeben und die wir teilweise auch schon bei unserem letzten Treffen bei Walter andiskutiert haben, nämlich die Frage der Namensrelationen, die später als „(non XXX)“ im Portal dargestellt werden.

Meine beiden Fragen sind, ob wir (1) mehr solche Relationen brauchen, als wir bislang haben und ob wir (2) eine Basisrelation brauchen, die lediglich so etwas wie „is NOT same as“ ausdrückt, und die für alle Fälle verwendet werden kann, in denen entweder keine bessere Relation existiert oder in der die Daten zur Entscheidung für eine bessere Relation nicht vorliegen.

Bislang haben wir die 3 Relationstypen „is later homonym of“, „is treated as later homonym of” und “is blocking name for” soweit ich mich entsinnen kann.

Folgende Fälle sind mir u.a. in letzter Zeit vorgekommen, die ich (als Nicht-Taxonomon) da nicht richtig einsortieren konnte:

  1. “Smilax lancifolia” nom. inval. Smilax lanceifolia Roxb.

  2. Miconia costata (Urb.) Judd & al. (Ossaea costata Urb.)

Hat die heterotypischen Synonyme: Calycogonium verrucosum Griseb. (Ossaea verrucosa (Griseb.) M. Gómez)

mit Miconia verrucosa Cogn.

Wenn ich Fall 2) richtig interpretiere soll hier nur auf die Verwechslungsgefahr hingewiesen werden, eine wirkliche Namensbeziehung liegt also gar nicht vor. Zudem ist hier zu beachten, dass sich die Beziehung, wie Greuter meinte, ja auf die ganze Gruppe bezieht, und nicht auf einen einzelnen Namen aus der Gruppe. Diese Modellierung würde ich aber aus Komplexitätsgründen gerne vermeiden.

Hinzu kommt der (3) Fall, den wir diskutiert haben:

Replaced Synonym:          A x Lus, 
Replacement Name:        B y Mus
Blocking name:                   B x Kus
Und theoretisch aber nicht genannt der blockierte Name
                                                  B x (Lus)Fus

Jetzt war unklar, auf welchen Namen sich die blocking Name Beziehung beziehen soll, wobei wir festgestellt haben, dass das i.d.R. hinter dem replacement name steht und somit die Beziehung zu diesem Namen Sinn macht. Aber aus taxonomischer Sicht schien das eher nicht einleuchtend zu sein, da eher das replaced synonym als der blockierte Name empfunden wurde.

Evtl. bräuchten wir hier also überhaupt eine anders lautende Beziehung, die klarer macht, wie sie zu benutzen ist.

Meine WICHTIGSTE Frage wäre nun:

Spricht etwas dagegen eine zusätzliche sehr allgemeine „is NOT“ oder „is NOT same as“ Beziehung einzuführen, die man immer verwenden kann, wenn etwas spezifischeres nicht existiert oder das Wissen dafür fehlt.

Die Gefahr ist natürlich wie immer, dass diese Beziehung dann auch verwendet werden kann wenn das Wissen eigentlich existieren würde.

Zusätzlich können wir dann noch über mögliche fehlende und/oder umzubenennende Namensrelationen unterhalten.

Meint ihr, wir können das per Email klären oder sollten wir das nochmal unter 10+ Augen besprechen mit einem Extrameeting oder während des BGBM User Meetings?

Auch würde mich interessieren, ob so etwas im Zusammenhang mit dem Berlin Model schon mal diskutiert wurde.

Viele Grüße,

Andreas M.


Related issues

Related to Edit - feature request #9698: Make name relationship filter a DB preference New 07/06/2021
Duplicated by Edit - feature request #5640: [DISCUSS] Do we need a general "non" name relationship Duplicate 04/19/2016

Associated revisions

Revision c7c43b5b (diff)
Added by Andreas Müller 4 months ago

ref #5655, ref #5640 unspecific 'non' NameRelationshipType added

History

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

  • Keywords set to Cuba

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

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

  • Subject changed from [DISCUSS] Do we need further "non xxx" relatsions? to [DISCUSS] Do we need further "non xxx" relations?

#4 Updated by Andreas Müller 4 months ago

  • Description updated (diff)

#5 Updated by Andreas Müller 4 months ago

#6 Updated by Andreas Müller 4 months ago

  • Target version changed from Unassigned CDM tickets to Release 5.25

#7 Updated by Andreas Müller 4 months ago

Hallo,
ich dachte, ich hätte hierzu schon geschrieben, aber ich finde die Mail nicht (und im Release ist’s auch nicht):
Ich brauche (Cuba) eine Name relationship die nur „non“ sagt, ohne Begründung. Das sind Fälle, wo über manchmal 3 Ecken klargestellt wird, das ein Name nicht zu einem anderen gehört, z.B. obwohl das vom Epitheton und von der Gattungssynonymie her so scheinen könnte.
Isnardia repens DC., Prodr. 3: 60. 1828. [non Jussiaea repens L.]
Das kommt ziemlich oft vor. Wenn es da keine schnelle Möglichkeit gibt, müsste ich das in die Appended Phrase setzten (lassen).
Herzlichen Gruß
Walter

#8 Updated by Andreas Müller 4 months ago

WGB:

Non-indications without giving the exact reason:
I would also [like] to have a simple directed name relationship that has the effect that a second name appears after the homotypic group following “non” in the output. This can be used as an initial input in order not to lose too much time in finding out why exactly this was expressed in a publication, and it can help to avoid over-modelling very rare nomenclatural cases (with the resulting rare errors in the output). Example:

Ludwigia repens Sw., Prodr.: 33. 1788 (non Ludwigia repens J. R. Forst. 1771, nom. cons.) ≡ Isnardia repens DC., Prodr. 3: 60. 1828 ≡ Jussiaea swartziana DC., Prodr. 3: 54. 1828, nom. altern. (non Jussiaea repens L. 1753).

Here I refer to the second “non”. This name relationship refers to the entire group, clarifying that neither of the names given before has anything to do with J. repens L. (which might be thought, of course, because Jussiaea L. is treated as a synonym of Ludwigia). I think we don’t have an explicit relationship expressing that for any of them.

In this case it is the entire homotypical group, but this may also be the case for individual names (where the author wants to express this independence of epithets in different synonymised genera). I’d therefore opt for including this as a simple name relationship, with a function to cite it only once in the end if the same relationship has been defined for all members of a homot. group.

#9 Updated by Andreas Müller 4 months ago

  • Private changed from Yes to No

#10 Updated by Andreas Müller 4 months ago

#11 Updated by Andreas Müller 4 months ago

  • Status changed from New to Resolved
  • Priority changed from New to Highest
  • % Done changed from 0 to 50

#12 Updated by Andreas Müller 4 months ago

AM:

Was ich dafür noch bräuchte wären passende Labels für beide Richtungen. Da diese Beziehung als solches nicht vom Code beschrieben wird und da sie auch von Leuten verstanden werden sollte, die damit vielleicht nicht so viel anfangen können, ist das nicht ganz trivial. Hier mal ein paar erste Ideen:

  • is ‘non‘ for – „has ‘non‘
  • is unspecified non for – has unspecified non
  • non … - … non

Hast du noch weitere bzw. was würdest du vorschlagen?

===

WGB:

ich würde in beiden Richtungen in der Ausgabe nur das „non“ setzen, da die Fälle sehr verschieden sein können. Im Eingabedialog müssen wir ein bisschen überlegen, was wir wollen. Wenn wir die spezifizierbaren Fälle ausschließen wollen, dann wäre ich für „has no nomenclatural relation with“. Allerdings würde das die vorläufige Eingabe von non-relationen, die (noch) nicht geklärt sind, ausschließen. Daher vielleicht besser „‘non‘ (has no relation with)“.

Im Prinzip existiert hier keine reziproke Relation, da von Seiten des 2. Namens u.U. keinerlei Verwechslungsrisiko besteht, man die Relation also von diesem aus nicht als gegeben betrachten würde.

===

AM:

ja, es ging mir erstmal nur um die „Eingabe“. Bei der Ausgabe (Publikation) ist ja eigentlich klar, dass „non“ angezeigt werden soll, ähnlich wie bei z.B. Homonymen.
Ein Label für die reziproke Relation brauchen wir auf jeden Fall, da es immer wieder den Fall gibt, dass man die Eingabe auch von der anderen Seite her machen will. Es geht also auch hier um die Eingabemöglichkeit. Da denkt man ggf. falsch. Wenn die Relation nicht symmetrisch ist, dann braucht man aus prakmatischen Gründen ein inverses Label. Und Namensbeziehungen sind eigentlich alle nicht symmetrisch.
Das ist ein bisschen schwierig mit „‘non‘ (has no relation with)“, welches mir ansonsten gut gefällt. Aber da ist die Richtung nicht so richtig intuitiv klar.

===

WGB:

ok, ich sehe hier die Eingabe von der anderen Seite her nicht, und das kompliziert die Sache (und das Verständnis der Sache) natürlich ziemlich.
Für die “richtige” Richtung: Name A - ‘non’ (has no relation with) – Name B.
Für die (nicht auszugebende) Richtung: Name A – has a unilateral ‚non‘ relation from – Name B.

#13 Updated by Andreas Müller 4 months ago

Before closing this ticket we need to check dataportal and cdmlight to include this relationship in the set of "non"-relationships.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)