Die nachfolgende Fallstudie zeigt an einem Beispiel auf, welche Änderungen die digitale Transformation von Forschungsprozessen bereits heute ermöglicht. Ich ziehe dabei als Beispiel die Publikation eines Forschungsberichts heran, der empirische Daten nutzt, auswertet, kommentiert und veröffentlicht.
Medienbrüche als Kennzeichen bisheriger Arbeitsprozesse
Die bisher häufigste Vorgangsweise ist die Nutzung getrennter Software-Pakete, in denen das jeweilige Produkt des vorherigen Arbeitsablaufes durch eigene Verfahrensschritte z.B. durch Export/Import-Funktionen oder auch durch Kopieren und Einfügen für den nächsten Arbeitsschritt adaptiert wird.
Kennzeichen dieses Arbeitsprozesses ist es, dass zusammenhängende Arbeitsschritte infolge von Medienbrüchen keine digitale Weiterverarbeitung ermöglichen. Diese Vorgangsweise ist nicht nur wegen der vielen manuellen Zusatzarbeiten („copy & paste“, Konvertieren etc.) ineffizient, sondern bedeutet auch, dass jede Änderung im Ursprungsdokument (z.B. geänderte Daten) neuerlich händische Eingriffe erfordert. Damit steigt die Fehlerhäufigkeit und leidet die Transparenz der einzelnen Verfahrensschritte. Außerdem wird nur das Endprodukt (die eigentliche Publikation) veröffentlicht und damit eine Reproduzierbarkeit (in unserem Beispiel der Forschungsergebnisse), die für die Qualitätssicherung extrem wichtig ist, erschwert.
Digitalisierung von Forschungsprozessen
Im nachfolgenden Beispiel werden Daten mit R – einem sehr populären Open Source Statistik Programm – verarbeitet, ausgewertet und publiziert. Die Ergebnisse werden daher nicht wie üblich zwischen gespeichert und dann von einem anderen getrennt arbeitenden Programm weiter verarbeitet --- oder noch schlimmer: mit copy & paste in das andere Programm (z.B. eine Textverarbeitungssoftware) kopiert, wo das Material weiterbearbeitet wird und dann als Druckvorlage dem Verlag übermittelt wird. In vielen Fällen, z.B. bei Grafiken, ist vielleicht auch das Exportieren und unter Umständen auch das Konvertieren von Dateien mit Hilfe weiterer Programme notwendig.
Durch die Gestaltung eines einheitlichen Arbeitsflusses, der alle notwendigen Schritte miteinander kompatibel macht, können diese Nachteile überwunden werden. Prinzipielles Ziel dieser neuen Wertschöpfungsketten ist es, dass ausgehend von einem einzigen Quelldokument (single source publishing), die gesamte Kette der weiteren Verfahrensschritte ohne Medienbrüche bedient werden kann. Das bedeutet nicht nur eine effizientere Arbeitsweise und eine Reduktion von Fehlerquellen, sondern bringt auch eine Erweiterung der Publikationsmöglichkeiten mit sich (cross media publishing, multi-channel publishing).
Zusammenspiel von R, RStudio, RMarkdown und knitr
Dieser bruchlose Arbeitsprozess wird in R durch eine speziell für R adaptierte Markdown Sprache erreicht. Das speziell dafür entwickelte R Paket knitr ermöglicht eine Weiterverarbeitung in viele andere Formate. knitr ist DAS Allzweck Paket für dynamisches Generieren von Berichten in R (A General-Purpose Package for Dynamic Report Generation in R). Damit kann das in RMarkdown geschriebene Ausgangsdokument nicht nur die Programmiersprache R ausführen, sondern auch eines der bereits 11232 R-Zusatzpakete (Stand: 15.8.2017), wie z.B. knitr selbst eines ist. Vor allem aber können Text und Daten und die aus dem Programm generierten Grafiken und Tabellen bruchlos in andere Formate überführt werden. Es lassen sich Dokumente in HTML, PDF, Word bzw. Open Office / Libre Office, LaTeX (bzw. LyX, das eine einfache Word-ähnliche Benutzeroberfläche hat, ) erstellen. Selbstverständlich können durch entsprechende Porgrammierung auch andere Möglichkeiten (z.B. Excel, XML, SPSS, SAS, Mail, Webseiten etc.) wahrgenommen werden. Ein öffentlichen kostenloser Upload ist bereits vorgefertigt in der häufig für R verwendeten Programmierumgebung RStudio eingebaut.
Obwohl hinter diesen Prozessen eine komplexe Software-Maschinerie steht (so nutzt knitr selbst wiederum einen universellen Dokumentenkonverter ist eine detaillierte Kenntnis der verschiedenen unterschiedlichen genutzten Werkzeuge für die Nutzung nicht (mehr) notwendig. Mit einer Standard-Installation von R über https://cran.r-project.org/ und der Entwicklungsumgebung RStudio (https://www.rstudio.com) sind alle Voraussetzungen für cross media publishing geschaffen. Gelernt werden muss jedoch die Bedienung der Werkzeuge und die zur Verfügung stehenden Optionen, die eine detailreiche Adaption auf die je eigenen Wünsche und Aufgabenstellungen ermöglicht. (Siehe dazu genauer: Xie 2015; Xie 2016; Gandrud 2015)
Zusammenfassung
Dieses Beispiel zeigt vier Vorteile der Digitalisierung von Forschungsprozessen:
- Reproduzierbarkeit: Ausgehend von einem Quelldokument wird durch einen einzigen Befehl – ohne manuelle Zwischenschritte – das gewünschte Ausgangsdokument produziert. Das Ergebnis kann dann – wie bei diesem Beispiel oben in der Grafik gezeigt – auf derselben Benutzeroberfläche in einem eigenen Fenster gleichzeitig mit dem Quelldokument inspiziert werden. Änderungen, die im Quelldokument vorgenommen werden, lassen sich daher in ihren Ergebnissen unmittelbar einsehen und für alle nachvollziehen.
- Versionskontrolle und Kooperation: Zwischenschritte lassen sich mit Systemen der Versionskontrolle wie Git oder Subversion öffentlich über Webseiten wie z.B. GitHub oder Bitbucket nicht nur nachvollziehen, sondern auch gemeinsam, d.h. in kooperativen Arbeitssettings, weiterverarbeiten.
- Open Source Software: Alle eingebundenen Software-Pakete (mit Ausnahme von Microsoft Word) sind Open Source und frei verfügbar. Sie grenzen daher nicht durch proprietäre Regelungen aus, ermöglichen die Adaption auf individuelle Bedürfnisse und können sich auf eine aktive helfende Gemeinschaft (z.B. Stack Overflow, die größte Online-Community für Programmierer/innen) stützen.
- Nachhaltigkeit: Dadurch, dass vorwiegend offen zugängliche Texte ohne spezielle verschlüsselte Codierungen verwenden werden, ist auch große Nachhaltigkeit gesichert. Weil die Text von allen Texteditoren gelesen und weiterverarbeitet werden können gibt es keine Abhängigkeit von einem bestimmten Softwarepaket (oder noch schlimmer: von der konkreten Version einer bestimmtes Software).
Dieses ausführlich dargestellte Beispiel zeigt auch mein Verständnis von Educational Technology: Es handelt sich dabei nicht bloß um Autor/innen-Werkzeuge, die direkt für die Produktion von Bildungsmaterialien bzw. für die Entwicklung von eLearning-Szenarien genutzt werden können, sondern ich zähle darunter auch Technologie bzw. Software, die inkrementelles Lernen durch eigenständige Anwendung ermöglicht.
Gleichzeitig wird im obigen Beispiel auch meine didaktische Sichtweise demonstriert: Statt die Funktion eines Werkzeuges abstrakt einzuüben (z.B. indem die Benutzeroberfläche erläutert wird), findet im einem projektierten bzw. praxisorientierten Zugang der Lernprozess im Kontext eines (neuen) Arbeitsprozesses statt. Damit wird nicht nur die Vielzahl möglicher Tastenkombinationen – und damit die sog. „cognitive load“ (Sweller, Ayres und Kalyuga 2011) – eingeschränkt, sondern auch ein unmittelbarer motivierender Bezug zur Arbeitsaufgabe hergestellt.
4 Antworten auf „Digitalisierung von Forschungsprozessen“
Ich kann diesen Ansatz nur unterstützen. Ich komme aus dem Bereich der Ingenieurwissenschaften und setze deshalb nicht auf R, sondern eher auf Python (oder MATLAB) zur Datenanalyse und auf LaTeX zum Schreiben der Dokumente, wobei man mit entsprechenden Paketen wie pgfplots auch direkt die Rohdaten der Diagramme (als Textdatei) aus Python/MATLAB übernehmen und in LaTeX visualisieren kann.
Ich veröffentliche auch seit Jahren zu meinen Papern die entsprechenden Rohdaten der Messungen, die kompletten, direkt lauffähigen und gut kommentierten Auswertungsskripte in Python/MATLAB, die Quelltexte der Dokumente und Präsentationen etc. Die Rückmeldung dazu ist aber eher ernüchternd. Auf etwa 10 Veröffentlichungen gibt es im Schnitt mal eine Anfrage oder tatsächliche Nachnutzung der Daten von anderen Wissenschaftlern.
Diesbezüglich muss sich in unserer Wissenschaftskultur also noch ein bisschen was ändern, so dass das „Rad nicht immer neu erfunden“, sondern das (schon vorhandene, „erforschte“ oder „gemessene“) Rad mal lieber noch etwas „runder“ gemacht wird.
Danke für Ihren ausführlichen Kommentar und der Beschreibung Ihrer Erfahrungen. Ja, ich habe bereits vermutet, dass noch recht wenig auf Quelldokumente und/oder Originaldaten zurückgegriffen wird. Umso eher sollte man/frau diesen Ansatz weiter propagieren.
Mir ist bewusst, dass neben R vor allem Python die zweite echte Alternative für Data Science ist. Ich habe mich aber vorerst mal für R entschieden – ja selbst schon eine eigene Welt, in die einzuarbeiten viel Zeit kostet. Aber vielleicht können wir unsere Erfahrungen in Zukunft weiter austauschen?
Ich habe dazu folgende konkrete – bisher noch nicht ausgearbeitete – Idee: Ich würde gerne viele Aspekte von „Reproducible Research“ weiter ausarbeiten und publizieren. Einerseits ist das aber – weil es bereits extrem viele Initiativen und Softwarepakete gibt – ein riesiges Unterfagen, das kaum alleine zu bewältigen ist. Andererseits habe ich das Gefühl, dass ein „traditionelles“ Buch dem Umfang und der Dynamik der Entwicklung nicht gerecht werden kann. Ich bin daher am Nachdenken, ob nicht eine kooperative Initiative über eine aufzubauende Internetplattform, eine (ergänzende oder alternative) Möglichkeit wäre. Was meinen Sie?
Ich finde das eine gute Idee, bin aber gerade dabei eine Habilitation zu schreiben und habe deshalb leider keine Zeit.
Danke für Ihre Rückmeldung. Keine Angst, ich wollte Ihnen da nicht unbedingt gleich Arbeit und Verantwortung aufladen. Habe mich einfach über die erste Rückmeldung eines Gleichgesinnten gefreut! Vielleicht geht sich aber trotzdem ab und zu ein Kommentar aus? Wünsche Ihnen auf jeden Fall viel Zeit, Kraft und Kreativität für Ihre Dissertation!