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 Bedarf mitzuteilen, was man suchen möchte. 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" über das Internet eine Anfrage an die ExpoDB-Schnittstelle schickt. Und dass die ExpoDB-Schnittstelle eine Antwort über das 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 Katalogs, das eine Webagentur für das Museum programmiert hat. Es fragt die ExpoDB im Hintergrund über das Internet ab. Oder der Client kann auch ein DAM-System des Museum sein, 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 vorher wollte bzw. bekommen hat. Die ExpoDB "erinnert" sich nicht, 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 ja zu allem Bilder geben, die Cumulus verwaltet), 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 Identifier 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 erreichbar ist).

Suche in der ExpoDB

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 - das heißt die erste Trefferseite von allen Datensätzen wird ausgegeben.. Eine Url könnte nun also z.B. 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 ein konfigurierter Defaultwert für die Installation festgelegt oder 10 (falls diese Konfiguration fehlt). Sofern weniger Treffern nach dem durch fst festgelegten ersten Treffer der Trefferseite vorhanden sind, werden einfach weniger Datensätze ausgegeben. 

Format und Mimetype

Nachdem mit der Suchanfrage spezifiziert wurde, welche und wieviel Treffer in welcher Reihenfolge zurückgegeben werden sollen, ist von Interesse, in welchem Format die Treffer aufbereitet werden. 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 zwischen unterschiedlichen Nutzungen 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 Antwort ausgeliefert wurde. Für die Daten der ExpoDB sind vorallem 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 beide Partner dieser Kommunikation leicht feststellen können, was der andere von ihnen erwartet bzw. ihnen liefert. 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 "automatisch" die Defaultpriorität des Browsers zum Tragen kommt: text/html, dann application/xml u.s.w.. Daher sieht die ExpoDB zusätzlich den Parameter mim vor, der die Einstellung des Mimetypes bei der Abfrage vereinfacht und 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 überhaupt ausgeliefert werden kann. Ind LIDO steht dann also: nur application/xml. Diese Angabe steuert dann die Ausgabe und priorisiert dabei ggf. eine explizite Mimetype-Anforderung in der Anfrage, falls diese nicht möglich ist. Sofern ein Format auch als JSON ausgeliefert werden kann, kann es auch als XML ausgeliefert werden und in der Regel auch als HTML. Wenn die Anfrage keine Angabe zum gewünschten Mimetype macht, werden dann mittlerweile die Ergebnisse als HTML ausgeliefert bzw. konkret im sog. Viewer. Denn prinzipiell kann jedes JSON im Expo-Viewer angezeigt werden und es wird angenommen, das eine Nutzer*in mit dem Viewer besser zurecht kommt, als mit einem XML oder JSON-Format. Für Frontends, z.B: für Digitale Kataloge, ist hingegen kein Aufwand den benötigten Mimetype json oder xml den Anfragen jeweils explizit mitzugeben. 

Facetten und Filter

Das sog. "Drill-Down" ermöglicht es Suchergebnisse weiter zu verfeinern. Dazu wird in den Resultaten das Vorkommen von Begriffen zu bestimmten Kriterien (Material, Technik, Personen, etc. ) ermittelt und als Liste ausgegeben. In dieser Liste (oder "Facette") kann man dann einzelne der vorkommenden Worte auswählen, die Trefferliste nach diesen Begriffen filtern und das Sucherergebnis damit präzisieren. Natürlich werden die Filterbegriffe der Facette nicht erst bei der Suche ausgezählt, sondern es werden vorab entsprechende Indexe vorbereitet, die bei der Suche nur noch auf die Resultate eingeschränkt werden. Insofern werden die möglichen Facetten einer ExpoDB-Schnittstelle bereits bei der Indexierung festgelegt. welche dann bei einer Suche mit ausgegeben werden, legt der Parameter fct  fest. Die Facetten können nach Häufigkeit des Vorkommens der Begriffe oder nach deren alphabetischen Ordnung sortiert sein. Dies legt der Parameter fcs fest, der die Werte "cnt" (für Häufigkeit) bzw. "dx" (für alphabetische Ordnung) annehmen kann. Da bei großen Treffermengen auch die Facetten lang werden können, oft aber nur die häufigsten Begriffe interessieren, kann man mit dem Parameter lmt die Anzahl der ausgegebenen Begriff z.B. auf 10 Begriffe beschränken. Der Wert "-1" steht dann für alle Begriffe der Facette. Allerdings hat sich gezeigt, dass es auch nötig ist, diese Anzahlen pro Facette zu steuern. Daher erlaubt es die Schnittstelle auch, die Anzahl der Begriffe pro Facette zu steuern, indem die gewünschte Anzahl im Parameter fct  mit Doppelpunkt abgetrennt dem Facettennamen angehängt wird. Die Parametrieisierung für fünf Begriffe zum Material und allen vorhandenen zur Technik sähe demnach z.B. so aus: fct=material:5;technik:-1.

Das Filtern nach Facettenbegiffen wird über den flt Parameter festgelegt. Dazu wird eine mit Semikolon getrennte List der Filter angegeben, wobei jeder Filter aus dem Facetten-Namen und, getrennt mit Doppelpunkt, dem Filterbegriff besteht. Dabei können auch mehrere Filter zum gleichen Facettennamen angegeben werden. Das Filtern nach Datensätze mit Materialangabe Gold und Materialangabe Silber sähe dann wie folgt aus flt=material:Gold;material:Silber. (Ein Filtern nach Gold oder Silber ist nicht vorgesehen). Die Semantik ist dann so, dass das gefilterte Ergebniss in der genannten Facette den Filterbegriff enthalten muss. Im Unterschied zur Suche in der ExpoDB, bei der die Suchbegriffe linguistisch "normalisiert" werden und "Relevanz" für das Ergebnis ausgewertet werden kann, ist das Filtern in Facetten eine binäre Angelegenheit: Entweder der Filterbegriff ist exakt so im Facetten-Index enthalten, dann gehört der Datensatz zur Treffermenge. Oder der Begriff ist nicht enthalten, dann wird der Datensatz ausgefiltert. Suche und Filtern sind insofern leicht unterschiedliche Konzepte, die jeweils in unterschiedlichen Situationen Vorteile haben und angewendet werden.