Heute möchte ich einen Ausblick versuchen, wie unsere Arbeit fortgesetzt werden könnte – ob nun im Rahmen einer Projektförderung oder ohne. Diese Ideen sind angetrieben vom Wunsch, unsere Ergebnisse besser nachnutzbar zu machen und allgemein die Usability zu erhöhen.
Bidirektionale Konsistenz von Metadaten
In der Arbeit mit den Herausgeber:innen von kommunikation@gesellschaft hat sich gezeigt, dass Metadaten für Artikel doppelt eingegeben und gepflegt werden müssen, wenn die Einreichung, Review und Veröffentlichung in OJS und die Produktion von HTML/XML/JATS mit Swapfire stattfindet (vgl. Abb. 1).
Abb. 1: Single-Source-Publishing mit Swapfire und OJS. Quelle: https://doi.org/10.15480/882.2902
Denn die Autor:innen geben bei der Einreichung und im weiteren Prozess alle Metadaten in OJS ein, die später den Artikel rahmen. Für die Produktion in GitLab müssen diese Daten noch einmal erfasst werden, was uns vor große Herausforderungen hinsichtlich der Usability gestellt hat. Denn ob JSON oder YAML, egal ob die Einpflegenden code-affin sind oder nicht: Beide Notationsformen sind höchst fehleranfällig und erfordern mindestens einen Linter, wenn die Produktion nicht an dieser Eingabe scheitern soll.
Um die Dateneingabe abzusichern und sie nicht von Codeaffinität abhängig machen zu müssen, haben wir das offene CMS Netlify eingesetzt, das in unserem Workflow für jeden Artikel auf einen Webserver deployt wird. Hier können sich Herausgeber:innen mit GitLab authentifizieren und in HTML-Formularen die Metadaten für die Produktion in GitLab erfassen (vgl. Abb. 2). Das hat für die fünfzig Artikel beim Relaunch von kommunikation@gesellschaft gut funktioniert. Lediglich einige Nachjustierungen waren nötig, wenn wir etwas über die notwendigen Metadaten gelernt hatten.
Abb. 2: Erfassung von Metadaten mit NetlifyCMS
Dennoch war dies eine redundante Arbeit, die zwischen GitLab und OJS zu Inkonsistenzen geführt hat. Das würden wir gern in Zukunft in zwei Schritten ändern:
- Metadaten von Artikeln werden von der REST-API in OJS abgeholt (JSON) und auf ein/unser Metadatenschema gemappt (YAML).
- Metadaten werden bidirektional zwischen GitLab und OJS ausgetauscht und sorgen so für Konsistenz. Leider ist die REST-Schnittstelle der Version 3.2 noch nicht so entwickelt, dass POST- und PUT-Befehle sorglos abgesetzt werden können.
Schritt 1 ist leicht zu haben, wie erste Experimente mit GET in Postman zeigen. Was es braucht, wäre ein Mapper, der (am besten in Docker gekapselt) zur REST-API von OJS läuft, die Daten holt (JSON) und in das vorgegebene Metadatenschema überträgt (YAML).
Schritt 2 macht dann schon mehr Arbeit. Hier wäre eine enge Zusammenarbeit mit der PKP-Community sinnvoll, die OJS weiterentwickelt. Wir konnten diese im Projekt schon aufs Gleis bringen, aber noch keine konkreten Schritte gemeinsam unternehmen. Gerne in Zukunft!
Verabredung auf ein Metadatenschema für Artikel
Im Laufe des Projekts haben einige, die sich für wissenschaftliches Publizieren interessieren, die Arbeitsgruppe JAMS gegründet. Albert und ich sind auch dabei. Die Abkürzung steht für Journal Article Metadata Schema und drückt den Wunsch aus, einen standardisierten Kerndatensatz für Metadaten zu haben, wenn es um wiss. Journalbeiträge geht. Das GitHub-Repo gibt Auskunft über den aktuellen Stand der Diskussion.
Das Metadatenschema, das wir im Projekt schließlich verwendet haben, orientiert sich an pandoc-scholar und erweitert die dort gesetzten Entitäten und Modellierungen. Allerdings ist unser Ergebnis eher gewachsen als konzipiert und hat sich auch stark nach der Darstellbarkeit von YAML mit NetlifyCMS gerichtet. Läuft, kann man sagen, könnte aber sicherlich eine Portion Standardisierung vertragen.
Wer sich also für die Mitarbeit in der Arbeitsgruppe interessiert, möchte sich bitte melden. Es gibt unregelmäßige Treffen in einem bekannten Videokonferenzprogramm.
Mandantenfähiges Docker-Image
Albert hatte am 20.12.2020 darüber geschrieben, dass wir zum Ende des Projekts ein Docker-Image entwickelt haben, durch das die Nutzung von Swapfire (Scholarly writing and publishing framework for independence in research and education) sehr viel nutzer:innenfreundlicher wird. Denn in dem Image stecken nicht nur pandoc, LaTeX und pandoc-scholar, sondern auch die Konfiguration des Journals sowie die angepassten Templates für HTML, PDF und JATS/XML. Allerdings hatten wir bisher nicht die Zeit, das Image so allgemeingültig zu bauen, dass es durch convention over configuration mandantenfähig ist. Soll heißen, dass Herausgeber:innen, die es verwenden, durch Überschreiben von Vorgaben zu ihrem eigenen Journaldesign kommen können.
Momentan produzieren wir mit dem Image für das Journal kommunikation@gesellschaft und erreichen zu später Stunde, wenn der shared runner in GitLab nicht viel zu tun hat, Buildzeiten für alle drei Formate von ca. 15 Sekunden.
Clientseitiges Bauen mit Zettlr
Das Docker-Image eröffnet schließlich ganz neue Perspektiven für Herausgeber:innen. Wie wir am 05.12. und am 15.12.2020 schon geschrieben hatten, ist der Editor Zettlr zentral in unserem Projekt gewesen. Nicht nur, dass er das Importieren und Konvertieren von Worddateien zu Markdown stark vereinfacht. Er generiert mithilfe von pandoc und LaTeX auch verschiedene Formate wissenschaftlicher Texte.
Abb. 3: Anpassungen der Ausgabe mit pandoc sind in Zettlr schon vorgesehen.
Wie Abb. 3 zeigt, lassen sich die Optionen für pandoc anpassen, was schon recht viel Flexibilität für die Ausgabe bringt. Wir würden uns nun wünschen, dass die erweiterten Einstellungen von Zettlr beliebige Befehle für den Export erlauben, sodass wir hier auch unser Dockerkommando platzieren können. Denn dann wäre Zettlr nicht nur die Schreibumgebung für Autor:innen, sondern auch die clientseitige Produktionsumgebung für Herausgeber:innen. Die Arbeit in GitLab wäre von hier an optional und könnte die Lernkurve noch einmal in kleinere Steigungen herunterbrechen.
$ docker run --rm -v $PWD:/data -u $(id -u):$(id -g) swapfire build/outfile.{html,pdf}
Snippet 1: Das Kommando, mit dem wir auf Basis des Docker-Images HTML und PDF aus Markdown bauen.
Denkbar wären dann auch noch weitere Plugins bzw. Optionen für den freien Editor: Die eingangs geschilderte Idee, Metadaten aus OJS zu saugen, um sie für die Produktion mit pandoc/pandoc-scholar zu nutzen, ließe sich ggf. auch in Zettlr einbauen. Das freie Malprogramm GIMP bspw. hat so ein Menü, über das beliebige Skripte auf die API von GIMP angewendet werden können. Dies wäre für Zettlr auch denkbar, um die GUI nicht unnötig zu überfrachten.
Fazit
Ohne Frage ist die Umstellung für das Schreiben mit Markdown, Zotero, BibTex, pandoc, LaTeX und einem Editor, der nicht Word ist, für viele Kolleg:innen eine große Herausforderung. Diese Tools lose auf dem eigenen Rechner zu kombinieren, dauert und muss auf den unterschiedlichen Betriebssystemen auch nicht immer reibungslos vonstatten gehen. Dazu kommt, dass viele Autor:innen und Herausgeber:innen gar nicht über die Rechte verfügen, auf ihren Dienstrechnern so umfangreiche Installationen und Konfigurationen durchzuführen. Möglichst viele der beteiligten Komponenten zu kapseln, könnte hier helfen. Docker jedenfalls ist für mich ein Schritt in diese Richtung, die Electron-Plattform, auf der Zettlr basiert auch.
