Wie mit der ExpoDB Daten abgefragt werden können

Die wichtigste Funktion der ExpoDB ist es, einen Online-Abruf für Daten zu ermöglichen, die in imdas-pro erfasst werden. Ein solcher Abruf wird einfach durch eine URL bewerkstelligt, die alle Angaben zu den gewünschten Datensätzen enthält. D.h. alle Parameter zur Auswahl der Daten, ihrer Sortierung, ihrer Formatierung sowie zu Facetten werden in der URL codiert. Es braucht und gibt kein anderes Mittel, der Schnittstelle den anliegenden Bedarf mitzuteilen. Diese Schnittstelle hat sich bewährt und musste über die Jahre kaum erweitert werden. Da die Parametrisierung der Schnittstelle (nahezu) vollständig beschreibt, was die ExpoDB leisten kann, ist es unbedingt notwendig diese Parameter zu verstehen, wenn man mit der ExpoDB arbeiten möchte und neue Features z.B. für einen Digitalen Katalog plant. 

Die ExpoDB-Schnittstelle ist eine "ganz normale" Webschnittstelle. D.h. im Kern geht es immer darum, dass ein "Client" übers Internet eine Anfrage an die ExpoDB-Schnittstelle schickt, und die ExpoDB-Schnittstelle eine Antwort übers Internet zurücksendet. Der "Client" kann dabei einfach der normale Internet-Browser sein, den man auf dem Arbeitsplatzrechner hat. Oder auch das Frontend eines Digitalen Katalog, das eine Webagentur für das Museum programmiert hat und das die ExpoDB im Hintergrund abfragt. Oder auch ein DAM-System, das über die ExpoDB den eigenen Datenbestand zu den Sammlungsdaten aktualisiert. 

Die ExpoDB folgt dabei dem Paradigma sog. RESTful-Webservices: Alle Anfragen werden unabhängig voneinander behandelt. D.h. die ExpoDB "merkt sich" zwischen zwei Anfragen nicht, wer da angefragt hatte und was der oder die wollte bzw. bekommen hat. Alle Informationen, die erforderlich sind, um eine Anfrage auszuführen müssen also in der URL codiert sein. Sprich es ist nicht möglich z.B. zunächst den Treffer 1 bis 10 mit "Künstler ist Dürer" anzufordern und danach die Treffer 11 bis 20 "vom Gleichen". Denn die ExpoDB hat sich "nicht gemerkt", dass kurz vorher von der gleichen Stelle nach Dürer gefragt wurde. Man muss also für die zweite Anfrage wieder angeben "Künstler ist Dürer" und nun Treffer 11 bis 20. In jeder URL müssen alle Informationen erneut enthalten sein. Dies hat den Vorteil, dass die URLs "bookmarkable" sind. D.h. man kann sie sich im Browser "bookmarken" oder auch per E-Mail verschicken: Bei einem späteren Aufruf erhält die ExpoDB alle erforderlichen Informationen erneut. (Ausnahme: Login-Daten, die ggf. auch in der Anfrage codiert sind, gelten im allgemeinen später oder woanderst nicht mehr!)

Zur Bildung dieser Urls werden nun jedem Museum eine Reihe von "Endpunkten" zu "seiner" ExpoDB mitgeteilt: Z.B. https://expo.bsz-bw.de/mus/digitaler-katalog, https://expo.bsz-bw.de/mus/cumulus, https://expo.bsz-bw.de/mus/lido etc. (Alle Endpunkte gibt es auch in der Testversion unter https://expotest.bsz-bw.de...) Wie bereits an anderer Stelle beschrieben, können die einzelnen Endpunkte jeweils mit der Einschränkung auf einen Teilbestand des Museums, einem bestimmten Vorgabe-Format sowie einer Zugriffsbeschränkung verbunden sein. Also https://expo.bsz-bw.de/mus/digitaler-katalog könnte z.B. auf den für die Onlinesammlung publizierten Teilbestand eingeschränkt sein. Das Format, das mit der Webagentur dafür abgestimmt ist, wird als Defaultformat vorgesehen. Es wird keine Zugriffsbeschränkung konfiguriert. Dagegen unterliegt https://expo.bsz-bw.de/mus/cumulus der Gesamtbestand der Museums (es kann zu allem Bilder geben), das Format ist für das DAM konfiguriert und der Zugriff ist auf die IP des Servers des DAM-Systems beschränkt. An die Endpunkte werden die weiteren Anfrageparameter nach einem Fragezeichen ("?") angehängt und mit Kaufmannsund ("&") getrennt. 

Die einfachste Abfrage spezifiziert einfach die imdas-id des gewünschten Datensatzes  https://expo.bsz-bw.de/mus/digitaler-katalog?id=4659987A4A23489A88CA13322559FD72. Solche Abfragen werden offensichtlich nicht direkt per Hand eingegeben sondern z.B. in Trefferlisten dafür genutzt, um zur Detailansicht des Einzeltreffers zu gelangen. Da die imdas-Id für die Daten in der ExpoDB (und hoffentlich auch bei allen Nachnutzungen der Daten ) als der persistente Idenfifier für die Datensätze fungiert, sind die URLs dieser Form auch besonders geeignet, um die Detailansicht eines Datensatzes im Browser zu bookmarken oder per E-Mail zu verschicken (sofern der Datensatz ohne Zugriffsbeschränkung ist).

Nach was kann man in der ExpoDb überhaupt suchen? Typischerweise sind dies sog. „Museumsobjekte“. Je nach Bedarf können in der ExpoDB jedoch auch andere Entitäten indexiert sein, so dass auch nach Personen, Thesaurus-Einträgen, Ausstellungen etc. mit spezifischen Indexen gesucht werden kann. Mit dem Parameter „typ“ gibt man an, auf welchen Entitätstyp eine Abfrage eingeschränkt werden soll. Wird der Parameter weggelassen wird der Defaultwert „museumsobjekt“ angenommen.

Komplizierter als die Abfrage nach einem durch seine imdas-id identifizierten Datensatz ist die Abfrage einer Selektion von Datensätzen. Im einfachsten Fall muss dazu ein einzelner Suchstring mit einem Index verglichen werden. In einem anderen Beitrag wurde dargestellt, dass man die Indexe dazu spezifisch anlegen kann und es auch z.B. einen Textindex über alle Textinhalte gibt. Es gibt sechs Varianten des Vergleichs eines Suchstrings mit einem Index: "all", "any" sowie "adj" für Texte und "eq", "le", "ge" für Zahlen und Datumsangaben. "all" bedeute dabei, dass alle einzelnen Wörter des Suchstrings für einen Datensatz im Index enthalten sein müssen, um diesen als Treffer zu qualifizieren. "any" bedeutet hingegen, dass irgendeines der Worte im Suchstring zum Datensatz im Index vorhanden sein muss. "adj" ist schließlich die Phrasensuche, das heißt alle Wörter müssen in der angegebenen Abfolge im Index vorhanden sein. Der Suchsting bzw. die in ihm enthaltenen Wörter lassen sich mit "*" links und rechts trunkieren. Die Operatoren "eq", "le" und "ge" bedeuten "gleich", kleiner als" und "größer als" in der üblichen Semantik für Zahlen und Datumsangaben. Beispiele für solche elementaren Abfragen sind also z.B. inventarisierungsnummer adj "III 4ap", material all "gold silber bronze", modified ge "2024-11-25".

Die elementaren Abfragen reichen nicht aus, z.B. um eine erweiterte Suche zu unterstützen. Dazu müssen mehrere solche elementare Abfragen mit "und", "oder" oder "not" verknüpfbar sein, wobei "not" die Semantik "und nicht" besitzt. Die Anfragesprache der ExpoDB lässt es dabei zu, dass beliebig viele elementarer Abrage verknüpft werden können und dabei die Reihenfolge der Auswertung durch Klammern gesteuert wird. Es lassen sich also komplexe Abfragen der Form "(material all "Gold Bronze" and technik any "getrieben geschmiedet") not person adj "Hans Müller" bilden. Elementare oder komplexe Abfragen werden mit dem Parameter "qry" an den Endpunkt angehängt. Sofern weder der Parameter "id" noch der Parameter "qry" in einer Anfrage verwendet ist (die beiden können nicht gleichzeitig verwendet werden), wird keine Selektion auf dem für den Endpunkt definierten Teilbestand vorgenommen. Eine Url könnte nun also wie folgt aussehen: https://expo.bsz-bw.de/mus/digitaler-katalog?qry=((material all ("Gold Bronze" and technik any "getrieben geschmiedet") not person adj "Hans Müller".

Mit Hilfe der Parameter srt und ord lassen sich Sortierung bzw. Sortierrichtung der Treffer festlegen. Für die Sortierung lässt sich der Name eines der bei der Indexierung festgelegten Sortierindexe angeben. Sofern dieser Parameter nicht angegeben wird, wird eine Default-Sortierung verwendet. Für den Parameter ord sind die Werte „asc“ sowie „desc“ für aufsteigend bzw. absteigend möglich. Defaultwert ist hier „desc“ also absteigend. 

Eine Trefferseite aus der Gesamtheit der Treffer eine Abfrage lässt sich mit den Parameter fst und len ausschneiden. Der erste anzugebende Treffer wird mit dem Parameter fst angegeben, wobei der erste Treffer und der Defaultwert mit 0 angegeben wird. Die Länge der Trefferseite wird mit len festgelegt. Hier ist der Defaultwert für die Installation festgelegt oder 10. Sofern weniger Treffern nach dem durch fst festgelegten ersten Treffer der Trefferseite vorhanden sind, werden einfach weniger Datensätze ausgegeben. 

Nach der Spezifikation welche und wieviel Treffer in welcher Reihenfolge zurückgegeben werden sollen, ist relevant, in welchem Format die Treffer aufbereitet werden sollen. Ein Format legt fest, welche Inhalte zu einem Datensatz ausgegeben werden sollen und wie diese im Resultat strukturiert werden. Die Formate sind als XSLT-Stylesheets implementiert und können umfangreiche Datenverarbeitungen auf den in der ExpoDB vorgehaltenen Daten vornehmen. Von der simplen Übernahme der Daten, wie sie aus imdas pro importiert wurden bis zu ambitionierten LIDO-Formaten ist dabei alles möglich. Welche verschiedenen Formate für ein Museum erstellt werden, hängt dabei von der Unterschiedlichkeit der beabsichtigten Anwendungen ab, die das Museum mit den Daten betreiben möchte. Hier ist es meist einfacher mehrere Varianten einzurichten, z.B: auch verschiedene "Flavours" von LIDO für unterschiedliche Abnehmer, als irgendwie einen Kompromis auszuhandeln. Das gewünschte Format wird der Abfrage mit dem Parameter fmt mitgegeben. Wird dieser nicht angegeben wird das für den Endpunkt konfigurierte Defaultformat angewandt. 

Mit dem Format eng verbunden ist der Mimetype. Das Http-Protokoll, über das die Daten der ExpoDB zwischen Server und Client, transportiert werden, enthält mit einem Mimetyp-Attibute eine Angabe, welches Datenformate der Client in welcher Priorität erwartet. Genauso teilt der Server in seiner Antwort mit, in welchem Datenformat diese ausgeliefert wride. Für die Daten der ExpoDB sind vorallmen die Mimetypes application/json, application/xml bzw. text/xml sowie text/html relevant. Sobald ein Excel-Export implementiert ist, bekommt dieser den Mimetype application/vnd.ms-excel, CSV erhält text/csv, PDF erhält appliication/pdf u.s.w. Der Sinn ist, dass die Partner dieser Kommunikation leicht feststellen können, was sie erwartet. Der Mimetype wird in der Regel (und auch in der ExpoDB) im sog. Http-Header transportiert. Benutzt man die ExpoDB direkt in einem Browser, so ist es nicht ganz einfach einen gewünschten Mimetype im Header einzustellen, so dass die Defaultpriorität des Browsers zum Tragen kommt: text/html, application/xml u.s.w.. Daher sieht die ExpoDB zusätzlich den Parameter mim vor, der die Einstellung des Http-Headers überschreibt. Er kann mit mim=xml, mim=json sowie mim=html belegt werden. 

Nicht jedes Format kann in jedem Mimetype ausgeliefert werden. Z.B. ist LIDO ein Xml-Format, für das es keine kanonische Umsetzung in JSON oder HTML gibt. Daher ist in jedem Format für die ExpoDB vermerkt, in welchen Mimetypes dieses Format ausgeliefert werden kann. Diese Angabe steuert dann die Ausgabe priorisiert der Mimetype-Anforderung in der Anfrage. Sofern ein Format auch als JSON ausgeliefert werden kann, kann es auch als XML ausgeliefert werden und in der Regel als HTML. Sofern das Format die Ausgabe von JSON ermöglicht und die Anfrage keine Angabe zum gewünschten Mimetype macht, wird text/html als Vorgabewert angenommen. Denn prinzipiell kann jedes JSON im Expo-Viewer angezeigt werden und dieser soll in erster Linie aufgerufen werden, sofen eine Nutzer*in am Browser sitzt und nicht explizit einen anderen Mimetype anfordert. Für Frontends, z.B: für Digitale Kataloge, ist hingegen kein Aufwand den benötigten Mimetype json oder xml den Anfragen jeweils mitzugeben. 

Das ist noch nciht alles. Der Artikel wird fortgesetzt: Facetten, Filter, Download ... und Praktisches.....