Was ist die ExpoDB - und wenn ja wie viele?

Christof Mainberger, 18.11.2024

Schon der Name "ExpoDB" ist etwas verwirrend. Denn im Moment handelt es sich gar nicht eigentlich um eine Datenbank, die originär selbst Daten verwaltet. Sondern eher um einen Index, der allnächtlich mit Daten aus imdas pro neu aufgebaut wird. Dazu kommt, dass die Anwendung im Laufe der Jahre und ihrer Entwicklung einer stetigen Evolution unterworfen war: Gibt es also für alle eine ExpoDB? Oder für jedes Museum eine? Oder vielleicht sogar für jedes Museum mehrere? All dieses gab es schon einmal. Im Augenblick stabilisiert sich jedoch das Bild und insofern lohnt es sich, dieses genauer zu zeichnen. 

Vorab: Da die ExpoDB einer stetigen Entwicklung unterworfen war (und ist) und dabei oft kurzfristig den Anforderungen der Museen oder ihrer Agenturen entsprochen hat, gibt es praktisch tatsächlich viele Varianten, die für das eine oder andere Museum noch "in Produktion" sind. Ein Problem stellt dabei dar, dass die benötigten Suchroutinen und Resultatformate sehr komplex sind (und bereits die imdas-Daten pro Museum vielfältig). Daher ist nur aufwendig zu gewährleisten, dass spätere Softwareversionen Annahmen erfüllen, die die Frontends der Museen an die Vorversion implizit gestellt haben. Daher sollten die Museen mit ihren Webagenturen unbedingt auch Teststellungen ihrer Digitalen Kataloge einrichten, so dass die Teststellung der ExpoDB auf expotest.bsz-bw.de jeweils verifiziert werden kann. Nur so kann die ExpoDB technologisch vereinheitlicht werden und können Neuerungen kontinuierlich zur Verfügung gestellt werden. Sonst birgt jedes Update die Gefahr, dass hinterher das Frontend, z.B. der Digitale Katalog, nicht mehr funktioniert.

Wie ist die ExpoDB nun aufgestellt? Auf der Teststellung, wo einheitlich die aktuelle "Generation" der ExpoDB installiert hat, hat jedes Museum eine einzige Instanz der Expo-Software. Dem entsprichen zwei sog. Solr-Cores, also Bestände des Museums in der Solr-Suchmaschine, ein "Live-Core" und ein "Schatten-Core". Für die Recherche und die Trefferausgabe verwendet die ExpoDB ausschließlich den Live-Core. Bei der nächtlichen Datenaktualisierung wird zunächst der Schatten-Core geleert und in diesen werden anschließend die aktuellen Daten aus Imdas pro aktualisiert. Danach wechseln die beiden Cores die Rollen: Der frisch aktualisierte Schatten-Core wird der neue Live-Core, während der bisherige Live-Core als neuer Schatten-Core als "Backup mit Vortagesstand" auf seine Aktualisierung in der nächsten Nacht wartet. 

Die Aktualisierung der Solr-Core wird durch eine Konfigurationsdatei expoconfig.xml gesteuert, die für jedes Museum spezifisch ausgestaltet in dessen ExpoDB-Installation liegt. In der expoconfig.xml werden im Wesentlichen sechs Dinge festgelegt: 

• Welche "Entitäten", also eigenständige Datensatztypen werden in derExpoDB für dieses Museum berücksichtigt? Immer gehören dazu "Museumsobjekte", also die Daten zu den Gegenständen in der Sammlung, Aber auch "Personen", "Medienobjekte", "Terme" (aus den Thesauri) oder "Ausstellungen" können Entitäten sein. Welche Entiäten es für ein Museeum gibt, richtet sich nach den Bedarfen der Anwendungen, die das Museum mit den ExpoDB-Schnittstellen realisieren möchte. 
• Welcher Teilbestand eines Museum wird überhaupt in die ExpoDB übernommen? Da für viele Anwendungen der Museen (z.B. DAM-Systeme) inzwischen alle Datensätze aus imdas pro in der ExpoDB benötigt werden, sind dies mittlerweile meist die Gesamtbestände. Pro ExpoDB-Anwendung werden diese Bestände dann auf den passenden Teilbestand eingeschränkt. 
• Wie sind die Entitäten aus Feldern, Komponenten, Thesauri sowie benutzerdefinierten Feldern aufgebaut? Für ein Museum kann z.B. die "Indigene Bezeichnung" essentiell sein, das nächste Museum nutzt dieses Feld überhaupt nicht. Entsprechend wird dieses Feld für das erste Museeum konfiguriert, für das zweite nicht. Ebenso mag ein Museum die Komponente "zusätzliche Nummern" verwenden, andere nicht. Der Einsatz von Thesauri sowie offenbar "benutzerdefinierte Felder" ist für jedes Museum unterschiedlich und wird in der expoconfig.xml entsprechend individuell festgelegt.
• Welche Personenrollen ("Voreigentümer"?, "Überbringer"?), Ortstypen usw. werden in die Datenübertragung einbezogen bzw. ausgeschlossen?
• Wie sollen die Feldinhalte vor der Datenübertragung bearbeitet werden? Z.B. möchten viele Museen die über die Jahre uneinheitlich gegenderten Rollenbezeichnungen in imdas pro in einer konsistenten Variante dargestellt haben. Oder die genauen Standortangaben aus imdas pro werden auf grobe Kriterien "ausgestellt", "depot" etc. abgebildet. Auch z.B. Homonymzusätze zu Thesaurustermen können entfernt werden, 
• Schließlich definiert die expoconfig.xml welche Indexe in den Solr-Cores angelegt werden sollen. Diese legen fest, nach welchen Kriterien die Datensätze gesucht, sortiert bzw. als Indexlisten (Facetten) aufbereitet werden. Ein spezieller Index ermöglich die Filterung nach Entitäten, eine anderer legt Teilbestände fest, auf die später einezlen Anwendungnen bzw. Nutzer*innengruppen der ExpoDB eingeschränkt werden können. Ein Index über die Imdas-Id erlaubt den schnellen Zugriff über dieses zentrale Schlüsselfeld.

Es ist zu betonen, dass jedes Museum eine eigene, aber auch nur eine einzige expoconfig.xml hat. D.h. die oben genannten Festlegunge werden für alle Anwendungen, die ein einzelnes Museum mit der ExpoDB realisieren möchte, gemeinsam getroffen. Natürlich kann für eine bestimmte Anwendung hinterher ein Feld, ausgeschlossen werden, das dort nicht benötigt wird. Aber erst mal muss es bei der Datenübertragung berücksichtigt werden, wenn es irgendwo gebraucht wird. Genauso können einzelne Indexe für gewisse Anwendungen ignoriert werden. Bzw. für jede Anwendung können so viele spezifische Indexe angelegt werden, wie diese eben benötigt. Hier sind keine Kompromisse nötig (allerdings beläuft sich alles in der Realität jeweils auf eine handhabbare Menge). Da die expoconfig.xml so komplex und so individuell pro Museum ist, wird sie für jedes Museeum dynamisch unter der Url https://expotest.bsz-bw.de/museumskürzel/modell als eine lesbare Webseite aufbereitet. Diese spiegelt also immer die aktuelle Konfigurtion der expoconfig.xml wider.

Die Seite unter https://expotest.bsz-bw.de/museumskürzel/modell greift auf eine interne Datei basisModell.xml zurück, die sich alle ExpoDBs von allen Museen teilen und die für alle gängigen Felder, Komponenten, Thesauri, Indexe sowie die gängigsten benutzerdefinierten Felder Labels und Erläuterungen bereitstellt. Neben der Webseite unter ...modell greifen auch die Viewer-Installationen der expoDB auf die Angaben in basisModell.xml zurück, um die Felder in ihren Detailansichten zu eklären. Es ist etwas schade, dass es bislang nicht gelungen ist, für alle Einträge in basisModell.xml passsende Inhalte zu hinterlegen und viel zu oft noch "ToDo" ausgegeben wird. Sofern für ein Museum oder eine einzelne Anwendung eines Museum in der ExpoDB die Textressourcen in basisModell.xml nicht ausreichen oder zutreffen , können diese individuell in der expoconfig.xml oder auch den Format-Konfigurationen (s.u.) überschrieben werden. 

Für jede Anwendung der ExpoDB für eine Museum wird in der ExpoDB-Webanwendung des Museums ein sog. "Endpunkt" konfiguriert. In der Praxis ist ein Endpunkt insbesondere eine URL über die man Daten beziehen kann. Dazu muss man ggf. ein sog. "Query-String" mit ? anhängen, der die Parameter verwendet, die in der Schnittstellen-Spezifikation der ExpoDB dokumentiert sind. Typische Endpunkte heißen z.B. .../museumskürzel/digitaler-katalog, .../museumskürzel/cumulus, .../museumskürzel/lido etc. Ein Endpunkt ist mit einem Standardformat verbunden (also z.B. expo, lido, leo,...) und kann mit der Einschränkung auf einen Teilbestand des Museum verbunden sein. Außerdem kann pro Endpunkt-Url ggf. eine Authentifizierung (Login oder IP Kontrolle) mit für das Museeum festgelegten Rollen eingerichtet werden. Natürlich können pro Museum so viele verschiedene Endpunkte eingerichtet werden, wie das Museum diese eben für unterschiedliche Anwendungen benötigt. Welche es für ein Museum bzw. seine ExpoDB jeweils aktuell gibt, sowie wie diese mit Standdardformat, Teilbestand und Authentifizierung konfiguriert sind, kann derzeit noch nicht extern abgerufen werden. In der Regel benötigen die Museen allerdings wenige Endpunkte, so dass diese einfach per E-Mail mitgeteilt werden.

Die ExpoDB eines Museeums definiert eine Reihe von Formaten, die die Datensätze vor der Auslieferung aufbereitet werden. Aufbereitung bedeutet dabei, die genaue Auswahl der Felder, deren Strukturierung sowie Sortierung; prinzipiell werden im Format auch noch Dtenelemente generiert werden bis hin zu komplexen Datenverarbeitungen.   Technisch stellen die Formate sog. "Stylesheets" in der XML-Transformationssprache XSLT dar, die dafür verwendet werden, die in den Solr-Cores pro Datenformat vorliegenden XML-Daten in das gewünschte Resultat zu transformieren. Typische Formate heißen expo, lido, cumulus, ccc, leo etc. Manche dieser Formate produzieren ausschließlich XML-Resultate. Z.B. sind LIDO oder LEO-XML XML-Formate, die man nicht alternativ als z.B. als JSON darstellen kann. Andere Formate, wie z.B. expo oder cumulus werden so angelegt, dass sie sowohl als XML oder als JSON auslieferbar sind. Welche Syntax für die Auslieferung jeweils gewählt wird, richtet sich dabei nach dem sogenannten Mimetype application/json bzw. application/xml, der dem Endpunkt über die Parameter mim=json bzw. mim=xml (oder über einen sog. HTML-Header) mitgeteilt werden. Eine Formatdefinition enthält neben diversen anderen Zusatzinformationan auch eine Angabe, welche Mimetypes für es möglich sind.

Formate, die auch mit dem Mimetype application/json verwendet werden können, sind auch mit den sog. "Expo-Viewern" kompatibel. Das vom Format aufbereitete Ergebnis wird dann nicht direkt als JSON oder XML ausgegeben, sondern anschließend noch mit HTML-Rahmen, Suchformular etc. versehen und als Webseite ausgegeben. Das Resultat wird damit selbst nicht ein weiteres Mal verarbeitet, so dass der Viewer damit als einfaches Kontrollinstrument für das JSON-Format dienen kann, das z.B. für einen Digitalen Katalog aufbereitet wird: Was der Endpunkt der Webagentur als JSON für das Frontend anbietet, zeigt auch der Viewer als HTML an. Muss derzeit noch für den Aufruf der Viewer der Parameter mim=viewer angegeben werden, soll der Aufruf des Viewers bald zur Defaulteinstellung werden. Im Browser wird dann immer der Viewer aufgerufen, wenn kein spezifischer Mimetype aufgerufen wird (also implizit der Mimetype text/html). Um JSON bzw. XML zu bekommen, muss die Webagentur diesen Mimetype dann gezielt angeben. Wie oben erwähnt, kann ein solches Format für den Viewer noch fehlende Labels sowie Felderläuterungen festlegen. Zudem ist es möglich, im Format auch die Trefferdarstellung in der Trefferliste des Viewers  festzulegen. Diese Informationen speziell für den Viewer werden bei der Aufbereitung des Formats als JSON oder XML natürlich wieder eliminiert.

Ich hoffe, es ist deutlich geworden, wie die ExpoDB-Software es mittlerweile versteht, sehr differenziert die spezifischen Anforderungen der einzelnen Anwendungen der Museen zu bewältigen. Und dabei eine unüberschaubare Vielzahl von Einzelinstallationen zu vermeiden. Über die expoconfig.xml, die Endpunkte sowie die Formatdefinitionen gibt es dabei eine aufeinander aufbauendes System von Konfigurationen, die u.a. auf der gemeinsamen Datei modell.xml basiert. Obwohl dies in der Praxis schon sehr gut funktioniert, ist die Entwicklung hier sicherlich ncoh nicht abgeschlossen. Derzeit steht dabei der Viewer im Vordergrund. Nachdem dieser hoffentlich bald in einer neuen, zuverlässigen und leistungsfähigen Version released werden kann, steht auf der Agenda, die ganz oben angesprochene Verwirrung anzugehen: Die ExpoDB wird eine Komponeten für originäre eigene Daten erhalten und dann auch endlich zurecht "DB" heißen...