OAPK Daten

Transformation der jährlichen OAPK-Daten in OpenAPC

Einleitung

Das Forschungszentrum Jülich (FZJ) führt im Auftrag der DFG ein Monitoring des laufenden DFG-Förderprogramms "Open Access Publikationskosten" durch. Teilnehmende Einrichtungen sind dabei verpflichtet, Kostendaten für geförderte OA-Publikationen jährlich an das FZJ zu melden (die Meldung weiterer, nicht durch die DFG geförderten Publikationen ist optional ebenfalls möglich). Im Zuge der Dateneinreichung können die Institutionen dabei per Opt-In festlegen, dass die Kostendaten durch das FZJ auch an OpenAPC weitergegeben werden, wodurch eine doppelte Meldung der Daten an zwei Empfänger vermieden werden soll.

Übersicht

Bereits frühzeitig wurde die Entscheidung getroffen, dass die Weitergabe der Daten an OpenAPC im openCost-Format stattfinden soll. Dieses Metadatenformat wird im gleichnamigen, ebenfalls DFG-geförderten Projekt entwickelt und wurde speziell für die Darstellung und Übertragung von publikationsbezogenen Kostendaten entworfen. OpenAPC ist in die Entwicklung des Schemas sowohl personell als auch organisatorisch involviert und auch mit Jülich wurde bei der Fortenwicklung eng kooperiert.

Ein zu lösendes Problem stellt dabei die Transformation der Daten dar. Das openCost-Format ist XML-basiert, da es grundsätzlich maschinenlesbar und im Speziellen über eine OAI-PMH-Schnittstelle durch Repositorien auslieferbar sein soll (Beispiel: Repositorium der Universität Regensburg). Sowohl Jülich als auch OpenAPC verarbeiten bzw. erheben ihre Daten hingegen in Tabellenform, was auf beiden Seiten eine Transformation nötig macht. Das FZJ wandelt die finalisierten und aufbereiteten Kostendaten daher in eine große XML-Datei um und übermittelt diese an OpenAPC, die Verwendung eines Repositoriums zum Harvesting der Daten ist dabei bis auf Weiteres nicht vorgesehen, aber prinzipiell jederzeit möglich. Die Übertragungen sind dabei jeweils nicht kumuliert: eine Datenmeldung enthält ausschließlich diejenigen Daten, die das FZJ im entsprechenden Jahr gesammelt hat, aber nicht die aus vorherigen Jahrgängen.

Auf OpenAPC-Seite muss diese Datei in der Folge analysiert und die enthaltenen Publikationen in CSV-Tabellen umgeformt werden, damit sie mit den etablierten Anreicherungsroutinen weiterverarbeitet werden können. Publikationen, die direkt mit Kosten verknüpft sind (etwa Artikel in Gold-OA-Zeitschriften mit APCs) sind dabei einfach zu verarbeiten: Im Wesentlichen müssen die für OpenAPC relevanten Metadaten (Kosten, Einrichtung, DOI...) aus jedem publication-Element der XML-Struktur extrahiert und in CSV-Zeilen umgeformt werden. Eine größere Schwierigkeit stellt hingegen der Umgang mit Artikeln in hybriden Zeitschriften dar, die unter einem der DEAL-Verträge veröffentlicht wurden. Bei diesen Einträgen sind die OA-Kosten nicht direkt mit einer Publikation verknüpft. Zwar gibt es mit der sogenannten PAR-Fee eine theoretische Bezugsgröße für die Kosten eines hybriden Artikels, diese stimmen jedoch aufgrund der speziellen Modalitäten der DEAL-Zahlungen üblicherweise nicht mit den tatsächlich angefallenen Kosten einer Einrichtung überein. OpenAPC verwendet daher an dieser Stelle bereits seit mehreren Jahren ein anderes Berechnungsverfahren, bei dem die Vorauszahlungssumme einer Einrichtung für einen DEAL-Vertrag (inklusive möglicher Nachzahlungen und Rückerstattungen) durch die Anzahl der publizierten Artikel in hybriden Zeitschriften geteilt wird. Dieser Betrag wird anschließend als sogenannte "Equivalent APC" (EAPC) allen betreffenden Artikeln als Kosten gleichermaßen zugeteilt (Eine genauere Beschreibung des Verfahren findet sich hier).

Im opencost-Format wurde diese Art der Kostendarstellung bereits früh berücksichtigt. Sie lässt sich modellieren, indem die Kosten für einen Vertrag in ein sogenanntes contract-Element aufgenommen werden, wo sie innerhalb einer invoice_group abgelegt werden. Die zugehörigen Publikationenen werden anschließend mit dieser invoice_group verknüpft, indem auf beiden Seiten eine eindeutige group_id als Identifier eingetragen wird. Das FZJ nutzt diese Vorgehensweise, um Kosten für Transformationsverträge im openCost-XML an OpenAPC zu übermitteln, wobei auf OpenAPC-Seite lediglich die DEAL-Verträge weiterverarbeitet werden.

Workflows und Skripte

Die vom FZJ übermittelten XML-Dateien werden grundsätzlich im Datenverzeichnis opencost_oapk abgelegt, jeweils unterteilt nach Jahrgängen. Jede Datei wird danach noch einmal aufgeteilt, und zwar so, dass jeweils zwei resultierende XML-Strukturen entstehen: Eine enthält ausschließlich openCost-Elemente von Typ publication, die andere solche von Typ contract (die Gründe dafür werden später erläutert). Für den Jahrgang 2022 wurde zu einem späteren Zeitpunkt eine gesonderte contract-Datei durch Jülich nachgeliefert, dies ist damit begründet, dass die 2022er-Daten ursprünglich in einem vorläufigen openCost-Format übertragen wurden, welches mit der finalen Variante nicht mehr kompatibel ist.

Zur Verarbeitung der Daten kommen zwei Python-Dateien zum Einsatz: Das Modul opencost_toolkit_v2.py enthält grundlegende Routinen zur Verarbeitung von openCost-XML, dazu gehören etwa die Extraktion von Publikations- und Vertragsmetadaten, die Zuweisung von Kosten zu Publikation gemäß dem oben beschriebenen "EAPC"-Prinzip oder die formale Validierung von openCost-XML. Das Toolkit dient dabei nicht nur der Transformation der OAPK-Daten, sondern kommt grundsätzlich bei der Verarbeitung des openCost-Formats zum Einsatz, etwa beim Harvesting aus Repositorien. Speziell der Transformation der OAPK-Daten dient hingegen das Skript transform_opencost_xml.py. Seine Hauptaufgaben, von denen einige in den folgenden Abschnitten im Detail erläutert werden, sind:

• Aufruf der relevanten Toolkit-Funktionen
• Auflösung der ROR-IDs zu sprechenden Institutionsnamen
• Ausfiltern von Publikationen, die durch OpenAPC nicht verwendbar sind.
• Generierung von CSV-Dateien zur Weiterverarbeitung, unterteilt nach Institution und Datentyp
• Generierung von textuellen Update-Anweisungen zur Behandlung von DEAL-Daten (s.u.)
• Generierung einer Log-Datei, um insbesondere die Filterung von Datensätzen langfristig nachvollziehbar zu machen.

Wichtig ist, dass das Skript grundsätzlich mit einer beliebigen Anzahl von übergebenen XML-Dateien aufgerufen werden kann. Informationen beispielsweise zu Verträgen und Publikationen können so miteinander verknüpft werden, auch wenn sie sich in unterschiedlichen Eingabedateien befinden.

Filterung von Publikationen

Nicht alle Publikationen, die vom FZJ gemeldet werden, sind zur Übernahme in die OpenAPC-Datensammlungen geeignet. Folgende Punkte stehen einer Aufnahme entgegen und führen dazu, dass die entsprechende Publikation durch das Transformationsskript ausgefiltert wird:

• Kostenteilung: im openCost-Format können Publikationen, bei denen die Kosten unter mehreren Einrichtungen aufgeteilt wurden, entsprechend markiert werden (Feld external_costsplitting). Ist das der Fall, wird der Eintrag ausgefiltert, da OpenAPC grundsätzlich immer die vollständigen Kosten verzeichnen will, die für eine OA-Publikation angefallen sind.
• Nicht unterstützte Publikationsarten: OpenAPC aggregiert zur Zeit ausschließlich OA-Publikationskosten zu Zeitschriftenartikeln und Monographien. Andere Publikationsarten wie etwa Konferenzbeiträge oder Datenpublikationen werden daher ebenfalls ausgefiltert, maßgeblich ist hierfür die Angabe im openCost-Feld publication_type.
• Keine Kosten auf Publikationsebene: Publikationen mit APC-Kosten von 0€ werden in OpenAPC grundsätzlich nicht verzeichnet, daher werden Einträge nicht übernommen, denen auf Publikationsebene keine Kosten von Typ gold-oa oder hybrid-oa zugeordnet wurden. Die einzige Ausnahme bilden die erwähnten Artikel in hybriden DEAL-Zeitschriften, bei denen nachträglich eine EAPC berechnet und zugewiesen wurde.
• Transformationsverträge: Hier können unterschiedliche Konstellationen auftreten, die zu einer Filterung eines Eintrags führen. Hat beispielsweise ein Artikel in einer hybriden Zeitschrift Kosten von 0€, ist aber mit einem anderen Vertrag als DEAL verknüpft, führt dies ebenfalls zu einer Löschung, da das EAPC-Prinzip zur Zeit explizit nur bei DEAL angewendet wird. Bei einem hybriden DEAL-Artikel kann wiederum eine Filterung ausgelöst werden, wenn diesem wieder Erwarten auf Publikationsebene APC-Kosten zugewiesen wurden - dies ist gemäß der DEAL-Mechanismen eigentlich nicht möglich und deutet auf einen Datenfehler hin.

Die folgende Übersicht zeigt die oben beschriebenen Abläufe als Flowchart:

Um diese Löschungen auch nachträglich transparent zu dokumentieren, kommt die Log-Datei des Skripts zum Einsatz. Auf der Log-Stufe WARNING und niedriger werden dabei alle Löschungen dokumentiert, daher wird das Skript bei einer Live-Transformation immer mit dieser Stufe aufgerufen und die generierte Log-Datei danach mit in das Ausgabeverzeichnis im Git aufgenommen.

DEAL-Daten

Wie erwähnt sind die unter den DEAL-Verträgen veröffentlichten hybriden OA-Publikationen die einzigen Einträge, für die mittels EAPC-Kalkulation eine Umrechnung von Vertragskosten auf einzelne Artikel stattfindet. In der Praxis ist dieser Vorgang der komplexeste Aspekt der OAPK-Verarbeitung, was insbesondere auf die folgenden Punkte zurückzuführen ist:

• DEAL-Daten wurden bereits vor Beginn des OAPK-Monitorings durch OpenAPC aggregiert, was durch individuelle Meldungen der Einrichtungen geschah. Eine "Mischung" dieser beiden Berichtswege für dieselbe Einrichtung ist aus Sicht der Datenhaltung kompliziert und sollte vermieden werden.

• Im Normalfall meldet eine Einrichtung für einen Jahrgang die Kosten für einen DEAL-Vertrag und zusätzlich eine Liste der publizierten Artikel in hybriden Zeitschriften (die gemäß der OAPK-Instruktionen seit 2023 direkt aus den offiziellen PABA-Abrechnungen der MPDL Services GmbH stammen sollte), woraus OpenAPC mittels der EAPC-Kalkulation die Kosten pro Artikel berechnen kann. Ein Problem ergibt sich nun aber, wenn sich diese Kosten im Nachhinein ändern: Eine Institution kann Rückerstattungen von der MPDLS erhalten, wenn sie in Relation zur PAR Fee pro Artikel zuviel gezahlt hat, sie kann sich aber ebenso entschließen, bei einer Unterdeckung der Kosten freiwillig einen gewissen Betrag nachzuzahlen. Diese Beträge können zwar ebenfalls an das FZJ gemeldet werden und erreichen somit OpenAPC, aber üblicherweise nicht im selben Jahr.

• Ebenso ist es möglich, dass eine Einrichtung nachträglich Artikel meldet, die einen bereits berichteten DEAL-Jahrgang ergänzen. Aus diesem und dem vorherigen Punkt ergibt sich somit jeweils die Problematik, dass sich die errechneten EAPCs ändern können und somit auch für Bestandsdaten angepasst werden müssen.

• Die gemeldeten Daten enthalten fast unvermeidlich Fehler, die teilweise erst bei der Verarbeitung durch OpenAPC auffallen, wie etwa Artikelmengen, die komplett einem falschen Jahr zugeordnet wurden oder fehlerhafte Kostendaten. Zu letzterem Punkt gehört als Beispiel die Situation, bei der eine Einrichtung - wie oben beschrieben - DEAL-Nachzahlungen melden will, aber anstatt lediglich den noch fehlenden Betrag nachzumelden, wird die sich nun neu ergebene Gesamtsumme ein zweites Mal berichtet, was bei der automatisierten Verarbeitung zu falschen Summierungen führt. Das Problem ist hier, dass in solchen Fällen keine etablierten Korrekturmechanismen existieren. Zwar könnte OpenAPC diese Funde an das FZJ zurückmelden, dort müssten die Fälle dann aber zunächst geprüft und korrigiert werden. Anschließend wäre es nötig, eine neue XML-Datei zu generieren und zu übermittelt, die dann durch OpenAPC wiederum transformiert werden müsste. Dieses Verfahren wäre aufwändig und zeitraubend.

Um diese Probleme auf Seiten von OpenAPC handhabbar zu machen, wurden folgende Lösungen erarbeitet:

• Bei der Datentransformation werden auch vorherige Jahrgänge berücksichtigt, allerdings nur in Bezug auf die Vertragskostendaten. Hierin liegt die oben beschriebene Auftrennung der XML-Dateien in einen "publication"- und einen "contract"-Teil begründet: Soll ein neuer OAPK-Jahrgang transformiert werden, so wird das Skript transform_opencost_xml.py mit den Publikationsdaten lediglich für den neuen Jahrgang, aber zugleich mit den Vertragsdaten für den aktuellen und alle bisherigen Jahrgänge aufgerufen. Zwar sind die nachgereichten Korrekturbeträge in diesen Fällen nicht innerhalb derselben invoice_group abgelegt, wie es der openCost-Standard eigentlich vorsieht, durch einen Abgleich der sonstigen Metadaten (Institutionsname/DEAL-Publisher/Vertragsjahr) gelingt die Zuordnung aber dennoch. Grundsätzlich wäre es möglich, auch die in den Vorjahren berichteten Publikationsdaten jedes Mal vollständig neu zu transformieren, dagegen spricht jedoch, dass all diese Daten dann auch jedes Mal erneut durch die üblichen OpenAPC-Anreicherungsroutinen laufen müssten, was zeitaufwändig ist und zudem bereits korrigierte Fehler jedes Mal wiederherstellen würde, was den Arbeitsaufwand vervielfacht.

• Da eine Korrekturschleife über das FZJ zu zeitraubend und aufwändig wäre, wird ein Mechanismus benötigt, über den OpenAPC auch lokal und nach direkter Rücksprache mit den Einrichtungen Datenkorrekturen vornehmen kann. Es wäre jedoch problematisch, hierzu direkt Änderungen in den übermittelten XML-Dateien vorzunehmen, da diese nicht zuletzt ein offizielles Projektergebnis repräsentieren. Aus diesem Grund behält sich OpenAPC die Option vor, nachbearbeitete Kopien der übermittelten bzw. transformierten Dateien anzulegen und mit diesen weiterzuarbeiten, während die Originaldaten unverändert bleiben. Diese Kopien sollten erst bei Bedarf angelegt und mit dem Suffix _postprocessed markiert werden, um ihren Charakter deutlich zu machen. Hierbei sind wiederum zwei Fälle zu unterscheiden: Da Vertragsdaten ausschließlich in den XML-Dateien vorgehalten werden, ist es in Fällen wie dem oben geschilderten (Falsche Meldung als Gesamtsumme) nötig, die Änderung direkt in der XML-Struktur durchzuführen. Hierzu muss also eine _postprocessed-Kopie der _contracts.xml angelegt werden, in welcher die Korrekturen vorgenommen werden, anschließend müssen die Daten für die betroffene Einrichtung einmalig neu transformiert werden. Bei zukünftigen Jahrgängen muss dann ebenfalls immer mit dieser angelegten Kopie gearbeitet werden (siehe vorheriger Punkt). Bei Fehlern in den Publikationsdaten selbst ist mehr Spielraum gegeben, da diese Daten bei zukünftigen Jahrgängen nicht mehr einbezogen werden. Es kann also analog mit einer Kopie der _publications.xml und anschließender Neutransformation gearbeitet werden, alternativ ist es auch möglich, die erzeugten CSV-Dateien nachträglich zu bearbeiten. Letzteres ist insbesondere dann zu empfehlen, wenn größere Korrekturen vorgenommen werden müssen, was sich im XML nur mit viel Aufwand ändern lässt. Unabhängig von der gewählten Herangehensweise müssen auch hier die zu modifizierenden Dateien in jedem Fall kopiert und die Kopien mit dem _postprocessed-Suffix kenntlich gemacht werden.