Datenaustausch schwer gemacht

Das Beispiel OAI-PMH-Schnittstellen

von Stefan Müller, BAdW

Mangelnde Austauschbarkeit von Daten ist ein Haupthindernis auf dem Wege, die Möglichkeiten vernetzter und digitaler Datenverarbeitung auszuschöpfen. Dieses Hindernis lässt sich grundsätzlich auf genau zwei Arten ausräumen:

  1. Alle am Austausch beteiligten Stellen nutzen dasselbe Datenformat.
  2. Es werden Werkzeuge geschaffen, die die genutzten Datenformate selbsttätig, ohne weiteren menschlichen Arbeitsaufwand, ineinander umwandeln können.

Ersteres ist der Daseinszweck von Datenformat-Standards. Gewisse Erfolge damit gab es auf der unteren, der formal-syntaktischen Ebene, z. B. mit XML und JSON. Auf der höheren, der semantisch-lexikalischen Ebene, sind entsprechende Versuche nicht geglückt, z. B. im Falle von TEI-XML, das als Standard wohl leider gescheitert ist.

Man könnte zwar hoffen, dass ein Standardisierungsversuch eher gelingt und einen leichten Datenaustausch ermöglicht, wenn es um bibliographische Daten geht, da dieser Gegenstandsbereich im Vergleich zu dem von TEI-XML kleiner sei. Wir haben diese Hoffnung aber als trügerisch erfahren müssen – aus mehreren Gründen. Doch urteilen Sie selbst; hier ein Ausschnitt aus unserer Erfahrung.

Austausch zwischen BAdW, BASE, DNB und BSB

Wir möchten die im Netz verfügbaren Publikationen der Bayerischen Akademie der Wissenschaften in BASE einbringen. “BASE (Bielefeld Academic Search Engine) ist eine der weltweit größten Suchmaschinen für wissenschaftliche Web-Dokumente. Der Index umfasst über 120 Millionen Dokumente aus über 6.000 Quellen. Bei etwa 60% der in BASE indexierten Dokumente sind die Volltexte frei zugänglich (Open Access). Betreiber der Suchmaschine BASE ist die Universitätsbibliothek Bielefeld.” (Quelle)

Gespeist wird diese große Sammlung aus Quellen im Netz. Eigene Quellen kann man entweder mittelbar oder unmittelbar in BASE einbringen: “⟦…⟧ laden Sie Ihre Dokumente in Aggregatoren wie DataCite oder Zenodo hoch, in einem fachlichen Repository wie RePEC oder melden Sie Ihre Open-Access-Zeitschrift im DOAJ an. Diese Quellen indexieren wir regelmäßig. ⟦|⟧ Der beste Weg, damit Ihre Dokumente von uns indexiert und in BASE gefunden werden, ist aber das Betreiben einer eigenen OAI-Schnittstelle.” (Quelle)

Empfohlen wird also der unmittelbare Weg, die eigenen Daten abrufbar zu machen, ohne (und darin liegt wohl der Vorteil) dass für jeden Abruf oder für jede neue Quelle menschliche Arbeit zu verrichten wäre. Auf derselben Netzseite werden auch Hinweise gegeben, wie das einzurichten sei. Zunächst scheint eine OAI-Schnittstelle zu genügen: “Wir indexieren grundsätzlich alle Quellen – Zeitschriften, Repositorien, Digitale Sammlugen etc. – mit wissenschaftlichen Inhalten, die über eine OAI-Schnittstelle verfügen und die Metadaten über OAI-PMH bereitstellen (mehr zu OAI erfahren Sie auf den Seiten der Open Archives Initiative oder in der Wikipedia).”

Wie aber im Folgenden deutlich wird, genügt verständlicherweise nicht einfach irgendeine OAI-Schnittstelle, sondern sie muss an die Bedürfnisse von BASE angepasst sein: “Wir haben einige “Goldene Regeln” zusammen getragen, die Ihnen dabei helfen, Ihre OAI-Schnittstelle zu optimieren. Hält Ihre OAI-Schnittstelle diese Regeln ein, ist eine problemlose und schnelle Indexierung in BASE gewährleistet. Die Daten Ihrer Quelle werden optimal und vollständig in BASE präsentiert … und natürlich profitieren davon auch alle anderen Dienste, die Daten über Ihre OAI-Schnittstelle indexieren.”

Letzteres ist leider nicht immer richtig. Unter den “Goldene⟦n⟧ Regeln” finden sich zwar erstens solche, die in der Tat alle OAI-Schnittstellen einhalten müssen, zweitens solche, die in der Tat allgemein empfehlenswert sind und von allen Schnittstellennutzern ertragen, wenn schon nicht begrüßt würden, drittens aber auch mindestens eine, die den Wünschen anderer möglicher Schnittstellennutzer widerstreitet. Und diese eine ist die weitreichendste von allen, denn sie betrifft das Format, in dem sämtliche bibliographischen Daten übermittelt werden: “Jeder Eintrag in Ihrer OAI-Schnittstelle verfügt über möglichst vollständige Metadaten zu einem Dokument (Titel, Autor, Abstract, Erscheinungsjahr) und verwendet das info-eu-repo-Vokabular”. Eine nach dieser Regel, so golden sie sein mag, antwortende Schnittstelle würde den Wünschen der Deutschen Nationalbibliothek zuwiderlaufen, die zur Zeit nur MARC-XML, ONIX-XML und – für Hochschulschriften – XMetaDissPlus-XML annimmt (vgl. Diebel 2015, S. 26). Für bibliothekarische Belange ist DublinCore-XML derzeit nicht granular genug (gemäß einer freundlichen Auskunft von C. Germer, DNB).

Die Wünsche der DNB sind für uns maßgeblich, da wir ihr gegenüber nicht nur einen Ablieferungswunsch, sondern auch eine Ablieferungspflicht haben. Zudem speichern wir die bibliographischen Daten von publikationen.badw.de nicht in einem eigenen System, sondern sind dankbare Nutzer der SRU-Schnittstelle des Bibliotheksverbundes Bayern und der Bayerischen Staatsbibliothek – denn in deren großen Katalog muss jede unserer Veröffentlichungen ohnehin eingetragen werden. Und von dort bekommen wir die Daten schon in MARC-XML. Übrigens können wir dieses MARC-XML auch nicht einfach an die DNB durchreichen. Abgesehen von kleineren inhaltlichen Abweichungen (etwa bei der Angabe von Hochschulschriften) liegt das im Grunde daran, dass die Retrodigitalisate sinnvollerweise keinen eigenen Eintrag im Katalog bekommen und wir die bibliographischen Angaben aus dem Eintrag der Druckpublikation bekommen, die dem Retrodigitalisat entspricht. Für publikationen.badw.de mit den absichtlich schlicht gehaltenen bibliographischen Angaben macht das keinen Unterschied, wohl aber für die Angaben, die wir zur Ablieferung an die DNB zusammenzustellen haben.

Die abweichende Empfehlung in den Regeln von BASE ist aber auch sehr gut zu rechtfertigen – denn sie läuft auf die Verwendung von einer(!) Art von DublinCore-XML heraus, und die OAI-PMH-Vorschriften fordern ohnehin schon, dass eine OAI-PMH-Schnittstelle mindestens ein DublinCore-XML senden kann.

Dennoch erstaunt mich der oben zitierte Verweis auf info-eu-repo für die doch wesentliche Frage, in welchem Format die bibliographischen Daten selbst zu übermitteln sind. Denn obwohl schon die OAI-PMH-Richtlinien selbst nicht gut geschrieben sind, so macht info-eu-repo auch an diesem Maß gemessen einen für das Anliegen, bibliographische Daten an BASE zu übermitteln, zur Zeit noch ganz unfertigen Eindruck: mit zahlreichen Überarbeitungskommentaren oder bloßem “?” (so als erstes im Abschnitt “Publication types”), redundanten Auflistungen (z. B. des Eintrages “conferenceObject”) und Erläuterungen wie “The term conferenceContribution is confusing. A more clear term is concerente⟦sic⟧ItemNotInProceedings.” (Quelle), unsinnig gegliedert, vor allem aber aufgebläht mit Inhalt, der für die Übermittlung grundlegender bibliographischer Angaben überflüssig ist (“Grant Agreement Identifiers” usw.), und ohne den Inhalt, der dafür nötig wäre: Wie man Autoren, Titel, Jahr übermittelt, wird nicht erwähnt, zu schweigen davon, dass das konkret gewünschte XML nirgends gezeigt wird. Dafür muss man auf gut Glück nach einer anderen Quelle suchen und landet über die Seite von info-eu-repo vielleicht bei den dort unter “Projects used for input” neben anderen Seiten verlinkten Richtlinien von OpenAIRE, die zwar ebenfalls unverhältnismäßig umständlich sind, aber doch auch die wichtigsten Angaben abdecken und konkrete Angaben zum gewünschten XML machen. Warum wird in den Goldenen Regeln von BASE auf info-eu-repo verwiesen statt auf die Richtlinien von OpenAIRE? (Nicht ganz so hilfreich sind dort übrigens auch die Links, die zum OAI-PMH selbst gesetzt sind; ich habe sie oben zitiert: Der eine führt zum Wikipedia-Eintrag der OA-Initiative, nicht des OAI-Protokolls, der andere zur Seite der OA-Initiative, aber keiner unmittelbar auf die Seite der OAI-PMH-Richtlinien.)

Leider sind die Abweichungen zwischen MARC-XML einerseits und (info-eu-repo)-OpenAIRE-DublinCore-XML andererseits nicht nur formaler, oberflächlicher Art, sondern auch inhaltlicher, und leider lässt sich der (info-eu-repo)-OpenAIRE-DublinCore-XML-Inhalt nicht immer aus dem MARC-XML-Inhalt ableiten. Dazu ein Beispiel: Laut OpenAIRE-Richtlinien muss ein “Publication Type” angegeben werden. Die dem nächste Angabe enthält das MARC-XML – wie uns A. Kugler von der Bibliothek der LMU und dhmuc-Mitglied freundlicherweise mitgeteilt hat – im leader-Element, eine Besonderheit von MARC-XML, die zum Beispiel so aussieht:

<leader>01953nam a2200409 cb4500</leader>

Das Ainigma dieses Elementes zu zerstören, davor empfand man begreiflicherweise eine Scheu, und daher ist Auskunft über seinen Aufbau nicht leicht zu finden für den Uneingeweihten. Vgl. zum Beispiel die Seiten mit allgemeineren und irgendwo auch näheren Angaben, die endlich zum Feld “Type of record” führen. Doch die darüber getroffenen Unterscheidungen reichen nicht, jene Unterscheidungen zu treffen, die von info-eu-repo unter “Publication types” gefordert werden.

Der Zeitaufwand, der bei so bewandten Dingen getrieben werden muss, scheint mir umso weniger gerechtfertigt in Fällen, in denen die Angabe für die Endnutzer von solch geringer Bedeutung ist wie der “Publication type”. Es kann doch, um die Wendung von Kleist zu klauen, den in BASE Suchenden auf der Welt Gottes nichts gleichgültiger sein als die Frage, ob eine Veröffentlichung ein “ConferencePaper” oder ein “ConferencePoster” sei, eine “lecture”, ein “workingPaper” oder ein “preprint”. Und selbst wenn: Unter diesen Umständen und bei dieser Unterscheidungsfeinheit kann man sich ohnehin nur darauf verlassen, dass man sich auf die Angaben nicht verlassen kann: dass sie – zumal von ungeschulten Kräften eingegeben – unvollständig, fehlerhaft und uneinheitlich eingegeben werden, mithin mehr oder minder wertlos sind. Die Angabe sollte keine verpflichtende sein.

Wie gute Richtlinien beschaffen sind

Knapp und klar,
Schritt für Schritt umsetzbar.


10 Gedanken zu „Datenaustausch schwer gemacht

  1. Dass Sie in ihren Marc-Daten im Feld 655 nicht viel rausholen können, hätte ich mir eigentlich fast denken können, sorry.
    In sog. “Discovery-Systemen” wie VuFind wird viel Aufwand betrieben, um aus den Marc-Daten benutzerfreundliche Bezeichnungen wie “Buch”, “E-Book”, “Artikel” ableiten und anzeigen zu können. Schauen Sie sich den FormatCalculator von VuFind an: https://github.com/vufind-org/vufind/blob/master/import/index_java/src/org/vufind/index/FormatCalculator.java
    Wahrscheinlich lässt sich mit etwas Anpassung des dort enthaltenen Mappings ein kontrolliertes Vokabular wie das COAR erzeugen. Und vielleicht lohnt es sich in der bibliothekarischen Mailingliste inetbib nachzufragen, ob schon jemand dieses Mapping gemacht hat. Das weiß ich leider nicht und würde es auch gern erfahren.

    BASE bekommt als Aggregator von Tausenden von Quellen alle möglichen Werte in dc:type (natürlich auch für andere dc-Felder). Da ist es nachvollziehbar, dass sie in ihren Golden rules die Verwendung von kontrollierten Vokabularen empfehlen. Nach meinem Verständnis sind diese Golden rules “nur” Empfehlungen. Wenn Sie sich nicht daran halten, dann werden ihre Publikationen ggf. nicht über die Facetten auffindbar sein. Werte, die BASE nicht mappen und bspw. für die Facetten auswerten kann, werden aber in der Detailanzeige angezeigt und ich nehme an auch indexiert.

    • Herzlichen Dank für Ihre – mir wiederum sehr willkommenen und lehrreichen – Hinweise! Auch darauf, dass BASE schon gut daran tut, über gemeinsame Vokabulare ja immer noch recht sanft auf eine Einheitlichkeit der Angaben hinzuwirken. Und es gäbe ja auch bei weitem mehr zu loben als zu beklagen, zum Beispiel, dass es einen Validator gibt, mit dem man seine OAI-Schnittstelle prüfen kann.

      Wenn ich Ihrem Nutzernamen ablesen darf, dass Sie vom bibliothekarischen Fach sind, und ich vielleicht fragen darf: Welches bibliographische Vokabular würden Sie wohl für das zur Zeit und auf absehbare Zeit verbreitetste, gängigste oder sonst empfehlenswerteste halten? (Hierzulande, wie man vielleicht einschränkend hinzufügen muss.)

      “Nach meinem Verständnis sind diese Golden rules „nur“ Empfehlungen. Wenn Sie sich nicht daran halten, dann werden ihre Publikationen ggf. nicht über die Facetten auffindbar sein. Werte, die BASE nicht mappen und bspw. für die Facetten auswerten kann, werden aber in der Detailanzeige angezeigt und ich nehme an auch indexiert.”

      Das ist für uns natürlich interessant und relevant 😉 Mir war nur so, dass unsere OAI-PMH Schnittstelle vom Validator “http://oval.base-search.net/” mit Hinweis auf das Vokabular abgelehnt wurde – was ich zur Zeit nicht nachvollziehen kann, da der Validator zum Beispiel nach Eingabe von “http://publikationen.badw.de/de/api/oai?verb=GetRecord&identifier=badw:007457763”, geschweige bloßem “http://publikationen.badw.de/de/api/oai”, anscheinend nur eine eingeschränkte Prüfung durchführt, da kein Datensatz zurückgegeben werde. Den Datensatz, der eigentlich zurückgegeben wird, sieht man, wenn man “http://publikationen.badw.de/de/api/oai?verb=GetRecord&identifier=badw:007457763” in die Adresszeile des Brausers kopiert. Da muss ich noch einmal schauen.

      Herzliche Grüße

      • Hierzulande ist das sog. “Gemeinsame Vokabular für Publikations- und Dokumenttypen” https://doi.org/10.18452/1492 relevant, da es von der DNB und bei der DINI-Zertifizierung gefordert wird. Auf europäischer Ebene gibt es neuerdings eine Empfehlung für das COAR-Vokabular, in den Guidelines v4 von OpenAIRE nachzulesen: https://openaire-guidelines-for-literature-repository-managers.readthedocs.io/en/v4.0.0/field_publicationtype.html (davor in v3 war es noch das info:eu-repo-Vokabular)
        Damit nicht genug, bringt die Spezifikation des Kerndatensatz Forschung vom Wissenschaftsrat ein eigenes Vokabular ins Spiel.
        Jetzt gibt es eine Arbeitsgruppe, die das alles harmoniseren will. Deren Blogpost bietet eine ausführlichere Darstellung der Situation: https://blogs.tib.eu/wp/fis/2020/02/17/empfehlung-kdsf/
        Wer denkt da nicht an https://xkcd.com/927/ 😉

        Die OAI-Schnittstelle unter http://publikationen.badw.de/de/api/oai verhält sich zurzeit nicht standardkonform. So gibt bspw. die Anfrage http://publikationen.badw.de/de/api/oai?verb=ListRecords&metadataPrefix=oai_dc eine Fehlermeldung zurück. Daher kann der Validator von Base keine Validerung der Datensätze durchführen. Der Validator von DINI ist sonst auch einen Test wert, wenn die badw-Schnittstelle wieder funktioniert.

        • Herzlichen Dank für die interessanten Auskünfte! Dann ist die Frage des Vokabulars also noch etwas im Fluss.

          Die von Ihnen beobachtete und dankenswerterweise mitgeteilte Meldung auf die Anfrage mit “metadataPrefix=oai_dc” ist ja “CannotDisseminateFormat” und erklärt mir meine Erinnerung wieder, “dass unsere OAI-PMH Schnittstelle vom Validator “http://oval.base-search.net/” mit Hinweis auf das Vokabular abgelehnt wurde”. Der Validator selbst sagt das (wenn ich’s gestehn darf) leider nicht ganz so klar: Außer den “Success”- und “Recommendation”-Mitteilungen gibt es nur einige “Unverified”-Mitteilungen wie “UNVERIFIED: dc:language conformance to ISO 639 could not be checked: no records”, die nur danach klingen, als würden keine Datensätze zurückgegeben, was aber ja geschieht, wenn man zum Beispiel http://publikationen.badw.de/de/api/oai?verb=ListRecords&metadataPrefix=marc validieren lässt.

          Dass der Validator die Schnittstelle nicht goutiert, weil kein Dublin Core unterstützt wird, ist durch den OAI-Standard, der Dublin Core fordert, natürlich völlig gerechtfertigt. Ich hatte, wie im Artikelchen angedeutet, bei der DNB angefragt, ob ich Dublin Core statt MARC benutzen dürfe; aber das ging nicht. Daher habe ich nur MARC benutzt; denn leider fehlte bislang die Zeit, beides einzubauen – zumal das in diesem Fall bedeutet hätte, für bislang nur zwei Datennehmer (DNB, BASE) auch zwei “Standards” zu unterstützen, also für jeden seinen eigenen. Und diese Schnittstelle hat vergleichsweise – gemessen an der Schlichtheit des Grundanliegens und an den daneben Entwicklungszeit beanspruchenden wissenschaftlichen, sozusagen datengebenden Vorhaben – schon unverhältnismäßig viel Zeit verschlungen.

          Vielleicht führen die von Ihnen freundlicherweise mitgeteilten neuesten Bemühungen, ein einheitliches Vokabular zu finden, ja dazu, dass es in Zukunft weniger aufwändig ist. Wobei der größte Zeitverlust vielleicht nicht so sehr das bloße Nebeneinander von Vokabularen ist, sondern die Unübersichtlichkeit und Aufgeblähtheit ihrer Richtlinien. Das unter https://doi.org/10.18452/1492 verlinkte PDF ist auch schon wieder 56 Seiten lang; und wenn ich all die Seiten zusammennehme, auf die im Zusammenhang mit dieser Schnittstelle als relevant verwiesen wurde – direkt oder indirekt –, dann kommt ein ganzer Zauberberg dabei heraus. Schade, dass es sich nicht auch so schön liest …

  2. Für das Mapping der Publikationstypen könnten Sie in ihren Marc-Daten im Feld 655, Unterfeld $a nachschauen: https://www.loc.gov/marc/bibliographic/bd655.html

    Die aktuelle Guideline von OpenAIRE empfiehlt das COAR-Vokabular für Publikationstypen und nicht mehr das von info:eu-repo.

    Ja, es wäre schön, wenn es auf der Welt nur ein Datenformat gäbe und alle es richtig verwenden 😉 Und natürlich auch nur *das* eine kontrollierte Vokabular.

    • Vielen Dank für den wertvollen Hinweis bzw. Link. Eine Welt, in der es für jeden Zweck jeweils nur ein einziges Datenformat gibt, wünschen wir uns dabei gar nicht unbedingt. (Das könnte im schlimmsten Fall die technische Entwicklung zum Stillstand bringen.) Wir wären schon zufrieden, wenn es etwas mehr Einheitlichkeit und wechselweitiges Übereinstimmung zwischen verschiedenen Bibliotheken und Suchdiensten bei bibliothekatischen Formaten und deren Anwendung gäbe.

      Aber noch viel wichtiger ist eine leicht auffindbare (!), sorgfältige Dokumentation der Formate und Schnittstellen mit Beispielen (please!). Da haben wir, keineswegs nur im Zusammenhang mit OAI-PMH häufig schlechte Erfahrungen gemacht, so dass es im Kollgenkreis manchmal schon als Strafarbeit empfunden wird, wenn jemand die Aufgabe bekommt, unsere Daten bei irgendeinem Repositorium oder Such- und Sammeldienst anzumelden bzw. zu verknüpfen oder Metadaten dafür bereit zu stellen.

    • Ja, im Feld 655 sähe ich die Angaben gerne – aber das Feld ist in den Datensätzen unserer Veröffentlichungen leider oft gar nicht gegeben. Vgl. zum Beispiel mit : Zur Zeit gibt die SRU-Schnittstelle den Datensatz jedenfalls ohne Feld 655 zurück. Sortiert nach Feldnummer folgt dort auf 490 gleich 830.

      Das ist nicht einmal ein Ausnahmefall; und eben deswegen sind wir auf den “leader” in den MARC-Daten verwiesen worden.

      Was ich aber beklage, sind nicht diese Datensätze und ihre Schnittstelle. Sondern dass BASE nicht einfach sagt: Schreiben Sie die folgenden bibliographischen Angaben als JSON: Autor(en) / Editor(en), Titel, Jahr, Verlagsort und, wenn vorhanden, Reihe und Reihennummer; hier ist ein Beispiel-JSON. Die Sache wäre in fünf Minuten erledigt, die Angaben wären verlässlicher – weil sicherer zu geben, wie im Beitrag erwähnt – und im Grunde auch austauschbarer als so, wie es jetzt ist. Einen Grund dafür nennen Sie dankenswerterweise:

      2. Dass das empfohlene Vokabular jetzt ein anderes ist, zeigt zwar eine gewisse Einsicht in die Unzulänglichkeit vorher, aber wozu die Nachteile von Standards in Kauf nehmen, wenn man dann auch noch von einem Jahr aufs andere das Vokabular austauscht.

  3. Pingback: Bielefelder Suchmaschine BASE torpediert den Datenaustausch mit OAI-PMH | Archivalia

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.