CQL

Historisch wurde CQL zunächst auch als Common Query Language bezeichnet.

Mit CQL formulieren Sie strukturierte, maschinenlesbare Suchanfragen für Kataloge, Discovery-Systeme, Verbundkataloge, Repositorien und andere Informationssysteme.Besonders häufig begegnet Ihnen CQL im Zusammenhang mit SRU- und SRW-Schnittstellen. CQL beschreibt dabei die Suchlogik, nicht den technischen Transport. CQL standardisiert vor allem die Syntax von Suchanfragen. Welche Indizes, Relationen, Modifier und Kontextsets verfügbar sind, entscheidet das jeweilige Zielsystem.

Im Unterschied zu einer einfachen Stichwortsuche können Sie mit CQL Suchkontexte ansprechen, Bedingungen logisch kombinieren und Abfragen dokumentierbar wiederholen. Das ist besonders relevant, wenn Systeme automatisiert miteinander kommunizieren, Daten vergleichen, Metadaten validieren oder Suchprofile dauerhaft reproduzierbar bleiben sollen.

Was ist CQL?

CQL ist eine Abfragesprache für strukturierte Suchanfragen in Informationssystemen. Sie wird vor allem im Search-Retrieve-Kontext genutzt.

Eine einfache CQL-Abfrage kann so aussehen:

dc.title = "Faust"

Diese Anfrage sucht im Dublin-Core-Titelindex nach „Faust“, sofern das Zielsystem diesen Index unterstützt.

Wichtig ist: dc.title ist ein qualifizierter Index aus einem Kontextset. Ein unqualifizierter Index wie title ist nicht allgemein verbindlich standardisiert.

CQL wird typischerweise in Umgebungen eingesetzt, in denen strukturierte Metadaten vorliegen. Dazu zählen:

• Bibliothekskataloge
• OPACs
• Verbundkataloge
• Discovery-Systeme mit geeigneter Schnittstelle
• institutionelle und fachliche Repositorien
• Fachdatenbanken
• Archiv- und Dokumentationssysteme
• Normdaten- und Metadatendienste
• Portale für wissenschaftliche Informationsversorgung

CQL ist besonders nützlich, wenn Suchanfragen präzise, wiederholbar und technisch integrierbar sein müssen. Das betrifft Recherche, Datenabgleich, Migration und Qualitätssicherung.

CQL im Standard- und Schnittstellenkontext

CQL ist eng mit den Spezifikationen rund um Search/Retrieve verbunden. Dazu gehören historische ZING-Arbeiten, SRW, SRU und spätere OASIS-Spezifikationen.

In der Praxis begegnen Ihnen häufig CQL 1.1 und CQL 1.2 sowie SRU 1.1, SRU 1.2 und SRU 2.0.

SRU steht für Search/Retrieve via URL. Es beschreibt, wie Suchanfragen an einen Server übertragen und Ergebnisse strukturiert zurückgegeben werden.

SRU wird häufig über HTTP GET genutzt. Je nach Version, Implementierung und Binding können jedoch auch andere HTTP-Methoden oder Übertragungsformen relevant sein.

SRW steht für Search/Retrieve Web Service. SRW ist die SOAP-basierte Variante des Search-Retrieve-Ansatzes.

CQL beschreibt die Suchanfrage. SRU oder SRW regeln, wie diese Anfrage übertragen und wie die Antwort strukturiert wird.

Eine SRU-Anfrage kann eine CQL-Abfrage als Parameterwert enthalten:

https://example.org/sru?version=1.2&operation=searchRetrieve&query=dc.title%20%3D%20%22Faust%22

Der Parameter query enthält hier die URL-kodierte CQL-Abfrage:

dc.title = "Faust"

Grundsätzlich müssen URL-Parameterwerte korrekt kodiert werden, sobald sie Leerzeichen, Anführungszeichen oder reservierte Zeichen enthalten.

In JavaScript entspricht dies zum Beispiel dem Prinzip von encodeURIComponent() für den CQL-Ausdruck als Parameterwert.

CQL legt nicht fest, welche Metadatensätze zurückgegeben werden. Dafür sind SRU-Parameter wie recordSchema, recordPacking und die Serverkonfiguration relevant.

Formale Grundstruktur von CQL

Eine CQL-Abfrage besteht aus Search Clauses, Operatoren, Modifiern und optionalen Sortieranweisungen.

Eine einfache Search Clause besteht meist aus drei Bestandteilen:

1. Index
2. Relation
3. Term

Beispiel:

dc.creator = "Goethe"

Dabei ist:

• dc.creator der Index
• = die Relation
• "Goethe" der Suchterm

Die Relation = ist nicht automatisch eine mathematische Gleichheit. In vielen Implementierungen bedeutet sie eine server- oder indexabhängige Standardsuche.

Das Zielsystem entscheidet, wie der Index ausgewertet wird. Es kann normalisieren, tokenisieren, Groß- und Kleinschreibung ignorieren oder Felder zusammenführen.

Komplexere Abfragen kombinieren mehrere Search Clauses mit booleschen Operatoren:

dc.subject = "Open Access" and dc.date >= "2020-01-01"

Zusätzlich kann eine CQL-Abfrage Modifier oder eine Sort Spec enthalten:

dc.subject any/stem "libraries archives" sortBy dc.date/sort.descending

Ob solche erweiterten Bestandteile unterstützt werden, hängt vom Server ab.

Indizes, Kontextsets und qualifizierte Suchfelder

Indizes legen fest, in welchem Suchkontext recherchiert wird. CQL selbst schreibt jedoch keine universelle Liste bibliografischer Indexnamen verbindlich vor.

Häufig stammen Indizes aus Kontextsets. Ein verbreitetes Kontextset ist Dublin Core mit Indizes wie dc.title, dc.creator oder dc.subject.

Beispiele:

dc.title = "Bibliotheksmanagement"dc.subject = "Langzeitarchivierung"dc.creator = "Müller"

Im Dublin-Core-Kontext meint dc.creator in der Regel die primär verantwortliche Entität. Weitere Beteiligte können eher über dc.contributor abgebildet sein.

Ob ein lokaler Index creator breiter interpretiert wird, hängt vom jeweiligen System ab. Manche Systeme mappen darin Personen, Körperschaften und Herausgebende gemeinsam.

Typische Indexbezeichnungen in CQL-Systemen können unterschiedliche Bedeutungen haben und sind oft vom jeweiligen Metadatenschema abhängig.

Der Index dc.title steht beispielsweise für den Titel im Dublin-Core-Kontext. dc.creator bezeichnet die primär verantwortliche Person oder Körperschaft, während dc.contributor weitere beteiligte Personen oder Organisationen erfasst, meist Mitwirkende.

Der Index dc.subject wird für Schlagwörter oder Themen verwendet und hängt stark von der jeweiligen inhaltlichen Erschließung und dem Mapping ab. dc.identifier dient zur Identifikation einer Ressource, etwa über ISBN, DOI oder URI.

Mit dc.date wird ein Datum oder Jahr angegeben, wobei die Vergleichbarkeit nur dann zuverlässig ist, wenn die Daten konsistent indexiert wurden. dc.publisher steht für den Verlag oder die herausgebende Stelle und ist ebenfalls vom jeweiligen Schema abhängig.

Weitere Beispiele sind bib.title als bibliografischer Titelindex, der oft systemspezifisch genutzt wird, sowie pica.*, das verschiedene PICA-bezogene Suchschlüssel umfasst und stark vom jeweiligen System abhängt.

Ein weiteres Beispiel ist local.recordId, das eine rein systeminterne Datensatzkennung darstellt.

Diese Beispiele zeigen typische Muster, stellen jedoch keine verbindlichen CQL-Standardindizes dar. Daher sollte immer geprüft werden, welche Indizes der jeweilige Server tatsächlich unterstützt.

Kontextset-URIs und Prefix Assignments

CQL kann Präfixe für Kontextsets explizit deklarieren. Dadurch wird klar, auf welches Kontextset sich ein Präfix bezieht.

Ein Beispiel für ein Prefix Assignment:

>dc="info:srw/cql-context-set/1/dc-v1.1" dc.title = "Faust"

Damit wird das Präfix dc dem Dublin-Core-Kontextset zugeordnet.

Ein weiteres Beispiel:

>cql="info:srw/cql-context-set/1/cql-v1.2" cql.serverChoice = "Goethe"

Präfixe sind in CQL nicht automatisch global festgelegt. Server können eigene Default-Kontextsets sowie lokale Präfixzuordnungen verwenden. Dadurch kann die Bedeutung unqualifizierter Indizes je nach System stark variieren. Insbesondere bei Integrationen sind explizite Präfixzuweisungen daher sehr hilfreich.

Typische Kontextsets sind:

• Das CQL Context Set, das grundlegende Indizes, Relationen und Modifikatoren definiert.
• Das Dublin Core Context Set, das allgemeine Metadatenfelder wie Titel oder Urheber abdeckt.
• Das Bath Context Set, das vor allem in bestimmten bibliografischen Suchprofilen verwendet wird.
• Lokale Kontextsets, die systemspezifische Indizes und Suchschlüssel enthalten.

Die genaue URI sowie die jeweilige Version eines Kontextsets sollten der Systemdokumentation oder der SRU-Operation explain entnommen werden.

Das CQL-Kontextset

Das CQL-Kontextset definiert unter anderem grundlegende Indizes, Relationen, Modifier und semantische Konventionen.

Ein wichtiger Index ist cql.serverChoice. Er überlässt dem Server die Entscheidung, welcher Standardindex verwendet wird.

Beispiel:

cql.serverChoice = "Faust"

Dies kann einer allgemeinen Suchbox ähneln. Es ist aber nicht zwingend identisch mit der Suche in der Benutzeroberfläche eines Systems.

CQL erlaubt in vielen Implementierungen auch Suchanfragen ohne expliziten Index. Solche Abfragen werden häufig auf einen Default-Index gemappt.

Beispiel:

"Faust"

oder:

Faust

Ob dies cql.serverChoice oder einem anderen Default-Kontext entspricht, hängt von Server und Parser ab.

Weitere besondere Indizes können cql.allRecords oder cql.resultSetId sein, sofern der Server sie unterstützt.

Beispiel für alle Datensätze:

cql.allRecords = 1

Beispiel für ein gespeichertes Ergebnis-Set:

cql.resultSetId = "set123"

Diese Beispiele sind SRU/CQL-spezifische Spezialfälle. Insbesondere Result Sets setzen voraus, dass der Server Ergebnislisten speichert.

Relationen in CQL

Relationen bestimmen in CQL, wie ein Suchterm mit einem Index verglichen wird. Sie steuern damit die Breite, Genauigkeit und Interpretation einer Suche.

Häufige Relationen sind:

• =: server- oder indexabhängige Standardsuche
• exact: engere Suche nach einem exakt passenden Feldwert
• any: mindestens einer der Terme soll vorkommen
• all: alle Terme sollen vorkommen
• adj: Terme sollen benachbart oder in definierter Reihenfolge vorkommen (falls unterstützt)
• >: größer als
• <: kleiner als
• >=: größer oder gleich
• <=: kleiner oder gleich
• <>: ungleich (falls unterstützt)
• within: innerhalb eines Bereichs (falls unterstützt)
• encloses: umfasst einen Bereich (falls unterstützt)

Beispiel mit exact:

dc.title exact "Der Prozess"

exact ist meist enger als =, aber nicht automatisch absolut exakt. Normalisierung und Indexierung können die Ergebnisse beeinflussen.

Beispiel mit any:

dc.subject any "Bibliothek Digitalisierung"

Hier reicht es, wenn mindestens einer der Terme im unterstützten Themenindex vorkommt.

Beispiel mit all:

dc.title all "digitale Bibliothek"

Hier müssen beide Terme vorkommen, sofern der Server all unterstützt.

Beispiel mit adj:

dc.title adj "digitale Bibliothek"

adj ist relevant, wenn benachbarte Wörter oder eine Wortfolge gesucht werden sollen. Die genaue Semantik ist implementierungsabhängig.

Anführungszeichen, Strings, Phrasen und adj

Anführungszeichen markieren in CQL primär einen Suchterm als String. Sie bedeuten nicht automatisch eine echte Phrasensuche.

Korrekt ist zum Beispiel:

dc.title = "digitale Bibliothek"

Problematisch oder syntaktisch ungültig ist in vielen CQL-Parsern:

dc.title = digitale Bibliothek

Mehrwort-Terme sollten normalerweise als String in Anführungszeichen geschrieben werden.

Ob ein String als Phrase, Wortfolge, Vollstring oder Menge einzelner Wörter interpretiert wird, hängt von Relation, Index und Server ab.

Für Wortfolge- oder Nachbarschaftssemantik ist eher adj relevant, sofern der Server diese Relation unterstützt:

dc.title adj "digitale Bibliothek"

exact zielt dagegen eher auf einen exakteren Feldwert. Auch hier entscheidet die Implementierung über Normalisierung und Vergleichslogik.

Bei Personen, Körperschaften und festen Fachbegriffen sind Anführungszeichen meist sinnvoll:

dc.creator = "Thomas Mann"dc.subject = "Open Access"dc.title exact "Die Vermessung der Welt"

Datums- und Zahlenvergleiche

Abfragen wie diese sind in CQL syntaktisch naheliegend:

dc.date >= "2020"

Ob sie chronologisch oder numerisch korrekt funktionieren, hängt jedoch vom Zielsystem ab.

Das Feld muss passend indexiert sein. Außerdem muss der Server eine geeignete Vergleichslogik für Zahlen oder Datumswerte unterstützen.

Bei vollständigen Datumswerten sind ISO-Formate oft robuster:

dc.date >= "2020-01-01"

Auch das garantiert keine chronologische Auswertung. Ohne passenden Datentyp oder Modifier kann ein Server lexikografisch vergleichen oder die Relation ablehnen.

Ein möglicher Modifier für ISO-Datumswerte kann so aussehen:

dc.date >=/cql.isoDate "2020-01-01"

Ob dieser Modifier unterstützt wird, müssen Sie in der Dokumentation oder über explain prüfen.

Relation Modifier

CQL kennt Relation Modifier, mit denen Relationen genauer beschrieben werden können. Ihre Unterstützung ist stark serverabhängig.

Modifier können sich zum Beispiel auf folgende Aspekte beziehen:

• Wortvergleich oder Stringvergleich
• numerische Vergleiche
• ISO-Datumsvergleiche
• Groß- und Kleinschreibung
• Akzentbehandlung
• Stemming
• Relevanzorientiertes Matching
• phonetische Suche
• unscharfe Suche
• Maskierung oder Wildcards

Beispiele können je nach Server so aussehen:

dc.title =/relevant "Informationsmanagement"dc.subject any/stem "libraries archives"dc.date >=/cql.isoDate "2020-01-01"

/relevant beeinflusst nicht automatisch die Sortierung. Es kann die Matching-Semantik beeinflussen, wenn der Server dies unterstützt.

Nicht jeder Server versteht diese Modifier. Eine unbekannte Erweiterung kann zu einer Fehlermeldung oder zu abweichender Interpretation führen.

Boolesche Operatoren

Mit booleschen Operatoren kombinieren Sie mehrere Bedingungen. CQL unterstützt insbesondere:

• and
• or
• not

Beispiel mit and:

dc.title = "Datenmanagement" and dc.date >= "2020-01-01"

Diese Anfrage kombiniert ein Titelkriterium mit einem Datums- oder Jahreskriterium.

Beispiel mit or:

dc.creator = "Goethe" or dc.creator = "Schiller"

Diese Anfrage sucht nach Datensätzen mit Goethe oder Schiller.

Beispiel mit not:

dc.subject = "Digitalisierung" not dc.title = "Einführung"

In Standard-CQL ist not ein binärer boolescher Operator. Die Form A not B entspricht praktisch „A und nicht B“.

Die Schreibweise A and not B ist in Standard-CQL nicht korrekt, auch wenn einzelne Systeme sie tolerant akzeptieren können.

Klammern, Präzedenz und Auswertungsreihenfolge

CQL definiert Regeln für die Gruppierung und Auswertung von Ausdrücken. Dennoch sind Klammern für Lesbarkeit und Implementierungssicherheit empfehlenswert.

Boolesche Ausdrücke werden ohne Klammern nicht immer so verstanden, wie Sie es aus anderen Suchsprachen erwarten.

Beispiel mit eindeutiger Gruppierung:

(dc.subject = "Bibliothek" or dc.subject = "Archiv") and dc.date >= "2015-01-01"

Diese Abfrage bildet zuerst die thematische Alternative und kombiniert sie dann mit dem Datum.

CQL-Ausdrücke sind in der Praxis häufig linksassoziativ. Bei mehreren Operatoren sollten Sie dennoch nicht auf implizite Auswertung vertrauen.

Gerade bei gespeicherten Suchprofilen, Schnittstellenprozessen und Migrationen sollten Sie Klammern großzügig verwenden.

Reservierte Wörter und CQL-Grammatik

Bestimmte Wörter haben in CQL eine besondere Bedeutung. Dazu gehören insbesondere Operatoren und syntaktische Schlüsselwörter.

Wichtige reservierte Wörter sind:

• and
• or
• not
• prox
• sortBy

Wenn solche Wörter als Suchterm verwendet werden, sollten Sie sie als String in Anführungszeichen setzen.

Beispiel:

dc.title = "and"

Auch Sonderzeichen, Anführungszeichen und Backslashes müssen korrekt behandelt werden.

Eine syntaktisch korrekte CQL-Abfrage ist nicht automatisch semantisch ausführbar. Der Server muss Index, Relation und Modifier unterstützen.

Näheoperator prox

CQL kann den Operator prox für Nähe- und Abstandsabfragen unterstützen. Damit suchen Sie Begriffe, die nahe beieinanderstehen.

Beispiel:

dc.title = "digital" prox/unit=word/distance<3 dc.title = "bibliothek"

Diese Abfrage ist nur sinnvoll, wenn der Server prox und die angegebenen Modifier unterstützt.

Näheabfragen sind besonders implementierungsabhängig. Tokenisierung, Wortgrenzen, Satzzeichen und Sprachverarbeitung beeinflussen die Ergebnisse stark.

Escaping von Sonderzeichen

Wenn Suchterme Anführungszeichen oder Backslashes enthalten, müssen sie in CQL maskiert werden.

Beispiel für ein Anführungszeichen im Suchterm:

dc.title = "Er sagte \"Ja\""

Beispiel für einen Backslash:

dc.title = "Pfad \\ Beispiel"

Die genaue Behandlung weiterer Sonderzeichen hängt vom Parser des Zielsystems ab.

Bei SRU kommt zusätzlich URL-Kodierung hinzu. CQL-Escaping und URL-Kodierung sind zwei verschiedene Verarbeitungsschritte.

Trunkierung, Maskierung und Wildcards

Viele CQL-Implementierungen unterstützen Wildcards oder Maskierung. Häufig begegnen Ihnen * für mehrere Zeichen und ? für ein einzelnes Zeichen.

Beispiele:

dc.title = "Bibliothek*"dc.creator = "M?ller"

Diese Schreibweise kann funktionieren, muss es aber nicht. CQL-Server können Wildcards als Suchfunktion oder als normale Zeichen behandeln.

Manche Server verlangen spezielle Modifier, etwa für maskierte oder unmaskierte Suche. Andere deaktivieren Wildcards aus Performancegründen.

Beispiele für mögliche Modifier sind:

dc.title =/masked "Bibliothek*"dc.title =/unmasked "Bibliothek*"

Ob solche Modifier verfügbar sind, hängt vom Server ab.

Prüfen Sie außerdem, ob Wildcards am Wortanfang erlaubt sind. Führende Wildcards können Suchindizes stark belasten.

Unicode, Umlaute und Normalisierung

Im deutschsprachigen Bibliothekskontext sind Umlaute, Diakritika und Schreibvarianten besonders wichtig.

Ein Server kann Müller, Mueller und Muller unterschiedlich oder als äquivalent behandeln.

Auch Akzente, Ligaturen, Unicode-Normalisierung und Transliteration können Treffer beeinflussen.

Beispiele:

dc.creator = "Müller"dc.creator = "Mueller"

Bei produktiven Workflows sollten Sie testen, welche Normalisierung das Zielsystem verwendet.

Das betrifft besonders Personen, Körperschaften, fremdsprachige Titel, Normdaten und historisch gewachsene Metadaten.

Sortierung mit sortBy und sortKeys

CQL kann Sortierung über sortBy innerhalb der CQL-Abfrage ausdrücken, sofern der Server dies unterstützt.

Beispiel:

dc.subject = "Open Access" sortBy dc.date/sort.descending

Eine Sortierung kann nach Datum, Titel, Relevanz oder anderen Indizes erfolgen, sofern der Server diese Sortierschlüssel anbietet. Nicht jede syntaktisch plausible Sortierung ist ausführbar. Häufig dürfen nur speziell definierte Sortierindizes genutzt werden.

Davon zu unterscheiden ist sortKeys als älterer oder implementierungsspezifischer SRU-Request-Parameter.

In SRU-Parametern sollte klar zwischen verschiedenen Mechanismen der Sortierung unterschieden werden.

sortBy ist ein Bestandteil der CQL-Abfragesyntax und wird direkt innerhalb der Suchanfrage verwendet. sortKeys hingegen ist ein SRU-Parameter, der insbesondere in älteren oder bestimmten Implementierungen genutzt wird.

Zusätzlich können lokale Sortierparameter vorkommen, die systemspezifische Erweiterungen darstellen und nicht standardisiert sind.

Grundsätzlich sollte immer geprüft werden, welche Form der Sortierung die jeweilige Schnittstelle tatsächlich erwartet.

Beispiele für CQL-Abfragen

Die folgenden Beispiele zeigen typische CQL-Muster. Ob sie tatsächlich funktionieren, hängt von den verfügbaren Indizes, Relationen und den Fähigkeiten des jeweiligen Servers ab.

Für eine Suche nach dem Titel kann beispielsweise dc.title = "Informationsmanagement" verwendet werden. Die Standardsuche erfolgt häufig über cql.serverChoice = "Faust".

Eine Autorensuche erfolgt über dc.creator = "Umberto Eco", während weitere beteiligte Personen über dc.contributor = "Max Mustermann" abgefragt werden können. Für Schlagwörter wird typischerweise dc.subject = "Bibliothekswesen" genutzt.

Ein Identifier kann über dc.identifier = "10.1000/example" abgefragt werden. Lokale Erweiterungen ermöglichen spezifischere Suchen, etwa bib.isbn = "9783161484100" für ISBN, bib.issn = "1234-5678" für ISSN, local.gnd = "118540238" für die GND oder local.orcid = "0000-0002-1825-0097" für ORCID.

Kombinierte Abfragen sind ebenfalls möglich, zum Beispiel dc.subject = "Open Access" and dc.date >= "2018-01-01" für Thema und Zeitraum. Ausschlüsse lassen sich mit not formulieren, etwa dc.subject = "Digitalisierung" not dc.title = "Einführung".

Falls unterstützt, kann auch die Wortfolge berücksichtigt werden, z. B. dc.title adj "digitale Bibliothek". Für die Sortierung wird beispielsweise dc.subject = "Open Access" sortBy dc.date/sort.descending verwendet.

Lokale Indizes wie bib.isbn, local.gnd oder local.orcid sind jedoch keine allgemeinen CQL-Standardindizes.

CQL und SRU in der Praxis

SRU überträgt CQL-Abfragen an einen Server. Die wichtigste Operation ist dabei in der Regel searchRetrieve.

Typische SRU-Parameter sind:

• version: SRU-Version, zum Beispiel 1.2
• operation: Operation, meist searchRetrieve, explain oder scan
• query: CQL-Abfrage als URL-kodierter Parameterwert
• startRecord: Startposition innerhalb der Trefferliste
• maximumRecords: maximale Anzahl zurückgegebener Treffer
• recordSchema: gewünschtes Metadatenschema
• recordPacking: Format der Datensatzverpackung, zum Beispiel XML oder String
• sortKeys: älterer oder implementierungsspezifischer SRU-Sortierparameter

SRU-Antworten können verschiedene Metadatenschemata enthalten, abhängig vom Server.

Typische Formate oder Schemas sind:

• Dublin Core
• MARCXML
• MODS
• PICA/XML
• lokale XML-Formate
• normdatenbezogene Schemas
• in Einzelfällen Container- oder Strukturformate wie METS

METS kann vorkommen, ist aber eher ein Container- und Strukturformat als ein typisches Schema für einfache Suchtreffer.

Welches Schema sinnvoll ist, hängt vom Anwendungsfall ab. Für Anzeigezwecke reicht oft Dublin Core, für Katalogisierung eher MARCXML oder PICA/XML.

Die SRU-Operation explain

Mit der Operation explain können SRU-Server ihre Fähigkeiten beschreiben. Das ist ein wichtiger erster Schritt bei der Arbeit mit CQL.

Eine Explain-Anfrage kann so aussehen:

https://example.org/sru?version=1.2&operation=explain

Explain-Antworten verwenden häufig ZeeRex, ein XML-Format zur Beschreibung von Search-Retrieve-Diensten.

Die Antwort kann Informationen enthalten zu:

• unterstützten Indizes
• Kontextsets
• Relationen
• Relation Modifiern
• Sortiermöglichkeiten
• Record Schemas
• Diagnosecodes
• Serverlimits
• Beispielabfragen

Ein stark vereinfachter Auszug kann so aussehen:

<index>
 <title>Title</title>
 <map>
   <name set="dc">title</name>
 </map>
</index>

Daran erkennen Sie, dass ein Titelindex im Dublin-Core-Kontext angeboten wird.

Nicht jeder Server dokumentiert alles vollständig. Trotzdem ist explain oft hilfreicher als blindes Ausprobieren.

Die SRU-Operation scan

Neben searchRetrieve und explain kann SRU auch scan unterstützen.

scan dient dem Browsing von Indextermen. Damit können Sie beispielsweise in einem Titel-, Schlagwort- oder Namensindex blättern.

Ein Beispiel kann so aussehen:

https://example.org/sru?version=1.2&operation=scan&scanClause=dc.subject%3D%22Bibliothek%22

Ob scan verfügbar ist und welche Indizes browsefähig sind, hängt vom Server ab.

Für kontrollierte Vokabulare, Schlagwortlisten oder Normdaten kann scan besonders hilfreich sein.

Result Sets in SRU und CQL

Einige SRU-Server können Ergebnislisten serverseitig speichern. CQL kann dann über cql.resultSetId auf ein solches Result Set verweisen.

Beispiel:

cql.resultSetId = "set123"

Solche Funktionen sind nicht selbstverständlich. Sie hängen von Serverkonfiguration, Result-Set-Unterstützung und einer möglichen Result Set TTL ab.

Die Result Set TTL beschreibt, wie lange ein gespeichertes Ergebnis-Set verfügbar bleibt.

Für produktive Clients sollten Sie nie voraussetzen, dass Result Sets dauerhaft oder überhaupt unterstützt werden.

Paginierung über startRecord und maximumRecords ist meist verlässlicher als die Annahme stabiler serverseitiger Result Sets.

Fehlermeldungen und Diagnostics

SRU kann Diagnostics zurückgeben, wenn eine Anfrage nicht verarbeitet werden kann. Solche Fehler sind bei CQL-Abfragen normal.

Typische Ursachen sind:

• ungültige CQL-Syntax
• unbekannter Index
• nicht unterstützte Relation
• nicht unterstützter Modifier
• falsches Kontextpräfix
• ungültige Sortierung
• zu lange Anfrage
• zu viele Treffer
• interne Serverbegrenzung

Typische Diagnosefälle sind:

• Query syntax error: fehlerhafte CQL-Grammatik
• Unsupported index: der angegebene Index wird vom Server nicht angeboten
• Unsupported relation: die verwendete Relation wird für den Index nicht unterstützt
• Unsupported relation modifier: der verwendete Modifier ist unbekannt oder nicht erlaubt
• Unsupported sort: der Sortierschlüssel oder die Sortierrichtung wird nicht unterstützt
• Too many records: die Anfrage überschreitet serverseitige Begrenzungen

Auch eine syntaktisch korrekte CQL-Abfrage kann somit fehlschlagen, wenn der Server die verwendeten Indizes, Relationen oder Funktionen semantisch nicht unterstützt.

Bei produktiven Workflows sollten Sie Diagnostics protokollieren. So erkennen Sie Änderungen im Serververhalten oder in Schnittstellen.

CQL im deutschen Bibliothekskontext

Im deutschen Bibliotheksumfeld begegnet Ihnen CQL häufig bei SRU-Schnittstellen von Katalogen, Verbundsystemen, Repositorien und Normdatendiensten.

Typische Szenarien sind:

• Recherche in Verbundkatalogen
• Abfragen gegen DNB-SRU-Schnittstellen
• Suche in GND-bezogenen Diensten
• Metadatenabgleich für Repositorien
• Validierung von Importdaten
• Prüfung von ISBN, ISSN, DOI oder URN
• Anreicherung lokaler Daten mit Normdaten

Auch Schnittstellen im Umfeld von K10plus, B3Kat oder anderen Verbundsystemen können CQL oder CQL-nahe Suchprofile anbieten.

Die konkreten Indexnamen müssen Sie jedoch immer aus der jeweiligen Dokumentation entnehmen.

Gerade bei Normdaten ist die Wahl des richtigen Index entscheidend. Eine Namenssuche ist weniger eindeutig als eine Suche über GND, ORCID, ROR oder ISNI.

Beispielhafte lokale Suche nach einer GND-ID:

local.gnd = "118540238"

Diese Schreibweise ist kein allgemeiner CQL-Standard. Sie steht exemplarisch für systemabhängige Normdatenindizes.

Identifier, Normdaten und kontrollierte Vokabulare

Identifikatoren sind für zuverlässige Datenabgleiche besonders wertvoll. Dazu zählen ISBN, ISSN, DOI, URN, GND, ORCID, ROR und ISNI.

Bei Identifiern sollten Sie auf Normalisierung achten:

• ISBN mit oder ohne Bindestriche
• ISSN mit Prüfziffer X
• DOI mit oder ohne https://doi.org/
• URN mit unterschiedlicher Groß- und Kleinschreibung
• GND als Nummer oder URI
• ORCID mit oder ohne URI-Form
• ROR als URL
• ISNI mit oder ohne Leerzeichen

Beispielvarianten einer ISBN:

bib.isbn = "978-3-16-148410-0"bib.isbn = "9783161484100"

Für robuste Workflows ist es oft sinnvoll, Identifier vor der Abfrage zu normalisieren.

Kontrollierte Vokabulare und Normdaten verbessern die Trefferqualität. Sie reduzieren Mehrdeutigkeiten bei Personen, Körperschaften und Themen.

CQL kann diese Qualität nutzen, wenn passende Indizes vorhanden sind. Ohne entsprechende Indizes bleibt oft nur eine weniger präzise Textsuche.

CQL in Discovery-Systemen

Discovery-Systeme können CQL über Schnittstellen unterstützen, müssen es aber nicht. Viele nutzen intern Solr, Lucene oder Elasticsearch.

Wenn ein Discovery-System CQL akzeptiert, wird die Anfrage häufig intern in eine andere Suchsyntax übersetzt.

Das kann zu Abweichungen führen. Relevanzranking, Facetten, Tokenisierung und Normalisierung folgen dann oft der internen Suchmaschine.

Typische Übersetzungsverluste betreffen:

• exact gegenüber analysierten Suchfeldern
• adj gegenüber Phrase Queries
• Datumsrelationen gegenüber String-Feldern
• Wildcards und Performancebegrenzungen
• lokale Indexmappings
• Relevanzberechnung und Sortierung

Prüfen Sie daher, ob CQL direkt unterstützt wird oder nur über eine spezielle SRU-Schicht verfügbar ist.

CQL und Z39.50

CQL entstand auch als besser lesbare Alternative zu komplexeren Suchformen wie Z39.50 Type-1-Queries.

Z39.50 ist ein älteres Protokoll für bibliografische Recherche. Es arbeitet mit Attributsets und binäreren Protokollstrukturen.

CQL ist textbasiert und dadurch leichter zu lesen, zu protokollieren und in URLs zu übertragen.

In manchen Systemen wird CQL intern auf Z39.50-Attribute oder andere Suchmodelle abgebildet. Auch dabei können semantische Unterschiede entstehen, etwa bei Indexmappings, Relationen und Normalisierung.

CQL in automatisierten Workflows

Der größte Nutzen von CQL entsteht oft in automatisierten Informationsprozessen. Dort müssen Abfragen wiederholbar und nachvollziehbar sein.

Typische Workflows sind:

• regelmäßige Suche nach neuen Datensätzen
• Prüfung vorhandener ISBNs
• Abgleich vor Importen
• Dublettenprüfung
• Aktualisierung von Discovery-Indizes
• Validierung von Migrationsdaten
• Anreicherung lokaler Metadaten
• Kontrolle von Normdatenverknüpfungen
• Analyse von Beständen nach Thema oder Zeitraum

Beispiel für eine ISBN-Prüfung:

bib.isbn = "9783161484100"

Beispiel für eine thematische Aktualisierung:

dc.subject = "Forschungsdatenmanagement" and dc.date >= "2022-01-01"

Solche Abfragen können in Skripte, Schnittstellenprozesse oder Administrationswerkzeuge eingebunden werden.

CQL und Datenqualität

CQL kann nur so gute Ergebnisse liefern, wie es die zugrunde liegenden Daten erlauben. Metadatenqualität beeinflusst Treffer direkt.

Typische Probleme sind:

• fehlende ISBNs oder ISSNs
• uneinheitliche Namensformen
• fehlende Normdatenverknüpfungen
• uneinheitliche Schlagwörter
• nicht normierte Datumswerte
• Dubletten mit abweichenden Feldern
• lokale Sonderfelder ohne Dokumentation
• unterschiedliche Transliteration

CQL kann Datenqualitätsprobleme sichtbar machen, wenn geeignete Indizes vorhanden sind.

Eine allgemeine NULL- oder NOT-EXISTS-Semantik gehört jedoch nicht zuverlässig zum CQL-Kern. Abfragen nach fehlenden Feldern benötigen meist lokale Indizes.

Beispielhaft könnte ein Server einen speziellen Index anbieten:

local.missingIdentifier = "true"

Diese Schreibweise ist rein systemabhängig. Sie funktioniert nur, wenn das Zielsystem sie explizit unterstützt.

Sicherheit und Betrieb

CQL-Schnittstellen sind häufig öffentlich oder halböffentlich erreichbar. Deshalb spielen Betriebsgrenzen und Schutzmechanismen eine wichtige Rolle.

Achten Sie besonders auf:

• Rate Limits
• Timeouts
• maximale Abfragelänge
• maximale Trefferzahl
• Einschränkungen bei Wildcards
• Authentifizierung
• IP-basierte Zugriffskontrolle
• Caching
• Protokollierung
• Schutz vor teuren Abfragen

Sehr breite Abfragen, führende Wildcards oder komplexe Näheabfragen können Server stark belasten.

Bei Nutzereingaben sollten Sie keine ungeprüften Werte direkt in CQL einfügen.

Escapen Sie Sonderzeichen, begrenzen Sie Query-Längen und erlauben Sie nur geprüfte Indexnamen, Relationen und Sortierschlüssel.

Für produktive Clients sind außerdem wichtig:

• Paginierung
• Retry-Strategien mit Backoff
• sinnvolle Timeouts
• Caching wiederholter Anfragen
• Logging von Requests und Diagnostics
• robuste Fehlerbehandlung
• Monitoring von Antwortzeiten und Fehlerquoten

Vergleich mit verwandten Standards und Suchsprachen

CQL ist nur ein Baustein im Informationsmanagement. Andere Standards erfüllen jeweils andere Aufgaben.

• CQL: strukturierte Suchsprache für Search-Retrieve-Szenarien
• SRU: HTTP-basierte Search-Retrieve-Schnittstelle
• SRW: SOAP-basierte Variante von Search-Retrieve
• Z39.50: älteres Protokoll für bibliografische Recherche
• OpenSearch: einfache webbasierte Suchschnittstellen
• OAI-PMH: Harvesting von Metadaten anhand von Sets und Zeitstempeln
• Solr/Lucene Syntax: Suchsyntax für Suchmaschinenindizes
• Elasticsearch DSL: JSON-basierte Abfragesprache für Elasticsearch

‍OAI-PMH ist keine Suchsprache wie CQL. Es dient primär dem Harvesting von Datensätzen, meist nach Sets und Änderungszeitpunkten.

Solr, Lucene und Elasticsearch sind in Discovery-Systemen weit verbreitet. CQL kann dort über zusätzliche Schnittstellen oder Übersetzungsschichten vorkommen.

Grenzen und typische Herausforderungen

CQL ist standardisiert, aber nicht jede Implementierung unterstützt alle Funktionen gleich. Die Ergebnisse hängen stark vom Zielsystem ab.

Typische Herausforderungen sind:

• unterschiedliche Indexnamen
• lokale Kontextsets und Suchschlüssel
• serverabhängige Bedeutung von =
• unterschiedliche Normalisierung
• abweichende Tokenisierung
• unvollständige Metadaten
• begrenzte Relation-Unterstützung
• fehlende Modifier
• eingeschränkte Sortierung
• URL-Kodierungsfehler
• Performancegrenzen bei komplexen Abfragen

Eine CQL-Abfrage kann formal korrekt sein und trotzdem keine sinnvollen Treffer liefern.

Prüfen Sie daher immer die Dokumentation, explain-Antworten und reale Testfälle.

Best Practices für CQL

Beginnen Sie bei neuen Systemen immer mit der Schnittstellendokumentation. Prüfen Sie anschließend die verfügbaren Indizes und Kontextsets.

Nutzen Sie nach Möglichkeit die SRU-Operation explain. Sie zeigt oft, welche Funktionen ein Server tatsächlich anbietet.

Starten Sie mit einfachen Abfragen:

dc.title = "Bibliothek"

Erweitern Sie die Anfrage erst, wenn Index, Relation und Suchterm erwartbare Ergebnisse liefern.

Verwenden Sie qualifizierte Indizes, wenn sie verfügbar sind:

dc.title = "Katalogisierung"

Unqualifizierte Indizes wie title können funktionieren, sind aber nicht systemübergreifend verbindlich.

Setzen Sie Anführungszeichen bei Wortgruppen:

dc.title = "digitale Bibliothek"

Nutzen Sie adj, wenn Sie eine Wortfolge ausdrücken wollen und der Server diese Relation unterstützt:

dc.title adj "digitale Bibliothek"

Nutzen Sie Klammern bei kombinierten Bedingungen:

(dc.title = "Bibliothek" or dc.subject = "Bibliothekswesen") and dc.date >= "2020-01-01"

Testen Sie exakte und breitere Varianten:

dc.title exact "Bibliotheksmanagement"dc.title = "Bibliotheksmanagement"

Dokumentieren Sie produktive Abfragen. Halten Sie Zielsystem, Version, Indizes, Relationen und erwartete Treffer fest.

Teststrategie für CQL-Abfragen

Eine systematische Teststrategie spart Zeit und verhindert Fehlinterpretationen.

Gehen Sie schrittweise vor:

1. Rufen Sie explain ab.
2. Prüfen Sie unterstützte Kontextsets.
3. Testen Sie eine einfache Standardsuche.
4. Testen Sie den gewünschten Index.
5. Testen Sie die benötigte Relation.
6. Ergänzen Sie boolesche Operatoren.
7. Testen Sie Klammern und Sortierung.
8. Prüfen Sie URL-Kodierung.
9. Validieren Sie Treffer gegen bekannte Beispiele.
10. Protokollieren Sie Fehlermeldungen und Diagnostics.

Diese Reihenfolge ist besonders hilfreich bei Migrationen, Schnittstellenanbindungen und automatisierten Workflows.

Mini-Spickzettel für CQL

Prüfen Sie jedes Muster gegen die konkrete Serverdokumentation. Nicht jeder Server unterstützt alle gezeigten Funktionen.

Typische Fehlerquellen

Viele CQL-Probleme entstehen nicht durch die Grundsyntax, sondern durch systemabhängige Details.

Häufige Fehler sind:

• unbekannte Indexnamen
• falsche Kontextpräfixe
• fehlende Anführungszeichen bei Mehrwort-Termen
• falsch gesetzte Klammern
• nicht unterstützte Relationen
• falsch kodierte URLs
• nicht maskierte Sonderzeichen
• Annahmen über exact
• Annahmen über adj
• Annahmen über Datumsvergleiche
• nicht normalisierte Identifier
• zu komplexe Abfragen
• fehlende Fehlerbehandlung

Wenn eine Abfrage keine Treffer liefert, bedeutet das nicht automatisch, dass keine passenden Datensätze vorhanden sind.

Prüfen Sie zuerst Index, Relation, Normalisierung, Kodierung und unterstützte Serverfunktionen.

Häufige Missverständnisse zu CQL

CQL wird gelegentlich mit anderen Technologien verwechselt. Besonders wichtig ist die Abgrenzung zu SQL.

SQL dient der Abfrage und Bearbeitung relationaler Datenbanken. CQL im Bibliothekskontext dient der Suche in Informationssystemen und Metadatenbeständen.

Es gibt außerdem die Cassandra Query Language, die ebenfalls CQL abgekürzt wird. Sie hat mit der bibliothekarischen Contextual Query Language nichts zu tun.

Ein weiteres Missverständnis betrifft die Standardisierung. CQL standardisiert die Abfragesyntax, aber nicht automatisch alle bibliografischen Suchfelder.

Auch identisch aussehende CQL-Abfragen können unterschiedliche Treffer liefern. Gründe sind Indexierung, Datenmodell, Normalisierung und Suchalgorithmus.

Anführungszeichen sind ebenfalls häufig missverstanden. Sie markieren einen String, garantieren aber keine bestimmte Phrasenlogik.

Häufige Fragen zu CQL

Was bedeutet CQL?

CQL bedeutet heute Contextual Query Language. Historisch wurde die Sprache auch als Common Query Language bezeichnet. Im Bibliothekskontext meint CQL eine strukturierte Suchsprache für Kataloge, Repositorien und andere Informationssysteme.

Wofür wird CQL verwendet?

CQL wird für präzise, feldbezogene und maschinenlesbare Suchanfragen verwendet. Typische Anwendungen sind Katalogrecherche, SRU-Schnittstellen, Verbundabfragen, Dublettenprüfungen, Metadatenabgleiche, Migrationen und Qualitätssicherung.

Ist CQL dasselbe wie SQL?

Nein. SQL ist eine Sprache für relationale Datenbanken. CQL im Bibliothekskontext ist eine Suchsprache für Informationssysteme. Außerdem gibt es die Cassandra Query Language, die ebenfalls CQL heißt.

Was ist der Unterschied zwischen CQL und SRU?

CQL ist die Suchsprache. SRU ist eine Search-Retrieve-Schnittstelle, mit der Suchanfragen an einen Server übertragen werden. In einer SRU-Anfrage steht die CQL-Abfrage meist im Parameter query.

Sind Indizes wie title oder creator standardisiert?

Nicht allgemein durch CQL selbst. CQL standardisiert vor allem die Syntax. Konkrete Indizes stammen aus Kontextsets wie Dublin Core oder aus lokalen Systemdefinitionen.

Was ist cql.serverChoice?

cql.serverChoice ist ein Index aus dem CQL-Kontextset. Er überlässt dem Server die Wahl des Standardsuchfelds. Er kann einer allgemeinen Suchbox ähneln, ist aber nicht zwingend identisch mit der Suche in der Benutzeroberfläche.

Kann ich CQL ohne Index verwenden?

Viele Implementierungen erlauben Abfragen ohne expliziten Index. Eine Anfrage wie "Faust" wird dann häufig auf einen Default-Index abgebildet, oft auf cql.serverChoice oder eine lokale Standardsuche.

Was bedeutet die Relation = in CQL?

= bedeutet in vielen Implementierungen eine server- oder indexabhängige Standardsuche. Sie ist nicht zwingend eine exakte Gleichheit und nicht automatisch eine einfache Enthält-Suche.

Was ist der Unterschied zwischen =, exact, all, any und adj?

= steht meist für die Standardsuche des Servers. exact ist enger, aber nicht immer absolut exakt. all verlangt üblicherweise alle Terme, any mindestens einen Term. adj ist für benachbarte Wörter oder Wortfolgen relevant.

Sind Anführungszeichen dasselbe wie Phrasensuche?

Nein. Anführungszeichen markieren in CQL primär einen Suchterm als String. Ob daraus eine Phrasen-, Wortfolge- oder Vollstringsuche wird, hängt von Relation, Index und Server ab.

Warum ist dc.title = digitale Bibliothek problematisch?

Mehrwort-Terme ohne Anführungszeichen sind in vielen CQL-Parsern syntaktisch ungültig. Schreiben Sie stattdessen normalerweise dc.title = "digitale Bibliothek".

Ist exact wirklich exakt?

exact ist meist enger als =, aber nicht immer absolut exakt. Normalisierung, Groß- und Kleinschreibung, Akzentbehandlung, Interpunktion und Indexierung können die Ergebnisse beeinflussen.

Wie schließe ich Treffer in CQL aus?

In Standard-CQL verwenden Sie den binären Operator not. Ein Beispiel ist dc.subject = "Digitalisierung" not dc.title = "Einführung".

Ist A and not B korrektes CQL?

In Standard-CQL ist not ein binärer boolescher Operator. Standardkonform ist daher A not B. Einzelne Server können A and not B tolerant interpretieren, Sie sollten sich darauf aber nicht verlassen.

Kann ich mit CQL nach ISBN suchen?

Ja, wenn das Zielsystem einen passenden Index anbietet. Eine Suche über dc.identifier kann funktionieren, präziser ist aber oft ein spezieller ISBN-Index wie bib.isbn.

Kann ich mit CQL nach Normdaten suchen?

Ja, sofern das Zielsystem geeignete Indizes bereitstellt. Für GND, ORCID, ROR oder ISNI benötigen Sie häufig spezielle lokale Indizes oder definierte Suchschlüssel.

Warum liefern gleiche CQL-Abfragen unterschiedliche Ergebnisse?

CQL standardisiert die Syntax, aber nicht die interne Suchlogik jedes Systems. Unterschiede entstehen durch Indexierung, Mapping, Normalisierung, Datenqualität, Tokenisierung und unterstützte Relationen.

Was ist die SRU-Operation explain?

explain liefert Informationen über die Fähigkeiten eines SRU-Servers. Dazu können unterstützte Indizes, Kontextsets, Relationen, Record Schemas, Sortierungen und Servergrenzen gehören.

Was ist die SRU-Operation scan?

scan dient dem Browsing von Indextermen. Damit können Sie beispielsweise Schlagwörter, Namen oder Titelanfänge durchsuchen, sofern der Server diese Operation unterstützt.

Welche Antwortformate kann SRU liefern?

Das hängt vom Server ab. Häufig sind Dublin Core, MARCXML, MODS, PICA/XML oder lokale XML-Schemas. Das gewünschte Schema wird oft über den Parameter recordSchema angegeben.

Was ist der Unterschied zwischen sortBy und sortKeys?

sortBy ist typischerweise Bestandteil der CQL-Abfrage. sortKeys ist ein älterer oder implementierungsspezifischer SRU-Parameter und wird nicht von jedem Server unterstützt.

Muss ich CQL lernen, um einen Bibliothekskatalog zu nutzen?

Für normale Recherchen meist nicht. CQL ist vor allem für Administratorinnen, Entwickler, Systemintegratoren und Fachpersonal relevant, das Schnittstellen oder automatisierte Datenprozesse nutzt.

Unterstützt jedes Bibliothekssystem CQL?

Nein. CQL wird häufig in SRU-fähigen Systemen eingesetzt, ist aber nicht überall verfügbar. Viele Discovery-Systeme nutzen intern Solr, Lucene oder Elasticsearch und bieten CQL höchstens über spezielle Schnittstellen an.

Was muss ich bei URL-Kodierung beachten?

Wenn CQL in einer URL übertragen wird, muss der CQL-Ausdruck als Parameterwert korrekt URL-kodiert werden. Aus dc.title = "Faust" wird beispielsweise dc.title%20%3D%20%22Faust%22.

Kann CQL nach fehlenden Feldern suchen?

Nicht allgemein zuverlässig. CQL hat keine universelle NULL- oder NOT-EXISTS-Semantik. Solche Abfragen benötigen meist spezielle lokale Indizes, Relationen oder Suchprofile des Zielsystems.

Welche Fehler treten bei CQL häufig auf?

Häufig sind unbekannte Indizes, falsche Präfixe, fehlende Anführungszeichen, nicht unterstützte Relationen und fehlerhafte URL-Kodierung. Auch nicht normalisierte Identifier und falsche Annahmen über exact, adj oder Datumsvergleiche führen oft zu Problemen.