EDIT

AM:

upps, das ist mir vollständig neu, dass für Namen über den Bulkeditor auch (Name-)facts editiert werden können.
Das sollten wir unbedingt ausstellen, da die Namefacts ja sobald wie möglich abgeschafft werden sollen.
Eigentlich sollten sie im Moment NUR noch für die Protologe im Details View verwendet werden, bis auch diese umgestellt sind.
Bekommen wir das noch ins Release? Sollte vermutlich ja schnell zu implementieren sein.

WGB:

schade, hatte gerade gedacht, dass es die noch gibt - wo soll man denn z. B. den ethymologischen Hintergrund zu einem Namen unterbringen?

AM: ==> all moved to #8133

hmm, interessant. Grundsätzlich ist die angedachte Alternative, die Extensions zu verwenden (Supplemental Data). Also einen entsprechenden ExtensionType anlegen und dazu einen Informationsstring hinzufügen. Somit können fehlende Attribute einer Klasse quasi dynamisch erzeugt werden. Das könnte man dann auch im UI noch besser unterstützen (hinzufügen der Extensions zum Details View, etc.).

Aber: was dann nicht möglich ist, ist die Information mit einer Quelle zu hinterlegen. Die Frage ist also, ob diese Möglichkeit gebraucht wird. Da in den letzten 10 Jahren die Nachfrage danach quasi gleich 0 war, haben wir beschlossen das Model in diesem Bereich zu vereinfachen, um die Verwendung zu erleichtern.
Sollten sich aber doch sinnvolle Anwendungen ergeben, können wir darüber natürlich nochmal nachdenken.
Das ist allerdings ein Problem, welches für alle Attribute einer Klasse stellt. Solange sie als Einzelattribute dastehen, können sie nicht separat referenziert werden. Z.B. kann individualCount für Occurrences, welches v.a. in der Zoologie wichtig ist, nicht explizit referenziert werden, sondern nur das Specimen als ganzes.

Grundsätzlich haben wir also mind. 3 Möglichkeiten semantisch reiche Daten an ein Objekt zu hängen: als Attribut in der Klasse (entsprechend Spalte in einer Tabelle), als Extension mit ExtensionType und Textstring (nicht referenzierbar und keine Multi-Language-Unterstützung), Descriptions(DescriptionElements/Facts). Letztere sind sehr flexibel, aber auch kompliziert, mit der Möglichkeit zu gruppieren, scopes (geo, time, …) anzulegen, Modifier hinzuzufügen, verschiedene Datentypen zu verwenden, Quellen hinzuzufügen, Mehrsprachigkeit, etc.

In letztere Zeit bin ich davon ausgegangen, dass letztere letztlich nur für Taxa und Specimen relevant sind. Vielleicht irre ich da aber auch.
Vielleicht wäre es besser zu versuchen, dass Extension System und die Descriptions zu vereinheitlichen. Z.B. würde es vermutlich Sinn machen, wenn es nicht Features und ExtensionTypes gäbe und diese inkompatibel zu einander sind, sondern dass das quasi eine Klasse ist, und man lediglich mitspeichert, für welche Datentypen ein Feature/ExtensionType anwendbar ist, also ob für Specimen, Taxa, Namen, Personen, Teams, Referencen, …
Dann könnte man versuchen, ein abgespecktes Description System und ein Advanced System zu entwickeln, wobei wenn möglich das eine in das andere überführbar sein sollte. Das abgespeckte System könnte dann z.B. neben dem Typ noch Quellen und Mehrsprachigkeit ermöglichen, aber keine sopes, modifier etc.
Das würde alles ein bisschen konsistenter machen.

Das ist natürlich nur mittel- bis langfristige Planung. Das Löschen der NameFacts stünde allerdings schon relativ bald an, daher würde mich natürlich die Meinung, ob die wirklich durch Extensions ersetzt werden können sehr interessieren.
Ich nehme auch mal Norbert in cc. Vielleicht wäre das ja auch mal ein Thema für ein Usermeeting.

WGB:

ich sehe da eine Reihe von Anwendungen für Namens-bezogene Fakten:

• Etymologie – ist ganz allgemein wie ein Text-Faktum strukturiert, also auch Mehrsprachigkeit und natürlich mit Quelle => #8019

• Die bereits angesprochene Typusdiskussion: Beim Nepenthes bearbeiten fällt mir hierzu auf, dass man folgende Arten gebrauchen könnte (auch gleich der Ausgabe-Usecase dazu): Das Originalzitat (mit Referenzierung, denn das kann auch aus einer anderen Quelle entnommen worden sein) – das würde ich in Anführungszeichen setzen. Kommentare dazu (z.B. Typensuche etc.) anschließend in chronologischer Reihenfolge. Alles Textfelder mit Sprache und Referenz (und ggf. in-line Referenzen). Noch dazu wünschen würde ich mir ein individuelles Publish-Flag – so wurde z.B. kürzlich endlich die Neotypisierung von N. alata blanco vorgenommen, sodass die vorangehende Diskussion zur Suche etc. eigentlich durch die Angaben im letzten Artikel ersetzt werden. Das sollte dann ausgeklammert werden, aber die Geschichte erhalten bleiben.

• Anmerkungen zur Orthographie des Namens (da gibt’s manchmal wilde Diskussionen – man braucht hier oft „pers. comm.“ Referenzen). => #8019

Das nur mal für’s erste, um die Diskussion anzustoßen.

AM:

ok, habe ich ins Ticket eingetragen. Die Typussachen würde ich ja lieber in einem verbesserten Typusmodul behandeln(=> #8133 (Note: maybe #8318 was meant here)). Hoffentlich können wir das nach der E+M Migration angehen. Die beiden anderen Punkte sind aber auf jeden Fall wichtig und gut für die Diskussion.
Wie wichtig ist die Eingabe dieser Daten? Sollen wir die Namefacts evtl. doch lieber wieder einschalten?

WGB:

richtig wichtig erscheint mir vor allem die Sache mit den Typen. Aber für alle Fälle gilt, dass man das vorläufig in Taxon Facts unterbringen kann – derzeit stelle ich da dann dem Text einen entsprechenden Vermerk voran.

Unification of extensions and facts moved to new ticket #8133