Project

General

Profile

Actions

feature request #10083

closed

Add name relationship type "avoids homonym of"/"causes replacement name"

Added by Andreas Müller almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Priority14
Category:
cdm
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal

Description

Currently we have a name relationship type "is blocking name for" with a label "is new combination blocked by" for the inverse relationship. This relation causes confusion as it is semantically not clear.

Generally we have 3 names to consider if a blocking name exists:

  1. replaced synonym
  2. blocking name (having the same epithet as the replaced synonym)
  3. replacement name (new combination for replaced synonym in the same group as the blocking name so having the same genus (for species) or specific epithet (for infraspecies), the last epithet is new as it is blocked by the blocking name

Note: there is also a fourth name the potentiall created illegal later homonym, this is related via the later homonym relationship to the blocking name and therefore not handled here

The relationship between 1->3 is handled by the "is replaced synonym for" relationship. The current "is blocking name" relationship should handle the relationship between 1->2 according to definitions in the nomenclatural code. However, the inverse label indicates that it is about the relatioship 2->3.

To better distinguish the 2 latter relationships we should add a new relationship type "avoids homonym of" <-> "causes replacement name" that represents relationship 2->3 and we need to adapt the inverse label of the current "is blocking name for" relationship to "has blocking name" (or "is blocked by").

Finally we need to adapt existing data to use the new 2->3 relationship instead of the 1->2 where it was originally meant to be used.

Also we need to adapt the output tools (dataportal, CDM light, ...) to support the new relationshiptype(s) correctly. Also check TaxEditor if the relationship is correctly supported.


Related issues

Related to EDIT - feature request #5655: [DISCUSS] Do we need further "non xxx" relations?ClosedAndreas Müller

Actions
Related to EDIT - bug #10102: Non-names formatted in italicsClosedKatja Luther

Actions
Related to EDIT - bug #10122: NameRelationship display should be more configurable in cdmLightNewKatja Luther

Actions
Actions #1

Updated by Andreas Müller almost 2 years ago

  • Status changed from New to Discussed
  • Priority changed from New to Highest
  • % Done changed from 0 to 10

ERS:

das Pendant zu „is blocking name for“ lautet „is new combination blocked by“. Es gibt aber auch den Fall, dass ein neuer Name (nomen novum) geblockt wird. Spricht etwas dagegen, diese Beziehung einfach „is blocked by“ oder „has blocking name“ zu nennen?

... ich habe eben noch einmal kurz mit Norbert über diese besondere Beziehung gesprochen. Wir stimmen darin überein, dass „is blocking name for“ bzw. „is blocked by“ die Eigenschaft der Beziehung nicht klar ausdrückt.

Denn: blockiert wird ja nicht der legitime Name, sondern ein potentielles illegitimes Homonym, das dann im besten Falle gar nicht erst gebildet wird und also nicht-existent ist. Wenn solch ein eigentlich blockierter Name dagegen schon existiert, gibt es dafür schon die Homonym-Beziehung. In diesen beiden Fällen ist eine Beziehung wie „is blocked by“ eigentlich irreführend.

Wir suchen daher nach einer geeigneteren Formulierung für die Beziehung zwischen einem Namen, der zur Vermeidung eines illegitimen Homonyms gebildet wurde, und dem älteren Namen, der dies notwendig macht.

„[nomen novum] avoids homonym of [blocking name]“

Und umgekehrt

“[blocking name] causes replacement name [nomen novum]”

Oder so ähnlich… Vorschläge willkommen!

WHK:

die Vorschläge von Eckhard finde ich klar, verständlich und mir ist keine bessere Formulierung eingefallen (nur schlechtere Formulierungen).

WGB:

mir fällt auch nichts eleganteres ein – Nick?

NT:

Norbert/Eckhards Vorschlag gefällt mir auch.

Actions #2

Updated by Andreas Müller almost 2 years ago

AM:

diese Mail ist letztes Jahr leider bei mir liegen geblieben. Aus aktuellem Anlass würde ich sie gerne wieder aufgreifen und habe ein Ticket dafür angelegt: #10083

Das Ticket plädiert dafür, für die 3 Namen

  1. replaced synonym
  2. blocking name
  3. replacement name

3 Relationstypen anzubieten:

I. is replaced synonym for/is new name for (1->3)
II. is blocking name for/has blocking name (1->2)
III. avoids homonym of/ causes replacement name (2->3)

Die bisherige Kombination „is blocking name“/“is new combination blocked by” würde dann wegfallen, da sie in der inversen Richtung einen anderen Relationstyp (nämlich III.) darstellt, als in der direkten Richtung (II.).

Existierende Daten müssten im Anschluss dann noch korrekt angepasst werden.

Relationstyp II und III scheinen beide gebraucht zu werden, da einige Projekte in der Ausgabe lieber die 3. Beziehung ausgeben, andere lieber die 2. Beziehung, wobei sich mit etwas taxonomischem Wissen die beiden Beziehungen natürlich ineinander überführen lassen (was theoretisch erlauben würde, die Beziehung III wegzulassen, dies würde aber vieles komplexer machen und ist daher weniger wünschenswert).
Je nach Projekt kann stattdessen der nicht gewünschte Relationstyp über die Preferences ausgeblendet werden.

Ich hoffe, dies entspricht der Intention dieses älteren Email-Threads. Falls ihr noch Änderungsvorschläge habt, lasst es mich bitte möglichst bis Mittwoch Abend (29.6.) wissen, ansonsten würde ich dann mit der Implementierung beginnen.

Actions #3

Updated by Andreas Müller almost 2 years ago

  • Target version changed from CDM UML 5.45 to Release 5.32

Separate discussion WGB-AM:

...

AM

ja, das war semantisch nie einfach, was bei blocking name was ist bzw. bedeuten soll. Für Cuba mussten wir da ein aufwendiges Script schreiben, um die Daten nochmal umzuhängen, da sie zuerst falsch interpretiert wurden: https://dev.e-taxonomy.eu/redmine/issues/6024 ). Es ist da leider auch noch etwas offen, siehe die Mails im Anhang, die noch nicht abgearbeitet sind, zumindest die von Nick als letztem Threadautor.

Das Problem ist ja, dass es mind. 2 blocking Beziehungen gibt, die zwischen Blocking Name und Replaced Synonym und die zwischen Bl.name und Replacement name (s. https://dev.e-taxonomy.eu/redmine/issues/5655). Die einen wollen v.a. letztere Anzeigen (s. Mail Eckhard) die anderen wie du jetzt wohl die erstere.
Und dann gibt es noch die allgemeinen „non“ Beziehungen und die Tatsache, dass die Blocking Names sich ja wenn man so will auf die ganze homotypische Gruppe beziehen.
Wir müssten also die existierende Beziehung splitten, wenn ich es richtig verstehe, gute Labels finden (für die 2. Beziehungen haben Eckhard und Norbert ja schon was vorgeschlagen) und dann pro Datenbank/Datensatz anschauen, was jeweils gemeint war.

WGB:

ich habe mir die Mail von Eckhard angesehen, er sagt ja eigentlich genau das gleiche wie ich – die logische Beziehung besteht zwischen dem replaced synonym und dem blocking name.
Die Beziehung zwischen dem nomen novum und dem replaced synonym wird ja getrennt hergestellt.
Der Unterschied liegt darin, wo der blocking Name ausgegeben wird, Greuter (der ja vielfach aus Platzgründen Sachen einfach verkürzt darstellt) und er wollen den den blocking name direkt zum nomen novum stellen, das wäre dann durch die „is new combination blocked by“ Sache (die man aber auch aus den beiden obigen Beziehungen ausgabeseitig herstellen könnte).
Norberts und Nicks Vorschläge machen ja nur expliziter, was durch den (im Code definierten) Begriff (replaced synonym) schon ausgedrückt wird. Ich würde diese Beziehungen dann für „meine“ Datenbanken ausblenden, falsch sind sie ja nicht.

Was ich aber brauche ist die direkte gerichtete Beziehung zwischen den Namen (nicht unbedingt den homotypischen Gruppen, da dort ja auch noch andere Epitheta vorkommen können), also „has blocking name“ oder „is blocked by“ und von mir aus auch (das dann immer auch automatisch zu setzende) „is blocking name for“.

AM:

ich bin mir jetzt nicht ganz sicher, ob ich deine Mail richtig interpretiere, aber so wie ich sie interpretiere, widerspricht sie nicht meiner Mail, oder?

Also mein Vorschlag „die existierenden Beziehungen zu splitten“ meint ja im Prinzip, dass wir für jede der 3 möglichen Namensbeziehungen zwischen den 3 Namen (replaced synonym, blocking name, replacement name) auch explizit eine Beziehung im Model haben sollten. Also

• is replaced synonym for <-> is replacement name for
• is blocked by <-> is blocking name for
• avoids homonym of <-> causes replacement name

Die bisherige Beziehung „is blocking name for“ <-> „is new combination blocked by” ist natürlich insofern Quatsch, als dass sie das direct label der 2. Beziehung und das inverse label der dritten Beziehung kombiniert, was offensichtlich semantisch nicht korrekt ist. Woher diese Kombination kommt ist mir übrigens unklar. Im CDM war sie wohl von Anfang an drin, ob das irgendwo abgeschrieben wurde, konnte ich aber nicht rausfinden.

Du deutest in deiner Mail unten an, dass die 3. Beziehung aus den beiden ersteren hergeleitet werden und damit evtl. auch weggelassen werden könnte, auch wenn die dritte und nicht die zweite Beziehung bei der Ausgabe angezeigt werden soll. Grundsätzlich stimmt das natürlich, aber die Lösung finde ich aus mehreren Gründen nicht gut:

• es setzt Vollständigkeit der Daten voraus, die längst nicht immer gegeben ist (Importe, Umgehung der aufwendigen Dateneingabe, dirty data im Allgemeinen, …)
• es verkompliziert die Formatierungsregeln und verringert die Performance bei der Formatierung
• es ist für den User weniger verständlich und setzt explizites Wissen voraus in einem Bereich, der auch für viele Taxonomen nicht auf den ersten Blick so eindeutig ist

Daher würde ich jetzt den dritten Relationstyp zusätzlich einführen und das inverse Label des zweiten Relationstyps umbenennen. Im Anschluss müssen wir noch Altdaten korrekt anpassen, z.B. in E+M. Das haben wir bei Cuba ja schon mal gemacht und es sollte halbautomatisiert möglich sein, da ja aus den Epitheten der Namen eigentlich immer ersichtlich sein sollte, ob der zweite oder der dritte Relationstyp gemeint ist.

WGB:

klingt gut! Da man die in einem Projekt verfügbaren Name Relationships ja konfigurieren kann, macht es ja nichts, wenn da ein paar mehr sind.

Actions #4

Updated by Andreas Müller almost 2 years ago

  • Status changed from Discussed to Resolved
  • % Done changed from 10 to 70

The relationship was added. We still need an update script or handling for the inverse label and for existing data.

Actions #5

Updated by Andreas Müller almost 2 years ago

SELECT r.id relId, n1.titleCache n1, t.titleCache rel, n2.titleCache n2, n1.nameCache n1short, n2.nameCache n2short
FROM NameRelationship r INNER JOIN TaxonName n1 ON n1.id = r.relatedfrom_id INNER JOIN TaxonName n2 ON n2.id = r.relatedto_id
     INNER JOIN DefinedTermBase t ON t.id = r.type_id
WHERE t.uuid = '1dab357f-2e12-4511-97a4-e5153589e6a6';
  • Caryo_amaranth: 1
  • Caryo_spp: 1
  • Cichorieae: 6
  • euromed: 167
  • euromed_caucasus: 1
  • cuba: 214
  • greece: 7
Actions #6

Updated by Andreas Müller almost 2 years ago

  • % Done changed from 70 to 90

Update script is written and checked on integration.

Dataportal and cdmlight(?) still need to be updated.
Relationships need to be updated manually after release.

Actions #7

Updated by Andreas Müller almost 2 years ago

Actions #9

Updated by Andreas Müller almost 2 years ago

  • Priority changed from Highest to Priority14
Actions #10

Updated by Andreas Müller almost 2 years ago

  • Related to bug #10102: Non-names formatted in italics added
Actions #11

Updated by Andreas Müller almost 2 years ago

Before fully closing also check #5655

Actions #12

Updated by Andreas Müller almost 2 years ago

  • Assignee changed from Andreas Müller to Katja Luther

Mail sent to datamanager to adapt their data (list of effected DBs see #note-5).

Katja, could you please check if it works correctly in cdmlight and dataportal (and if it is correctly implemented)? And then close the ticket?

Please also check #5655 (non-specific "non"-relationship) for correct implementation in cdmlight and dataportal as it was not implemented before (at least not for the dataportal).

Actions #13

Updated by Katja Luther almost 2 years ago

Andreas Müller wrote in #note-12:

Mail sent to datamanager to adapt their data (list of effected DBs see #note-5).

Katja, could you please check if it works correctly in cdmlight and dataportal (and if it is correctly implemented)? And then close the ticket?

The dataportal implementation is correct!

Please also check #5655 (non-specific "non"-relationship) for correct implementation in cdmlight and dataportal as it was not implemented before (at least not for the dataportal).

Actions #14

Updated by Katja Luther almost 2 years ago

Actually there was a bug in cdmLight, this is fixed. Now the namerelationships are exported to the NameRelationship.csv and in HomotypicGroup.csv, here it depends on the configuration whether the label is shown for both directions (config: ShowInverseNameRelationsInHomotypicGroup).

Maybe we should discuss to split this configuration for the different Namerelationship Types.

-> create new ticket for configurable namerelationships (#10122)

Actions #15

Updated by Katja Luther almost 2 years ago

  • Related to bug #10122: NameRelationship display should be more configurable in cdmLight added
Actions #16

Updated by Andreas Müller almost 2 years ago

  • Status changed from Resolved to Closed
  • Assignee changed from Katja Luther to Andreas Müller
  • % Done changed from 90 to 100

Should be fixed. Open issues moved to related tickets.

Actions

Also available in: Atom PDF