task #6091
closedVersionierung von Records (workflow draft ticket)
100%
Description
Inhaltlich ist eine Versionierung notwendig.
Es ist nicht möglich, die Datenbank zu versionieren (auch technisch zurzeit nicht), da sie kontinuierlich bearbeitet werden soll.
Andreas M. sagte, dass die ursprünglichen Records bei Änderung aufgehoben werden können.
Inhaltlich stelle ich mir vor:
Solange ein Record noch nicht publiziert ist, könnte der Record mit 0.1, 0.2 versioniert werden (es ist die Frage, ob das sinnvoll ist, da ja noch nicht publiziert ist).
Prinzipiell sollte die publizierte Version, die Version 1.0 sein. Prinzip der Algenregistrierung ist, dass die Daten dann unverändert erhalten bleiben. Dennoch könnte es notwendig sein, zu korrigieren. Das können Eingabefehler sein, das können wichtige Änderungen in der Einschätzung der Validität sein, die zum Zeitpunkt der Registrierung noch nicht bekannt war.
Das ist dann der Fall, wo eine Version 1.1 geschaffen wird, mit Datum der Änderung. Da sich in der wissenschaftlichen Diskussion auf einen Record bezogen werden kann, sollte die Version angezeigt werden. Da wir Stable Identifier verwenden, könnte trotz Änderung der Stable Identifier stable bleiben.
Alle externe Information, d.h. Information, die nicht aus der registrierten Quelle kommt, muss als externe Information sichtbar sein (siehe CDM-interne und CDM-externe Annotations).
Files
Updated by Andreas Kohlbecker over 6 years ago
- Due date set to 10/03/2016
- Start date changed from 09/16/2016 to 10/03/2016
Updated by Andreas Kohlbecker over 6 years ago
- Category changed from Model to Workflow
- Status changed from New to Feedback
- Assignee set to Wolf-Henning Kusber
- Priority changed from New to Priority14
- % Done changed from 0 to 30
Solange ein Record noch nicht publiziert ist, könnte der Record mit 0.1, 0.2 versioniert werden (es ist die Frage, ob das sinnvoll ist, da ja noch nicht publiziert ist).
Ich glaube nicht, dass wir Versionen brauchen bevor der Name publiziert wurde. Mit der Publikation werden der Namens und Registrierungs Record öffentlich und die Versionsnummer 1 wird vergeben.
Ganzzahlige Versionsnummern sind meines Erachtens ausreichend, also 1, 2, 3, etc. Nummerierungen mit 1.x , also Major-Version.Minor-Version machen nur dann Sinn, wenn es auch möglich ist, dass es eine Version 2.0 gibt. Wenn normale Änderungen die Minor-Version erhöhen, könnte nur eine besonders große, bedeutende Änderung einen Versionsschritt bei der Major-Version verursachen. Eine solche besonders bedeutende Änderung kann ich mir für Namen nicht vorstellen.
Für das bessere Verständnis der Versionierung wäre es gut, wenn wir noch genauere Details dazu hätten, welche Änderungen, Korrekturen dies genau sind, die das Vergeben einer neuen Version zwingend machen. Welche Usecase-Szenarien gibt es? Beispiele?
Updated by Wolf-Henning Kusber over 6 years ago
Die Idee der Versionierung war im Hinblick auf Kew-Daten und die Verwendung von LSIDs mit Versionen und Unterversionen, die jeweils direkt clickable sind entstanden. Jede Änderung (Standards, Rechtschreibung, Metadaten, Ergänzungen) ist dort direkt transparent nachvollziehbar.
Mit entsprechenden Änderungen müssen wir uns auch beschäftigen und die transparent zugänglich machen. Versionierung und Unterversionen wären z.B. durch http-Identifier schwerer handhabbar. Eine Analyse hat (Excel, Blatt 2) hat zunächst gezeigt, dass nicht alle publizierten Namen für das Registrierungssystem relevant sind.
Die Analyse möglicher Änderungen von Daten, ab dem Anlegen eines Registrierungs-Records bis nach der Publikation des Registrieungs-Records zeigt in der Excel-Datei, Blatt 1, dass es nur einen Fall gibt, bei dem 2 Records vorgehalten werden und auf einander bezogen werden müssen:
Wenn ein Namens-String (ohne Author Team) nach Publikation des Records in der Schreibweise verändert/korrigiert wird. Alles andere bezieht sich auf die Metadaten. Dort müssen Änderungen zwar auch kommentiert und transparent gemacht werden, konstituieren aber keinen neuen Record oder eine neue Version.
Updated by Andreas Kohlbecker over 6 years ago
- Assignee changed from Wolf-Henning Kusber to Andreas Kohlbecker
Nun sollten diese 'Regeln' in das Workflow dokument übertragen werden.
Updated by Andreas Kohlbecker almost 4 years ago
Note: We could implement a timeline view of the changes recorded in the audittables for the popup edit
Updated by Andreas Kohlbecker over 3 years ago
- Status changed from Feedback to Closed
- % Done changed from 30 to 100
versioning has been rejected and the timeline view would be something to be implemented in future and is not essentially for PhycoBank. So this issue can be closed now