Reproduzierbare Webseiten für alle – Ein Projektbericht aus dem Fellow-Programm Freies Wissen

Veranstaltungshinweis:
„Wissenschaft offen gestalten – Open Science in der Praxis“
Am 10. März präsentieren die Stipendiatinnen und Stipendiaten des Fellow-Programms Freies Wissen in Berlin ihre Projekte und diskutieren über ihre Erfahrungen mit Open Science in der Praxis. Mehr Informationen zur Veranstaltung sind hier zu finden.

Das Fellow-Programm Freies Wissen wurde 2016 von Wikimedia Deutschland und dem Stifterverband initiiert, um junge Wissenschaftlerinnen und Wissenschaftler dabei zu unterstützen, ihre eigene Forschung und Lehre im Sinne von Open Science zu öffnen und damit für alle zugänglich und nachnutzbar zu machen. In diesem Gastbeitrag berichtet der Stipendiat Ruben C. Arslan über seine Forschung, die er im Rahmen des Fellow-Programms durchführt. 

In meiner wissenschaftlichen Arbeit bemühe ich mich, so offen wie möglich zu sein. Leider arbeite ich mit Daten, die ich nicht ausreichend de-identifizieren kann, um sie zu teilen (sprich komische Sextagebücher) und Daten, bei denen mir die Entscheidung schlicht nicht obliegt (sprich die Stammbäume aller Schweden seit 1950). Um diesen peinlichen Mangel an Offenheit zu kompensieren habe ich versucht, andere Methoden zu entwickeln, um meine Arbeit transparent zu machen. Nach ein paar Fehlschlägen (niemand wollte sich meinen Rstudio-Speedrun-Twitch-Kanal ansehen), habe ich einen Weg gefunden, der für mich bisher passabel funktioniert hat. Jetzt denke ich, es könnte sogar für Forscher interessant sein, die nichts zu kompensieren haben.

Und zwar habe ich versucht, nicht nur meinen statistischen Code zu teilen, sondern auch sicherzustellen, dass er leicht zugänglich ist, indem ich ihn in eine reproduzierbare Website verwandle.

Warum? Weil viele Probleme auftreten können, wenn man “nur” Daten und Code teilt:

Eine unvollständige Liste

1. Unvollständige Anweisungen oder Code. Vielleicht hast du Geheimwissen wie “Zuerst muss ich das Arbeitsverzeichnis auf C:\DavemasterDave\Nature_paper\PNAS_paper\JPSP_paper\PAID_paper\Data setzen, die statistischen Pakete in der Reihenfolge laden, die uns von unseren Ältesten überbracht wurde, die Variablen umbenennen und zu Meehl beten. “
2. Inkonsistente Paketversionen. Du hast dplyr v0.5.0 anstelle von v.0.4.9 verwendet, um die Analysen zu reproduzieren. Fataler Fehler. Es stellt sich heraus, dass distinct() neuerdings die Funktion “wirf alle meine Daten weg und warn mich nicht” ist.
3. Umständlichkeit. Zuerst lade den Code aus dem Supplementary herunter (dazu klick diesen Link im PDF an und suche auf der Journalwebsite nach dem Paper). Die  Daten kriegst du dann von Dryad. Dann leg sie in den gleichen Ordner und installier die folgenden Pakete (oh übrigens müssen diese Pakete kompliliert werden, aber keine Bange dafür brauchst du nur R, Rstudio, Rtools und OS X Xcode command line tools). Oh, und um das Codebuch zu bekommen, musst du nur Mount Doom erklimmen. Weck auf dem Weg bloß nicht meinen Doktorvater auf und du bist schon fast da.
4. Schlechte Dokumentation des Codes. Was macht die Funktion transformData _???_profit? Was bedeuten die Variablen prc_stirn_b, fertile_fab? Ist RJS_6R die Variable, die invers kodiert ist oder hast du sie so genannt, nachdem du RJS_6 umgedreht hast? Und der Allzeit-Klassiker: Sind Frauen Sex == 2 oder Sex == 1 (oder doppelt so sex wie Männer, siehe auch hier)?
5. Es fängt mit den aufbereiteten Daten an. Wenn ich an einem Projekt arbeite, verwende ich 80% meiner Zeit auf die Datenaufbereitung, Reinigung, Kontrolle. Doch wenn ich reproduzierbare Dateien herunterlade, beginnen sie oft mit einer Datei namens cleaned_final_2_Sunday23July_BCM.csv. Da fehlt was. Und es können Fehler in diesem versteckten Teil stecken. Tatsächlich ist es exakt 99% wahrscheinlicher, dass ich einen Fehler bei der Datenaufbereitung gemacht habe, als dass Paul Bürkner einen Fehler bei der Programmierung von brms gemacht hat. Weil unsere Daten und deren Aufbereitung immer komplexer werden, sollten wir unsere Pipelines für die Datenaufbereitung teilen.
6. Zuletzt, das schlimmste: Verlust. Es zeigt sich, dass persönliche Universitäts-Seiten nicht besonders zuverlässige Orte sind, um Daten und Code zu speichern und auch nicht das Backup, das du auf dem USB-Stick hattest, den du deiner Kollegin geliehen hast, die .. Mist.

Reproduzierbare Webseiten lösen diese Probleme. Risiken und Nebenwirkungen beinhalten die quälende Ungewissheit darüber, ob du sie endlich freigeben sollst und ob noch Fehler gefunden werden (fun fact: niemand liest das Supplement. Ich habe ein Video von Rick Astley in jedem einzelnen meiner Supplements und bislang hat es niemand bemerkt).

Der Stack, den ich verwende, um meine reproduzierbaren Webseiten zu machen.

1. R & RStudio RStudio ist eine integrierte Entwicklungsumgebung. Braucht man nicht unbedingt, aber RStudio entwickelt eine Menge der Pakete, die notwendig sind, um Reproduzierbarkeit mit R umzusetzen, also ist ihr Editor eine kluge Wahl.
2. Packrat. Packrat schlichtet Paketversionenkonflikte. Leider ist es ein bisschen unreif, also würde ich zur Zeit empfehlen, es nur in der Endphase des Projektes zu aktivieren. Wenn du oft an vielen Projekten gleichzeitig arbeitest und weißt, welches Leid es verursacht, wenn ein Update in einem Projekt Bugs in einem anderen Projekt auslöst, könnte es sich lohnen die Mühe auf sich zu nehmen, packrat aktiviert zu lassen.
3. Rmarkdown (knitr). Markdown ist eine leicht zu erlernende Markup-Sprache. Mit Rmarkdown kannst du deinen R-Code dokumentieren, und Graphen und Tabellen einfügen, wo sie hingehören. Es erzeugt jetzt auch Webseiten und Bibliographien mit wenig zusätzlicher Arbeit.
4. Git & Github Git übernimmt die Versionskontrolle. Viele Wissenschaftler arbeiten alleine, also kann Git nach Overkill klingen, aber a) einmal open, wirst du nie wieder alleine arbeiten (man spiele die kitschige Musik) und b) die Features, die Github bietet (vor allem: Hosting für deine Website auf Github pages) könnten dich für die etwas steile Lernkurve entschädigen. RStudio bietet eine rustikale visuelle Schnittstelle für Git, ich persönlich bevorzuge SourceTree .
5. Zenodo kann deine Website dauerhaft, kostenlos archivieren (und andere Daten auch). Wenn man die Webseite öffentlich macht, kriegt man eine zitierbare DOI , die zu der Website führen wird, auch falls Github und Zenodo eines Tages das Zeitliche segnen. Zenodo kann mit Github integriert werden, so dass Releases auf Github automatisch in Zenodo hochgeladen werden.

Damit dieser Stack gut zusammenarbeitet, muss man noch einige kleinere Probleme bewältigen. Und um ganz ehrlich zu sein: Man braucht immer noch R, RStudio und eine rudimentäre Kenntnis der Geographie von Mount Doom. Aber deine Leser brauchen nur einen Webbrowser, um deine Arbeit nachzuvollziehen (okay, Drucken ginge auch, aber einer meiner Co-Autoren hat einmal versucht, alle meine Mplus-Outputs zu drucken und dabei einen wesentlichen Teil von Honduras entwaldet).

Jens Bludau, Stromboli animiert, CC BY-SA 3.0

Um es einfacher zu machen, habe ich ein Anfänger-RStudio-Projekt hochgeladen, das du bei Github forken kannst, um mit einer Konfiguration zu beginnen, die bislang gut für mich funktioniert hat. Ich habe versucht, einige der Risse im Stack zu übertünchen, und ich habe ein bisschen Struktur und Code hinzugefügt, die du dann anpassen kannst.

Mit diesen Projekten dokumentiere ich meinen gesamten Forschungsprozess mit Rmarkdown (z. B. Laden und Verarbeiten der Rohdaten, Reshaping in die richtige Form, Analysieren, Diagramme).

Aber statt die rohen Skripte zu teilen (die nur sinnvoll sind, wenn sie interaktiv mit den Daten laufen), mache ich eine Website, auf der die Leser den Code zusammen mit den resultierenden Graphen und anderen Outputs sehen.

Ich benutze die so erstellten Berichte, um meine eigenen Ergebnisse zu verstehen und mit meinen Co-Autoren umfangreiche Ergebnisse zu teilen. Manche Freunde schreiben sogar ihre kompletten Manuskripte mit Scholarly Markdown und Papaja, aber mir ist hier eigentlich wichtiger, nicht alle interessanten Details, die es nicht in das Manuskript schaffen, unter den Tisch fallen zu lassen.

Hier sind zwei Projekte, wo ich diesen Stack (oder eine frühere Version) verwendet habe:

• https://rubenarslan.github.io/paternal_age_fitness/ – das Online-Supplement für dieses Manuskript. Das ist die größte Seite, die ich bisher gemacht habe (~ 90 Seiten, >7000 Graphen) und es war eine komplexe Nummer mit Modellen, die auf einem Cluster liefen, aber offline dokumentiert wurden.
• Https://rubenarslan.github.io/generation_scotland_pedigree_gcta/ – das Online-Supplement für dieses Manuskript. Dieser Projekt war viel einfacher, einfach nur eine einzige Seite mit vielen Tabs. Im Manuskript konnten wir nur die Ergebnisse unserer Modellselektionsprozedur zeigen, aber online konnten wir zeigen, welchen Einfluss unsere Entscheidungen hatten und die Komponenten sich gegenseitig beeinflussen.

Dieser Stack sollte mit kleineren Änderungen auch mit Shiny Apps funktionieren.

Also, seid reproduzierbar und mehret euch: https://github.com/rubenarslan/repro_web_stack/

(Es gibt noch ein paar langweiligere Anweisungen auf der Github-Seite, aber es ist wirklich einfacher als all diese Software-Namen es klingen lassen).

PS: Wenn dir das nicht nerdy genug war, ist vielleicht Jon Zelners Blog-Post-Serie interessant. Er benutzt Make-Files, Docker und continuous integration wie ein richtiger, erwachsener Programmierer.

Dieser Artikel ist eine übersetzte Fassung eines Beitrags auf der Webseite von Ruben C. Arslan

Zum Autor

Ruben C. Arslan promoviert in der Biologischen Persönlichkeitspsychologie an der Georg-August-Universität Göttingen. Dort befasst er sich mit den evolutionären und genetischen Ursachen von individuellen Unterschieden in Persönlichkeit und Intelligenz und untersucht romantische Präferenzen und Beziehungsdynamiken. Er hofft, dass offene, transparente Wissenschaft die psychologische Forschung solider und replizierbarer machen wird. Um das voranzutreiben veröffentlicht er wissenschaftliche Open Source Software und beteiligt sich an internationalen und lokalen Initiativen zur Förderung von Open Science.