Skip to content

Zitierung

Jump to bottom Edit New page
Christoph Broschinski edited this page Apr 14, 2016 · 3 revisions

Versionsnummern für korrekte Zitierung

von Marco Tullney, mit Ergänzungen von Christoph Broschinski

Zusammenfassung

Es gibt eine Ergänzung der Informationen auf Github, um die Zitation der Daten zu erläutern: "How to cite" unter https://github.com/OpenAPC/openapc-de/blob/master/README.md

Details

Die im OpenAPC-Projekt gesammelten Daten wachsen und werden zunehmend sehr positiv referenziert. Einige von uns werden die Daten bereits zitiert haben - in Anträgen an die DFG, in Auswertungen oder Projektplänen. Es gab bisher zwei Möglichkeiten der Zitation:

In beiden Fällen führt die einfache Verlinkung dazu, dass auf den jeweils aktuellen Stand verwiesen wird und die wichtige Kontextinformation, welcher historische Stand zitiert wird/ausgewertet worden ist nicht enthalten ist. Dies ist nicht nur eine Prinzipienfrage, sondern höchst relevant, wenn z.B. Daten wie "durchschnittliche APC-Höhe" zitiert werden.

Was fehlt(e): eine einfache Identifizierbarkeit und Zitierbarkeit von Versionen.

Durch die Verwaltung der OpenAPC-Daten in einem Git-Repository gibt es eine komplette Versionsgeschichte aller kleinen und großen Änderungen. Auch bisher war es schon möglich, den Datenstand nach einer bestimmten Aktualisierung (Commit) zu referenzieren: https://github.com/OpenAPC/openapc-de/tree/20d9ef5d532eb794aac5826a9e07f4d61fba03c3 - die Verwendung dieses Schemas mit einem Hashwert des letzten Commits ist aufwändig. Mit dezidierten Versionsnummern wird die Referenzierung einfacher, und die Versionierung zeigt eine sinnvolle Unterteilung des Fortschritts an.

Konkret benannte Versionen (Releases) sind auf Github verfügbar: https://github.com/OpenAPC/openapc-de/releases. Sie können als Archivdatei (tarball oder zip) heruntergeladen werden, z.B. um den derart versionierten Stand zu archivieren und auszuwerten.

Da die Versionen als tags in Github realisiert sind, können sie sowohl zur Identifikation des gesamten Datensatzes oder einer bestimmten Datei zu einem bestimmten Zeitpunkt genutzt werden: https://github.com/OpenAPC/openapc-de/tree/v1.0.4, https://github.com/OpenAPC/openapc-de/blob/v1.0.4/data/unihannover/unihannover.csv

Die Versionsnummern folgen grob dem Konzept des semantic versioning (http://semver.org/). Bis zur letzten Version unter der Hauptversionsnummer 1 (Version 1.2.002 vom 23. Dezember 2015) galten dabei folgende Regelungen:

  • aa.bb.cc, mit

    • aa: Hauptversion (major release number): Erhöhung z.B. wenn das Datenschema inkompatibel geändert wird

    • bb: Nebenversion (minor release number), bei substantiellen Neuerungen (Erhöhung z.B. bei der Aufnahme von Hybrid-APC)

    • cc: Revision (patch number), nach Erweiterungen, Aktualisierungen etc. (Erhöhung bei Aufnahme neuer Datenquellen, neuer Auswertungen)

Seit dem Umstieg auf Hauptversionsnummer 2 (Version 2.0.0 vom 27. Januar 2016, bedingt durch die Umstellung des Kerndatensatzes auf das neue OpenAPC-Datenschema) gelten folgende Regeln für die semantische Versionierung:

  • aa.bb.cc, mit

    • aa: Hauptversion: Erhöhung bei inkompatiblen Änderungen am Datenschema (wie vorher)

    • bb: Nebenversion: Erhöhung bei Erstaufnahme einer neuen Institution in den Kerndatensatz

    • cc: Revision: Erhöhung bei substantieller Aufnahme neuer Daten von bestehenden Institutionen (kleinere Korrekturen werden üblicherweise nicht neu versioniert)

DOI

Es wäre einfach möglich, jedes Release automatisch auf zenodo archivieren zu lassen und einen DOI dafür zu erhalten. Allerdings sind wir uns noch nicht einig, ob dies sinnvoll ist - v.a. angesichts einer großen Zahl von Releases. Grundsätzlich ist die DOI-Vergabe an vertrauenswürde Archivversionen gebunden; Bielefeld hat eine kontinuierlich aktualisierte Kopie der Dateien, und auf dieses Archiv (das dann seinerseits die Versionsgeschichte von Github erbt) verweist der DOI: https://gitlab.ub.uni-bielefeld.de/njahn/unibiapc

Dies sollte weiter diskutiert werden - brauchen wir DOI für einzelne (welche?) Versionen oder nur für das Gesamtprojekt?

Zukunft

Mit Versionen ist es auch möglich, für bestimmte Releases zu planen: Feature x, das zum Beispiel über Github issues (https://github.com/OpenAPC/openapc-de/issues) angefragt/vorgeschlagen worden ist, erhält als milestone die künftige Version 1.3.0 zugewiesen.

Mit freundlicher Unterstützung der Arbeitsgruppe Elektronisches Publizieren der Deutschen Initiative für Netzwerkinformation (DINI), der Deutschen Forschungsgemeinschaft und dem Bundesministerium für Bildung und Forschung.

Inhalte sind lizenziert unter CC BY 4.0.

Inhalt

Dokumentation

Technisches

GitHub

Clone this wiki locally