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 modell.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 modell.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 modell.xml passsende Inhalte zu hinterlegen und viel zu oft noch "ToDo" ausgegeben wird. Sofern für ein Museum oder eine einzelen Anwendung eines Museum in der ExpoDB die Textressourcen in modell.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.

...