feature request #2506
closed(Type-) Specimens may need status
Added by Andreas Müller over 12 years ago. Updated about 2 years ago.
100%
Description
For eFlora specimen need at least the following markers:
notSeen, unknown, notFound (same as not seen?), destroyed, lost.
Seen may be handled even more accurately depending on who has seen it in a multi-user database. However, for now it may be sufficient to use the marker as suggested.
see also the duplicate #1580
Files
picture503-1.png (60 KB) picture503-1.png | Andreas Müller, 11/18/2021 02:34 PM | ||
picture503-2.png (101 KB) picture503-2.png | Andreas Müller, 11/18/2021 02:34 PM |
Related issues
Updated by Andreas Müller almost 11 years ago
- Priority changed from Highest to Priority13
Updated by Andreas Müller over 9 years ago
- Target version changed from CDM UML 3.5 to CDM UML - Next major release
Move all unassigned modelling tickets to next major release
Updated by Andreas Müller about 8 years ago
- Target version deleted (
CDM UML - 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.
Updated by Andreas Müller about 8 years ago
- Keywords changed from mexico_ws, to mexico_ws, eFlora,
Updated by Andreas Müller almost 8 years ago
- Target version changed from CDM UML 4.0 to CDM UML 4.1
Updated by Andreas Müller almost 8 years ago
- Priority changed from Priority13 to Priority11
Updated by Andreas Müller over 7 years ago
- Target version changed from CDM UML 4.1 to CDM UML 4.7
Updated by Andreas Müller almost 7 years ago
- Target version changed from CDM UML 4.7 to CDM UML 5.0
Updated by Andreas Müller almost 6 years ago
- Description updated (diff)
- Target version changed from CDM UML 5.0 to CDM UML 5.5
Updated by Andreas Müller over 5 years ago
- Priority changed from Priority11 to Priority10
Updated by Andreas Müller about 5 years ago
- Target version changed from CDM UML 5.5 to CDM UML 5.15
Updated by Andreas Müller almost 4 years ago
- Target version changed from CDM UML 5.15 to CDM UML 5.43
Updated by Andreas Müller over 2 years ago
- Related to feature request #461: Improve / compact display of types added
Updated by Andreas Müller over 2 years ago
- Related to feature request #1580: Doubtful flag or presence attribute for specimen in collection added
Updated by Andreas Müller over 2 years ago
- Related to deleted (feature request #1580: Doubtful flag or presence attribute for specimen in collection)
Updated by Andreas Müller over 2 years ago
- Has duplicate feature request #1580: Doubtful flag or presence attribute for specimen in collection added
Updated by Andreas Müller over 2 years ago
- File picture503-1.png picture503-1.png added
- File picture503-2.png picture503-2.png added
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 .
- 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).
- 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.
- 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.
- 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.
Updated by Andreas Müller over 2 years ago
- Priority changed from Priority10 to Highest
Updated by Andreas Müller over 2 years ago
- Subject changed from (Type) Specimen may need markers to (Type-) Specimens may need markers
Updated by Andreas Müller over 2 years ago
- Subject changed from (Type-) Specimens may need markers to (Type-) Specimens may need status
Updated by Andreas Müller over 2 years ago
- Status changed from New to In Progress
- Target version changed from CDM UML 5.43 to Release 5.45
Updated by Andreas Müller over 2 years ago
- Related to feature request #9596: Open issues for TypeDesignationWorkingSet added
Updated by Andreas Müller over 2 years ago
- Related to feature request #6865: [DISCUSS] Separator for Code and Accession Number added
Updated by Andreas Müller about 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 50
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.
Updated by Andreas Müller about 2 years ago
- Target version changed from Release 5.45 to Release 5.29
Updated by Andreas Müller about 2 years ago
- Precedes feature request #9939: Implement specimen status in TaxEditor added
Updated by Andreas Müller about 2 years ago
- Related to task #9940: Handle type category formatting in compact typification strings added
Updated by Andreas Müller about 2 years ago
- Related to task #9941: [DISCUSS] Formatting of type designation categories in compact type string added
Updated by Andreas Müller about 2 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100
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.
Updated by Andreas Müller about 2 years ago
- Related to bug #9965: Newly created derived unit is not shown in selection dialog added
Updated by Andreas Müller about 2 years ago
- Related to feature request #10003: Implement specimen status in Data portal added
Updated by Andreas Müller over 1 year ago
- Related to bug #10182: Portal does not show typespecimen for duplicated typedesignation added