Seitenhistorie

...

Für die ExpoDB wird die Daten daher in ein logisches Modell transformiert, das ein Verständnis der Sammlungsdaten und ihrer Zusammenhänge möglichst erleichtern soll. Das Ziel ist, dass möglichst viele Beteiligte bei den Daten in der ExpoDB mitreden können. Beteiligt sind natürlich die, die Daten in imdas pro eingeben und die Bestände in imdas-pro pflegen. . Beteiligt sind auch die Kommunikationsabteilungen der Museen, die mit diesen Daten z.B. Digitale Kataloge konzipieren wollen. Beteiligt sind die Webagenturen, die die Digitalen Kataloge programmieren. Beteiligt können evtl. auch Projektpartner der Museen sein, die die Daten weiter auswerten. Beteiligt sind nicht zuletzt die Mitarbeiter:innen von Musis, die u.a. die Daten in die ExpoDB aus imdas importieren. Alle diese Beteiligten sollen mit der ExpoDB eine gemeinsame Sprache ("Ubiquitous Language") finden, in der sie über die Daten diskutieren können. 

Eine Die Basis einer gemeinsamen Sprache sind gemeinsame Begrifflichkeiten. Zum Beispiel verwendet imdas pro für das, was in diesen Text hier mit "Entität" bezeichnet wird, den Begriff "Objekttyp". Er unterscheidet in imdas pro Sammlungsobjekte von Personen, Medien, Konvoluten, Provenienzen... Verbindet man mit dem Begriff "Objekt" enger nur Sammlungsobjekte, würde man unter "Typ" eine Klassifizierung in Gemälde, Münzen, Druckgrafik etc. erwarten. Dies wird in imdas pro wiederum über die "Objektbezeichnung" geleistet. Die Frage ist nun, ob man sich mit der gemeinsame gemeinsamen Sprache auf die Terminologie von imdas pro stützen möchte. Weil diese bereits vielen vertraut ist, dei mit imdas pro arbeiten. Oder ob dies nicht die Gefahr birgt, dann in jeder Hinsicht nur in den Möglichkeiten von imdas pro zu denken. Ich persönlich habe z.B. unter Objektbezeichnung lange Zeit sowas so etwas wie eine ein weiterer Titel oder Namen vermutet, was jedenfalls zumindest nicht ganz richtig war...

Es gibt umgekehrt auch "Nicht-Beteiligte" an der gemeinsamen Sprache. Z.B. wurden Daten aus imdas pro im SAP-System des Landes verwendet. Es wäre offensichtlich sinnlos anzustreben, dass die Sammlungsdokumentation die Sprache der Finanzverwaltung spricht oder umgekehrt die Finanzverwaltung die Sprache der Sammlungsdokumentation. Oder z.B. hat die Deutsche Digitale Bibliothek für Datenlieferungen aus Museen LIDO festgelegt. LIDO ist ein Transferformat und beabsichtigt nicht, sich direkt als Datenmodell in der Sammlungsdokumentation zu eignen. Auch die breite Öffentlichkeit (z.B. in Digitalen Katalogen) erfordert eine andere Sprache (oder parallel sogar mehrere verschiedene Sprachen pro Publikum), die nicht sinnvoll gleichzeitig die interne Sprache der ExpoDB oder der Sammlungsdokumentation sein kann. Es ist also auch wichtig, die Grenze der Sprachverwendung ("Bounded context") zu definieren. Wo dann explizit Schnittstellen und Übersetzungen in andere Sprachen nötig sind, sofern Nicht-Beteiligte mit den Daten etwas anfangen sollen. Es ist jedenfalls hilfreich, zu wissen, wie weit man mit den gleichen Begriffen dasselbe meint. Und wann evtl. unterschiedliches. 

...

Um gemeinsam zu Modellieren ist wichtig, wer eine gemeinsame Sprache finden muss, und wer extern über Schnittstellen zu bedienen ist.

Für die Datenmodellierung in der ExpoDB ist es vorteilhaft, dass sie sich JSON und XML bedient, um Daten auszudrücken (Dabei werden nur XML so eingesetzt, dass es sich direkt in JSON-Syntax übersetzen lässt und umgekehrt - ohne dass sich die Semantik der Daten verändert). JSON und XML haben hier verschiedene Vorteile: Sie sind gleichzeitig von Menschen als auch von Maschinen lesbar. Insofern nehmen JSON- sowie XML-Daten gleichzeitig die Rollen von logischem Schema, Nutzerschnittstelle und physischer Realisierung wahr: JSON- und XML-Files sind Textdateien, die einfach aufzubewahren und auszutauschen sind sowie in jedem Texteditor zu betrachten. Browser formatieren die Formate ansprechend, sodass man auch ihre Struktur leicht erfassen kann.

Über die oben skizzierten Tabellen und ihre Relationen via Schlüsselbeziehungen hinaus kennt die ExpoDB noch ein weiteres Konstrukt: Es gibt Datenelemente, die eng zusammengehören, die aber nicht ein gedankliches Konzept darstellen, das für sich separat verwaltet werden sollte. Z.B. gehört in einer Maßangabe die Dimension, der Betrag und die Einheit immer zusammen. Es macht jedoch keinen Sinn "Länge 3 cm" für sich, losgelöst von seinem Objekt zu betrachten. Oft, auch bei Maßen, wiederholen sich solche Datenkomponenten. Neben den "atomaren" Attribute kennt die Modellierung der ExpoDB daher auch solche intern komplex zusammengesetzten "Komponenten", die sich wiederholen können. Andere Beispiele sind z.B. Aliasnamen zu Personen oder zusätzliche Nummerrn zu einem Sammlungsobjekt. Das relationale Konzept bildet solche Situationen in Tabellen ab. Da die ExpoDB mit XML bzw. JSON arbeitet, lassen sich Komponenten direkt in die Entitäten einbetten.

...