Einleitung
In den letzten Jahren sind einige größere und kleinere Plattformen und Online-Editoren auf den Markt gekommen, die das kollaborative Schreiben und Publizieren vereinfachen wollen. Authorea und Overleaf sind hierbei vielleicht die bekannteren. Sie sind in der Tat sehr leistungsfähig und warten mit vielen Komfortfunktionen auf, die den wissenschaftlichen Schreib- und Publikationsprozess vereinfachen. Wie Christian Heise in seiner offenen Doktorarbeit herausgefunden hat, gehen diese Ansätze zwar schon in die richtige Richtung, sie lösen allerdings aus verschiedenen Gründen nicht ein, was sich eine wissenschaftliche Community von solchen Werkzeugen erwarten darf (vgl. Heise, 2017, 2018). Abhängigkeiten von Geschäftsmodellen spielen hier ebenso eine Rolle wie Datenschutzaspekte und fehlende Anreize.
“Die notwendige (Weiter-)Entwicklung der Plattformen wird jedoch nur dann stattfinden, wenn die Nachfrage nach solchen Lösungen steigt. Die wissenschaftliche Gemeinschaft ist auch hier gefragt, diese Nachfrage (zum Beispiel durch Experimente mit offener wissenschaftlicher Kommunikation) zu erzeugen und bei der Entwicklung solcher Lösungen eine aktive und gestaltende Rolle einzunehmen.” (Heise, 2018, S. 261f.)
Experimente sind gefragt
Weiterer Forschungs- und Entwicklungsbedarf ist demnach angezeigt. Im Projekt “Modernes Publizieren” widmen wir uns der Frage nach bedarfsgerechten und zeitgemäßen Tools und Workflows aus der Perspektive sozio-technischer Systeme. Denn digitale Tools für kollaborative Schreib- und Publikationsprozesse zusammenzuziehen heißt, dass nicht nur die Technik im Blick behalten werden muss. Ebenso wichtig erscheinen uns die beteiligten Akteur_innen mit ihren höchst unterschiedlichen Schreibgewohnheiten, Computererfahrungen, Reputationskulturen und Publikationsstrategien in ihren Fächern. Unter dieser doppelten Perspektive kann ein zu entwickelndes System nur als sozio-technisches System begriffen werden, das im Sinne von Herrmann (2003) das Geflecht sozialer, kultureller, organisatorischer und technischer Aspekte und Teilsysteme zu gleichen Teilen betrachtet und entwickelt.
Dabei leiten uns die zentralen Wertvorstellungen im Diskurs Open Science: Transparenz, Nachvollziehbarkeit und Reproduzierbarkeit sowie Zugang und die FAIR-Prinzipien (vgl. Wilkinson et al., 2016) wollen wir im Hinblick auf zeitgemäße wissenschaftliche Publikationsprozesse analysieren und implementieren.
Der Architekturentwurf
Im Folgenden wollen wir die Entscheidungen für unseren initialen Architekturentwurf entfalten und begründen. Die einzelnen technischen Komponenten werden vorgestellt und ihr Zusammenspiel herausgearbeitet.
Architekturentwurf eines sozio-technischen Systems zum kollaborativen Schreiben und Publizieren wissenschaftlicher Journalbeiträge. Quelle: Axel Dürkop
Die Abbildung gliedert sich grob in drei Teile:
- In der Writing Stage ist der Schreibprozess von einer oder mehreren Personen dargestellt, die allein oder gemeinsam, synchron oder asynchron zu einem ersten Entwurf eines wiss. Journalbeitrags kommen.
- Die Pre-submission Stage in der Mitte ist eine Phase des Schreib- und Publikationsprozesses, die sich beliebig oft vor der eigentlichen Einreichung (Submission) wiederholen kann. In dieser Phase spielen verschiedene Tools und Formate mit, die unten detailliert vorgestellt werden. Die grüne Figur stellt die neue Rolle des Pre-submission Facilitators dar.
- Die Submission Stage rechts zeigt die Übergabe generierter Formate aus der Pre-submission Stage an ein Journal. In unserem Projekt ist OJS an der Staats- und Universitätsbibliothek Hamburg (SUB) das Zielsystem.
Vorannahmen zur Writing Stage
Wir gehen davon aus, dass der Schreibprozess für einen Journalbeitrag mit einer, eher jedoch mit mehreren Personen beginnt. Diese Annahme stützen wir auf erste Gespräche mit Kolleg_innen aus verschiedenen Fachdisziplinen über Ihre Schreibgewohnheiten und Publikationsstrategien. Im weiteren Verlauf des Projekts werden wir hier systematisch forschen. Ihre Vorlieben für Schreibwerkzeuge und die Organisation des Schreibprozesses handeln die Autor_innen in der Regel miteinander aus und einigen sich auf die inhaltliche Aufteilung, den Modus des Schreibens und die Ausweisung der Autorenschaft.
In dieser Writing Stage wollen wir Empfehlungen aussprechen und anregen, Neues auszuprobieren. Statt also – vielleicht wie in der Vergangenheit – Office-Dokumente per Mail untereinander zu verschicken, regen wir an, kollaborative Schreibwerkzeuge wie Etherpad, CryptPad oder HackMD zu verwenden. Wichtig ist uns, dass die Autor_innen sich in ihrer Schreibumgebung wohlfühlen. Da das Schreiben ein sehr individueller und intimer Prozess ist, soll die Qualität des wissenschaftlichen Beitrags nicht durch eine hohe parallele Lernkurve neuer Werkzeuge beeinträchtigt werden.
Pre-submission Stage: Die Phase vor der Einreichung
Haben die Autor_innen einen ersten Entwurf ihres Artikels verfasst, bieten wir einen Übergang in die Pre-submission Stage an. Die Pre-submission Stage ist die Phase im Publikationsprozess, in der ein Beitrag vor der Einreichung technisch aufbereitet wird und erste Zyklen der Qualitätssicherung durchlaufen kann.
Die Rolle des/der Pre-submission Facilitators
Für die Pre-submission Stage haben wir eine neue Rolle des/der Pre-submission Facilitators geschaffen, die in der Abbildung des Architekturentwurfs grün dargestellt ist. Im Rahmen des Projekts “Modernes Publizieren” übernehmen wir Teammitglieder diese Rolle gemeinsam und finden heraus, welche sozialen und technischen Kompetenzen ihr zugeschrieben werden müssen. Zum jetzigen Zeitpunkt des Projekts ist es so, dass wir in der Rolle des Pre-submission Facilitators schon zu Beginn der Writing Stage mit den Autor_innen im Gespräch sind, um sie als Proband_innen zu gewinnen.
Die neue Rolle des/der Pre-submission Facilitators kommuniziert Funktionen und Wertvorstellungen des sozio-technischen System an die Autor_innen und andere beteiligte Akteur_innen. Sie leistet konkrete Hilfe in der Einrichtung und Anwendung des Systems auf dem Weg zur Publikation. Quelle: Axel Dürkop
Wir gehen davon aus, dass die Rolle Pre-submission Facilitator mit zunehmender Kompetenz der Autor_innen verzichtbar wird, weil sie die anfallenden Aufgaben und Arbeitsschritte selbst übernehmen können.
Technische Aufbereitung des Beitragsentwurfs
An diesem Punkt besteht für die Pre-submission Facilitators die Chance, die Autor_innen auf die Vorzüge von Markdown und pandoc/pandoc-scholar hinzuweisen, die sich vor allem darin zeigen, dass sich aus einer Markdown-Quelle jederzeit verschiedene offene Formate generieren lassen (HTML, PDF, EPUB, MOBI u.a.). Krewinkel & Winkler (2017) beschreiben diese Vorteile ausführlich und erweitern mit der Software pandoc-scholar den Funktionsumfang von pandoc unter den Anforderungen moderner wissenschaftlicher Publikationsstrategien. Daher wollen wir pandoc-scholar zentral für unser System einsetzen. Grandesso (2018) hat in diesem Zusammenhang ebenfalls schon Vorarbeit geleistet und einen Workflow mit pandoc zu OJS skizziert.
Sofern die Autor_innen ihren Beitrag nicht in Markdown einreichen, ist es demnach die erste Aufgabe des Pre-submission Facilitators, eine entsprechende Konvertierung des Ausgangsformats durchzuführen. Denn nur, wenn der Text in Markdown vorliegt, können mit pandoc-scholar die vielen Vorteile der automatisierten Formaterzeugung nutzbar gemacht werden, die weiter unten noch entfaltet werden. Die Konvertierung erfolgt mit pandoc und zusätzlicher Handarbeit, bspw. um die Metadaten des Beitrags korrekt zu erfassen. Quellformate können bspw. Worddokumente mit korrekter Anwendung von Formatvorlagen oder LaTeX-Dokumente sein.
Zusammenwirken von Akteur_innen und Technik in der Pre-submission Stage
Nach der Konvertierung des Entwurfs richtet der/die Pre-submission Facilitator den Beitrag für den Technikstack der Pre-submission Stage ein. Dieser Stack besteht vornehmlich aus GitLab, Docker und pandoc-scholar. Die Nutzung dieser drei Komponenten im Zusammenhang kann wie folgt umrissen werden (vgl. dazu auch die Abbildung des Architekturentwurfs oben):
Ein wissenschaftlicher Journalbeitrag wird im Markdown-Format in GitLab hinterlegt. GitLab ist so konfiguriert, dass es bei jeder Änderung der Markdown-Datei mithilfe von pandoc-scholar eine HTML-Seite des Artikels generiert. pandoc-scholar wird dabei in einem temporären Docker-Container ausgeführt. Die erzeugte HTML-Seite wird anschließend (zugriffsgeschützt) von einem Webserver zur Verfügung gestellt.
Die Öffentlichkeit oder eine eingeladene Commmunity können nun mithilfe von Hypothesis den Autor_innen Anregungen zur Überarbeitung des Artikels vor der eigentlichen Einreichung geben, indem sie die geschützte Website kommentieren und annotieren. Die Autor_innen können sich an dieser Diskussion beteiligen.
Durch das Konzept von Review Apps in GitLab, die auf Branches basieren, ist es möglich, beliebig viele Versionen des Beitrags kommentierbar im Netz zu veröffentlichen und ihn gemeinsam iterativ zu verbessern.
Durch den Einsatz von pandoc-scholar können zudem bei jedem Durchlauf verschiedene Ausgabeformate des Beitrags (HTML, PDF, EPUB, MOBI u.a.) generiert werden, die direkt an ein in OJS gehostetes Journal übergeben werden können, wenn die Autor_innen bereit sind für die Submission.
Diese kurze Zusammenfassung des Systems soll nun noch etwas genauer betrachtet werden.
GitLab und Docker im Verbund: ein universelles CMS
Mit GitLab, Docker, pandoc und weiteren statischen Seitengeneratoren (Jekyll, GitBook, Hugo u.a.) wurden schon in den vergangenen Jahren umfangreiche Erfahrungen in der Entwicklung von Open Educational Resources (OER) gesammelt.1 Diese transferieren wir nun im Projekt “Modernes Publizieren” in den Kontext wissenschaftlicher Publikationen.
Zentral für das Verständnis ist dabei, dass wir GitLab auch hier als universelles Content-Management-System begreifen: Nutzer_innen arbeiten wenn möglich im Browser. Änderungen an “Quelltext” stoßen die oben beschriebene vorkonfigurierte Pipeline an, die einen Docker-Container hochzieht (vgl. den Inhalt des Kreises in der Abb. oben). Das Docker-Image für diesen Container enthält in unserem Projekt pandoc-scholar, sodass wir online verschiedene Ausgabeformate sowohl generieren als auch verschiedentlich nutzbar machen können. Erzeugte HTML-Artefakte nutzen wir, um sie zum Kommentieren mit Hypothesis ins Netz zu stellen, andere Formate reichen wir zu gegebener Zeit beim Journal in OJS ein.
Review Apps in GitLab
GitLab wartet mit einem sehr potenten Feature auf, von dem wir auch in diesem Projekt Gebrauch machen: Review Apps. Bei entsprechender Konfiguration werden digitale Artefakte des Projekts aus jedem Branch generiert. Das bedeutet, dass alle gewünschten Formate wie HTML, PDF etc. alternativ für jede Version des Artikels generiert werden können.
Die Idee hierfür stammt aus der Softwareentwicklung. Für Auftraggeber_innen von Software ist es schwer vorstellbar, wie ein gewünschtes Feature aussehen wird, nachdem es programmiert wurde. Der Code, der dafür geschrieben werden muss, macht es erst anschaulich. Erkennen und Lernen wird möglich, wenn alle Beteiligten sich mit der konkreten Implementierung auseinandersetzen.
Review Apps sind demnach Vorschauen von Softwarefeatures, die in eigenständigen Branches entwickelt werden. Am Beispiel einer Website erklärt, wäre eine Review App die (meist geschützte) Ansicht einer neuen Unterseite oder einer neuen Funktion im Webshop, die noch der Abstimmung zwischen Entwickler_innen und Auftraggeber_innen bedarf. Wird das Feature akzeptiert, wird der Entwicklungsbranch in den Hauptbranch gemergt.
Gebrauch von Review Apps in der Softwareentwicklung. Wir übersetzen diese Arbeitsweise für die Erzeugung alternativer Versionen von Textbeiträgen in der Pre-submission Stage. Quelle: GitLab Docs
Dieses Feature machen wir uns in unserem System zunutze, indem wir für verschiedene Iterationen eines Textbeitrags Branches erzeugen, aus denen Review Apps generiert werden. Jede Review App ist eine HTML-Version des Beitrags und verfügt über eine eindeutige URL.
Verschiedene Versionen des Beitrags werden von GitLab in Branches abgebildet. Aus diesen Branches lassen sich bei entsprechender Konfiguration Review Apps in Form von HTML-Seiten erzeugen, die von der Öffentlichkeit oder Community mit Hypothesis kommentiert und annotiert werden können. Quelle: Axel Dürkop
Hypothesis
Hypothesis ist eine Anwendung, die Nutzer_innen die Annotation von Internetquellen ermöglicht. Diese Funktionsweise von Hypothesis verhält sich wie ein zusätzlicher Layer bzw. eine zusätzliche Schicht, die auf offenen Standards basiert und über die eigentlichen Inhalte im Internet gelegt wird. Webseiten, Dokumente, Bilder, Videos, Daten: In dieser “Schicht” lassen sich sämtliche Inhalte mit individuellen Gedanken, Ideen und Ansichten versehen, ohne dass das Originalmaterial verändert wird.
Features von Hypothesis sind:
- Ausgewählte Inhalte wie Texte lassen sich annotieren, ohne dass direkt im Originaltext gearbeitet wird. Diese Annotationen können zusätzlich mit Tags versehen werden. Anschließend können sie öffentlichen oder geschlossenen Kreisen zugänglich gemacht werden.
- Das Annotieren kann somit alleine oder kollaborativ in Gruppen erfolgen.
- Auf Annotationen können andere Nutzer_innen über einen “Reply-Button” reagieren. Zudem lassen sich ganze Seiten oder einzelne Annotationen über Links mit anderen Personen direkt teilen.
Annotieren beliebiger Webinhalte mit Hypothesis. Quelle: Axel Dürkop
Annotieren und Kommentieren mit Hypothesis
Nachdem die Autor_innen dem/der Pre-submission Facilitator den Text übergeben haben und er für erstes Feedback aufbereitet wurde, kann er in Form einer Review App (HTML-Dokument) ausgewählten Personenkreisen zur Verfügung gestellt werden. Diese Personenkreise können dann das entsprechende Dokument kommentieren und annotieren. Die dafür notwendigen Funktionen können über Eingabe der URL in “Paste a Link” aktiviert werden. Möglich ist auch, forciert ein Panel an der rechten Seite der Website einzublenden (vgl. animierte Abb. oben).
Soll nun ein Text annotiert werden, so muss der entsprechende Abschnitt mit der Maus markiert werden. Ein Klick auf die Annotate-Schaltfläche zeigt das Panel rechts, in dem Kommentare und Tags hinterlegt werden können. Hier könnte zukünftig ein Filtersystem zum Einsatz kommen, das Kommentare bspw. in Aspekte wie “Quellenangabe” oder “Rechtschreibung & Grammatik” einordnen könnte.
Ebenfalls festzulegen gilt es, ob nur die Schreibenden oder auch Lesende bzw. die Weltöffentlichkeit im Netz die vorhandenen Kommentare einsehen können. Nach Formulierung der Annotation muss der entsprechende Inhalt über den Button Post to… abgespeichert werden, wobei auch geschlossene Gruppen ausgewählt werden können. Im Nachgang können Kommentare noch über Auswahl des Stift-Icons angepasst oder über das Papierkorb-Icon gelöscht werden. Über die Reply-Funktion können Annotationen bspw. vom Autorenteam kommentiert werden.
Feedbackphasen sollten sinnvollerweise mit Deadlines versehen werden. Im Anschluss und auch währenddessen haben Autoren die Möglichkeit, die Anmerkungen in einem neuen GitLab-Branch einzuarbeiten. Gleichzeitig kann die Community weiter eine Vorgängerversion kommentieren. Sollte der Bedarf bestehen, kann die überarbeitete Version erneut mit Hypothesis von derselben oder einer anderen Community kommentiert werden.
Open Journal Systems (OJS)
Wir nehmen an, dass der Entwurf in der Pre-submission Stage durch das beschriebene Vorgehen irgendwann eine Qualität erreicht, durch die er bereit für die eigentliche Submission ist. Dieser Zeitpunkt wird von den Autor_innen bestimmt.
Durch den Einsatz von pandoc-scholar können jederzeit verschiedene Exportformate des Beitrags generiert, kommentiert und eingereicht werden. Quelle: Axel Dürkop
In unserem Projekt arbeiten wir an der Überstellung verschiedener Exportformate aus GitLab an das OJS der Staats- und Universitätsbibliothek Hamburg (SUB). Wir evaluieren hierfür sowohl einen technischen Ansatz, in dem mit der noch recht unvollständigen REST-API der Software interagiert wird, als auch Szenarien, die den manuellen Upload der Exportformate in OJS beinhalten.
In OJS greifen dann wiederum traditionelle Verfahren des Reviews mit ausgewählten Freiwilligen des jeweiligen Journals. Inwieweit Reviewprozesse in Pre-submission Stage und Submission Stage miteinander korrespondieren können, wissen wir noch nicht. Unser Ziel ist es, in diesem Jahr dazu mit verschiedenen Proband_innen aus unterschiedlichen Fachdisziplinen zu experimentieren.
Erprobung von Architekturentwurf und Workflow
Aktuell finden Dank Unterstützung wissenschaftlicher Mitarbeiter_innen der TUHH erste Testphasen mit dem dargestellten sozio-technischen System statt. Im Rahmen dieser Experimente sollen zukünftig die Verständlichkeit und Praxistauglichkeit des Systems überprüft werden. Hierbei interessiert uns die Kommunikation in Feedbackworkflows ebenso wie die Wahrnehmung der verschiedenen technischen Teilsysteme und im Besonderen die Wahrnehmung von Hypothesis als zentrales Feedbacksystem.
Wir werden berichten.
