Entwurf und Implementierung

Zu Beginn des Projektes existierte ein Prototyp mit vier Hauptseiten des Webportals. Dieser wurde mit Angular erzeugt und enthielt folgende Seiten:

1. publications (Anzeige von Publikationen),

2. publication (Anzeige und Bearbeitung einer Publikation),

3. authors (Anzeige aller Autor*innen),

4. import (Übersicht über die verschiedenen Importe).

Ein detaillierter Entwurf der Dezernentin für Medienbearbeitung zu den gewünschten Importen und des Workflows lag bereits zu Projektbeginn vor. Anhand der Erfahrungen mit der bisherigen Bearbeitung, weiteren Gesprächen und dem Entwurf wurden gemeinsam die gewünschten Funktionen identifiziert, die folgend näher beschrieben werden.

Damit Autor*innen bearbeitet und manuell hinzugefügt werden können, wurden neue Formulare erstellt. Im Rahmen der Formularbearbeitung werden alle Felder bis auf die ID mit Informationen befüllt. Zudem musste es die Möglichkeit geben, Autor*innen zu löschen. Um versehentliches Löschen zu verhindern, erfolgte die Implementierung einer Bestätigungsabfrage.

Das manuelle Hinzufügen von Publikationen ist ebenfalls möglich. Dieser Use-Case kann vorkommen, wenn Veröffentlichungen dem Dezernat Medienbearbeitung per Mail mitgeteilt werden.

Weiterhin wurden Importe anhand der im Entwurf vorhandenen Beispiele programmiert und dafür nach Möglichkeit APIs genutzt. Insbesondere dem Import der Daten von ORCID wurde eine hohe Priorität zugeordnet.

Für angekündigte Veröffentlichungen gibt es die Funktion einer sogenannten Temp-Tabelle. Dort werden Publikationen gespeichert, welche noch nicht endgültig publiziert sind. Sobald dies umgesetzt war, wurde eine Funktion programmiert, mit der diese Daten in die Produktiv-Tabelle verschoben werden konnten.

Die Implementierung eines Authentifizierungsverfahrens schafft die Möglichkeit, ein späteres Rechtemanagement zu etablieren. Präferiert wird das Login über Single-Sign-On (SSO) mit Shibboleth über den Identity Provider (idp) der Universität Potsdam. Zurzeit ist nur eine einfache lokale Authentifizierung realisiert.

Für die schnelle Auswertung der Daten erfolgt der dynamische Abruf vordefinierter Reports. Diese umfassen:

• die Top 20 der Verlage auf Basis der Anzahl an Publikationen,

• die verwendeten Lizenzen (z. B. Transformationsverträge, DEAL),

• die Zahl der Veröffentlichungen pro Fakultät,

• der OA-Status der Publikationen und zusätzlich pro Fakultät sowie

• die Angabe, bei wie vielen Veröffentlichungen der Corresponding Author von der UP ist.

Zusätzlich bestand der Wunsch nach einer grafischen Darstellung der genannten Reports.

Server

Um das Webportal zu hosten, wurde eine virtuelle Maschine in der Virtualisierungsumgebung der UB installiert. Auf dieser wurden ein Nginx Webserver, Node.js und eine MariaDB SQL-Datenbank eingerichtet.

Datenbank

Zu Beginn des Projektes existierten beim Prototyp die drei Tabellen publications, author und pub-author. Dort können sowohl die Publikation, Autor*innen als auch die Zuordnung zwischen Autor*in und Publikation hinterlegt werden.

Um die Lizenzen abbilden zu können, wurde eine weitere Tabelle hinzugefügt und über die ID mit der Publikationentabelle verknüpft.

Anschließend wurden die anderen Tabellen anhand der Anforderungen angepasst bzw. erweitert. So wurde in der Tabelle publication das Feld temp hinzugefügt, um die noch nicht veröffentlichten Publikationen zu kennzeichnen. Diese werden dann separat in der Weboberfläche angezeigt und können bei Bedarf durch Ändern des temp-Wertes zu den auszuwertenden Datensätzen hinzugefügt werden.

Des Weiteren wurde das Attribut pub_type in der Tabelle publication ergänzt. So kann die Art der Publikation (z. B. journal-article, book-chapter) erfasst werden.

Backend

Für den Zugriff auf die Datenbank von Output.UP wurden mit dem Node.js-Server und dem Express-Framework eigene APIs angelegt. Mit diesen können Daten abgerufen, verändert, eingefügt und gelöscht werden.

Das komplette Datenmodell wird mit dem über npm installierten Paket TypeORM in Typescript erstellt. Zunächst werden die einzelnen Tabellen (entities) erzeugt, indem für jede zu generierende Tabelle eine eigene Datei mit der Definition des Namens und der einzelnen Felder angelegt wird. Mit der Eintragung der Zugriffsdaten erfolgt dann beim Starten des Node.js Backends, falls noch nicht vorhanden, die automatische Erzeugung aller Tabellen mit dazugehörigen Attributen und Eigenschaften in der Datenbank.

Durch diesen Ansatz können auch unterschiedliche relationale Datenbankmanagementsysteme (z. B. MarieDB, MySQL oder PostgreSQL) benutzt werden, solange ein entsprechender Treiber dafür vorhanden ist.

Frontend

Mithilfe des Angular Framework wurde das Webportal weiterentwickelt. Durch npm wurden u. a. Module für die Gestaltung der Oberfläche (Material Design), den Import von csv-Dateien sowie für den Abruf bei APIs eingebunden.

Importe

Die Importe sind zentraler Bestandteil der Anwendung. Die Auswahl der Importe und der jeweiligen Felder erfolgte im Projektteam nach fachlichen und inhaltlichen Kriterien. Für die Importe werden nur die Publikationen der aktuellen Jahresscheibe betrachtet. „Die […] gesammelten Publikationsdaten sind für die Verhandlung zukünftiger Transformationsverträge, die Abschätzung des Mittelbedarfs und die Zweitveröffentlichung von zentraler Bedeutung.“^[5] Anhand des Digital Object Identifier (DOI) und des Titels wird automatisch abgeglichen, ob eine Publikation bereits vorhanden ist. Dies dient der Vermeidung von Dubletten. Eine Ausnahme bilden Springer, MDPI und Taylor & Francis. Aufgrund der Erfahrungen im Dezernat Medienbearbeitung wird bei diesen Anbietern eine höhere Datenqualität erwartet. Aus diesem Grund werden schon existierende nicht abschließend geprüfte Daten in Output.UP teilweise überschrieben. Als abgeschlossen gelten Publikationen, welche die Bearbeiter*innen begutachtet, gegebenenfalls modifiziert und abschließend als „gelockt“ markiert haben. Ab diesem Zeitpunkt werden in diesen Datensätzen keine Informationen mehr angereichert oder bearbeitet.

Für die Importe werden je nach Quelle csv- oder Bibtex-Dateien sowie die APIs von ORCID und Crossref genutzt.

Zunächst werden die Dateien von den Bearbeiter*innen auf der entsprechenden Plattform herunter- und mithilfe eines Formular in Output.UP hochgeladen. In diesem Prozess werden die Daten mit dem Paket „papaparse“ zeilenweise eingelesen.

Im Anschluss wird anhand der DOI geprüft, ob die ermittelten Daten bereits in der Datenbank vorhanden sind. Sollte dies der Fall sein, werden bestimmte Felder überschrieben, sofern es sich beim Anbieter um Springer, MDPI und Taylor & Francis handelt. Alle anderen Dubletten werden verworfen. Zudem wird überprüft, ob das Publikationsjahr dem auszuwertenden Jahr entspricht.

Dabei ist für jeden Import die Definition der Felder fest im Code programmiert. Diese werden dann dem Datenmodell zugewiesen.

Problematisch ist es und im Testbetrieb bereits vorgekommen, wenn sich an der Struktur der csv-Datei etwas ändert. In diesem Fall ist ein korrekter Upload nicht mehr möglich. Daher ist eine Anpassung der Konfiguration direkt im Code notwendig. Um bei solchen Änderungen in Zukunft einfacher reagieren zu können, ist geplant, die Felddefinitionen in der Weboberfläche konfigurierbar zu machen.

Import Bibtex-Dateien

Im ersten Schritt werden die Bibtex-Dateien ebenfalls über ein Formular hochgeladen und im Anschluss mit dem Paket bibtex-parse-js ausgewertet.

Bei Importen kommt es jedoch zu Problemen, wenn die Struktur der Eingangsdateien nicht valide ist. Fehlende Zeichen oder eine falsche Formatierung sind meist die Fehlerquelle.

Deshalb wird bei etwaigen Fehlern angezeigt, bei welcher Datei diese aufgetreten sind. Aufgrund der Größe der Dateien und der vielschichtigen Ursachen wurde zunächst vereinbart, dass eventuelle Fehler in den Dateien von den Kolleg*innen manuell korrigiert und im Anschluss erneut hochgeladen werden.

Import über APIs

Beim Import über APIs werden die Daten automatisiert abgerufen. Dadurch ist es nicht notwendig, Publikationen von Quellen zu exportieren und wieder in Output.UP hochzuladen. Somit kann das Einspielen schneller und einfacher umgesetzt werden.

Bei Crossref und ORCID kann der Import über eine API durchgeführt werden. Dafür müssen je nach Anforderung unterschiedliche Parameter übergeben werden^[6].

Ein Problem, welches sich beim Abrufen ergeben kann, ist, dass der Zugriff aufgrund einer zu hohen Anzahl an Anfragen geblockt wird. Dies dient zum einen der Sicherheit und zum anderen dem Schutz vor Überlastung. Durch Einsatz des Pakets smart-request-balancer wird dieses Problem verhindert. In diesem können sogenannte Rules konfiguriert werden, die bestimmen, wie viele Anfragen pro Sekunde an eine API gesendet werden.

Anreicherung der Datensätze

Die Anreicherung von vorhandenen Datensätzen wird anhand der DOI durchgeführt. Diese dient als eindeutiger Identifier, um Informationen abzurufen und einzubinden. Je nach Vorauswahl können sowohl alle als auch nur einzelne Publikationen angereichert werden. Durch Bearbeiter*innen gelockte Publikationen werden in diesem Prozess nicht verändert. Bei diesen ist die inhaltliche Prüfung abgeschlossen und eine Modifikation der Daten kann verhindert werden.

Crossref

Für die Anreicherung wird erneut die Crossref REST API^[11] genutzt. Dabei werden Daten der Autor*innen mit Name, Affiliation und ORCID gespeichert. Des Weiteren werden die Informationen Titel, Verlag, E-ISSN, Print-ISSN, Journal, Veröffentlichungsdatum – falls noch nicht vorhanden – in der Datenbank ergänzt. Mithilfe der eingespielten Informationen zur ORCID kann anschließend ein erneuter Import über ORCID durchgeführt werden, um weitere noch nicht vorhandene / erfasste Publikationen zu identifizieren.

Unpaywall

Über Unpaywall werden Informationen zu Open Access, wie z. B. die OA-Lizenz oder der OA-Status, abgerufen. Dafür wird die REST-API https://api.unpaywall.org/v2^[12] verwendet. Jede Anfrage muss eine E-Mail-Adresse als Parameter enthalten.^[13] Damit kann bei Fehlern in der Clientanwendung die Person, welche die Anfrage stellt, von Unpaywall kontaktiert werden. Der Zugriff ist auf 100.000 Aufrufe pro Tag eingeschränkt. Aufgrund der zu erwartenden Anzahl an Datensätzen in Output.UP (maximal 3.000) ist dies jedoch kein limitierender Faktor.

Authentifizierung

Die Implementierung an das SSO der Universität Potsdam mit dem Paket passport-saml wurde zurückgestellt. Für den Testbetrieb wurde daher zunächst eine simple Authentifizierung über eine htpasswd- und htaccess-Datei konfiguriert. Dadurch haben zwar alle Nutzer*innen die gleichen Rechte, jedoch findet die Bearbeitung im Moment nur intern innerhalb des Dezernates Medienbearbeitung durch ausgewählte Kolleg*innen statt.

Statistiken

Um die geforderten Charts übersichtlich zu programmieren, wurde für jede Statistik eine eigene Angular-Komponente generiert. Diese werden in einer übergeordneten Dashboard-Komponente zusammengefügt. Dadurch ist der jeweilige Code kürzer und leichter zu pflegen. Zudem sind eventuelle Fehler an einzelnen Komponenten isoliert.

Die grafische Darstellung der Statistiken (siehe Abbildung) wird mit der JS-Bibliothek von Highcharts^[14] umgesetzt, da für den Hochschul- und Non-Profit-Bereich eine Gratislizenz angeboten wird.^[15] Diese ist jedoch an den Ersteller dieser Arbeit als Entwickler gebunden und müsste bei einer Nachnutzung des Projektes von anderen Organisationen neu beantragt werden.

Highcharts bietet für die Funktionserweiterung diverse Module an. Für dieses Projekt wurde das exporting-Modul installiert. Damit können Charts über eine Schaltfläche in die Formate pdf, png und svg exportiert werden. Im Normalfall wird der Export auf den Servern von Highcharts durchgeführt. Da es sich teilweise um sensible Informationen handelt, wird jedoch die Erweiterung offline_exporting genutzt. Dadurch generiert der Client den Export.

Abb.:

Beispiel Statistik OA-Category (erstellt mit highcharts.com).

Erstes Jahr im Testbetrieb

Mit der ersten Version von Output.UP wurde im Jahr 2020 gleich der Testbetrieb gestartet. Eine parallele Erfassung in den alten Excel-Dateien fand nicht statt.

Die Kolleg*innen gaben bereits in den ersten Wochen Feedback zur Usability (Formulargestaltung, Darstellung der Publikationsübersicht etc.) und inhaltlichen Themen, um das System und die Abläufe weiter zu verbessern. Diese und andere Anpassungen sowie Bugfixes wurden kontinuierlich in das System eingepflegt.

Probleme, die im Testbetrieb identifiziert werden konnten, waren u. a. das Fehlen von DOIs und / oder Titeln bei Importen. Deshalb wurden weitere Prüfroutinen in den Importprozess für die Löschung entstandener Dubletten implementiert. Jedoch lassen sich nicht alle Fehler dieser Art abfangen. Dadurch müssen die Mitarbeiter*innen gelegentlich Dubletten manuell bereinigen.

Die Zuordnung von Autor*innen und Publikationen ist ein weiterer wichtiger Punkt. Im Moment werden für jede Veröffentlichung die entsprechenden Autor*innen in der Datenbank gespeichert. Das führt dazu, dass aufgrund eines fehlenden Identifiers bei Personen diese mehrfach in der authors-Tabelle eingetragen sind. Hierfür wird eine konzeptionelle Lösung erarbeitet.

Neben den vorhandenen Statistiken wurde noch der Bedarf für zwei weitere ermittelt. In diesen werden die Auswertung der Verteilung der Datenquellen sowie der Kosten pro Fakultät dargestellt. In diesem Zusammenhang sind auch die unterschiedlichen Benennungen der Verlage bei den Importen aufgefallen. Es wird deshalb nun eine Konkordanz erstellt, um diese in Zukunft bereits bei der Einspielung zu bereinigen.

Im Rahmen des Jahresübergangs werden die erfassten Daten in ein Archiv gespeichert, da in Output.UP immer nur eine Jahresscheibe betrachtet werden soll. Alle vorhandenen Statistiken können jedoch auch weiterhin mit den Informationen aus vorherigen Jahren abgefragt werden. Die entsprechenden Funktionen dafür werden zurzeit programmiert.

Ausblick

Im System werden in Zukunft noch einige Teilaspekte angepasst. Dazu gehören die schon erwähnte Autor*innenzuordnung, weitere Importe, aber auch die Authentifizierung mittels SSO sowie allgemeine Konfigurationsmöglichkeiten. Außerdem soll der momentan noch vom DDD manuell durchgeführte Jahresübergang in Output.UP so automatisiert werden, sodass die Mitarbeiter*innen die Publikationsdaten der aktuellen Jahresscheibe selbstständig archivieren können. Zudem ist geplant, zu den einzelnen Datensätzen die Kostenarten (z. B. page charge, colour charge) zu erfassen.

Im Rahmen einer Kooperation mit der Universitätsbibliothek der Otto-von-Guericke-Universität Magdeburg wird Output.UP gemeinsam weiterentwickelt. Geplant ist eine Veröffentlichung auf einem Git-Repository.

Um den Entwicklungs- und Deploymentprozess weiter zu optimieren, wird ein CI / CD^[16] über GitLab getestet. Dadurch werden u. a. bei jedem Commit in GitLab mit vordefinierten Tests einzelne Funktionen getestet. Eine Überprüfung und automatische Anpassung des Coding Styles ist ebenfalls möglich. Tests in anderen Projekten wurden erfolgreich abgeschlossen und können auf Output.UP übertragen werden.