task #6044
closedcdm model changes/entensions for algea registry
100%
Description
The algea registry requires to store additional data in the CDM.
We are planing to extend the CDM classes TaxonNameBase
and TypeDesignationBase
by a field for a collection of multiple registration records. Having them in a separate table has been considered as an option but is not feasible for all situations, since multiple reegitrations may exist for a name or typification.
1. Reference publication date¶
Bei den Algen streben wir an, dass bei späterer automatischer Registrierung Publikations- und Registrierungsdatum identisch ist. Allerdings werden wir immer bei Printmedien die Diskrepanz zwischen Publikationsdatum und Registrierungsdatum haben. Ich denke bei dem Publikationsdatum müssen wir entscheiden, wie viel Information wir brauchen. Wir brauchen ein echtes Datumsfeld. Für Fälle, in denen das exakte Datum nicht klar ist, könnte man das eine Datum mit einem Qualifier versehen (exact, before, after) oder gleich 2 Daten angeben (Start oder exakt + Enddatum). Zusätzlich benötigen wir ein Textfeld, das das Datum erklärt, z.B. wenn publiziertes Datum und Publikationsdatum abweichen, oder man sich auf nicht verifizierte Quellen bezieht (z.B. der Verlag sagt, die Publikation wurde im Dezember so abgeschickt, dass sie in den Bibliotheken noch im selben Monat angekommen sein muss).
Hier ist ein schönes Beispiel für Daten. Wir würden für die Publikation das korrigierte Jahr angeben. In das Textfeld käme der Hinweis auf das gedruckte Publikationsdatum und die Quelle der Korrektur. Ich nehme an, das Publikationsdatum ist aus einem späteren Volume entnommen oder es wurde beim Verlag nachgefragt.
http://archive.bgbm.org/scripts/ASP/registration/regDetail.asp?Key=8760
This is already covered by the cdm as Reference.datePublished
2. Registration data¶
TaxonNameBase [1]-------- \ ----[m] Registration / TypeDesignationBase [n]--
As new CDM Class Registration
Registration of
- Name ->
TaxonNameBase.registration
- Typisierung ->
TypeDesignation.registration
2.1 Registration date¶
Registrierungsdatum einer Typisierung oder eines Namens zum oder nach dem Zeitpunkt der Publikation, also auch gleichzeitig das Datum der Freischaltung / Publikation des Records.
Registration.registrationDate
asorg.joda.time.DateTime
2.1 Registration Identifier¶
Registration.identifier
asString
2.3 Registration center or office¶
We expect that multiple registration centers could exists in parallel. In this case it would make sense to store a reference to the registration center with the registration record.
Registration.institution
asInstitution
Workflow status¶
During the workflow from the initial registration of a name to the final publication, a name record will undergo several state changes. For states the CDM Markers
can be used.
Registration.status
asenum
(maybeDefinedTerm
?)
For suggestion for states see #6168
Locking of Names and registration records¶
Once a name is published, further modification of the name must be prohibited, see also (#6017)
This could be achieved by withdrawing the permission to edit the name from the Author and from the Curator.
This step would be triggered by a state change to published
.
Related issues
Updated by Andreas Müller over 6 years ago
Das verstehe ich nicht ganz.
Fragen: 1) Bei dem Ticket geht es um ein Datumsfeld für Referenzen, nicht TaxonNamen? Sind aber die Registrierungen nicht eher namensabhängig? D.h. in der gleichen Publikation können mehrere Namen stehen, die im ungünstigen Fall an unterschiedlichen Tagen registriert wurden?
2) Wenn das Feld für Referenzen eingeführt werden soll, gibt es dieses eigentlich bereits in Form von "datePublished" welches vom Typ TimePeriod ist. TimePeriod hat sowohl ein Anfangs- als auch Enddatum. Zudem erlaubt es per Freitext zusätzliche Informationen auszugeben, die insbesondere auch für Abweichungen des offiziellen Publikationsdatum mit dem realen Publikationsdatum verwendbar sind. Im strukturierten Teil sollte dann jedoch immer das Datum stehen, welches auch z.B. für Berechnungen wie Sortierungen relevant ist.
Updated by Wolf-Henning Kusber over 6 years ago
Das Ticket umfasst zwei unterschiedliche Daten. Das Publikationsdatum (1) scheint nach Andreas M. ausreichend durch das CDM abgebildet zu sein, es geht dabei um die Publikation oder die ganze Referenz.
Neu ist tatsächlich das Registrierungsdatum (2) einer Typisierung oder eines Namens. Dieses Datum ist an einen Namen oder nomenklatorischen Akt geknüpft und prinzipiell unabhängig vom Publikationsdatum. Dabei sind die ersten Frage, wie es in die Architektur passt und wo das ins Modell passt.
Updated by Andreas Kohlbecker over 6 years ago
Wolf-Henning Kusber wrote:
Das Ticket umfasst zwei unterschiedliche Daten. Das Publikationsdatum (1) scheint nach Andreas M. ausreichend durch das CDM abgebildet zu sein, es geht dabei um die Publikation oder die ganze Referenz.
Das ist vollkommen richtig, ich hatte dieses Ticket angelegt ohne diesen Sachverhalt ausreichend zu dokumentieren. Mir war zunächst nur wichtig die essentiellen Informationen die in den über 1000 Emails die sich in meiner Inbox nach dem Urlaub befanden strukturiert festzuhalten.
Für Registration date brauchen wir definitiv eine Erweiterung oder Ergänzung des CDM.
Updated by Andreas Kohlbecker over 6 years ago
- Target version set to Technical planning completed
Updated by Andreas Kohlbecker over 6 years ago
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to Andreas Kohlbecker
Updated by Andreas Kohlbecker over 6 years ago
- Related to task #6168: Full registration workflow model added
Updated by Andreas Kohlbecker over 6 years ago
- Description updated (diff)
- % Done changed from 0 to 50
Updated by Andreas Kohlbecker almost 4 years ago
- Status changed from In Progress to Closed
completed