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.