Omeka S – eine Option für die Sammlungsdokumentation?

Wir beginnen mit diesem Beitrag eine Serie, in der wir in loser Folge verschiedene Softwaresysteme vorstellen, die Sammlungen – uns interessieren besonders Universitätssammlungen – für die Dokumentation ihrer Bestände einsetzen könnten. Los geht es mit dem vom Roy Rosenzweig Center for History and New Media entwickelten Open-Source-System Omeka S.
Ein guter Bekannter
Mit Omeka habe ich persönlich in verschiedenen Projekten seit etwa zehn Jahren Erfahrungen gesammelt, zunächst mit Omeka Classic[1], nun vermehrt auch mit dem neuen Omeka S[2]. In unserem aktuellen Projekt haben wir die Einführung von Omeka S für eine Nachlass-Erschließung in der Theaterhistorischen Sammlung der Freien Universität Berlin (zur Datenbank) beratend und unterstützend begleitet und das System noch einmal gründlich auf seine Eignung für den Einsatz in Universitätssammlungen untersucht.
Bevor wir uns die Stärken und Limitierungen von Omeka S im Hinblick auf die uns interessierenden Zwecke genauer anschauen, empfiehlt es sich, sich klarzumachen, wofür Omeka S “eigentlich” geschaffen wurde:
„Omeka S is a next-generation web publishing platform for institutions interested in connecting digital cultural heritage collections with other resources online.“
https://omeka.org/s/
Entscheidend ist hier die Bezeichnung “publishing patform”. Es geht also primär um die Online-Präsentation von Objekten. Was Omeka damit nach dem Selbstverständnis seiner Macher*innen nicht ist: ein Datenbanksystem zur grundständigen digitalen Erfassung einer Sammlung. Die Fairness gegenüber den Initiatoren gebietet also, unsere Fragestellung so zu fassen: Könnte man Omeka S trotzdem für die digitale Dokumentation von Universitätssammlungen einsetzen, nämlich in Fällen, in denen ein “richtiges” Dokumentationssystem zu aufwendig, zu teuer, nicht gewollt ist.
Die Installation
Über das Prozedere, das notwendig ist, um Omeka auf einem Standard-Server (Linux, Apache, MySQL, PHP) zum Laufen zu bringen, ist erfreulich wenig zu sagen. Die Installation einer Instanz ist in etwa so (un)aufwendig wie die Installation von WordPress: Wenn der Server richtig konfiguriert ist, lädt man die Dateien hoch, trägt die Datenbank-Credentials ein und füllt im Browser ein Anmeldeformular aus – fertig.
Kann man gleich loslegen?
Für das beschriebene Einsatz-Szenario (begrenzte Ressourcen und Kompetenzen verfügbar) stellt sich an diesem Punkt die spannende Frage: Kann man mit einer solchen unkonfigurierten Installation gleich loslegen mit der Sammlungsdokumentation? Die Antwort enthält ein großes “Ja!” und ein kleines, aber entscheidendes “Aber”.
Die Entwickler*innen von Omeka S haben unverkennbar viel Wert auf die Benutzerfreundlichkeit des Systems gelegt. Mit zwei Klicks kann man nach der Installation im Prinzip sein erstes Sammlungsobjekt dokumentieren. Was es dazu unter realen Bedingungen allerdings noch braucht, ist aus Sicht der Datenbank ein Datenmodell, aus Sicht der Nutzer*innen eine passende Eingabemaske.
Konfigurierbar auf der grafischen Oberfläche
Eine Stärke von Omeka S ist, dass diese Konfiguration von Objekttypen und Eingabemasken vollständig und ausschließlich über die grafische Benutzeroberfläche stattfindet.

Man klickt sich die benötigten Felder einer “Ressourcenvorlage” zusammen, bestimmt ihre Anordnung per Drag & Drop und legt, wenn man möchte, noch den Datentyp der Felder fest. Dieses niedrigschwellige Verfahren hat sich in der Praxis, auch mit technisch weniger versierten Anwender*innen, bewährt.
S steht für Semantic
Um das “Aber” zu verstehen, müssen wir noch einmal kurz die in der Selbstdefinition erwähnte Zielsetzung in den Blick nehmen, wo es heißt: “connecting digital cultural heritage collections with other resources online”. Omeka S verfolgt somit einen Linked-Data-Ansatz, was übrigens den Zusatz “S” (für Semantic) im Namen motiviert.
Wer Online-Ressourcen vernetzten möchte, ist darauf angewiesen, dass die vernetzten Daten nicht nur verfügbar, sondern auch verständlich sind, dass also auch außerhalb des Kontextes der Quelldatenbank klar ist, was ein Datum wie “Urheber”, “Titel” oder “beteiligte Personen” meint. Dies wird erreicht, indem alle Daten semantisch ausgewiesen sind, die Bedeutung also explizit und in einem öffentlich verfügbaren Vokabular bzw. einer Ontologie nachlesbar definiert ist.
Keine Felder ohne Vokabular
Omeka S nimmt deshalb eine konsequente Einschränkung bei der Zusammenstellung der Ressourcenvorlagen (Datenmodelle, Eingabemasken) vor: Es stehen nur Felder zur Verfügung, die aus einem publizierten Vokabular stammen. Vorinstalliert sind Bibliographic Ontology, Dublin Core, Dublin Core Type und Friend of a Friend. Damit stehen 184 Properties zur Verfügung (mit etlichen Überschneidungen und Dopplungen). Das ist nicht wenig, man kommt aber sehr schnell an einen Punkt, wo man wichtige Informationen zu einem Sammlungsobjekt nicht erfassen kann, weil ein passendes Feld in diesen Vokabularen nicht enthalten ist.
Die Krux mit den Vokabularen
Nun kann man weitere Vokabulare installieren, die es ja in Fülle für alle möglichen Fach- und Wissensgebiete gibt. Die Erfahrung zeigt allerdings: von “niedrigschwelllig” kann hier keine Rede mehr sein. Die passenden Vokabulare zu finden, ggf. umzuformatieren und in Omeka S einzubinden bedarf einiger Erfahrung im Bereich Linked Open Data und solider technischer Kenntnisse. Erschwerend kommt hinzu: Die Rückmeldungen, die Omeka S gibt, wenn es nicht auf Anhieb klappt, sind leider recht spartanisch und wenig aussagekräftig.
Wer auch hoch spezifische Informationen oder gar interne Vermerke, nicht standardkonforme Altdaten o.ä. erfassen möchte, beißt bei der erzwungenen Bindung an öffentliche Vokabulare ohnehin auf Granit – man ist ja immer auf Felddefinitionen angewiesen, die andere vorgenommen haben und die für die Allgemeinheit gedacht sind.
Ein Notbehelf
Der Workaround für dieses Problem – aus Sicht der Anbieter ist die Beschränkung keine Schwäche, sondern der Ausrichtungen von Omeka S geschuldet – ist technisch recht simpel: Man schreibt sein eigenes Vokabular und “veröffentlicht” es auf demselben Server, auf dem die Instanz läuft. Formal sind damit die Anforderungen erfüllt: Die Daten sind in einem öffentlich zugänglichen Namespace semantisch ausgewiesen. Dem Geist des Semantic Web entspricht diese idiosynkratische Lösung natürlich nicht wirklich.
Nach diesem Sündenfall hat man die Möglichkeit, gleich den gesamten Feldkatalog aus der eigenen Quelle, nämlich dem pseudo-öffentlichen eigenen Vokabular, zu schöpfen, oder man beschränkt sich auf die Fälle, an denen man mit “richtigen” Vokabularen nicht weiterkommt. Die homogene Lösung hat große praktische Vorteile etwa bei der Verwendung der erweiterten Suche und im Hinblick auf die Mehrsprachigkeit. Wenn man Wert auf Standardkonformität der Daten legt, sollte man das eigene Vokabular nur punktuell als Notbehelf einsetzen, beispielsweise bei Feldern, die ohnehin nicht für die Öffentlichkeit gedacht sind.
“Tripel”-Schritte …
Technisch betrachtet ist Omeka S eine klassische relationale Datenbank: Es gibt Datenbank-Objekte mit Eigenschaften, diese Eigenschaften werden in einer Eingabemaske mit vordefinierten Feldern[3] erfasst. Nun sieht Omeka S in der Basiskonfiguration für diese Datenfelder drei Datentypen vor: Texteinträge, Item Relations und URIs. Item Relations sind Verknüpfungen zu anderen Entitäten in der Omeka-S-Instanz, URIs ermöglichen die Verlinkung auf externe Ressourcen, etwa auf Einträge in Referenzdatenrepositorien. Wenn man interne Verknüpfungen und externe Verlinkungen konsequent und extensiv nutzt, löst man sich vom klassischen Modell “Objekt mit Eigenschaften” und nähert sich einem Wissensgraphen an, einem Netz aus dreigliedrigen Statements, also Tripeln:
Die Fotografie (eine Entität in unserer Instanz) ist im Feld „Fotograf*in“ verknüpft mit Josef Albert (eine Entität)
und
Die Fotografie (Entität) ist im Feld „Herstellungsort“ verlinkt mit http://vocab.getty.edu/page/tgn/7004333 (= München, Eintrag im Getty GeoNames-Thesaurus).
Ich belasse es bei diesen Andeutungen, wer sich jemals mit RDF-basierten Datenmodellen beschäftigt hat, erkennt das Muster.
Das Beste aus zwei Welten oder fauler Kompromiss?
Ist ein solcher Hybrid aus relationaler Datenbank und Graphdatenbank sinnvoll und brauchbar?
Ein Vorteil ist sicher, dass man gleichsam in “vertrauter Umgebung” und ohne die Hürden, die beim Einsatz originärer Graphtechnologie zu meistern wären, viele Vorteile nutzen kann, die dieser Ansatz bietet. Zu beachten sind aber zwei entscheidende Limitierungen:
Die Qualität einer Verknüpfung, also ihre Semantik, ergibt sich einzig aus dem Feld, in dem sie vorgenommen wird. In unserem Beispiel: Die Entität Fotografie X (Subjekt) ist mit der Entität Person Y (Objekt) über das Feld „Fotograf*in“ (Prädikat, Rolle) verknüpft. Damit ist das Spektrum der möglichen Rollen (Prädikationen) 1:1 an die Anzahl der Felder geknüpft.
Wenn man semantisch präzise und differenziert erfassen möchte, wie dies für RDF-basierte Systeme typisch ist, müsste man mit entsprechend großen und damit unübersichtlichen Feldkatalogen arbeiten[4].
Eine zweite Limitierung ergibt sich daraus, dass Omeka S für Entitäten nur flache, nicht-hierarchische Datenmodelle vorsieht. Die Felder einer Eingabemaske lassen sich nicht gruppieren und als Gruppe wiederholen. Damit ist es nicht möglich, eventbasierte Datenmodelle, wie sie etwa CIDOC CRM oder das Austauschformat LIDO vorsehen, zu realisieren.
Nach diesen Standards hätte in unserem Beispiel die Fotografie ein Herstellungs-Event, mit dem der Fotograf in der Rolle des Urhebers und München als Ort des Ereignisses verbunden ist. Das ist mit einer eindimensionalen Feldliste nicht sinnvoll abzubilden.
Was sich mit den von Omeka S angebotenen Instrumenten allerdings sehr gut realisieren lässt, sind klassische “Normalisierungen”: Normansetzungen (intern oder über öffentliche Normdaten), die Abbildung von Teil-Ganzes-Beziehungen usw.
Elegant gelöst
Eine der großen Stärken von Omeka S ist die Benutzerfreundlichkeit der Bedienoberfläche und der angebotenen Funktionen. Man bewegt sich in einem sorgfältig gestalteten, modern und aufgeräumt wirkenden Ambiente und findet sich in aller Regel intuitiv zurecht.

Keep it simple
Zum Teil ist diese Übersichtlichkeit durch einen im Vergleich zu anderen Systemen reduzierten Funktionsumfang erkauft (z.B. bei der Granularität des Rechtemanagements in der Benutzerverwaltung), gerade an wichtigen Stellen wurden aber auch beachtliche Möglichkeiten geschaffen, die man auch ohne Studium der (übrigens vorzüglichen) Dokumentation gut nutzen kann. Dazu zählen unter anderem:
Eine sehr spezifische erweiterte Suche mit der Möglichkeit, komplexe Abfragen zu erstellen und das Suchschema per Bookmark zu speichern.[5]
Die Einbindung von Medien, die neben dem Hochladen von Bildern auch die Verwendung von Online-Ressourcen, Videos, IIIF-Ressourcen und oEmbed erlaubt, mit beliebig vielen Medien pro Entität.
Das gebündelte Bearbeiten von mehreren Entitäten (Batch Editing), allerdings beschränkt auf administrative Basisoperationen.
Relationale Daten, also Item Relations und Verlinkungen auf URIs, sind in der Detailansicht direkt klickbar; verknüpfte Ressourcen werden bei der referenzierten Entität übersichtlich und semantisch gegliedert gelistet.

Limitierungen
Im Interesse der konzeptionellen Ausrichtung von Omeka S und auch der intuitiven Bedienbarkeit ist der Funktionsumfang des Systems in bestimmten Aspekten beschränkt:
Mehrsprachigkeit auf Ebene der Daten (nicht der Bedienoberfläche) wird ermöglicht, indem jedes Feld die Eingabe eines Sprachcodes (EN, DE, FR …) vorsieht. Durch Duplizieren des Feldes lassen sich so sprachspezifische Eintragungen vornehmen. Wenn man allerdings das Duplizieren von Feldern ohnehin vorsieht (mehrere Werte für ein Feld), hätte man zwei Arten von Feldwerten – das wäre keine gute Lösung.
Es gibt keinen Datentyp HTML und deshalb auch keinen Editor (z.B. TinyMCE); [6] Texteingaben sind immer plain text. Bei längeren Texten wie Beschreibungen oder Transkriptionen oder auch schon bei formatierten Literaturangaben (Titel kursiv etc.) kann das sehr einschränkend sein.
Zu einem Feld können beliebig viele Werte eingegeben werden (Repeater-Funktion), die Kardinalität lässt sich aber nicht steuern – jedes Feld ist beliebig oft duplizierbar. Das kann bei Feldern wie z.B. Inventarnummer oder Signatur zu erhöhter Fehleranfälligkeit führen.
Bei sehr vielen Entitäten und/oder vielen Typen von Entitäten (Ressourcenvorlagen) muss man praktisch immer über die erweiterte Suche gehen, wenn man die erfassten Objekte in brauchbarer Form auflisten möchte. In manchen Nutzungsszenarien (“Ich möchte nur schnell …”), wirkt die erweiterte Suche mit ihren vielen Auswahlmöglichkeiten etwas überladen.
Die Schnittstelle
Omeka S verfügt out-of-the-box über eine vernünftig konfigurierte REST API, die die Daten im JSON-Format ausliefert. Die Such- und Filtermöglichkeiten sind ausreichend, allerdings sehr spärlich dokumentiert. Die Sichtbarkeit an der REST API kann für Entititäten im Ganzen und für einzelne Felder auf der Ebene der Ressourcenvorlagen beschränkt werden (nur binär: für nicht authorisierte Nutzer*innen sichtbar oder nicht).
Erweiterungen
Die Arbeit mit Omeka S gewinnt deutlich, wenn man einige der aktuell über 60 verfügbaren Erweiterungen (Modules) einsetzt. Hier sei in der gebotenen Kürze ein Portfolio skizziert, das sich als Basisausstattung bewährt hat:
Ermöglicht den Import von tabellarischen Daten sowie den Upload und die Einbindung von Digitalisaten. Das Mapping auf das Datenschema in Omeka S wird sehr gut unterstützt; neben Komplett-Ingests sind auch partielle Updates möglich.
Modul zum Erstellen einfacher (!) kontrollierter Vokabulare, die dann als Auswahlfelder mit Autocomplete-Funktion in die Eingabemasken eingebunden werden können.
Diese Erweiterung bietet eine Live-Anbindung mit Autosuggest-Funktion zu einem breiten Spektrum von Normdatenrepositorien und Thesauri wie der Gemeinsamen Normdatei (GND), GeoNames oder den Getty-Vocabularies. Für eine referenzdatenbasierte Dokumentationsarbeit ist dieses in zwei Minuten installierte Modul von unschätzbarem Wert.
Erweitert die Möglichkeiten, mehrere Entitäten gebündelt zu bearbeiten.
Sehr interessant sind zudem die Modules IIIF Server und Image Server, die eine Omeka-S-Instanz mit überschaubarem Aufwand zu einem vollgültigen IIIF-Server machen (übrigens an sich ein unorthodoxes aber interessantes Verwendungsszenario für Omeka S).
Und das Frontend?
Den in der Selbstdefinition von Omeka S erwähnten Aspekt “web publishing platform” haben wir bislang vollständig ignoriert, weil uns Omeka im Kontext unseres Projekts vornehmlich als System zur Sammlungsdokumentation (nicht: -präsentation) interessiert. Der Vollständigkeit halber soll nicht unerwähnt bleiben, dass Omeka S über ein integriertes Frontend verfügt, das sich über die grafische Benutzeroberfläche umfangreich konfigurieren lässt. Für die Präsentation stehen (wenig spektakuläre) Themes zur Verfügung, die PHP-Templates können aber wie bei jedem Open-Source-System beliebig angepasst werden, was freilich eher eine Aufgabe für eine/n erfahrenen Webentwickler*in ist. Die Theaterhistorische Sammlung der Freien Universität Berlin hat bei der Objektdatenbank zum Nachlass der Bühnenbildnerfamilie Brandt diese Möglichkeit genutzt.
Fazit
Für Sammlungen, die eine pragmatische, leicht verfügbare und einfach zu konfigurierende Lösung für die digitale Sammlungsdokumentation suchen, scheint uns Omeka S eine interessante Option zu sein. Bei der Evaluierung für den konkreten Einsatz sollte das Augenmerk auf den beschriebenen Limitierungen liegen. Die entscheidende Frage lautet: Kommt man für den geplanten Einsatzzweck mit den ewähnten Einschränkungen zurecht? Ein weiterer Aspekt ist die Frage der Skalierbarkeit: Wenn am Ende sehr umfangreiche Datenbestände zu verwalten oder sehr komplexe redaktionelle Workflows zu berücksichtigen sind, könnte dieses bewusst einfach gehaltene System an seine Grenzen kommen bzw. die Benutzerfreundlichkeit leiden. Außerdem ist zu bedenken, dass sich administrative Vorgänge und Sachverhalte, etwa das Sammlungsmanagement oder der Leihverkehr in diesem als Web Publishing Platform konzipierten System nicht besonders gut abbilden lassen.
Wer Omeka S in Aktion erleben möchte, dem sei die mit Beispieldaten befüllte Sandbox-Version empfohlen, in die man sich jederzeit einloggen und nach Herzenslust experimentieren kann!
Weitere technische Details haben finden Sie im Dossier zu Omeka S.
[1] Die Version Omeka Classic kam bei dem von mir mitentwickelten Ausstellungstool der Deutschen Digitalen Bibliothek DDBstudio (Liste der Ausstellungen) und bei der Provenienzforschungsdatebank zur Sammlung Mosse (MARI) zum Einsatz.
[2] Für die Gedenk- und Bildungsstätte Haus der Wannsee-Konfernz in Berlin entstanden auf der Grundlage von Omeka S eine virtuelle Ausstellung zum Fotonachlass Seeliger und die Präsentation zum Public-History-Projekt “Stumme Zeugnisse” zu privaten Fotoalben aus der Frühphase des Zweiten Weltkriegs.
[3] Im “Normalfall” wird man eine Erfassungsmaske für eine Ressourcenvorlage (Objekttyp) anlegen und sich bei der Eingabe der Daten zu einem bestimmten Objekt dieser Felder bedienen. Es besteht allerdings immer die Möglichkeit, bei einem individuellen Objekt weitere Felder aus den Vokabularen hinzuzufügen. Diese Option scheint mir nur sinnvoll, wenn man ganz auf vordefinierte Erfassungsmasken verzichtet und bei jedem Objekt die Datenstruktur ad hoc erzeugt wie bei Wikibase bzw. Wikidata. Damit hätte man sich allerdings sehr weit von den gewohnten Workflows entfernt.
[4] Oder man verzichtet auf vordefinierte Eingabemasken, siehe Anmerkung 3.
[5] Das Suchschema wird in die Query-Parameter der Seiten-URL übersetzt. Ruft man den Link mit diesen Parametern erneut auf, wird die Suche wieder mit denselben Operationen durchgeführt.
[6] Es besteht allerdings die Möglichkeit, HTML-Content als Medium einzubinden, wofür in der Medien-Eingabemaske ein Editor zur Verfügung steht.
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Michael Müller (16. März 2022). Omeka S – eine Option für die Sammlungsdokumentation? Digitales Netzwerk Sammlungen. Abgerufen am 14. Juni 2025 von https://doi.org/10.58079/nt5m
Eine sehr interessante Artikelreihe, die gespannt auf die weiteren Testkandidaten macht. Insgesamt ist das Thema des “Digital Asset Managements” vielleicht auch in Bezug auf Sammlungsverwaltung interessant?
Vielen Dank, das freut uns zu hören! Digital Asset Management begegnet im Sammlungsbereich z.B. in der Konstellation, dass Systeme wie ResourceSpace de facto als Objektdatenbanken eingesetzt werden, etwa an der Humboldt-Universität in der Variante “Medienrepositorium”. Das halte ich nicht für einen vielversprechenden Weg. Interessanter fände ich einen Ansatz, der im Sinne einer “Separation of Concerns” nicht nur Datenhaltung und Präsentationsschicht technisch entkoppelt, sondern auch die Metadatenerfassung und die Verwaltung der Digitalisate. Im Bibliotheksbereich bietet hier vielleicht der Gobi-Viewer Anknüpfungspunkte, oder auch das Thema IIIF. In welche Richtung gehen Ihre Überlegungen?