Allgemeines
Architekturarchive
Archivbau
Archivbibliotheken
Archive in der Zukunft
Archive von unten
Archivgeschichte
Archivpaedagogik
Archivrecht
Archivsoftware
Ausbildungsfragen
Bestandserhaltung
Bewertung
Bibliothekswesen
Bildquellen
Datenschutz
... weitere
Profil
Abmelden
Weblog abonnieren
null

 

Archivsoftware

Archiverschließung und -verwaltung mit standardkonformer Software

Geschrieben für die Softwareanbieter der Archivistica 2013 ;-)

https://internet.archivschule.uni-marburg.de/midosabb/

Das Firefox-Skript http://jk.g6.cz/dezoomify.html ermöglicht das Herunterladen eines kompletten Bildes einer Zoomify-Anwendung.

Siehe auch
http://de.wikisource.org/wiki/Benutzer:Paulis/Zoomify

http://hdl.handle.net/2027/mdp.39015072446613?urlappend=%3Bseq=239

Siehe auch
http://archiv.twoday.net/search?q=sachav

Als Dienstleister kann man den Verdacht, stets auch immer werben zu wollen, grundsätzlich nicht ausräumen. Nachfolgender Beitrag behandelt aber OpenSource-Software-Bausteine, die wir mit der archium UG zwar wohl als erste in dieser Form eingesetzt haben, nichtsdestotrotz unterliegen sie einer "OpenSource"-Lizenz und sind somit auch unabhängig von uns zu beziehen und zu nutzen. Insofern möge man mir den kurzen Hinweis auf das Unternehmen als "Vorgeschichte" nachsehen.
Interessieren dürfte der Beitrag möglicherweise so manchen Archivaren mit gewissem Drang zur Unabhängigkeit.


Vorgeschichte

Die Essinger Firma archium betreut eine Anzahl von Unternehmensarchiven in Süddeutschland und betreibt Softwareprojekte rund um die Archivierung.

Bereits ab 2008 favorisierten wir die Verwendung einer OpenSource-Erschließungssoftware. ICA-AtoM erschien uns damals als geradezu ideal konzipiert, es erwies sich aber im laufenden Betrieb als mangelhaft umgesetzt. Um unseren Kunden dennoch eine OpenSource-Archivsoftware bieten zu können, haben wir ab Ende 2010 einen recht unkonventionellen Weg beschritten. Wir haben die sehr bewährte OpenSource-Software, die wir zuvor schon seit vielen Jahren für das Projektmanagement genutzt hatten, für den Einsatz im Archiv ausgebaut: Das MediaWiki. Mittlerweile ist es bei mehreren von uns betreuten Unternehmensarchiven im Einsatz.

Aber warum denn unbedingt OpenSource?

"OpenSource" bietet einen fundamentalen Vorzug für Archive.

Eigentlich kann keine Software für sich in Anspruch nehmen, wirklich langzeitstabil zu sein. Software lebt von der Weiterentwicklung. Eine Software, die nicht kontinuierlich gepflegt wird, ist angezählt und nach kurzer Zeit nicht mehr einsetzbar. Denn die Betriebssysteme, Formate, Applikationen und ganz besonders auch die Code-Libraries entwickeln sich drumherum ständig weiter und warten nicht, wenn ein einzelnes Programm aus ihren Reihen zurückbleibt. Auch im Archiv spielen wir dieses Spiel zwangsläufig mit und hoffen, daß der Software-Dealer, der uns den Stoff verkauft hat, dies möglichst lange weiter tun wird und zwar zu gleichbleibenden Konditionen.

OpenSource-Anwender hängen an dieser Nadel nicht. Dabei bietet OpenSource-Software schon grundsätzlich eine bessere Zukunftsprognose. Eine Software, deren Codes vollständig offengelegt sind, gibt die technische Gewähr dafür, daß die Programme prinzipiell weiterentwickelt werden können, selbst wenn der Anbieter nicht mehr existiert oder die Entwicklung einstellt. Und Software, die unter einer freien Lizenz herausgegeben wird, gibt eine ökonomische Gewähr, daß regelmäßige Lizenzkosten entfallen und Wartungskosten auch auf lange Sicht überschaubar bleiben.

Starke Verbreitung des MediaWiki

Allein schon aus diesen Gründen mußte sich eine MediaWiki-Installation wunderbar eignen für den Betrieb in Archiven und Sammlungen. Doch das MediaWiki kann mehr, viel mehr. Es begegnet uns täglich in etlichen tausend Installationen im Internet, gelegentlich zweckentfremdet als CMS gebraucht, zumeist aber als leistungsfähige Basis für Multi-Autorenprojekte. Das prominenteste ist zweifellos die Wikipedia. 1,4 Millionen Datensätze umfasst gegenwärtig allein deren deutscher Zweig. Und diese sehr gut skalierbare Software stöhnt unter dieser Datenlast nicht ansatzweise. Die Zahl der aktiven Benutzer ist jedenfalls jetzt schon so groß, daß der Fortbestand dieser Software sehr eng verflochten sein wird mit dem Fortbestand des freien Internets überhaupt. Denn selbst wenn die Entwicklung der Software MediaWiki eines Tages eingestellt würde, so gäbe es viele tausend Argumente dafür, eine alternative Software zu entwickeln, die ihre Datensätze lesen kann.


Ein typisches Archivobjekt nach ISAD(G), allerdings erweitert um die Darstellung eines Bildes.

Das Lesen der Datensätze -- oder besser als »pages« wahrgenommen -- ist übrigens sehr einfach. MediaWiki speichert Informationen für den Anwender in reiner Textform. Im Hintergrund aber erstellt es einen ObjektCache. Dadurch sind die Daten für den Menschen einerseits mit relativ einfachen Software-Werkzeugen lesbar und zu bearbeiten, der ObjektCache im Hintergrund aber sorgt für die Performance der Maschine, also dafür, daß Recherchen über große Datenbestände schnell zu einem Resultat führen.

Eine »Extension«, die MediaWiki zur Datenbank macht

Auf diese Weise wären wir zunächst aber nur in der Lage, eine strukturierte Textsammlung zu führen. Durch das MediaWiki-eigene Kategoriesystem, über welches sich in der Wikipedia die Zuordnung der Artikel zu Jahrestagen und Personengruppen umsetzen lassen, ist es nun zwar möglich, Indizes zu führen, eine echte Datenbank haben wir damit aber noch nicht. Hier hilft eine der zahlreichen MediaWiki-Erweiterungen, eine s.g. »Extension«, die beim KIT-Karlsruhe im Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB) entwickelt wurde, das »Semantic MediaWiki«.


Die Formulareingabe ist im Prinzip mit jeder anderen Browser-Datenbankschnittstelle identisch. Es gibt Pflichtfelder. Fehleingaben werden erkannt.

Durch die Semantic MediaWiki-Extension wird es möglich, im Text des MediaWiki Felder mit festgesetzten Typen zu definieren und Werte zuzuweisen. Gleichzeitig bleiben die zahlreichen Gestaltungsmittel des MediaWiki verfügbar und können in den Inhalt dieser Felder integriert werden. Diesen, in der deutschen Version »Attribute« und in der englischen Fassung »property« genannten, Feldern sind vielfältige Datentypen zuzordnen. z.B. Volltext, Zeichenkette, Datum, Zahl, URL uvm.


Bei der Bearbeitung von Bildbeständen ist die Bildvorschau sehr hilfreich.

Weitere Extensions erweitern das System um die Möglichkeit der Formulareingabe, stellen eine eigene Parsersprache bereit und erlauben Zeichenkettenoperationen. Das MediaWiki wird damit zu einem äußerst vielseitigen und universell konfigurierbaren Datenbankbaukasten. Wie in jeder anderen Datenbank auch können die Inhalte nun über logische Abfragen erschlossen werden. Die Ergebnismengen enthalten die relevanten »pages«, deren Inhalte aber auch in Tabellenform oder vielen anderen Austauschformaten ausgegeben werden können. Der Datenaustausch erfolgt beispielsweise über XML oder CSV, ermöglicht eigene Volltextfilter und PDF-Ausdrucke.

Die Einrichtung (oder zu Deutsch das »Customizing«) der Datenbank erfolgt über eine Kaskade miteinander verknüpfter Makros, welche die Benutzereingaben interpretieren. Die Funktionsweise läßt sich mit dem geschichteten Aufbau der Erdkugel vergleichen. Der Benutzer bewegt sich auf der Erdkruste. Hier erfolgen die Eingaben. Diese werden über Makros im Oberen Erdmantel in den Unteren Erdmantel geleitet. Dort werden den »properties« die Werte zugewiesen. Und bis hierher kann der Benutzer -- entsprechende Administratorrechte vorausgesetzt -- noch über die Browser-Oberfläche selbst zugreifen. Der Erdkern darunter ist mit PHP- und SQL-Kenntnissen zu erschließen. Im äußeren Erdkern werden die zahlreichen Extensions installiert, die den Inneren Erdkern um zahlreiche Funktionalitäten erweitern.

Diese Analogie zu Ende spinnend: Erdbeben erfolgen ausnahmslos an der Oberfläche, der harte Kern ist sehr stabil bzw. ausgereift. Doch anders als das Erd-Modell verfügt das MediaWiki über eine Versionsgeschichte, die sämtliche Änderungen der Benutzer reversibel macht. Fehleingaben werden dadurch leicht verziehen. Außerdem bleiben alte Zustände dadurch zitierfähig.

Die Möglichkeit zur Rekonstruktion alter Stände gilt übrigens nicht nur für Textinhalte. Auch Dateien können versioniert gespeichert werden. Und wie aus der Wikipedia bekannt, können Bildformate direkt sichtbar gemacht werden. Auf diese Weise läßt sich das MediaWiki ohne weiteres zur Bilddatenbank und zu einem Dokumentenmanagement erweitern.

Für die diesem Aufsatz zugrunde liegende Musterdatenbank wurde ein Datenmodell gewählt, das dem ISAD(G)-Standard sehr nahe kommt. Kleine Abweichungen sind im zusätzlichen »Darin«-Feld zu erkennen. Auch die Bilder oder Anhänge sind untypisch, zeigen aber den fließenden Übergang zur Bilddatenbank.


Anhänge können auf unterschiedliche Weise präsentiert werden. Vorschaubilder erleichtern die Übersicht.

Die große Stärke des MediaWiki zeigt sich gerade dann, wenn es gilt, Datenmodelle (u. U. im laufenden Betrieb) umzubauen. Der Umstand, daß auf der »Erdkruste« und im »Erdmantel« Code und Daten miteinander verschmelzen, ermöglicht die Durchführung systemrelevanter Änderungen mit Textwerkzeugen, die sämtlich das MediaWiki selbst anbietet! So ist es problemlos möglich, Änderungen an einer großen Anzahl von Datensätzen global vorzunehmen.

Schwächen?

Bei allem Lob, es gibt natürlich auch Schwächen.

Es kann vorkommen, daß der ObjektCache im Erdkern der Aktivität im Erdmantel hinterherhinkt. Normalerweise wird dies nur nach automatisierten Schreib-Lese-Vorgängen großer Datenmengen sichtbar, weshalb die Beeinträchtigungen eher den Administrator treffen, und nicht den Anwender. Es existieren aber Hilfsmittel, um das Abarbeiten der s.g. »Job Queue« zu beschleunigen und Ansichten zu aktualisieren.

Das MediaWiki bietet einen solch reichen Kosmos an Möglichkeiten, daß dem Bearbeiter unweigerlich mehr Sachverstand abverlangt wird. Immerhin ist diese Anforderung nicht sehr speziell, schließlich bringt jeder, der sich schon an der Wikipedia beteiligt hat, diese Kenntnisse mit. Außerdem sind die Arbeitsprozesse bestens dokumentiert. Trotzdem muß der Bearbeiter die Tektonik seines Archivs kennen und z.B. bei der Vergabe von Signaturen diszipliniert arbeiten. Diese potentielle Fehlerquelle wird allerdings sehr schön dadurch kompensiert, daß in Serie eingeschlichene Fehler eines unerfahrenen Bearbeiters in der Regel über ein umfassendes Suchen&Ersetzen leicht behoben werden können. Auf dieselbe Weise lassen sich übrigens auch neue Vorgaben problemlos auf ältere Datensätze anwenden, ohne daß ein erneutes Aufrufen alter Datensätze notwendig werden würde.

Fazit


Der großen MediaWiki-Kosmos hält viele Gestaltungsmittel bereit. Das Beispiel zeigt die Verortung von Archivbeständen auf einem interaktiven Zeitstrahl.

Zusammenfassend ist zu sagen: Das Potential des zur Datenbank gereiften MediaWiki ist enorm! Schon die Performance ist überzeugend und die Kinderkrankheiten sind bei einer Software mit solch großer Verbreitung weitestgehend ausgeheilt. Und prinzipiell kann kein proprietäres System hinsichtlich Langzeitarchivierung bieten, was ein OpenSource-System wie das MediaWiki bietet: Eine sehr günstige Zukunftsprognose, Bindungsfreiheit, die denkbar geringsten Anschaffungskosten und eine sehr gut kalkulierbare Kostenentwicklung im laufenden Betrieb.

Die Musterdatenbank der hier gezeigten Beispiele ist online einsehbar hier.

Der identische Aufsatz ist auch als PDF verfügbar hier.

 

twoday.net AGB

xml version of this page

xml version of this topic

powered by Antville powered by Helma