EDIT

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.

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.

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

Update script is written and checked on integration.

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

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).

Should be fixed. Open issues moved to related tickets.