EDIT

Move all unassigned modelling tickets to next major release

Hallo,

gibt es eine Möglichkeit, einem Specimen eine Notiz hinzuzufügen.

Konkreter Fall:

Holotype: Peru, Puno, near Sandía, 31. July 1902, Weberbauer 1353 (B, destroyed), isotype: US.

Wo bringe ich das “destroyed” unter?

Im Fall von Berlin betrifft das Tausende von Typusexemplaren, es wäre als ggf. sogar ein spezieller Fall möglich. Besser aber ein Textfeld, dass man nach der Herbarangabe (die ja den spezifischen physischen Beleg abgrenzt) in der Ausgabe einfügen kann.

Herzlichen Gruß

Walter

===

Hallo Walter,

ja und nein. Natürlich ist es wie für alle Identifiable Entities möglich Annotationen, Marker, Extensions etc. an die Specimen zu hängen, so dass die Daten gespeichert werden können. Evtl. könnte man im gegebenen Fall auch die PreservationMethod für die Eingabe missbrauchen, aber das ist unschön.

Ein explizites Feld für die „Status“-Angaben, ob Freitext oder aus einem kontrollierten Vokabular, gibt es noch nicht, obwohl ich es seit längerem auch schon brauche insbesondere für die eFlora Daten, wo solche Angaben ja regelmäßig vorkommen. Ich habe mir da nur noch nicht abschließend Gedanken drum gemacht, wie das Modellseitig am besten aussehen könnte. Es gibt ja Angaben, die wirklich Specimen immanent sind, wie destroyed, und die sich höchstens über die Zeit ändern können.

Und dann gibt es Angaben, die projektspezifisch sind, wie „not seen by the author“. Diese sollten bei der Migration von Daten in ein anderes Projekt nicht unbedingt übernommen werden. Zudem stellt sich die Frage nach festem Vokabular oder Freitext oder beidem. Grundstätzlich denke ich schon, dass es sich um ein relativ festes Vokabular handelt, welches immer wieder auftaucht und für welches auch gerne Symbole (z.B. Kreuz für destroyed) verwendet werden, so dass ein Freitext hier nicht so optimal ist.

Es gibt dazu auch schon ein relativ altes Ticket: http://dev.e-taxonomy.eu/trac/ticket/2506. Vielleicht können wir nach deiner Rückkehr ja mal kurz darüber sprechen, wie wir damit am besten umgehen und welche Lösungen es vielleicht auch in anderen Systemen dafür bereits gibt.

Viele Grüße,

Andreas M.

NaK:

Bei den Kakteen-Typus-Angaben stoße ich immer wieder auf „not preserved“ und „not found at..“, und um diese Information mitzunehmen muss ich die Typus-Angabe als Text eingeben, nicht als Specimen.

Wäre es denkbar, „not preserved“ und „not found“ als Flags für Typ-Specimens zu implementieren?

AM:

Bislang haben wir aber noch nicht entschieden, wie es implementiert werden soll. Vielleicht wäre dies mal der Zeitpunkt, eine Entscheidung zu treffen.
Dabei gibt es ein paar Probleme zu lösen, die bereits im Kommentar des Tickets .

1. Subjektive vs. objektive Status, also z.B. destroyed (objektiver Status) vs. “not seen by the author” (subjektiver Status). Siehe hierzu auch meine Antwort an Walter im Ticket (Kommentar 3).
2. Freitext vs. Vokabular: ich tendiere sehr zu einem festen (aber vom User erweiterbaren) Vokabular, es würde mich aber interessieren, ob da was dagegen spricht.
3. Anzahl: kann es sein, dass mehrere solcher Status für das gleiche Specimen vorkommen können? Dabei sollte man vielleicht auch eine erweiterete Status-Liste denken, in der auch Dinge wie fossil etc. vorkommen.
4. Möglichst vollständige Liste: welche Status brauchen wir auf jeden Fall und sollten in das Vokabular mit aufgenommen werden?

Hierzu würde mich die Meinung aller Nutzer sehr interessieren!

Als schwierigstes Problem sehe ich dabei Punkt 1. Grundsätzlich zu klären ist hier, ob der Status einzig mit dem Beleg gespeichert werden soll, also z.B. hier irgendwo:

oder ob es sich um eine Information handelt, die nur im Kontext der gegebenen Taxonomie/Publikation relevant ist und somit auch ein Attribut der Beziehung zwischen Taxon(-knoten) und Specimen, genannt Individuals Association, sein könnte. Und dann z.B. hier eingetragen wird:

Oder, ob es beides gibt.
Ersteres nenne ich derzeit „objektiv“ und letzteres „subjektiv“.

In letztere Kategorie würde ich z.B. eher „not seen by …“ oder „not found at .. “ und vielleicht auch „unknown“ stecken, während „destroyed“ oder „lost“ eher in die erste Kategorie gehört.

Grundsätzlich lässt sich natürlich auch alles direkt an den Beleg hängen. In den absolut meisten Fällen, die wir bislang behandeln würde das sicherlich ausreichen. Wenn man Belege aus der Datenbank aber evtl. doch auch mal in Zukunft in einem anderen Kontext verwenden will, dann könnte das dazu führen, dass die Information „not seen“ nicht in jedem Kontext stimmt.

Am korrektesten wäre somit vermutlich, beide Möglichkeiten zu haben und somit auch 2 Vokabulare zu implementieren. Andererseits würde das die Dinge eben auch komplizierter machen (vielleicht unnötig kompliziert), sowohl aus technischer Sicht als auch aus Nutzer Sicht.

WHK:

wichtig ist Andreas Kommentar, dass „not seen“ aber auch „destroyed“ kontextabhängig ist. Meines Erachtens wäre es am saubersten, die Information zu referenzieren. So hätte jeder Status eine Referenz, mehrere Status könnten mehrere oder dieselbe Referenz haben. Das könnte dann einfach addiert werden. Bei einer Referenzierung könnte die Information am Beleg hängen.
Und wenn ich Nadja richtig verstanden habe, hat diese Information immer eine Referenz (die auch die Source sein kann, oder eigene Recherche).

Im Übrigen muss ein publizierter Status nicht stimmen, eine 1988er Publikation z.B. gibt den Status eines Belegs als destroyed an, wir haben ihn inzwischen gefunden und gesehen.

WGB:

not seen and not found are different statements.
And I’d add “image seen” (=”! image”).
And I think all these statements need a source – this may be a bibliographic reference (where the statements were used) or a person editing the treatment (which may change over time).

WGB:

hatte schon das Ticket kurz kommentiert – ja, wenn jede dieser Statusangaben referenziert ist, dann kann man sie beim Beleg lassen – das dürfte die Sache doch vereinfachen?

NaK:

ich schließe mich Henning und Walter an. Ich denke auch, dass man die Status-Angaben beim Beleg lassen kann, aber jeder Status sollte referenziert werden können, denn die Information bezieht sich tatsächlich auf den Beleg, stammt aber aus einer Publikation, und der Status kann sich zwischen Publikationen unterscheiden, wie Henning schon schrieb. „Not seen by“ ist vielleicht der einzige Status, der auch eine individuals association sein könnte.
Freitext vs. Vokabular: Ich wäre für ein festes, aber vom User erweiterbares Vokabular
Anzahl: ja, es können mehrere Status-Angaben für einen Beleg vorkommen

Vokabular: bisher kenne ich aus Publikationen:

• destroyed
• lost
• dried out (für Alkohol-Belege)
• not found at…,
• not seen by….
• not preserved
• not extant

Oft findet man aber etwas abweichende Formulierungen, also z.B. „not extant?“ oder „presumably not preserved“, deswegen fände ich es wichtig, das Vokabular erweitern zu können, um den Status so anzugeben, wie ihn die Quelle angibt, sonst wird das schnell zu einer Interpretation.

NoK:

ich sehe das wie Nadja, Henning und Walter: referenzierte Statusangabe beim Beleg + festes erweiterbares Vokabular.

AM:

vielen Dank für eure Rückmeldungen. Dann würde ich das genauso implementieren wie die nomenklatorsichen Status für Namen: mehrere Status möglich (wenn auch selten), jeder Status mit einer Quelle versehbar, eigenes erweiterbares Vokabular (wobei das nom. Status Vokabular bislang nicht erweiterbar ist).

Eine Frage noch: „not found at…“ – das ist etwas schwierig, da es sich ja um quasi festes Vokabular handelt. Reicht hier „not found“ und gleichzeitig hat man ja die Collection des Specimen? Soll das dann explizit als „not found at …“ formatiert werden oder reicht wie bei den anderen sowas wie „B, destroyed“ also dann „B, not found“?

NoK:

ja, "not found" reicht m.E.

NaK:

ich würde sagen „B, not found“ ist ok, ein zusätzliches „not found at“ brauchen wir nicht.

WGB:

stimme zu.

The model part of this ticket is implemented. We may need to split the ticket for the remaining formatting issues and for implementing editing in taxeditor.

Follow up tickets: #9939, #9940 and #9941. The issue is also handled in #461 again with

AM:

Und jetzt noch Thema 3: Separator für Beleg Status (z.B. „destroyed“)

Diese Thema wurde eigentlich schon in https://dev.e-taxonomy.eu/redmine/issues/2506#note-21 ausreichend behandelt und wir haben uns für eine Kommaseparierung entschieden. Ich bin nur im Zuge der Recherche auf https://dev.e-taxonomy.eu/redmine/issues/461 gestoßen, wo damals vor langer Zeit mehrheitlich eine geschachtelte Klammer vorgeschlagen wurde

Type: Borneo, Sabah, Sandakan Ramos 1490 (Holotype: B (presumed destroyed); isotypes: L, PNH).

und wollte daher fragen, ob es an der Klammervariante noch Interesse gibt, ansonsten würde ich das in #461 so vermerken.

Therefore I close this ticket.