Glossar
Fach- und technische Begriffe, denen Sie bei der Arbeit mit ddb begegnen. Die Optionsreferenz
finden Sie in der README, das vollständige Kochbuch in Usage.md.
ddb nutzt die v2-API der DDB (https://api.deutsche-digitale-bibliothek.de/2).
Ihre Lese-Routen – Suche, Objekt, Version – sind öffentlich: kein API-Schlüssel.
Die DDB und ihre Daten
Deutsche Digitale Bibliothek (DDB). Deutschlands nationaler Aggregator für digitalisiertes Kultur- und Wissenschaftserbe. Sie verwahrt selbst keine Objekte, sondern sammelt Metadaten von rund 500 Partnereinrichtungen (Archive, Bibliotheken, Museen, Forschungseinrichtungen) und bietet eine gemeinsame Suche über alle an.
Objekt / Item. Ein einzelnes katalogisiertes Stück – ein Buch, ein Bild, eine Archivalie, ein
Notenblatt, ein Film, eine Tonaufnahme usw. Es wird über eine 32-stellige ID aus
Großbuchstaben und Ziffern identifiziert (z. B. TNPFDKO2VDGBZ72RWC6RKDNZYZQZP3XK); das ist der
Wert von id in einem Suchtreffer und das Argument für ddb item. Leerraum am Anfang und Ende
wird ignoriert; jede andere ID wird vor einer Anfrage abgelehnt, von der CLI wie von der
Bibliothek.
Einrichtung / Provider. Ein Datenpartner, der Objekte liefert. Diese CLI hat keinen eigenen
Befehl institutions; filtern oder aggregieren Sie stattdessen über die Facette
provider_fct (--facet provider_fct oder --filter provider_fct:"…").
Sparte. Der Kulturbereich, zu dem die liefernde Einrichtung eines Objekts gehört, abgebildet
als Facette sector_fct mit den Codes sec_01..sec_07: Archiv, Bibliothek,
Denkmalpflege, Forschung, Mediathek, Museum, Sonstige.
Suche
v2 = Solr-Passthrough. In v2 ist ddb search ein dünner Wrapper um den Apache-Solr-Index
der DDB (GET /2/search/index/{collection}/{requestHandler}, standardmäßig
search/select). Ihre Optionen werden auf native Solr-Abfrageparameter abgebildet, und die
Antwort ist natives Solr-JSON, keine von der DDB aufbereitete Antwortstruktur. --handler
wählt einen anderen Request-Handler, unterstützt werden aber nur Handler, die Solrs
Standard-Antwortstruktur response (numFound, docs) liefern – select tut das; einer, der
anders antwortet (etwa ein Echtzeit-get), scheitert mit einer Fehlermeldung, die
den Handler nennt. Für andere Formen gibt es keinen Ausweichweg.
Solr-/Lucene-Abfragesyntax. search-Abfragen verwenden einfache Suchbegriffe, Phrasen in
Anführungszeichen ("quoted phrases"), die booleschen Operatoren AND/OR/NOT, feldbezogene
Terme (title:Faust), Bereiche und *:* als Treffer für alle Dokumente.
q (die Abfrage). Der oder die Suchbegriffe. Pflichtangabe; übergeben Sie '*:*', um alle
Objekte zu durchstöbern. ddb search begrenzt die Treffer standardmäßig auf --rows 10;
search() in der Bibliothek sendet denselben Standardwert (DEFAULT_SEARCH_ROWS).
rows / start. --rows ist die Seitengröße (Solr rows); --offset gibt an, wie viele
Dokumente am Anfang übersprungen werden (Solr start). Zusammen blättern sie durch eine
Ergebnismenge. Ein Offset ab numFound ist upstream kein Fehler (leeres docs); die CLI
weist auf stderr darauf hin.
Antwortstruktur. Eine Solr-Antwort hat vier Teile, die für Sie relevant sind:
| Pfad | Bedeutung |
|---|---|
response.numFound |
Gesamtzahl der Treffer – lesen Sie diesen Wert für „wie viele passen?“ |
response.start |
Offset des ersten zurückgegebenen Dokuments (der --offset, zu dem Sie geblättert haben) |
response.docs[] |
die Dokumente dieser Seite (jedes mit einer id und weiteren Solr-Feldern) |
facet_counts.facet_fields.<field> |
Facettenwerte mit Anzahl, wenn --facet verwendet wurde |
Dokumentfelder. Jeder Eintrag in docs[] enthält die id des Items und viele Solr-Felder –
häufig label / title (Anzeigetext), type (Medientyp-Codes), objecttype, place /
place_fct, provider / provider_fct, preview (URL des Vorschaubilds), license. Die
Felder unterscheiden sich je nach Objekt; wählen Sie mit jq aus, was Sie brauchen.
Facette. Ein Feld, nach dem der Index gruppieren und zählen kann – Objekttyp, Ort,
Einrichtung, Sprache, Sparte, Zeit. --facet <field> weist Solr an, für dieses Feld die Anzahl
je Wert zurückzugeben, und zwar in facet_counts.facet_fields.<field> als flaches Array
[value, count, value, count, …]. Das Array kann Werte mit der Anzahl 0 enthalten, und die
Werte kommen so, wie die Einrichtungen sie erfasst haben (place_fct enthält München neben
München, Oktoberfest).
*_fct-Felder. Die Namen der Facettenfelder der DDB enden auf _fct. Die gebräuchlichsten:
| Feld | Facettiert nach | Wertform |
|---|---|---|
type_fct |
Medientyp | Codes wie mediatype_002 (siehe unten) |
objecttype_fct |
Objekttyp | Wörter (Druckgraphik, …) |
place_fct |
Ort | Ortsnamen |
provider_fct |
liefernde Einrichtung | Namen der Einrichtungen |
sector_fct |
Sparte | sec_01..sec_07 |
language_fct |
Sprache | Sprachcodes |
keywords_fct |
Schlagwörter | Wörter |
begin_time / end_time |
Zeitraum | Tagesnummern, keine Jahre: 660725 = 1. Januar 1810 (Python date.toordinal() + 1) |
mimetype_fct |
MIME-Typ der Medien | MIME-Typen |
Es gibt kein time_fct und keine Facette für Bundesländer: time_fct und state_fct sind
undefinierte Felder, ihre Verwendung scheitert mit HTTP 500 (Exit-Code 1).
Die type_fct-Codes, benannt nach dem Wert item.media der Objekte (Stichprobe vom
15.09.2026): mediatype_001 Audio, mediatype_002 Bild, mediatype_003 Text,
mediatype_005 Video, mediatype_007 unbekannt (kein Digitalisat, nur Metadaten),
mediatype_010 3D.
--facet vs. --filter. --facet type_fct weist Solr an, für dieses Feld Anzahlen
zurückzugeben (damit Sie sehen, worauf Sie eingrenzen können). --filter nimmt eine rohe
Solr-Filterabfrage (fq) entgegen, die die Ergebnismenge einschränkt, z. B.
--filter place_fct:"Berlin" oder --filter type_fct:mediatype_002. Wiederholen Sie
--filter, um mehrere Bedingungen mit AND zu verknüpfen; ein OR formulieren Sie innerhalb
einer fq (--filter 'place_fct:("Berlin" OR "Dessau")').
sort. Solr-Sortiersyntax: <field> asc|desc, z. B. --sort "score desc" (Relevanz, der
Standard, wenn nichts angegeben ist) oder --sort "id asc". Weitere Kriterien für Gleichstände
trennen Sie mit Komma ab (--sort "score desc, id asc").
fields (fl). --fields id,label,type beschränkt jedes zurückgegebene Dokument auf diese
Felder (Solr fl) – der sauberste Weg, ausführliche Dokumente zu bändigen.
Objektbestandteile
Objektbestandteile. ddb item <id> --part <component> ruft einen Bestandteil eines Objekts
ab. Die meisten sind JSON; einige werden als XML oder als einfache Datei geliefert und roh
ausgegeben (damit sie bei > file.xml und in Pipes unverändert bleiben):
Bestandteil (--part) |
Bedeutung | Format |
|---|---|---|
view (Standard) |
der Datensatz, aus dem eine Objektseite im DDB-Frontend aufgebaut wird – die zugänglichste Ansicht | JSON |
aip |
das Archive Information Package (der vollständige Datensatz) | JSON |
edm |
der Datensatz im Europeana Data Model – dem standardisierten, interoperablen Profil, das die DDB mit Europeana teilt | RDF/XML |
binaries |
zugehörige Binärdateien (Vorschaubilder, Medien) mit ihren URLs | JSON |
children / parents |
die direkten Kind-Objekte eine Ebene tiefer / die ganze Kette nach oben, beginnend mit dem Objekt selbst und endend mit seiner Einrichtung (Findmittel, mehrteilige Werke) | JSON |
source |
die Metadaten der Ingest-Quelle | JSON |
source-description |
eine Beschreibung des Quelldatensatzes | JSON |
source-record |
der rohe Datensatz der liefernden Einrichtung (METS/MODS, LIDO, MARCXML, …); bei einem Teilobjekt (Abschnitt eines Buchs, Verzeichnungseinheit eines Findbuchs) oft der ganze Datensatz eines übergeordneten Objekts, mit einem Hinweis, der es nennt | XML |
iiif |
das IIIF-Presentation-Manifest (nur wenn das Objekt eines hat) | JSON |
citation |
eine Zitier-/Zitatdatei für eine Zeitungsausgabe (nur wo zutreffend) | BIB-Datei |
--part childrenakzeptiert zusätzlich--rows/--offset, um durch eine große Menge von Kind-Objekten zu blättern.--lang <code>legt die bevorzugte Sprache der Bezeichnungen fürview/aip/edm/binaries/source/source-descriptionfest; hat ein Objekt keinen Datensatz in dieser Sprache, antwortet die API mit404(beobachtet bei--lang en). Alle anderen Komponenten ignorieren diese Optionen bei der API, deshalb lehnen CLI und Bibliothek sie dort vor einer Anfrage ab.
Authentifizierung & Rechte
Kein API-Schlüssel. Die Lese-Routen, die diese CLI nutzt, sind öffentlich – Suche, Objekt
und Version funktionieren anonym. Ein 403 ist daher ungewöhnlich und bedeutet, dass
--base-url auf einen authentifizierten Endpoint zeigt oder der konkrete Objektbestandteil
zugriffsbeschränkt ist – nicht, dass Sie einen Schlüssel brauchen.
CC0 1.0. Die Creative-Commons-Widmung „keine Rechte vorbehalten“, mit der Werke in die Gemeinfreiheit entlassen werden. Die DDB-API liefert Metadaten ausschließlich unter CC0 – frei nachnutzbar, ohne Pflicht zur Namensnennung.
Rechtehinweis / Lizenzkorb. Der „Lizenzkorb“ der DDB: die feste Auswahl an Rechtehinweisen,
die eine Einrichtung den Medien eines digitalen Objekts (Bild, Audio, Video) zuordnen kann –
CC0, CC BY, CC BY-SA, Public Domain Mark, verschiedene Hinweise wie In Copyright /
Rights Reserved. Die Medien eines Objekts (die diese CLI nicht herunterlädt) können daher
strenger lizenziert sein als die CC0-Metadaten – prüfen Sie immer die Rechte des einzelnen
Objekts, bevor Sie seine Medien nachnutzen: In view steht die Lizenz-URI der Medien in
item.license.resource (item.rights ist oft leer), in binaries im Feld kind jeder Datei.
Siehe DATA_LICENSE.md.
CLI / Technik
Exit-Codes. 0 Erfolg · 2 Aufruffehler (ungültiges Flag, ID mit falscher Länge) · 4
nicht gefunden · 6 Netzwerkfehler · 1 sonstiger API- oder Laufzeitfehler. Siehe
Usage.md.
Log-Eintrag (log record). Jede Diagnosezeile, die die CLI nach stderr schreibt: ein
Zeitstempel, eine Stufe (ERROR, WARN, INFO) und ein Thema ddb.<Bereich>, als Text
(im Stil von log4j) oder mit --log-format jsonl als ein JSON-Objekt pro Zeile. Die
Bereiche: cli (Bedienfehler, Meldungen von commander, unerwartete Fehler), api (die
Antworten der API: ein Fehlerstatus, die Hinweise zum Blättern und zum Vorfahren, und eine
fehlerhafte Antwort — ungültiges JSON, die falsche Form, eine HTML-Seite statt einer
Version), http (die Verbindung, die Klartext-Warnung und je Wiederholung eine WARN-Zeile vor dem Warten) und output (die -o-Datei,
Schreibfehler auf stdout). Ein Eintrag ist immer eine Zeile; Steuerzeichen darin werden
maskiert.
Entfernen von Zugangsdaten beim Wechsel des Origins. Die Lese-Routen senden keine
Zugangsdaten. Falls Sie aber über einen Header welche mitgeben und die API jemals auf einen
anderen Host umleitet, entfernt der Client vor dem Folgen jeden Header, den Sie hinzugefügt haben
(Authorization, Proxy-Authorization, Cookie, X-API-Key, jeden Token-Header), sodass keiner
an einen anderen Origin gelangt. Eine Weiterleitung auf denselben Origin (Schema, Host und
Port), mit relativer oder absoluter Location, behält sie. Ein user:passwort@ in
--base-url wird als Authorization-Header gesendet, der derselben Regel folgt, nie in der
URL selbst, und Zugangsdaten in einer Location werden ignoriert. Ein eigener Transport in der
Bibliothek darf Weiterleitungen nicht selbst folgen (HttpRequest.redirect ist "manual");
einer, der es tut, schickt diese Header an den anderen Host, bevor der Client eingreifen kann –
das kann die Bibliothek nicht verhindern.