Ergebnisse der Online-Diskussionen

Das openCost-Team hat im März drei sehr fruchtbare Online-Veranstaltungen ausgerichtet, bei denen das Metadatenschema zur Erfassung von Kostendaten bei Zeitschriftenartikeln mit der Community diskutiert wurde. Wir möchten uns an dieser Stelle noch einmal für das rege Interesse sowie die vielen Anmerkungen und Anregungen zu unserem Schema bedanken. Die Ergebnisse der drei Online-Veranstaltungen sind hier zusammengefasst.

Externe Datenweitergabe und interne Datenverarbeitung

Während der Online-Diskussionen wurde der Wunsch an das openCost-Team geäußert, eine erweiterte Form des Schemas zu erarbeiten, mit dem man auch lokale bzw. interne Komponenten abdecken kann (z. B. lokale Komponenten aus SAP wie Differenzierung zwischen zentralen und dezentralen Zahlungen). Die interne Datenhaltung ist i.d.R. breiter als das, was ausgetauscht werden soll bzw. kann. Das geplante openCost-Schema dient zwar in erster Linie der externen Datenweitergabe, theoretisch könnte man aus dem openCost-Format aber auch ein Internformat ableiten, wenn es um bestimmte Elemente ergänzt wird (siehe: Issue 36).

Zusammenarbeit mit Folio

Inwieweit steht das Projekt mit Folio im Austausch? Beteiligen sich Kolleg*innen aus der Folio-Gruppe aktiv an den openCost-Diskussion und wenn ja, wer?

In Folio soll es künftig ein Modul geben, in dem man Open Access Publikationsgebühren aufnehmen kann. Dort soll das openCost Schema implementiert werden, diese Daten können dann über die OAI-Schnittstelle ausgegeben werden.

• Ansprechpartner Folio Leipzig: Björn Muschall (UB Leipzig)
• Ansprechpartnerin OA-Teilprojekt: Christina Prell (UB Regensburg)

Kostendaten im Repositorium oder im Bibliothekssystem

Es kam die grundsätzliche Diskussion auf, ob die Kostendaten im Repositorium oder im Bibliothekssystem hinterlegt werden sollten. Dabei wurde aus dem openCost-Team angemerkt, dass Kostendaten Teil der Metadaten eines Artikels seien. Daher sollten sie auch im Repositorium stehen, künftig könnten die Daten aber über das openCost-Format zwischen Bibliothekssystem und Repositorium ausgetauscht werden.

JSON

Ist künftig eine JSON-Repräsentation der Daten angedacht?
Wir möchten zunächst das XML-Schema entwickeln, da sich dieses insbesondere für den Austausch über OAI-PMH anbietet. Außerdem wollen wir die Diskussion nicht verkomplizieren, indem wir zwei Schemata zur Disposition stellen. In einem weiteren Schritt wollen wir das XML-Schema in ein JSON-Format umwandeln (siehe: Issue 41).

Transformationsverträge und Mitgliedschaften

Wie kann man derzeit die Zugehörigkeit zu Transformationsverträgen und Mitgliedschaften im Schema erfassen?
Der aktuelle Entwurf fokussiert sich auf gebührenpflichtige Einzelartikel. In einem nächsten Schritt beschäftigen wir uns damit, wie wir Transformationsverträge und Mitgliedschaften in das Schema integrieren können. Auf Artikelebene soll dies künftig über das Feld „part_of_contract“ angegeben werden können. Eine Schwierigkeit besteht derzeit noch dabei, Transformationsverträge eindeutig zu identifizieren, da nicht alle eine eindeutige ID aufweisen (z. B. ESAC-ID), auf die man sich beziehen kann und die im Schema hinterlegt werden können.

Sammelrechnung für Rahmenvertrag mit OA-Publishern

Wie wird mit solchen Sammelrechnungen umgegangen?
Solange die einzelnen Artikel einen konkreten Betrag aufweisen, ist dies unproblematisch, da eine Rechnungsnummer mehrfach angegeben werden kann (siehe: Issue 38).

DFG-Monitoring

Soll es in openCost auch die Möglichkeit geben, die Funding Number zu hinterlegen?
Hier besteht noch weiterer Diskussionsbedarf. Unsere vorläufige Überlegung ist, dass openCost den Kostenblock als Ergänzung zu anderen Formaten wie DataCite bildet. Die Funding-Information kann man über die DOI einholen. Von den Teilnehmenden wurde angemerkt, dass man sich nicht darauf verlassen sollte, die Funding-Informationen vollständig automatisiert zu erhalten (z. B. Crossref nicht vollständig). Daher sollte es die Möglichkeit geben, diese an einer Stelle per Hand nachzutragen. An welcher Stelle dies geschehen soll, steht auch noch zur Diskussion (siehe: Issue 39).

Teilkosten/Kostensplitting

Durch höhere Kosten wird das Thema Kosten-Splitting zukünftig immer wichtiger werden. Daher würden es viele der Teilnehmenden begrüßen, wenn openCost zumindest die Möglichkeit schaffen würde, Teilbeträge als solche zu kennzeichnen, ohne konkrete Summen nennen zu müssen.
Aus dem openCost wurde dazu angemerkt, dass man bei Teilbeträgen und -buchungen zunächst zwischen intern und extern unterscheiden müsse. Bei internem Kostensplitting meldet trotzdem nur eine Einrichtung den kompletten Betrag. Bei externem Splitting sei ein Vermerk zum Teilbetrag prinzipiell gut. Hier bestehe jedoch die Problematik, dass die einzelnen Institutionen in vielen Fällen gar nichts von einer Kostenteilung wissen. Ebenfalls ist häufig unbekannt, wie viele andere Einrichtungen ggf. noch gezahlt haben und wie die einzelnen Teilbeträge aussehen (siehe: Issue 2).

0-Wert/Voucher-Element

Können Artikel, Konferenzbeiträge und ähnliches, für die nichts bezahlt wurde, auch hinterlegt werden (inkl. Begründung)?
Prinzipiell spricht nichts dagegen, einen expliziten Nullwert in das Schema mit aufzunehmen. Man könnte beispielsweise ein Voucher-Element einführen. Mitgliedschaften etc., bei denen keine klassischen APCs berechnet werden und deshalb auch ein Nullwert angegeben werden müsste, werden dagegen künftig über das Feld „part_of_contract“ reguliert (siehe: Issue 35).

Zweitveröffentlichung

Würden die in den Metadaten verzeichneten Kosten der Erstveröffentlichung mitgeführt, wenn der Artikel auf einem institutionellen Repo zweitveröffentlicht wird?
Hier würde kein getrennter Eintrag erfolgen, da die Zweitveröffentlichung im Repositorium quasi eine Inventarisierung des Artikels darstellt. Die grüne Zweitveröffentlichung erfolgt dann ohne Kosten. Denkt man allerdings in Richtung Informationsbudget und Diamond OA sollten die Kosten für das Betreiben des Repos bzw. die technischen Infrastrukturen auch berücksichtigt werden. Hier bräuchten wir dann zusätzliche Kostentypen oder eine Möglichkeit, dies über „Mitgliedschaften“ abzubilden.

Terminologie

Zu „item“: In der Diskussion kam der Vorschlag „item“ in „invoice“ umzubenennen, da item mit einem Beitrag in einer Fachzeitschrift oder einem Buch verwechselt werden könnte.

Zum „type“-Attribut von „amount_paid“: Hier kam der Vorschlag die Begriffe zu vereinheitlichen: „cover“ sollte (genau wie „colour charges“ und „page charges“) „cover charges“ heißen. Außerdem wurde vorgeschlagen, den Begriff „charges“ in „charge“ umzubennen (siehe: Issue 45 und Issue 46). Außerdem brachte eine Teilnehmende einen Gegenvorschlag zur Bezeichnung der Kostentypen „apc“ und „hybrid-oa“ ein: „apc-full-oa“ und „apc-hybrid-oa“ (siehe: Issue 37).

Zum „oa_status“: Alternative Bezeichnungsvorschläge der Diskussionsteilnehmenden anstatt „open“, „hybrid“, „closed“: „open-full“, „closed“, „open-hybrid“ (siehe: Issue 37).

Bibliografischer Block „bibliographic_information“

Es wurde von Seiten des openCost Teams betont, dass der bibliografische Block nur eine Hilfskonstruktion ist, wenn es keine DOI gibt. Anstatt den bibliografischen Block weiter auszubauen, würden wir die Diskussion gerne in die Richtung lenken, wie man Publisher dazu bringt, für wissenschaftliche Publikationen standardmäßig DOIs zu vergeben.
Zum Feld „isPartof“: Aus der Community wurde angeregt, hier nach Möglichkeit IDs wie ISSNs mit anzugeben, da so eine eindeutigere Identifikation möglich sei. Außerdem wurde der Vorschlag gemacht, einen Minimumstandard an bibliografischen Angaben für diesen Block zu definieren, aber die Möglichkeit zuzulassen, alle bibliografischen Daten zu liefern. Für den Moment erscheinen die Angaben den Teilnehmenden als ausreichend, wenn das Schema weiter ausgebaut wird, müsse man jedoch überlegen, ob es Kontexte gibt, für die man weitere Felder wie Jahr, Autor etc. benötigt. Zudem wurde angemerkt, dass die Definition des Feldes als „required“ zwar für Zeitschriftenartikel Sinn mache, für andere Publikationstypen aber problematisch werden könnte (siehe: Issue 34).

Metadatenschema: Feld „institution“

Wird es eine Standardisierung der Institutionsnamen geben?
Eine Standardisierung ist für die Maschinenlesbarkeit nicht unbedingt relevant, wichtiger sind eindeutige IDs wie ROR. Die Angabe der ROR-ID wird jedoch nicht verpflichtend vorgeschrieben, sondern wird als primärer Institutions-Identifier empfohlen bzw. vorgeschlagen und stellt den Idealfall dar, da die ROR-ID angereichert werden kann.

In Bezug auf Parent-Child-Beziehungen zwischen Institutionen wurde gefragt, ob es einen Richtwert gibt. Sollen die Institutionen möglichst granular und kleinteilig angegeben werden oder lieber die übergeordnete Organisation?
Es soll die ROR-ID der Organisation angegeben werden, die bezahlt hat.

Metadatenschema: Feld „oa_status“

Anmerkung: Die Eigenschaft beschreibt die Eigenschaft der Zeitschrift und nicht des Artikels.

Zum Wert „hybrid“: In Bezug auf den Wert „hybrid“ wurde angemerkt, dass die Bezeichnung terminologisch nicht ganz sauber sei, da ein Artikel selbst nicht hybrid ist, sondern Open Access; zudem bestünde Verwechslungsgefahr mit der Benennung im bei Büchern. Hier meint der Begriff „hybrid“ oftmals OA digital und Print auf Papier. Im openCost Schema sind mit dem Begriff „hybrid“ derzeit nur OA-Artikel, die in hybriden Zeitschriften erschienen sind. Alle übrigen Artikel, die in hybriden Zeitschriften erscheinen erhalten den Wert „closed“.

Zum Wert open: Hier wurde vorgeschlagen, den Wert in „gold“ umzubenennen. Zudem wurde nachgehakt, ob das Feld überhaupt notwendig sei, wenn beim Kostentyp „apc“ und „hybrid-oa“ angegeben werden kann. Dazu merkte ein Teilnehmer an, dass er die Angabe des OA-Status an dieser Stelle für plausibel halte. Würde man nämlich z. B. nur eine Cover Charge o.ä. angeben, sei eine Angabe des OA-Status allein über Kostentypen nicht gegeben.

Diamond OA: Ist es angedacht, auch Diamond OA abzubilden? Es sollen auf jeden Fall Artikel mitaufgenommen werden können, für die man nichts bezahlt. Ob dieser Wert dann allerdings als Diamond OA bezeichnet wird, steht noch zur Diskussion, da verschiedene Definitionen von Diamond OA genutzt werden.

Metadatenschema: Feld „amount_paid“

Zum Kostentyp „vat“: Die Mehrwertsteuer ist ein eigener Kostentyp und kann mit dem vat-Element angegeben werden. Dazu erhielten wir die Rückmeldung, dass das vielen Teilnehmenden im Schema nicht deutlich genug wird bzw. dass dies in der Dokumentation besser herausgearbeitet werden sollte.
Zudem wurde zum Kostentyp vat noch angemerkt, dass im derzeitigen Schema nicht unbedingt ersichtlich wird, welcher Mehrwertsteuerbetrag zu welchem anderen Kostentyp gehört. Die Überlegung im openCost-Team ist nun, ob wir das im Schema stärker koppeln sollen und vielleicht Klammern bauen, um das explizit auszuweisen. Um das Schema nicht zu verkomplizieren, ist es derzeit nicht vorgesehen.

Zum Kostentyp „other“: Bankgebühren müssten derzeit unter „other“ subsumiert werden.

Metadatenschema: Feld „date_paid“

Hier wurde diskutiert, ob die Angabe „date_invoice“ nicht sinnvoller wäre als das „date_paid“. Aus Arbeitssicht/-aufwand sei das Hinterlegen des Rechnungsdatums handlicher, aus Kostenlogik sei jedoch das Datum des Mittelflusses das wichtigere (Haushaltsjahrbrüche etc.). So wurde der Wunsch geäußert, beide Daten konkret erfassen zu können, um Missverständnisse zu vermeiden und auch mit Blick auf das DFG-Monitoring (siehe: Issue 17).
Eine weitere Möglichkeit wäre es, zwei optionale Datumsfelder zu definieren, von denen eines verpflichtend ist. Weitere mögliche Daten, die man an dieser Stelle angeben könnte, wären: „accepted date“, „submitted date“, „published date“. Dies würde weitere Auswertungen ermöglichen (Bsp.: Zeit zwischen submission date und invoice date; bei manchen Verlagen liegen dazwischen nur ein paar Tage, bei anderen kann es mehrere Monate dauern; siehe: Issue 44).

Metadatenschema: Feld „publisher“

Sind die Publishernamen normiert, z. B. durch eine ROR-ID?
Die ROR-ID ist zur Angabe nicht wirklich nutzbar, da viele publisher mehrfach vertreten sind (z. B. Springer Nature sechsmal vertreten). Im österreichischen Projekt AT2OA2 arbeiten sie in einem Teilprojekt an einer Verlagsnormierung über Wikidata. Die Vergabe von Wikidata IDs steht allerdings noch am Anfang (siehe: Issue 16).
Zudem wurde die Frage gestellt, was im Feld „publisher“ exakt erfasst werden solle. Beispiel: Wird bei einer MPDL-Rechnung an dieser Stelle die MPDL erfasst oder Springer bzw. Wiley? Dies steht noch zur Diskussion.
Außerdem wurde angemerkt, dass das Feld aus SAP-Sicht eher mit „creditor“ benennen würde. Die Bezeichnung „publisher“ könnte möglicherweise irreführend sein (siehe: Issue 43).