Imdas Pro, Expo und LIDO

Christof Mainberger, 12.11.2024

LIDO ist die Lingua franca zum Austausch von Daten im Museumsbereich, insbesondere im Hinblick auf deren Veröffentlichung. Daten, die z.B. an die DDB, das CCC-Portal oder an Museum Digital geliefert werden sollen, müssen das LIDO-Format aufweisen. Die Herausforderung dabei liegt darin, dass LIDO hinsichtlich der Beschreibung der Entstehung von Museumsobjekten sowie deren Behandlung im Laufe der Zeit ein anderes Paradigma verfolgt, als es bisher für eine typische Sammlungsdokumentationssystem wie imdas pro als Basis diente.

Imdas erlaubt es zu einem Sammlungsobjekt eine Anzahl Personen anzulegen, deren Beziehung zu dem Objekt durch eine Rolle spezifiziert wird. Genauso gibt es eine Reihe von Orten, die über den Ortstyp einer Situation im "Lebenszyklus" des Objektes assoziiert wird. Ebenso Datums- und andere Angaben zum Objekt. LIDO nimmt dagegen den Lebenszyklus des Sammlungsobjekt direkt als Folge von Ereignissen in den Fokus, z.B. Entstehung, Auffinden, Eingentumsübergänge, Zuordnung zu Sammlungen, Restaurierung, Ausstellung, etc. und beschreibt diese Ereignisse dann durch die beteiligten Personen, Orte, Datumsangaben etc.

Die Aufgabe liegt nun darin, die Datenelemente aus imdas pro geeignet Ereignissen für das LIDO zuzuordnen. LIDO legt dabei lediglich fest, dass Ereignisse und wie Ereignisse zu beschreiben sind, aber nicht welche Ereignisse verwendet werden sollen. Dies muss das Museum je nach Zweck der Datenlieferung selbst ausgestalten. Die städtischen Museen verwenden z.B. die folgenden Ereignistypen, die seitens der DDB durch URLs normiert sind, über die man auch die ausführlichen Definitionen findet. Zu manchen Typen existieren in den imdas pro-Datenbanken gewöhnlich nur Personen oder Orte oder Datumsangaben, manche ergeben sich aus anderen Datenelementen in imdas pro, z.B. aus der Inventarisierung.

• Herstellung:  http://terminology.lido-schema.org/lido00007
• Erwerbung: http://terminology.lido-schema.org/lido00001
• Zugang: http://terminology.lido-schema.org/lido00001
• Sammeltätigkeit: http://terminology.lido-schema.org/lido00010
• Fund: http://terminology.lido-schema.org/lido00002
• Besitz- oder Eigentumswechsel: http://terminology.lido-schema.org/lido01151
• Zuordnung zu einem kuratierten Bestand: http://terminology.lido-schema.org/lido0114

Die verschiedenen Kulturportale sehen jeweils ein Sortiment Ereignistypen vor. DDB sowie CCC kennen z.B. die Ereignistypen unter http://terminology.lido-schema.org/eventType, Museum Digital hat ein anderes Set. Die Dinge sind dabei im Fluss, z.B. ist "Sammeltätigkeit" in kolonialen Kontexten als Bezeichnung mittlerweile umstritten.  

Eine weitere Schwierigkeit ergibt sich daraus, dass die Datenelemente in imdas pro nicht einheitlich realisiert sind: Für den "Fundplatz" zu einem archäologischen Objekt gibt es z.B. ein obsoletes Datenelement in einer Tabelle. Die eigentlich in imdas pro inzwischen vorgesehene Variante sieht dagegen einen Ortstyp "Fundplatz" zu regulären Ortsangaben vor, so dass die angegebenen Ortsdaten Features wir Geokoordinaten, Oberbegriffe etc. aufweisen. Als weiteren Ansatz nutzte ein Museum kürzlich in imdas pro ein allgemeines Thesaurus-Feld "Fundplatz" um diese Information zu verwalten. Alle drei Varianten erfordern andere Verarbeitungen. 

Wegen der Freiheitsgrade im LIDO sowie der historischen Verwachsungen in imdas pro muss also bei der LIDO-Aufbereitung mit jedem Museum im Detail abgestimmt werden, wo welches Datenelement genau im LIDO verwendet werden soll. Und die entsprechende Datenverarbeitung muss dann aufwändig implementiert werden. Von Standards weit und breit keine Sicht! Immerhin ist allerdings LIDO im Rahmen seiner Variablilität genau spezifiziert, sodass hoffentlich die Daten-Empfänger der Daten nicht ein weiteres Mal an den Daten individuell herumschrauben müssen. 

Zur Definition der Verwendung von Datenelemente aus imdas pro und deren Zuordnung zu Ereignissen schicken wir den Museen eine Liste mit den verwendeten Rollen, Orts- und Datumstypen. Darin sollen sie markieren, ob ein Datenelement überhaupt im LIDO berücksichtigt werden soll. Ggf. kann angegeben werden unter welcher Label die Rolle bzw. der Typ in LIDO erscheinen soll. Denn in imdas pro wurden im Lauf der Zeit Bezeichnungen sehr inkonsistent gefasst, z.B. unterschiedlich gegendert. Schließlich muss noch die Zuordnung zu einem Ereignis vorgenommen werden. Sofern eine Angabe, z.B. "Dargestellte Person" nicht zu einem Ereignis zuzuordnen ist, ermöglich LIDO auch die Anwendung von Schlagworten. Ein hypothetisches Beispiel: 

In vielen Fällen reichen die in imdas pro verwendeten Rollen nicht aus, um die Datenverarbeitung für eine Datenveröffentlichung zu steuern. Z.B. ist es im Hinblick auf Provenienz wichtig, die Voreigentümer*innen sowie Sammler*innen von Sammlungsobjekten zu nennen. Allerdings ist dies rechtlich evtl. nicht für alle Beteiligte möglich, so dass Museen oft zur Rollenbezeichnungen wie "Sammler (öffentlich)"  bzw. "Voreingentümer (öffentlich)" greifen, um diese Differenzierung vorzunehmen. Sie muss dann natürlich in imdas pro nachgetragen werden. 

Grundsätzlich ist auch möglich parallel sowohl ein weibliche wie auch ein männliche Rollenbezeichnung für das LIDO abzuleiten und diese mit geeigneten URLs auf Normdaten aus GND, AAT oder Wikidatea abzustützen. Schließlich erlaubt es LIDO auch eine englische Fassung solcher Begriffe mitzuliefern.

Um die Problematik und Vorteile des Pardigmenwechsels zwischen imdas pro und LIDO nochmal zu illustrieren: Nehmen wir an, ein Objekt wäre zweimal verkauft worden. Damit gäbe es sowohl zwei Voreigentümer, zwei Kauf-Datumsangaben sowie evtl. auch zwei Kauf-Orte. In imdas pro würden diese Angaben vage über Sortierungen etc. assoziiert, aber nicht explizit zusammengefasst, welcher Voreigentümer zu welchem Kaufdatum und welchem Kauf-Ort gehört. Für die Provenienz wurde diese ausdrückliche Relationierung zusammengehöriger Angaben in imdas pro kürzlich im neuen Provenienzmodul realisiert; für ältere Daten muss die Relationierung nun bei der Erzeugung des LIDO nachgeholt werden, welches diese sinnvolle andere Strukturierung zwingend verlangt.

Die "Übersetzung" mit Hilfe der oben angegebenen Tabelle funktioniert dabei nur dort, wo in imdas pro die Standardvarianten zur Angabe von Personen, Orten und Datumsangaben gewählt wurden. Sofern in der Sammlungsdokumentation in imdas andere z.B. frühere Konzepte angewandt werden oder die Ereignisse aus anderen Datenelementen, z.B. Inventarisierungsdatum, zu beschreiben sind, muss noch weiter ins Detail der Datenstrukturen gegangen werden. Die Aufbereitung des LIDO kann dann leicht mal 1.500 Zeilen Quellcode umfassen...

Schaut man in das barocke XML einer ausgewachsenen LIDO-Datei, erschrickt man zunächst, wie komplex und undurchdringlich sich diese Dokumente präsentieren. Je länger man jedoch mit LIDO arbeitet, je deutlicher wird, dass diese Herangehensweise die Daten angemessener strukturieren kann: Das Denkmodell, in dem die Daten erfasst und vorgehalten werden, sollte möglichst gut zu dem passen, wie die Daten dann auch verwendet werden sollen. Die Datenmodellierung und die Arbeitsweise der Museen in imdas pro ist dagegen konzeptionell stehen geblieben. Als imdas pro eingeführt wurde, gab es LIDO bestenfalls in den Anfängen - durchgesetzt hat es sich das neue Paradigma eigentlich erst heute. Die Investition in die Daten und ihre Handhabung in imdas pro ist mittlerweile so groß, dass man sich eine Migration und ein Umlernen schwer vorstellen kann. Dabei ist dies nicht zuerst ein technisches Problem: Weil in imdas pro immer irgendwie alles möglich ist, wäre auch die Umstellung auf eine "ereignisorientierte" Sammlungsdokumentation innerhalb imdas pro denkbar. Eine Aufbereitung in ein XML-Format wie LIDO wäre dann lediglich eine syntaktische Übung. Die Spezifikation des Provenienzmoduls ist ein praktischer Beleg hierfür. 

In der Realität wird man allerdings eine Änderung der eingefahrenen Verwendungsweise von imdas pro wohl nicht mehr auf den Weg bringen: Zu teuer wären die vorgelagerten Auseinandersetzungen, die erwartbaren Verluste bei einer Datenmigration sowie vor allem der Aufwand, die neuen Denkweisen einzuüben. Vielleicht könnte jedoch die ExpoDB eine Plattform abgeben, um die Daten in den neuen Strukturierungen erlebbar und begreifbar zu machen. Und beim Essen entsteht dann ja bekanntlich der Appetit....