Project

General

Profile

Actions

feature request #2506

open

(Type-) Specimens may need status

Added by Andreas Müller over 10 years ago. Updated 2 months ago.

Status:
In Progress
Priority:
Highest
Category:
cdm
Target version:
Start date:
07/25/2011
Due date:
% Done:

0%

Estimated time:
Severity:
normal

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

Related to Edit - feature request #461: Improve / compact display of typesNewAndreas Kohlbecker12/15/2008

Actions
Related to Edit - feature request #9596: Open issues for TypeDesignationWorkingSetNewAndreas Müller04/30/2021

Actions
Related to Edit - feature request #6865: [DISCUSS] Separator for Code and Accession NumberResolvedAndreas Müller08/01/2017

Actions
Has duplicate Edit - feature request #1580: Doubtful flag or presence attribute for specimen in collectionDuplicateAndreas Müller09/15/2010

Actions
Actions #1

Updated by Andreas Müller over 8 years ago

  • Priority changed from Highest to Priority13
Actions #2

Updated by Andreas Müller about 7 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

Actions #3

Updated by Andreas Müller almost 6 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.

Actions #4

Updated by Andreas Müller almost 6 years ago

  • Keywords set to mexico_ws,
Actions #5

Updated by Andreas Müller almost 6 years ago

  • Keywords changed from mexico_ws, to mexico_ws, eFlora,
Actions #6

Updated by Andreas Müller over 5 years ago

  • Target version changed from CDM UML 4.0 to CDM UML 4.1
Actions #7

Updated by Andreas Müller over 5 years ago

  • Priority changed from Priority13 to Priority11
Actions #8

Updated by Andreas Müller about 5 years ago

  • Target version changed from CDM UML 4.1 to CDM UML 4.7
Actions #9

Updated by Andreas Müller over 4 years ago

  • Target version changed from CDM UML 4.7 to CDM UML 5.0
Actions #10

Updated by Andreas Müller over 3 years ago

  • Description updated (diff)
  • Target version changed from CDM UML 5.0 to CDM UML 5.5
Actions #11

Updated by Andreas Müller about 3 years ago

  • Priority changed from Priority11 to Priority10
Actions #12

Updated by Andreas Müller almost 3 years ago

  • Target version changed from CDM UML 5.5 to CDM UML 5.15
Actions #13

Updated by Andreas Müller over 1 year ago

  • Target version changed from CDM UML 5.15 to CDM UML 5.29
Actions #14

Updated by Andreas Müller 2 months ago

  • Description updated (diff)
Actions #15

Updated by Andreas Müller 2 months ago

  • Private changed from Yes to No
Actions #16

Updated by Andreas Müller 2 months ago

Actions #17

Updated by Andreas Müller 2 months ago

Actions #18

Updated by Andreas Müller 2 months ago

  • Description updated (diff)
Actions #19

Updated by Andreas Müller 2 months ago

  • Related to deleted (feature request #1580: Doubtful flag or presence attribute for specimen in collection)
Actions #20

Updated by Andreas Müller 2 months ago

  • Has duplicate feature request #1580: Doubtful flag or presence attribute for specimen in collection added
Actions #21

Updated by Andreas Müller 2 months ago

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.

Actions #22

Updated by Andreas Müller 2 months ago

  • Priority changed from Priority10 to Highest
Actions #23

Updated by Andreas Müller 2 months ago

  • Subject changed from (Type) Specimen may need markers to (Type-) Specimens may need markers
Actions #24

Updated by Andreas Müller 2 months ago

  • Subject changed from (Type-) Specimens may need markers to (Type-) Specimens may need status
Actions #25

Updated by Andreas Müller 2 months ago

  • Status changed from New to In Progress
  • Target version changed from CDM UML 5.29 to Release 5.29
Actions #26

Updated by Andreas Müller about 1 month ago

Actions #27

Updated by Andreas Müller about 1 month ago

Actions

Also available in: Atom PDF