Seitenhistorie

...

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 also für alle eine ExpoDB für alle? Oder für jedes Museum eine? Oder vielleicht sogar für jedes Museum mehrere? All dieses gab es schon maleinmal. Im Augenblick stabilisiert sich jedoch das Bild und insofern lohne 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 uneinheitlichvielfä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 einehitlich 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. 

...

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 mit in die Datenübertragungbei 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 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.

...

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 ein solches Format 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...