Search/Retrieve via URL (SRU)

Search/Retrieve via URL (SRU) ist ein internationaler, offener Standard für die webbasierte Suche und den Abruf strukturierter Daten, der insbesondere in Bibliotheken, Archiven, Museen, Forschungsdatenbanken und Informationssystemen eingesetzt wird.

Produkt:
Bibliotheksmanagement

Das Protokoll ermöglicht standardisierte Suchanfragen, die meist als URL-Parameter in HTTP-Requests formuliert und an einen SRU-Server gesendet werden. Die Antworten erfolgen in maschinenlesbaren, strukturierten Formaten. 

Einfache Suchanfragen lassen sich direkt in die Adresszeile eines Webbrowsers eingeben, während für erweiterte Funktionen wie Paging, Authentifizierung oder POST-Requests spezialisierte Softwaretools oder Skripte notwendig sind.

Historie und Standardisierung von SRU

SRU wurde Anfang der 2000er Jahre von der Library of Congress initiiert, um einen modernen, webbasierten Nachfolger für ältere Protokolle wie Z39.50 zu schaffen. Ziel war eine einfachere, internetbasierte Schnittstelle, die eine breite Integration in verschiedene Informationsmanagement-Systeme erlaubt. 

SRU wird gemeinsam mit SRW (Search/Retrieve Web Service, SOAP-basierter Webservice) gepflegt, wobei SRU inzwischen wesentlich verbreiteter ist. Die Standardisierung und Dokumentation erfolgen durch die Library of Congress, die auch Referenzimplementierungen und Testserver anbietet.

SRU existiert in mehreren Versionen. Die wichtigsten sind SRU 1.1 und SRU 2.0, mit kleineren Unterschieden bei den Features und der Fehlerbehandlung. Die jeweils aktuell gültige Version und Empfehlungen entnehmen Sie der Website der Library of Congress.

Technische Grundlagen und Funktionsweise

SRU basiert auf etablierten Webprotokollen wie HTTP-GET und HTTP-POST. Die Abfrage erfolgt durch Aufruf einer spezifizierten URL mit bestimmten Parametern. Zu den wichtigsten Parametern gehören:

  • operation: Gewünschte Aktion, z. B. searchRetrieve oder explain.
  • version: SRU-Version.
  • query: Die Suchanfrage, meist in Contextual Query Language (CQL).
  • recordSchema: Anfrage nach spezifischem Datenformat wie MARC21, Dublin Core, MODS oder EAD.
  • startRecord: Startposition bei der Ergebnisausgabe (Paging).
  • maximumRecords: Maximale Anzahl der angeforderten Datensätze.

Als verpflichtende Suchsprache sieht der Standard CQL (Contextual Query Language) vor. CQL ermöglicht differenzierte, feldbasierte Abfragen mit logischen Verknüpfungen. SRU-Implementierungen müssen CQL unterstützen, alternative Suchsprachen können optional angeboten werden, sind aber nicht interoperabel definiert.

Die Ergebnisse werden standardmäßig als XML geliefert, typischerweise in anerkannten Formaten wie MARC21, MODS, Dublin Core (DC) oder EAD für Archivdaten. JSON bleibt bisher eine optionale Erweiterung, deren Implementierung je nach Server variiert.

SRU zeichnet sich aus durch:

  • Client-Plattform-unabhängige Nutzung via Webtechnologien (Browser, Skripte, Anwendungen)
  • Standardisierte Schnittstelle für die Anbindung an unterschiedlichste Informationssysteme
  • Klare Protokollierung des Ablaufs von Suchanfrage und Antwort
  • Verpflichtende Unterstützung von CQL als Suchsprache

SRU erlaubt Paging über die Parameter startRecord und maximumRecords, sodass auch große Treffermengen selektiv abgerufen werden können. Einschränkungen bei der Performance und beim Handling sehr großer Datenmengen ergeben sich meist durch Servereinstellungen, Limits oder Timeouts.

SRU-Explain

Die Operation explain ermöglicht es Clients, maschinenlesbar die Fähigkeiten eines SRU-Servers (unterstützte Indizes, Suchfelder, Formate und Versionen) zu erfragen. Dies erleichtert automatisierte Integrationsprozesse und fördert Interoperabilität.

Beispiel für eine SRU-Anfrage und Antwort

Eine einfache Abfrage nach Büchern von Mustermann im MARCXML-Format könnte so aussehen:

https://example.org/sru?version=1.2&operation=searchRetrieve&query=author=Mustermann&recordSchema=marcxml&startRecord=1&maximumRecords=5

Die maschinenlesbare Antwort (Auszug):

<searchRetrieveResponse>
  <numberOfRecords>15</numberOfRecords>
  <records>
    <record>
      <recordSchema>marcxml</recordSchema>
      <recordData>
        <!-- MARCXML-Datensatz -->
      </recordData>
      <recordPosition>1</recordPosition>
    </record>
    <!-- Weitere Datensätze -->
  </records>
</searchRetrieveResponse>

Unterschied SRU und SRW

SRU basiert auf URL-Parametern via HTTP, während SRW die gleiche Logik via SOAP-Anfragen bietet. Historisch wurde SRW für komplexe serviceorientierte Architekturen eingesetzt, ist jedoch weniger verbreitet als SRU, das für die meisten modernen Anwendungen empfohlen wird.

CQL - Die Abfragesprache von SRU

CQL (Contextual Query Language) erlaubt es Ihnen, Suchanfragen gezielt zu formulieren - etwa feldspezifisch oder logisch verknüpft mit Operatoren. Beispielsweise:

title="Wissensmanagement" AND year>=2019

Zu den wichtigsten Operatoren zählen AND, OR, NOT, Relationen wie =, >= oder Präzisionsangaben (exact, any). Weiterführende Anleitungen, Onlinetests und Validatoren für CQL finden Sie bei der Library of Congress oder in einschlägigen Entwicklerportalen.

Unterschiede von SRU, Z39.50 und weiteren Schnittstellen

Der größte Unterschied zwischen SRU und Z39.50 liegt in den verwendeten Technologien. Z39.50 ist ein seit den 1980er Jahren etablierter, aber komplexer Netzwerkstandard mit eigenen Protokollen, der für den Betrieb spezielle Software erfordert. SRU verwendet offene, moderne Webtechnologien (HTTP, XML) und ist dadurch leichter in heutige IT-Umgebungen integrierbar. 

Während Z39.50 Systeme meist schwer wartbar und technologiegebunden sind, ermöglicht SRU flexible, clientseitig plattformunabhängige Entwicklung. Z39.50 ist deutlich älter, weniger wartbar und wird tendenziell durch neuere Protokolle abgelöst - wird aber noch in zahlreichen Bestandsystemen weltweit verwendet.

Weitere relevante Schnittstellen sind etwa OAI-PMH (für Metadaten-Ernte), REST-APIs und moderne Linked Data-Technologien. Die Auswahl hängt vom Informationsbedarf, der Komplexität der Daten und dem Integrationsaufwand ab.

Typische recordSchemas in Bibliotheken

  • MARCXML, MARC21: Bibliographische Metadaten im MARC-Standard
  • MODS: Metadata Object Description Schema
  • Dublin Core (DC): Standardisiertes, universell einsetzbares Metadatenschema
  • EAD: Encoded Archival Description für Archiv- und Nachlassinformationen

Sie können in jeder Anfrage das gewünschte recordSchema spezifizieren - die tatsächliche Unterstützung hängt vom Zielsystem ab.

Bekannte SRU-Implementierungen und Gateways

International bedeutende SRU-Zugänge bieten die Deutsche Nationalbibliothek, die British Library, die Library of Congress, OCLC WorldCat, die Verbundkataloge (z. B. Gemeinsamer Bibliotheksverbund (GBV), K10plus), sowie spezialisierte Discovery-Systeme wie Primo (Ex Libris) oder VuFind. Auch große Universitäts- und Landesbibliotheken sowie zahlreiche Forschungsdatenzentren im deutschsprachigen Raum unterhalten öffentlich zugängliche SRU-Endpunkte.

Discovery-Systeme sind Suchanwendungen, die Inhalte unterschiedlicher Systeme (z. B. Bibliothekskataloge, Fachdatenbanken, Archive) in einer einheitlichen Oberfläche aggregieren und durchsuchbar machen.

Typische Vor- und Nachteile von SRU

Protokoll / Technologie

Vorteile

Nachteile

SRU

Einfache Integration, Webstandards, CQL, öffentliche Dokumentation

Teils uneinheitliche Implementierung, Mapping-Aufwand, XML-Lastigkeit

Z39.50

Ausgereift, weltweit verbreitet, starke Feldunterstützung

Komplexität, proprietäre Protokolle, schwer wartbar

OAI-PMH

Einfache Metadaten-Ernte, hohe Interoperabilität

Keine On-Demand-Suche, weniger flexibel bei Abfragen

REST/GraphQL

Moderne Technologie, breite Entwicklung

Kein etablierter Suchstandard für Metadaten, viele proprietäre Varianten

Sicherheitsaspekte bei SRU

SRU spezifiziert keine eigenen Sicherheitsmechanismen. Der Zugangsschutz erfolgt klassisch über HTTPS, IP-Whitelist, Authentifizierung per Nutzerkonto oder - seltener - API-Keys oder OAuth. Sie sollten festlegen, welche Nutzer Zugriff erhalten, und Ihre Schnittstellen so konfigurieren, dass keine sensiblen Daten unkontrolliert nach außen gelangen. 

Funktionen wie Logging, Monitoring und gegebenenfalls Rate-Limiting helfen zusätzlich beim Schutz und bei der Fehlersuche Ihres Systems.

Fehlerbehandlung, Rückgabecodes und Diagnosen

SRU-Antworten liefern bei Fehlern strukturierte XML-Diagnosemeldungen gemäß offizieller Diagnosic-Listen. Typische Rückmeldungen sind „unsupportedOperation“, „querySyntaxError“ oder „tooManyRecordsRequested“. Fehler werden detailliert in diagnostics-Elementen ausgegeben. Sie sollten darauf achten, bei der Einbindung von SRU Rückgabewerte korrekt auszuwerten und Fehlerfälle angemessen zu behandeln.

Herausforderungen und Grenzen

Beachten Sie beim Einsatz von SRU folgende Herausforderungen:

  • Implementierungsunterschiede bei recordSchemas, Feldnamen und Response-Formaten erfordern zum Teil individuelles Mapping.
  • Serverseitige Limits (z. B. maximale Treffermengen, Timeouts) beeinflussen Performance und Skalierbarkeit.
  • Wenn sehr große Datenmengen abgerufen werden, empfehlen sich angepasste Paging-Strategien und ein Monitoring auf Seiten des Clients.
  • Nicht alle Systeme unterstützen neuere recordSchemas oder JSON.
  • Für fortgeschrittene Nutzung, Mapping und Fehleranalysen ist technisches Know-how wichtig.

Bei der Implementierung treten typische Probleme bei der Zuordnung eigener Felder zu Standardformaten, bei inkonsistenten Datenlieferungen und abweichenden Serverantworten auf.

Praktische Tipps zur SRU-Nutzung

  • Lesen Sie stets die Dokumentation der angebundenen SRU-Server, insbesondere zu unterstützten Parametern, Feldern und recordSchemas.
  • Nutzen Sie die Leistungsfähigkeit von CQL für gezielte Suchen. Online-Validatoren helfen bei der Fehlerprüfung.
  • Prüfen Sie Suchergebnisse regelmäßig auf Qualität und Konsistenz.
  • Testen Sie Anfragen mit dedizierten Tools wie YAZ-Client, Postman oder eigenen Skripten. Für SRU existieren öffentliche Testserver.
  • Stimmen Sie Integration, Feldauswahl und Formate eng mit Partnerinstitutionen und Anbietern ab.
  • Überwachen Sie die Nutzung Ihrer SRU-Endpunkte und implementieren Sie Logging, Monitoring und - falls nötig - Rate-Limiting.
  • Sichern Sie Schnittstellen immer mit passenden Methoden (HTTPS, Authentisierung, IP-Filter).

Typische Fehlerquellen sind CQL-Syntaxfehler, falsche Feldnamen, abweichende Schemas und nicht unterstützte Response-Formate.

Community, Ressourcen und Support

  • Offizielle SRU-Dokumentation: Library of Congress SRU
  • CQL-Validatoren und Beispiele finden Sie auf der Seite der Library of Congress CQL
  • Entwicklerforen, Github-Repositorien und einschlägige Mailinglisten bieten Austausch und praktische Hilfen.
  • Für Testzwecke stellen zahlreiche Bibliotheken und Bibliotheksverbünde öffentliche SRU-Demo-Endpunkte bereit.

Häufige Fragen zu SRU

Wie unterscheidet sich SRU konkret von Z39.50?

SRU nutzt moderne Webtechnologien (HTTP, XML) und ist daher leichter integrierbar als der deutlich ältere, komplexere Z39.50-Standard, der eigene Netzwerkprotokolle und meist spezielle Software erfordert. Gleichzeitig bietet SRU ein klar strukturiertes, erweiterbares Framework für Metadatenabfragen. Z39.50 ist weniger wartungsfreundlich und wird nach und nach abgelöst, hat aber weiterhin Bedeutung, vor allem wegen bestehender Alt-Systeme.

Kann SRU auch außerhalb von Bibliotheken verwendet werden?

Ja, SRU eignet sich für Bibliotheken, aber ebenso für Archive, Museen, Forschungsdatenzentren, Behörden und Organisationen, die strukturierte Suchen und Datenabrufe über das Web benötigen.

Welche Suchsprache muss ich bei SRU verwenden?

CQL ist laut Standard die verpflichtende Suchsprache und wird von allen konformen SRU-Implementierungen unterstützt. Andere Suchsprachen können optional implementiert sein, sind aber nicht interoperabel standardisiert.

Brauche ich technisches Know-how, um SRU zu nutzen?

Für einfache Recherche genügen Basiskenntnisse, etwa das Befüllen von Suchformularen oder Einstieg über fertige Tools. Für eigene Schnittstellen, Mappingarbeiten und Fehleranalysen sind jedoch Fachkenntnisse erforderlich.

Gibt es Alternativen zu SRU für die Datenintegration?

Je nach Bedarf stehen OAI-PMH, diverse REST-APIs und Linked-Data-Technologien zur Verfügung. Die Wahl hängt von den Anforderungen, der Systemlandschaft und dem Nutzungsszenario ab.

Wie kann ich die Sicherheit beim Einsatz von SRU gewährleisten?

Absicherung erfolgt durch HTTPS, Zugangsbeschränkungen (IP-Filter, Benutzerauthentifizierungen), Logging sowie Monitioring. API-Keys werden seltener genutzt. Sensible Schnittstellen sollten nicht ungeschützt im Web zugänglich sein.

Gibt es unterstützende Software und Tools für SRU?

Verbreitete Werkzeuge sind der YAZ-Client, zahlreiche Open-Source-Tools sowie gängige Bibliotheksmanagementsysteme und Discovery-Systeme. Nutzen Sie öffentliche SRU-Testserver für Experimente.

Was ist SRU-Explain und warum ist es nützlich?

Mit der explain-Operation können Sie automatisch abfragen, welche Suchfelder und recordSchemas ein Server unterstützt. Dies erleichtert Integration, Fehleranalyse und Mapping.

Welche Performance-Überlegungen sind wichtig bei SRU?

Berücksichtigen Sie Limits für die maximale Anzahl von Treffern pro Anfrage, Server-Timeouts und Intervalle für Datenabrufe. Für große Datenmengen empfiehlt sich eine schrittweise Abfrage mit Paging und Monitoring der Antwortzeiten.

Wo finde ich weiterführende Informationen zu SRU und CQL?

Die Library of Congress bietet umfassende Dokumentationen, Praxisbeispiele und Validatoren. Auch die Websites großer Verbundkataloge und Bibliotheksdienstleister halten Leitfäden und technische Details bereit. Community-Foren und Entwicklerplattformen bieten ergänzende Hilfestellung.

Inhaltsverzeichnis