Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

CollectiveAccess – ein Schwergewicht unter den Sammlungsdatenbanken

Cover image CollectiveAccess Review

Mit CollectiveAccess stellen wir ein Open-Source-System vor, das seit 2015 verfügbar ist und inzwischen von einer beachtlichen Zahl von Wissenschafts- und Kultureinrichtungen für die digitale Dokumentation und das Management ihrer Sammlungen verwendet wird. In Berlin wird sie beispielsweise von Looted Cultural Assets verwendet, einem Zusammenschluss von Bibliotheken, die sich für die Ermittlung und Restitution von NS-Raubgut engagieren (LCA-Datenbank). Insgesamt ist CollectiveAccess allerdings in Deutschland wenig verbreitet, die meisten Anwender finden sich in den USA, Kanada und Belgien.[1]

CollectiveAccess besteht aus zwei Komponenten: der eigentlichen Datenbank (Providence Core Cataloguing Software) und einem Templating-System zur öffentlichen Präsentation der Datenbank-Inhalte (Pawtucket2 Public Web-access Application). Wie bei all unseren Software-Reviews konzentrieren wir uns auf das Backend, also in diesem Fall auf CollectiveAccess Providence.

Rundum sorglos?

Die Besonderheit von CollectiveAccess ist, dass es versucht, zwei konkurrierende Anforderungen auf einen Nenner zu bringen: Es möchte ein Datenbanksystem sein, das bei der Installation schon auf die Anforderungen von Kulturgut-Sammlungen ausgerichtet ist, also vieles bereits mitbringt, was man zum Dokumentieren von Sammlungsobjekten und ihre Verwaltung braucht, das zugleich aber größtmögliche Flexibilität bei der Anpassung auf die spezifischen Anforderungen der eigenen Sammlung ermöglicht, und dies auf Anwender-Ebene über die Grafische Benutzeroberfläche (GUI), also ohne, dass für die Anpassungen technische Konfigurationen oder Programmierungen notwendig wären.

CollectiveAccess is software for describing all manner of things. Create catalogues that closely conform to your needs without custom programming.

https://www.collectiveaccess.org

Gelingt CollectiveAcces dieses Kunststück? Mit dem gegenüber einem Open-Source-Projekt geboten Wohlwollen würde ich sagen: Ja, durchaus. Allerdings wurde die Kombination aus Vollständigkeit und Offenheit durch eine Reihe von Nachteilen erkauft, die sich vielleicht mit den Begriffen Kompliziertheit und Sperrigkeit am besten benennen lassen.

Readymades – Profile zur Einmalkonfiguration

Dass CollectiveAccess sofort nach der Installation breit ist, für Standardaufgaben der Sammlungsdokumentation und -verwaltung eingesetzt zu werden, wird durch die Verwendung von Installationsprofilen erreicht. Das Profil, ein (sehr umfangreiches) XML-Dokument, legt bei der Installation u.a. fest, welche Typen von Entitäten es gibt, deren Datenmodell, den Aufbau der entsprechenden Eingabemasken usw. – bis hin zu den Sprachvarianten von Feldbezeichnungen. Profile die auf dem Server im Ordner install/profiles/xml vorhanden sind, stehen bei der Installation von CollectiveAccess zur Auswahl.

Wie kommt man nun zu einem passenden Profil und damit zu einer Anfangskonfiguration, die den eigenen Anforderungen entspricht? Hier gibt es drei Ansätze: Standardprofile, die im Hinblick auf einen gängigen Metadatenstandard entwickelt wurden, Profile, die von Anwendern entwickelt und zur Nachnutzung zur Verfügung gestellt wurden, oder ein von Grund auf selbst geschriebenes Profil.

Wer die Wahl hat …

Damit sind die Nutzer*innen von CollectiveAccess noch vor Abschluss der Installation mit einer verwirrenden Vielzahl von Optionen konfrontiert – und leider auch sehr begrenzten Möglichkeiten, eine informierte Entscheidung zu treffen.

Fangen wir von hinten an: Ein eigenes, selbst geschriebenes Profil wäre technisch die sauberste Lösung. Eine knappe Anleitung ist in der Dokumentation (s.v. Installation Profiles) vorhanden. Man muss allerdings nur eines der Standard-Profile anschauen (ca. 5.000 Zeilen komplexes XML), um zu erkennen, dass das Erstellen eines eigenen Installationsprofils eine ausgesprochen anspruchsvolle Aufgabe wäre. Ob das entwickelte Profil funktioniert, also keine die Installation blockierenden Fehlermeldungen produziert, und zu einer Konfiguration führt, die den eigenen Anforderungen entspricht, kann man nur testen, in dem man CollectiveAccess immer wieder neu installiert und dabei die aktuelle Profilversion auswählt. Denn ein einmal installiertes Profil kann für die installierte Instanz nicht mehr geändert werden.[2]

Die zweite Option – Nachnutzung von Fremdprofilen – scheitert schlicht daran, dass die in der Dokumentation aufgelisteten „user-contributed installation profiles“ allesamt „verschwunden“ sind, die angegebenen Links (z.B. Profile der Sterling Morton Library) führen (Stand: September 2022) zu nicht mehr existenten GitHub-Verzeichnissen. Man könnte sie sich vielleicht “besorgen”, aber das wäre dann doch eher eine Bastellösung.

Bleiben die Standard-Profile, die hier hinterlegt sind (seltsamerweise nur in der Develop-, nicht in der Master-Branch des GitHub Repos). Da man mit dem gewählten Profil die Startversion von Datenmodellen und Benutzeroberflächen festlegt, kommt der Frage, welches man nimmt, große Bedeutung zu. Die Beschreibungen in der Auflistung der CollectiveAccess-Dokumentation sind dafür keine gute Grundlage, denn sie charakterisieren letztlich nur den verwendeten Metadatenstandard selbst, nicht die Konfiguration der Anwendung. Am Ende bleibt deshalb nur: ausprobieren! (Für jeden Versuch ist eine Neuinstallation notwendig.)

Konfigurierbarkeit ohne Programmierung

Das zweite Charakteristikum von Collective Access, die weitgehende Konfigurierbarkeit auf Ebene der Grafischen Benutzeroberfläche, baut auf dem durch das Installationsprofil erzeugten Startzustand auf. Wie das funktioniert, ist in der Dokumentation unter User guide > Editing ausführlich beschrieben. Konfigurierbar sind u.a.: die Eingabemasken für eine Entität, ihre Gliederung in Screens (Tabs), die Eingabefelder selbst (Datentyp, Größe, Kardinalität …), ihre Bündelung zu wiederholbaren Komplexfeldern, Listen und Vokabulare.

Damit scheint sich die Frage, mit welchem Installationsprofil man startet, etwas zu relativieren. Was man auf dieser Ebene allerdings nicht konfigurieren kann, sind die überhaupt zur Verfügung stehenden Entitäten, also die Typen von Datenbankobjekten. Bei dem von uns gewählten Profil sind dies: Lots, Objects (gemeint sind physische Sammlungsobjekte), Entities (gemeint sind Personen und Instiutionen), Places, Collections, Exhibitions, Public Program, Publications, Storage Locations und Loans.[3] Hinzu kommen bei fünf dieser Entitäten zwei bis sieben Untertypen. Insgesamt steht bei diesem Profil also eine beachtlich Breite an objektspezifischen Erfassungsmöglichkeiten zur Verfügung.

Grenzen der Konfigurierbarkeit

Wenn man aber beispielsweise wissenschaftliche Apparate, Schriftstücke und Fotografien nach einem je eigenen Datenmodell erfassen möchte, während als Unterkategorien von Objects Document, Drawing, Film & Media, Painting, Photography, Sculpture verfügbar sind, käme man mit diesem Profil nicht weiter. Man müsste doch auf der Ebene des Installationsprofils ansetzen und z.B. das verwendete Profil entsprechend erweitern. Dann beginnt man nach der erforderlichen Neuinstallation wieder mit einer leeren Instanz, müsste die bereits erfassen Daten also exportieren und reimportieren (möglich, aber technisch ziemlich anspruchsvoll).

Ob diese Problematik auftritt, hängt natürlich von den konkreten Anforderungen der Sammlung ab und davon, ob die Datenmodellierung bei der Installation der Software schon abgeschlossen ist oder sich bei der Erfassungsarbeit dynamisch weiterentwickelt. Das Repertoire an verfügbaren Entitäten ist bei den Standard-Profilen in der Regel so groß, dass man in vielen Szenarien mit dem Vorhandenen gut zurechtkommt, zumal hier administrative Sachverhalte wie Ausleihen, Ausstellungspräsenzen oder Standorte erfasst werden können.

Die Kosten der Flexibilität

Die Möglichkeiten, im Profil vorgesehene Entitäten zu konfigurieren, also das zugrundeliegende Datenmodell und die Eingabemasken anzupassen, sind so vielfältig, dass wir uns in diesem Beitrag darauf beschränken müssen, einige Besonderheiten und Knackpunkte anzusprechen.

Das Datenmodell der Entität ergibt sich aus der Festlegung von Datentypen für die einzelnen Attribute/Felder (z.B. Text, HTML-Text, Datum, Relation …) und ihrer Kardinalität (Eingabe mehrerer Werte pro Feld möglich?). Besonders flexibel ist die Datenmodellierung, weil man Felder zu wiederholbaren Gruppen zusammenfassen kann, wie z.B. beim Metadata Element Alternate Name (für Personen), wie der folgende Screenshot zeigt.

Entsprechend komplex ist allerdings auch das Verfahren der GUI-basierten Konfiguration. Sie erfolgt auf unterschiedlichen Ebenen:

  • Preferences: Welches User-Interface soll für eine Entität verwendet werden?
  • User Interfaces mit Screens: Wie sind die Eingabemasken aufgebaut?
  • Metadata Elements mit Subelements: Wie sind die Felder bzw. Container/Komplexfelder konfiguriert?
  • Relations: Welche Beziehungen zwischen Entitäten können hergestellt werden?
  • List & Vocabularies: Welche Listen und kontrollierten Vokabulare stehen zur Verfügung?

(Um nur die wichtigsten zu nennen.)

Komplexität und Kompliziertheit

Bei meiner Arbeit mit CollectiveAccess (in einem frühren Anwendungsprojekt und bei unseren Erprobungen) bin ich offen gestanden nie an den Punkt gelangt, wo ich das Gefühl hatte, das angebotene Spektrum an Einstell- und Auswahlmöglichkeiten vollständig durchdrungen zu haben. Meist findet man einen gangbaren Weg, um das gewünschte Ergebnis zu erreichen, es bleibt aber das ungute Gefühl, vielleicht etwas Wichtiges nicht berücksichtigt oder übersehen zu haben, das einem später “auf die Füße fällt” (was immer wieder vorkam).

Diese Kritik ist selbstverständlich nur unter pragmatischen Gesichtspunkten legitim: Ich gestehe freimütig, die Dokumentation nie ganz gelesen und bei Schwierigkeiten auch nicht systematisch durchgearbeitet zu haben. Um es positiv zu wenden: Seriöserweise sollte man CollectiveAccces nur einsetzen, wenn man breit (und in der Lage) ist, sich intensiv, systematisch und strukturiert mit dieser sehr komplexen Software auseinander zu setzen. Bevor man das System produktiv einsetzt, sollte man klare Vorstellungen über die Modellierung der eigenen Daten haben, sich durch Tests und ggf. Modifikation von Installationsprofilen eine Startkonfiguration “erarbeiten”, die alle wesentlichen Anforderungen abdeckt, die Workflows bei der Datenerfassung an Probedaten durchspielen und dabei Verständnisschwierigkeiten im Hinblick auf Bedienkonzepte und Konventionen gründlich ausräumen. Ein Lern-, Planungs- und Entwicklungsvorlauf von mehreren Personenmonaten erscheint mir dafür eine realistische Einschätzung.

Benutzerfreundlichkeit

Die Frage, ob sich CollectiveAccess bei der praktischen Arbeit an den eigenen Daten gut, flüssig und zuverlässig bedienen lässt, kann hier nur kurz gestreift werden. Probleme sehe ich auf drei Ebenen:

Die Gestaltung der Benutzeroberflächen wirkt recht altbacken und scheint auf dem Stand und Anspruchsniveau der frühen 2010er-Jahre steckengeblieben. Es gibt viel zu viele unterschiedliche Bedienelemente und -konzepte, Listen- und Tabellenformate, Schriftgrößen … Arbeitet man eine Weile mit CollectiveAccess, stellt sich nicht der Eindruck ein, man habe das grundlegende Konzept verstanden. Bis man den gesamten Funktionsumfang durchexerziert hat, lernt man, auch was das Grundsätzliche angeht, nie aus.

Mein Eindruck ist, dass CollectiveAccess den Entwicklern so komplex geraten ist, dass sie nicht mehr in der Lage waren, es bis ins Detail durchzuarbeiten. Zwei Beispiele: die elementar wichtige Funktion, sich als Nutzer*in abmelden zu können (Logout) findet sich winzig in einem struppigen Footer, formatiert wie eine Breadcrump-Navigation:

Bei der Konfiguration der Eingabemasken kann man für ein Metada Element spezifische Einstellungen vornehmen, die nur für diese Maske wirksam werden. Dazu klickt man auf ein i-Icon, was schon seltsam ist, wenn man i als information interpretiert. Um die aufgerufene Pop-Up-Box wieder zu schließen, klickt man in der Box wiederum auf ein i-Icon, das man aber erstmal finden muss, denn es ist unten rechts platziert (statt oben rechts), die Box hat aber eine fixe Höhe, so dass man erstmal in der Box nach unten scrollen muss, sonst hängt man hier fest (Klick außerhalb funktioniert auch nicht).

Klar, das ist nur eine Kleinigkeit, die leicht zu beheben wäre (Stift-Icon zum Aufruf, x-Icon oben rechts zum Schließen, wie üblich), aber in der Summe zahlreicher solcher Schwächen ergibt sich der Eindruck, die Benutzeroberfläche sei unaufgeräumt und irgendwie unfertig.

Doch auch manche fundamentalen Bedienkonzepte, mit denen man bei der praktischen Arbeit ständig konfrontiert ist, sind aus meiner Sicht gründlich verunglückt. Auch hier zwei Beispiele:

Die Eingabemasken sind, was bei komplexeren Datenmodellierungen durchaus sinnvoll ist, auf verschiedene “Screens” aufgeteilt. Das ist eigentlich ein klassischer Fall für eine Tab-Logik, also das Ein- und Ausblenden von Inhaltselementen durch Nutzer*innen-Interaktion (“Reiter anklicken”). Das sollte instantan geschehen, weil ja nur ein paar Display-Attribute von Inhaltselementen geändert werden. In CollectiveAccess führt der Wechsel des Screens aber zu einem neuen Seitenaufruf. Hat man in der aktuellen Eingabemaske nichts geändert, dauert es nur einfach etwas länger, wurden aber zuvor Daten editiert, kommt beim Umschalten erst ein Prompt, das zum Speichern der Daten auffordert. Man hat also beim Arbeiten mit den Screens zwei Bedienkonzepte: Durchschauen ohnen Zwischenspeichern, Editieren mit Zwischenspeichern.

Gewöhnungsbedürftig ist auch die Suchfunktionalität. Für jeden Objekttyp der obersten Ebene (Objects, Entities …) bietet CollectiveAcccess eine einfache Suche, eine erweiterete Suche und eine “Browse”-Funktion, also die Aufschlüsselung des Gesamtbestandes v.a. nach Objekttiteln und Untertypen (Objects: Documents, Drawings, Paintings …). Eine Auswahl in einer dieser rubrizierten Listen führt zu einer Ergebnisliste und von dort zu dem oder den entsprechenden Datenobjekt(en). Unseeligerweise bleibt diese Auswahl bei der Browse-Funktion nun aber eingestellt, wenn man sie nicht mit “Start over” beseitigt. Und diese Voreinstellung überlebt sogar einen Logout/Login oder das Schließen des Browserfensters. Auch diese Eigentümlichkeit brigt großes Potenzial für Verwirrung und Frustration.

Die Frage der Nachhaltigkeit

Die Frage, wie nachhaltig die Investitionen sind, die man in die Einführung einer neuen Dokumentationssoftware steckt, stellt sich bei CollectiveAccess wie bei jedem anderen System, vielleicht aber noch etwas dringlicher, da es einen außergewöhnlich hohen Setup- und Einarbeitungsaufwand erfordert. Entwickler und Maintainer von CollectiveAccess ist die New Yorker Agentur Whirl-i-Gig. Ihre Internetpräsenz besteht aus einer Visitenkarte, auf der neben einen E-Mail-Adresse lediglich gesagt ist, dass es sich um die Macher von CollectiveAccess handelt (kein Impressum, keine postalische Anschrift). Auf Nachfrage per Mail antwortete Developer Seth Kaufman: “We are a small (9 employees) company with staff in New York and on the West Coast (Los Angeles and British Columbia). You are correct about the business model.” – nämlich, dass das Geschäft der Agentur im Wesentlichen darin besteht, Dienstleistungen rund um CollectiveAccess anzubieten.[4] Die Einschätzung, wie breit die Entwickler-Community ist, die sich um den Fortbestand von CollectiveAccess kümmert, wird durch den Umstand erschwert, dass in den letzten Jahren auf GitHub praktisch nur noch der GitHub-User collectiveaccess Commits beigesteuert hat, wohinter sich sicherlich mehrere Entwickler*innen verbergen, aber eben in der Black Box der etwas ominösen Agentur Whirl-Gig.[5]

Ich komme auf der Grundlage dieser dürftigen Informationslage zu der Einschätzung, dass der Fortbestand von CollectiveAccess solange als gesichert gelten kann, wie sich ausreichend Institutionen finden, die Whirl-i-Gig engagieren, um den komplexen Konfigurationsprozess und den Betrieb der Instanzen als Dienstleister zu unterstützen.

Fazit

CollectiveAccess für die Sammlungsdokumentation einzusetzen, erscheint mir als ein Abenteuer, auf das man sich nur gut gerüstet einlassen sollte: mit einiger Erfahrung im Umgang mit Datenbanksystemen, dem Willen und den Ressourcen, sich durch eine längere Test-, Konfigurations- und Lernphase zu kämpfen.[6] Im besten Fall hat man dann ein mächtiges und hochgradig flexibles System zur Verfügung, dessen Funktionsumfang hier nur angedeutet werden konnte. Ein Blick in die Dokumentation und das Experimentieren mit der Sandbox-Instanz lohnen auf alle Fälle.


[1] Siehe die „Projects“-Seite der CollectiveAccess-Website; die Aufstellung ist sicherlich nicht erschöpfend, Gespräche mit Anwendern in Deutschland stützen allerdings die Einschätzung, dass die Anwender-Community im deutschsprachigen Raum nicht sehr umfangreich ist.

[2] Die Dokumentation ist in diesem Punkt sehr deutlich (Abschnitt Changing the installation profile of an existing system: “The answer is you can’t. … Once the installation process is complete the profile ceases to play a role.”.

[3] Das Backend von CollectiveAccess kann auf zahlreiche Sprachen umgestellt werden. Auf Deutsch (Deutschland) heißen die Entitäten: Viele (sic!), Objekte, Entitäten, Orte, Sammlungen, Exhibitions, Public Program, Publications, Standorte, Leihgaben. Am besten verwendet man CollectiveAccess, das zeigt sich nicht nur hier, in der englischen Version.

[4] Meine, von Seth Kaufman bestätigte, Hypothese lautete: “The business model [von Whirl-i-Gig] is based on hosting and consulting solutions around CollectiveAccess.”

[5] Nach Ausweis der Betreiberangabe von collectiveaccess bei GitHub.

[6] Eine Abkürzung wäre es, die Agentur Whirl-i-Gig in New York zu engagieren – für Institutionen im deutschsprachigen Raum vielleicht keine naheliegende Option.


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Michael Müller (21. September 2022). CollectiveAccess – ein Schwergewicht unter den Sammlungsdatenbanken. Digitales Netzwerk Sammlungen. Abgerufen am 16. Mai 2025 von https://doi.org/10.58079/nt5o


Das könnte dich auch interessieren …

3 Antworten

  1. Lieber Herr Müller,

    diesem spannenden Artikel wollten wir eine noch größere Sichtbarkeit verschaffen und haben ihn deshalb in den Slider auf unserer Startseite de.hypotheses.org aufgenommen.

    Viele Grüße

    Ulrike Stockhausen (Community Management)

  1. 29/02/2024

    […] Michael Müller, “CollectiveAccess – ein Schwergewicht unter den Sammlungsdatenbanken,” in: Digitales Netzwerk Sammlungen (21.09.2022), https://dns.hypotheses.org/658.  […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

This site uses Akismet to reduce spam. Learn how your comment data is processed.