Seitenhistorie

...

• 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 zentrle 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 modellbasisModell.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 modellbasisModell.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 modellbasisModell.xml passsende Inhalte zu hinterlegen und viel zu oft noch "ToDo" ausgegeben wird. Sofern für ein Museum oder eine einzelen einzelne Anwendung eines Museum in der ExpoDB die Textressourcen in modellbasisModell.xml nicht ausreichen oder zutreffen , können diese individuell in der expoconfig.xml oder auch den Format-Konfigurationen (s.u.) überschrieben werden. 

Image Added

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.

...

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 modellbasisModell.xml basiert. Obwohl dies in der Praxis schon sehr gut funktioniert, ist die Entwicklung hier sicherlich ncoh noch 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...

...