Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

Christof Mainberger, 3. Dezember 2024

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 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.

...

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. 

...

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.passen.

Downloads und Schluss

Für manche Formate ist der Download aus dem Browser sinnvoller als die Anzeige am Bildschirm. Zum Beispiel sind 5.000 Datensätze LIDO sicher auch am Bildschirm möglich. Für die Weiterverarbeitung oder Lieferung an ein Kulturportal wird man allerdings eher den Download als Datei vorziehen. Mittels des Parameter dld kann mann auslösen, dass der Browser statt der Anzeige den Datei-Speichern-Dialog anzeigt und dabei den Dateinamen als Vorgabe anbietet, den man mit dem Parameter dld übergen hat. dld=lido_241203.xml führt also zum Download der Treffer in die Datei lido_241203.xml. 

Soweit die ExpoDB-Schnittstelle und ihre Möglichkeit Daten abzufragen. Dieser Teil der Software ist seit langem im wessentlichen stabil. Die jüngste Änderung betrifft das Format von Zahlen: Für spezielle Indexe zu Goekoordinaten war es nötig, als Suchbegriffe auch Dezimalzahlen zuzulassen. Bislang, wo Suchkriterien den Vergleich mit Jahreszahlen vorsachen, hatten Ganzzahlen genügt. Neue Anforderungen betreffen vor allem die Indexierung, wo neue Felder und Funktionalitäten zu realisieren sind. Z.B´. die soeben genannten Indexe zu Geookordinaten. Aber die Indexierung ist ein anderes Thema. Ebenfalls ein anderes Thema sind weitere Schnittstellen zu Bildern, Vorschlagslisten ("suggest") sowie schreibende Schnittstellen auf die ExpoDB. Alle diese Aspekte müssen in anderen Beiträgen behandelt werden.