Personal tools
You are here: Home Dokumentation Digilib
Navigation
Log in


Forgot your password?
« October 2024 »
Su Mo Tu We Th Fr Sa
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
 
Document Actions

Digilib

by raspe last modified 2006-12-17 21:37

Ein netzbasiertes Werkzeug zum Studium und zur Annotation von Bildern

A web-based tool for the scholarly study and annotation of images

Martin Raspe (Bibliotheca Hertziana, Rom)

Zusammenfassung

Digilib ist ein Computerprogramm für Wissenschaftler, mit dem man Bilder über das Netz betrachten, vergrößern und wissenschaftlich annotieren kann. Es wird von zwei geisteswissenschaftlichen Max-Planck-Instituten in Zusammenarbeit mit dem Institut für Wissenschaftsgeschichte der Universität Bern als Open Source entwickelt und bietet viele neue Möglichkeiten zur Erschließung wissenschaftlichen Bildmaterials.

Abstract

Digilib is a software tool for the scholarly study of graphic images via internet. Images can be zoomed and annotated in a persistent way. It is being developed as Open Source by two institutes in the Humanities section of the Max Planck society in collaboration with the Institute for the History of Science at Bern University and opens up new perspectives of scholarly research based on digital images.

Wissenschaftliche Bilder im Netz

Scientific images on the web

Der Zugang zu Texten über das Internet wird immer besser und schneller. Google und ähnliche Dienste eröffnen den augenblicklichen Zugang zu Informationen, die noch vor wenigen Jahren nur mit großen Mühen zu beschaffen gewesen wären. Die standardisierte Webseiten-Formatierungssprache HTML sorgt dafür, daß die schriftlichen Inhalte den Leser auch visuell ansprechen können.

Auch für die Wissenschaft ist der Mehrwert unübersehbar: Der Forscher konsultiert Fachdatenbanken in der ganzen Welt nach verschiedenen Gesichtspunkten, rare und historische Werke stehen ihm als elektronische Faksimiles und in digitaler Transkription zur Verfügung, und seine Ergebnisse kann er zeitnah online publizieren. Ein standardisiertes Dateiformat (PDF, portable document format) und ein weitverbreitetes, mit komfortablen Funktionen ausgestattetes und in den Internet-Browser integriertes Leseprogramm (Acrobat Reader[1]) tragen bei zur Verbreitung druckfertiger Texte und zum Austausch wissenschaftlicher Informationen.

Die Möglichkeiten, mit Bildern zu arbeiten, und ihre inhaltliche Erschließung halten damit nicht Schritt. Das hat verschiedene Gründe. Zum einen erfordern Dateien, die Grafiken enthalten, im Vergleich zu Texten in der Regel ein Vielfaches an Speicherplatz. Das wirkt sich auf die Archivierungskosten, die Ladezeiten im Internet und die erforderliche Bandbreite aus. Zwar könnten zweidimensionale Diagramme und vergleichbare synthetisch erzeugte Bilder durch den Einsatz von Vektorgrafiken stark vereinfacht und im Platzbedarf enorm reduziert werden. Das dazu notwendige, standardisierte Dateiformat (SVG, scalable vector graphics) ist aber gerade erst dabei, sich durchzusetzen, und wird noch nicht von allen Browsern unterstützt.[2] Im Bereich der dreidimensionalen Grafiken bzw. Modelle hat sich noch kein Standard durchgesetzt, geschweige denn eine Betrachtungssoftware.

Der größte Teil der in der Wissenschaft anfallenden bildlichen Daten besteht jedoch in optisch erzeugten Abbildern, also in digitalen Fotografien, Scans oder Filmen. Die Schwierigkeiten bei der Gewinnung von farbtreuem, unverfälschten Bildmaterial seien hier nur erwähnt. Probleme wirft auch die Speicherung der Bilddaten auf. Bislang gibt es noch kein Verfahren, die grafische Struktur der Bilder auf intelligente Weise so zu analysieren, daß man sie platzsparend digital ablegen kann. Daher speichert man Bilder so, wie sie die heutigen Erfassungsgeräte produzieren, nämlich als Rastergrafik. Das Bild besteht aus rasterförmig angeordneten, quadratischen Bildpunkten (Pixeln), deren Anzahl die Schärfe bzw. Detailliertheit des Bildes bestimmt: Je mehr Bildpunkte pro Maßeinheit, desto höher ist die Detailgenauigkeit der digitalen Reproduktion. Dieser auch „Auflösung“ genannte Wert wird meist in dots per inch (dpi) gemessen. Ein Bild, das in Druckqualität wiedergegeben werden soll, muß ungefähr 300 dpi haben. Auf den Quadratzentimeter kommen dabei etwa 14.000 Bildpunkte.

Helligkeit, Farbton, Sättigung und Transparenz müssen für jeden Bildpunkt einzeln gespeichert werden. Kompressionsmethoden können zwar den Speicherbedarf reduzieren, eine höhere Verdichtung ist aber ohne Qualitätsverluste meist nicht möglich. Außerdem muß vor jeder Wiedergabe oder Bearbeitung das Bild erst dekomprimiert werden. Die Anzahl der Dateiformate ist unübersehbar. Die universelle Verwendbarkeit vieler Formate ist zudem durch patentrechtliche Probleme oder Inkompatibilitäten zwischen verschiedenen Formatversionen beeinträchtigt.

Zum anderen kommen Probleme bei der inhaltlichen Erschließung hinzu. Ein Bild sagt mehr als tausend Worte, aber nur dem menschlichen Verstand, nicht dem Computer. Maschinell lassen sich aus Pixel- oder Vektordaten kaum nennenswerte inhaltliche Informationen extrahieren. Alles, was wir über das Bild wissen wollen, muß als „Metadaten“ mitgeliefert werden. Das betrifft den Bildinhalt, also das, was dargestellt ist, ebenso wie die technischen Daten und die Umstände der Aufnahme.

Der Umgang mit den notwendigen Zusatzinformationen wirft neue, bislang ebenfalls noch weitgehend ungelöste Probleme auf. Zwar gibt es die Möglichkeit, Metadaten in die Bilddateien zu integrieren, aber auch hier fehlt es an Standardformaten. Inhaltlich durchsuchbar sind diese Daten oft nicht. Eine separate Verwaltung der Metadaten erfordert ein hohes Maß an Organisation, damit der Zusammenhang mit den Bildern nicht verloren geht. Bilddatenbanken sind zwar mittlerweile zahlreich im Netz vorhanden, es handelt sich aber in der Regel um individuell konzipierte Lösungen. Höheren Ansprüchen genügende Standardanwendungen und –schnittstellen sind weiterhin Mangelware. Will der Forscher mit den Bildern weiterarbeiten, und sei es nur, um sie wissenschaftlich zu zitieren, ist er auf sich allein gestellt.

Von Forschern für Forscher: Die Entwicklung von Digilib

For scholars by scholars: Developing Digilib

Um das wissenschaftliche Material besser organisieren und studieren zu können, haben sich Forscher zu allen Zeiten ihr Werkzeug selber geschaffen. Das gilt auch für das digitale Zeitalter. Zwei Probleme stellten sich von Anfang an bei der Nutzung wissenschaftlicher Bilder im Internet. Beide stehen miteinander in Beziehung und sind auch heute noch nicht in allgemeinverbindlicher Weise gelöst.

Das eine ist die Wartezeit bei der Übertragung hochaufgelöster digitaler Pixelgrafiken. Sie bildet noch heute ein unübersehbares Hindernis. Ein bildschirmfüllendes Bild von 1024 mal 768 Bildpunkten in true color, wie es dem Standard heutiger Monitore entspricht, enthält unkomprimiert bereits 2,2 Megabyte an Daten und braucht auch bei sehr schneller Netzverbindung oft einige Sekunden, um ganz übertragen zu werden. Wenn man als Forscher viele Bilder durchsehen muß, kann das bald zu einem Hemmschuh werden.

Außerdem ist ein Monitorbild in vielen Fällen nicht ausreichend genau, es enthält weniger Bildinformationen als ein scharfer Fotoabzug von 7 mal 10 cm Größe. Will man detailreichere Bilder sehen, muß man entweder größere Bilddateien übertragen (bei entsprechend verlängerter Wartezeit) oder interaktiv auf höher aufgelöste Ausschnitte zugreifen können.

Hier zeigt sich das zweite Problem: Wenn man mit einem virtuellen Bildausschnitt arbeitet, dann muß man dessen Abmessungen und Maßstab fixieren, um den Ausschnitt später reproduzieren zu können, etwa um eine wissenschaftliche Aussage zu belegen. Um auf relevante Einzelheiten hinzuweisen, wäre es sinnvoll, Markierungen, Pfeile oder andere erläuternden Elemente einzeichnen zu können. In digitale Bilder lassen sich solche Dinge aber nicht einfügen, ohne das Original selbst zu verändern oder zumindest den Übertragungsvorgang auf dem Bildserver zu manipulieren.

Digitale Bilder stellen also zwei Herausforderungen an die Wissenschaft: Zum einen möchte der Forscher sie vertieft studieren, analysieren und erforschen, zum anderen seine Ergebnisse dokumentieren, indem er seine Aussagen überprüfbar mit anschaulichen Details belegt, erklärend annotiert und mit Hilfe fester Referenzen in zitiert. Diese Vorgehensweise sollte nicht nur dem Forscher möglich sein, der die Bilder faktisch besitzt, sondern jedem Wissenschaftler, der im Internet mit fremden Bildern arbeitet oder auch nur die Aussagen von Kollegen nachprüfen will.

Diesen beiden Anforderungen begegnet ein Grafikserver-Programm, das seit 1996 am Max-Planck-Institut für Wissenschaftsgeschichte in Berlin auf Anregung und unter Leitung von Prof. Gerd Graßhoff verwirklicht wird.[3] Am Anfang stand ein hauptsächlich von Michael May als clientseitiges Java-Applet geschriebenes Bildbetrachtungsprogramm mit hierarchischer Darstellung (tree view) der bereitgestellten Bilddokumente, das zunächst „docuedit“ (auch DocumentDatabase), später „doculight“ hieß. Mit dem Wechsel von Graßhoff an das Institut für Wissenschaftstheorie und Wissenschaftsgeschichte der Universität Bern verlagerte sich das Projekt dorthin. Im Juni 2000 erfolgte unter Beteiligung von Robert Gordesch der Übergang zu einer Client-Server Lösung namens "gg.jsp", die allerdings die Ausschnittvergrößerung noch nicht beherrschte.

Wenig später entstand das heute noch gültige Konzept, das unten dargestellt wird. Es erhielt den Namen „Digilib“ (kurz für digital document library), weil es zunächst hauptsächlich eingesetzt wurde für die Lektüre und Annotation digital faksimilierter historischer Druckwerke aus dem Bereich der Geschichte der Naturwissenschaften.

Seit Anfang 2002 ist das Projekt bei der Open Source-Vermittlungsplattform „BerliOS“ registriert, die vom Fraunhofer-Institut für Offene Kommunikationssysteme betrieben wird.[4] Dort sind der Programmcode und die Dokumentation beheimatet.[5] Seither verteilt sich die Entwicklung auf zwei Institute.

In Bern bauen Daniel Engler und Christian Luginbühl vorrangig die Client-Seite weiter aus. Der Schwerpunkt liegt dabei auf Zusatzmodulen, die sich in den Webbrowser Firefox integrieren lassen und zahlreiche Möglichkeiten zur Dokumentation und Annotation bieten (dazu unten mehr). Die online verfügbare Dissertation von Hans-Christoph Liess, der ebenfalls zu den Entwickern gehört, führt deren Anwendung in der Forschung am konkreten Beispiel vor.[6] Entscheidend ist dabei, daß das originale Bilddokument nicht kompromittiert oder manipuliert werden muß, sondern die zusätzlichen Informationen von außen hinzugefügt oder darübergeblendet werden. Der Benutzer ist nicht an die Vorgaben des Bearbeiters gebunden, sondern kann die Bildquelle uneingeschränkt und nach eigenem Gutdünken studieren. Trotzdem bleibt der gesamte Dokumentationskontext über die URL reproduzierbar.

In Berlin arbeitet seit 2001 Dr. Robert Casties vor allem an der Weiterentwicklung, Konsolidierung und Konzeption der Server-Software. Viele der unten beschriebenen Funktionen, die mittlerweile hinzugekommen sind, gehen auf seine Tätigkeit zurück.

Das ECHO-Projekt: Neue Anwendungen für Digilib

The ECHO project: New tasks for digilib

Am MPI in Berlin wird Digilib in erster Linie zur Präsentation von Digitalisierungen und Transkriptionen historischer naturwissenschaftlicher Druckwerke aus der frühen Neuzeit eingesetzt, die in dem Projekt „Archimedes“ zusammengefaßt sind.[7] In Bern werden astronomische Diagramme aus mittelalterlichen Handschriften[8], Abbildungen aus historischen Werken der Botanik[9] sowie Laborbücher aus der Naturwissenschaft des 20. Jahrhunderts[10] mit Digilib zugänglich gemacht.

Das von der Europäischen Kommission im 5. Rahmenprogramm geförderte Projekt ECHO (European Cultural Heritage Online), an dem mehrere Max-Planck-Institute beteiligt waren, brachte für Digilib von 2002 an einen starken Entwicklungsschub.[11] Seither gehört auch die Bibliotheca Hertziana (MPI für Kunstgeschichte) in Rom zum Kreis der Digilib-Benutzer und –Entwickler. Ziel von ECHO ist es, Quellen und Material zur gesamten europäischen Kulturgeschichte über das Internet öffentlich verfügbar zu machen und durch Vernetzung der Informationen kulturelle Vielschichtigkeit abzubilden sowie einen interdisziplinären Zugang zum europäischen Kulturerbe zu bieten.

Durch diese Erweiterung des wissenschaftlichen Horizontes kamen auch andere Anwendungen in das Blickfeld. Der Beitrag der Bibliotheca Hertziana zu ECHO ist das Projekt „Lineamenta“, eine von Prof. Elisabeth Kieven initiierte Forschungsdatenbank für Architekturzeichnungen.[12] Ziel von Lineamenta ist es, historische Architekturpläne – der Schwerpunkt liegt zunächst auf dem 18. Jahrhundert – in hochaufgelösten Digitalfotografien bzw. Scans der Forschung zur Verfügung zu stellen und parallel dazu die Zeichnungen wissenschaftlich zu katalogisieren und durch ein Datenbanksystem zu erschließen.

Die barocken Zeichnungen von bis zu 150 cm Seitenlänge werden mit aufwendiger Kameratechnik in der Hertziana gescannt (Projektleitung Hermann Schlimme) und werden mit Hilfe von Digilib konsultierbar gemacht. In einer zweiten Datenbank namens CIPRO (Catalogo delle Piante di Roma Online)[13], die historische Stadtpläne und Ansichten der Stadt Rom enthält, kommen noch größere Formate vor. Die einzelnen Dateien haben in der Regel eine Größe von 700 Megabyte und erreichen mitunter 1,5 Gigabyte.

Da die Abbildungen nicht nur betrachtet, sondern auch im Rahmen von Forschungsfragen untersucht werden sollten, mußte Digilib um entsprechende Funktionen erweitert, die die Anzeige des Bildausschnittes in Originalgröße, die Verstellung von Helligkeit und Kontrast und das Drehen und Spiegeln von Ausschnitten erlauben. Diese Neuerungen wurden im Rahmen des ECHO-Workpackage 2 (Technology) in Zusammenarbeit zwischen dem Berner Institut und dem MPI in Berlin entwickelt. Bei letzterem lag auch die Gesamtkoordination für ECHO.

Seither hat Digilib als Instrument zur Betrachtung und wissenschaftlichen Analyse grafischer Kunstwerke an Bedeutung gewonnen. Für diese Materialgattung bietet es sich besonders an, da die Werke häufig aus konservatorischen Gründen unter Verschluß gehalten werden müssen und nur an einem Ort, nicht selten unter starken Einschränkungen, konsultiert werden können. Das ändert sich nun. Der kunstwissenschaftlichen Forschung wird dadurch ein ganzes Materialcorpus erstmals zugänglich.

Auch andere Sammlungen setzen Digilib zur Präsentation von Architekturzeichnungen ein. Die Kasseler Museen veröffentlichen im Rahmen eines DFG-Projektes die Architekturzeichnungen der Staatlichen Graphischen Sammlung.[14] Das Museo di Castelvecchio in Verona verwendet Digilib zur internen Konsultation der Zeichnungen von Carlo Scarpa.[15]

Bei „ArsRoma“, einem weiteren Projekt der Bibliotheca Hertziana unter Leitung von Prof. Sybille Ebert-Schifferer[16], dient Digilib zur detaillierten Veranschaulichung römischer Gemälden um 1600. Das Archiv des Kunsthistorikers Friedrich Noack zu den in Rom tätigen ausländischen Künstlern wird ebenfalls mit Hilfe von Digilib erschlossen. Die aus über 18000 Notizzetteln in Kurzschrift bestehenden „Schede Noack“ wurden 2005 digitalisiert.[17]

Daneben spielt Digilib eine wichtige Rolle in wissenschaftlichen Fototheken, die ihre Bestände an dokumentarischen Fotografien online stellen möchten. Die Max-Planck-Institute für Kunstgeschichte in Rom und Florenz machen sowohl digitale Originalfotos als auch gescannte Negative mit Digilib über das Internet zugänglich. Die Fotothek der Bibliotheca Hertziana betreibt dafür intern ihren eigenen Digilib-Server, während die digitalisierten Fotos des Florentiner Instituts bei der GWDG in Göttingen untergebracht sind,[18] die für die Installation und den Betrieb des Servers verantwortlich ist. Auch die Bilddateien zum "Historischen Farbdiaarchiv zur Wand- und Deckenmalerei“ werden dort mit Hilfe von Digilib bereitgestellt. Die zugehörige Datenbank des Zentralinstituts in München enthält die Metadaten zu den von 1943 bis 1945 im Auftrag Hitlers aufgenommenen Farbdiapositive von vielen heute verlorenen Kunstwerken.[19]

Funktionsweise

How it works

Die Grundidee ist einfach und gehört noch im heutigen Digilib zum Kernbestand: Bilder und Bildausschnitte werden von einem zentralen Server mit einer stabilen Internetadresse ausgeliefert; die Steuerung der erfolgt über verschiedene Parameter im query string des Aufrufs. Damit diese Funktionalität nutzbar wird, besteht das System aus zwei Software-Komponenten. Die eine stellt dem anfragenden client, also im Internetbrowser des Benutzers, komfortable Bedienungsmöglichkeiten zur Verfügung, die andere arbeitet auf dem Server und überträgt das angeforderte Bild.

Die Größe des Bildausschnitts, die gewünschte Bildgröße und weitere Befehle zur Manipulation des übertragenen Bildes werden nicht nur an den Server übermittelt, sondern können in einer standardisierten URL gespeichert werden. Angaben, die nicht den Server, sondern die clientseitige Darstellung betreffen, wie Koordinaten von Markierungen und Annotationen, werden ebenfalls in die URL integriert. Sie enthält alle Informationen, um den kompletten Darstellungskontext zu reproduzieren. Die URL kann auf der Clientseite gespeichert, weitergegeben und von jedem anderen Programm genutzt werden, das zur Verwaltung von Internetadressen in der Lage ist.

Auf dem Server werden die Bilddateien werden in bestimmten Verzeichnissen vorgehalten und mit einer festen Pfad abgerufen. An die URL werden mehrere Parameter angehängt, von denen zwei (wx, wy) die linken oberen Eckkoordinaten des gewünschten Ausschnitts und zwei andere (ww, wh) Breite und Höhe des Ausschnitts angeben. Die Angabe der Koordinaten erfolgt relativ zu den Dimensionen der Originalgrafik in Werten zwischen 0 und 1. Zwei zusätzliche Parameter (dh, dw) fordern die Größe der Bilddatei in Pixeln an. So kann die übertragene Datenmenge genau auf die verfügbare Bildschirmgröße oder auf die Übertragungsgeschwindigkeit abgestimmt werden. Ein zusätzlicher Parameter (ws) vergrößert oder verkleinert die angeforderte Grafik um einen festen Skalierungsfaktor.

Sendet der Client eine solcherart geformte Anfrage, so rechnet das Programm auf dem Server aus der Originalgrafik den gewünschten Ausschnitt mit den passenden Abmessungen on the fly heraus und sendet diesen in einem für den Internetbrowser verständlichen Bildformat zurück. Hierfür werden wahlweise JPEG und PNG (portable network graphics) verwendet.[20]

Es liegt auf der Hand, daß die Reaktionszeit des Server-Programms von ausschlaggebender Bedeutung für die flüssige Nutzbarkeit des Programmes ist. Sie hängt in erster Linie von der Geschwindigkeit der grafischen Umrechnung ab. In der derzeitigen Version läuft auf dem Server ein in Java geschriebenes servlet innerhalb eines servlet containers (Apache Tomcat)[21], das diesen Dienst mit Hilfe der auf die Verarbeitung von Grafiken spezialisierten JAI-Softwarebibliothek (Java Advanced Imaging)[22] verrichtet. Durch zusätzliche Maßnahmen läßt sich der Umrechnungsvorgang weiter beschleunigen, etwa indem man kleinere, geringer aufgelöste Versionen der Grafiken bereithält, die bei weniger detaillierten Anforderungen benutzt werden, oder wenn die Dateien auf dem Server in einem geschickt durch stripes oder tiles gekachelten TIFF-Format (tagged image file format)[23] vorliegen.

Im Vergleich zu anderen Bildbetrachtern für hochaufgelöste Grafiken, die im Internet Verwendung finden, zeichnet sich Digilib allerdings bisher nicht durch besondere Geschwindigkeit aus, und auch nicht durch besonders einfache, intuitive Benutzung. Kommerzielle Produkte wie „Zoomify“, „FlashPix“ oder andere auf Flash basierende Anwendungen bieten in dieser Hinsicht mehr. Sie haben aber andere Nachteile: Sie zerlegen z. B. die Originalgrafik in eine schwer zu verwaltende Fülle von kleinen Einzeldateien oder erfordern die Installation eines speziellen plugin beim Client. In der Regel stehen sie auch nicht als open source zur Verfügung, können also nicht als zukunftssicher gelten. Außerdem fehlt ihnen die Möglichkeit, eine zitierfähige Referenz auf einen bestimmten Ausschnitt zu erstellen, bzw. Annotationen zu machen.[24]

Mit Hilfe der Java-Grafikbibliothek können weitere Manipulationen an dem übertragenen Bild vorgenommen werden. Auch diese werden durch Parameter im query string der URL gesteuert, die das Servlet liest und anwendet. So läßt sich das Bild horizontal oder vertikal spiegeln und in einem beliebigen Winkel drehen. Helligkeit, Kontrast und die Balance der Farben lassen sich verstellen, was zum Beispiel für das Entziffern kontrastarmer, nur schwach sichtbarer Beschriftungen in Bleistift wichtig ist. Außerdem kann der Client bessere, aber langsamere Algorithmen zur Bildumrechnung anfordern, die insbesondere bei geringerer Auflösung das Lesen kontrastreich gedruckter Texte erleichtern.

Um diese serverseitigen Funktionen zu nutzen, stehen für den Client verschiedene Oberflächen zur Bildbetrachtung und Verwaltung zur Verfügung, die ebenfalls auf dem Server zum Abruf bereitstehen. In der Regel erfolgt die Benutzung von Digilib im Browser mit Hilfe solcher vorgefertigter Arbeitsumgebungen, die im Prinzip wie gewöhnlich Webseiten gestaltet sind. Diese liegen auf dem Server als JSP („Java Server Page“). Im Gegensatz zu statischen Webseiten können sie mit veränderlichen Angaben aus dem Kontext des Servers angereichert werden, z. B. über die Anzahl und die Größe der vorhandenen Bilddateien. Auch Metadaten zum angeforderten Bild können in die JSP integriert werden, wenn sie dem Server in definierter Form vorliegen.

Außerdem muß die clientseitige Oberfläche dynamische Elemente enthalten, die eine interaktive Bedienung erst ermöglichen. So wird etwa der gewünschte Bildausschnitt festgelegt, indem ein beweglicher Rahmen mit der Maus aufgezogen wird. Dafür wird kein zusätzliches Plugin, Applet oder ActiveX-Objekt benötigt, sondern es wird nur standardisiertes DHTML (dynamic hypertext markup language) verwendet, das ein Browser ohne Zusatzinstallationen versteht. Die Programmierung der dynamischen Elemente erfolgt in Javascript. Das beste Ergebnis erzielt man derzeit mit Browsern aus der Mozilla-Familie, da diese sich am zuverlässigsten an die Standards halten. Soweit möglich, werden die Eigentümlichkeiten anderer Browser (Internet Explorer, Opera, Safari) berücksichtigt.

Neben der Standard-Oberfläche „digilib.jsp“ gibt es derzeit die Katalogansicht „digicat.jsp“, die eine Übersicht bietet über die Bilddateien, die im derzeit ausgewählten Server-Verzeichnis vorhanden sind. Diese werden als Matrix von minaturisierten Vorschaubildern (thumbnails) dargestellt, die Anzahl der Reihen und Spalten kann clientseitig eingestellt werden. Ein Klick auf das gewünschte Vorschaubild ruft das Bild in der gewohnten Digilib-Oberfläche zur weiteren Betrachtung auf.

Die an der Universität Bern entwickelten Zusatzmodule erweitern die Kernfunktionalität des Grafikservers um spezielle Anwendungsbereiche. Diese neuen Bestandteile sind unter dem Arbeitstitel „Alcatraz“ zusammengefaßt.[25] und nutzen die Fähigkeit des offenen Browsers Mozilla Firefox, dynamisch extensions zu integrieren.[26] Diese Erweiterungen können vom Benutzer je nach Bedürfnis installiert werden und ermöglichen es ihm, die Funktionalität von Digilib für eigene Zwecke einzusetzen, unabhängig davon, welche Nutzungsmöglichkeit der Bildserver von sich aus anbietet. Die Erweiterungen sind in der für Mozilla-Browser entwickelten Interface-Beschreibungssprache XUL erstellt; sie folgen diesem Standard und sind im Quellcode verfügbar.

Das Modul „Compago“ dient dem detaillierten und dokumentierten Vergleich zweier Bilder bzw. Faksimileseiten.[27] „Relato“ setzt die Abbildungen zu ihrem inhaltlichen Kontext in Beziehung, etwa ein historisches Schriftstück zu seiner Transkription, aber auch zu anderweitigem Material. „Navigio“ ermöglicht durch ein Zusatzwerkzeug für den Browser den Zugriff auf ein breites Spektrum von Internet-Ressourcen mit wissenschaftlichem Material. Die Erschließung erfolgt anhand semantischer Kategorien in einer hierarchischen Baumstruktur. So kann der Forscher Inhaltsverzeichnisse, Kataloge, Ontologien und vergleichbar organisierte Bestände durchblättern und relevantes Material herausfiltern. „Annota“ gibt dem Forscher die Möglichkeit, zu relevanten Positionen im Bild kommentierende Texte zu verfassen, diese dauerhaft lokal oder in einer Annotationsdatenbank auf einem Server zu speichern und so inhaltliche Anmerkungen mitzuteilen.

Unabhängige Webseiten oder eigenständige Programme können die Digilib-Servlets auch direkt ansprechen, wenn auf die vorgefertigten Bedienungsoberflächen oder Browser-Erweitungen verzichtet werden kann. Das dazu notwendige API (application programming interface) ist dokumentiert. Der Quellcode für Digilib ist offen zugänglich und steht unter der Open Source-Lizenz GPL (GNU General Public License).[28] Der aktuelle Stand kann jederzeit über ein CVS (concurrent versioning system) abgerufen und zur Erstellung einer neuen Programm-Version verwendet werden.[29] Von Zeit zu Zeit werden releases herausgegeben, wenn der Code einen stabil laufenden Zustand erreicht hat. Derzeit ist bei der Installation noch einiges an Handarbeit erforderlich, eine Automatisierung des Einrichtungsvorgangs ist ein Ziel, an dem gearbeitet wird.[30] Wie häufig bei Open Source-Projekten, speziell dort, wo die Entwickler wie bei Digilib zunächst nur für die eigenen Bedürfnisse programmiert haben, mangelt es an der notwendigen Dokumentation. Auch diesem Mangel soll nach und nach abgeholfen werden. Das wird um so wichtiger, je größer die Nutzergemeinschaft von Digilib wird. Dieser Artikel ist ein Schritt auf diesem Weg. Zum Informationsaustausch, zur Diskussion der weiteren Entwicklung, aber auch Anfragen an die Entwickler dient eine mailing list, bei der sich jeder Interessierte einschreiben kann.[31]

Zukunftsperspektiven

New horizons

Die Nutzungsmöglichkeiten von Digilib für die Wissenschaft sind mit den bisher realisierten Programmen und Modulen bei weitem nicht erschöpft. Es gibt viele Ideen für die Weiterentwicklung. Für manche liegen bereits prototypische Implementationen vor, die nur noch nicht in eine allgemeine nutzbare Form gebracht worden sind.

Zu verbessern ist zunächst die Integration von Bild- und Metadaten. Es gibt noch keine definierte Schnittstelle für den Austausch zwischen Digilib und der jeweiligen Datenbank, die die inhaltlichen Informationen zu den Bildern liefert. Die Metadaten müssen derzeit noch als XML-Dateien im gleichen Verzeichnis wie die Grafiken angelegt und unabhängig von der Datenbank gewartet werden. Eine engere Verknüpfung zwischen Datenbank und Bild, und zwar in beiden Richtungen, ist dringend notwendig.

Dazu gehören auch Maßnahmen, die sicherstellen, daß die Verbindung zwischen Daten und Bildern nicht verlorengehen, wenn sich einmal die Internet-Adresse des Servers oder der Anfragemechanismus ändern sollte. Dateiname und Verzeichnispfad reichen auf lange Sicht nicht aus, um eine bildliche Ressource zu lokalisieren. Jedes Bild muß eine individuelle Kennzeichnung erhalten, einen weltweit einzigartigen URI (uniform resource identifier)[32], vergleichbar dem ISBN-Code bei Büchern, der es ermöglicht, die Grafikdatei auch ohne die Angabe einer Serveradresse im Internet (etwa mit Hilfe von Suchmaschinen) aufzufinden und sie im wissenschaftlichen Kontext unverwechselbar zu referenzieren bzw. zu zitieren. Hilfreich, aber nicht unbedingt notwendig wäre es, wenn die für die Bildressource verantwortliche Institution und das Erstellungsdatum darin enthalten wären. Digilib sollte zukünftig in der Lage sein, nur mit Hilfe des Identifiers das gewünschte Bild auszuliefern, wenn es auf dem Server vorhanden ist.

Weitere Verbesserungsmöglichkeiten der Anwendung liegen im Bereich der Benutzeroberfläche für Clients. Eine standardisierte, integrierte Leseumgebung für digitalisierte Faksimiles von Büchern und Manuskripten, die über den derzeitigen „digicat“ hinausgeht, wäre wünschenswert.[33] Wenn alle notwendigen Metadaten – Inhaltsverzeichnisse, Kapitelüberschriften und dergleichen – in übersichtlicher Form angezeigt werden, kann der Benutzer im gewünschten Werk blättern, schnell zur gesuchten Seite gelangen und sich über Umfang und Inhalt informieren, ohne die Orientierung zu verlieren. Dabei sollte der physische Zusammenhang des Originals möglichst getreu bewahrt bleiben: Gegenüberliegende Seiten sollten auch im Browser korrekt nebeneinander stehen. Über eine definierte programmtechnische Schnittstelle sollte die Anbindung einer synchronisierten Volltext-Transkription mit Suchfunktionen möglich sein, wo diese vorhanden ist.

Um die wissenschaftliche Beurteilung der digital faksimilierten Originale zu erleichtern, sind einige Zusatzfunktionen für Digilib geplant. Wichtig bei der Betrachtung virtueller Abbildungen ist es, die Dimensionen des Originals nicht aus den Augen zu verlieren. Dazu sollen anhand der Bildauflösung ermittelte Vergleichsmaßstäbe oder Liniengitter über das Bild gelegt werden können. Von hier ist es nur ein kleiner Schritt zum selbständigen Vermessen der Bilder im Browser. Bei Architekturzeichnungen wäre es besonders sinnvoll, die dargestellten Pläne in den originalen historischen Maßeinheiten vermessen und analysieren zu können. Ein solches – allerdings nicht browserbasiertes – Werkzeug hat der Verfasser bereits für den eigenen Bedarf programmiert.

In Zukunft wird man auch komplexere, sogar interaktive grafische Elemente in die Bilder einblenden können. Das dazu benötigte Grafikformat SVG wird bereits von Mozilla Firefox in der Version 1.5 beherrscht. So können beliebig geformte Flächen im Bild visuell hervorgehoben und anklickbar gemacht werden. Auf diese Weise werden komplexere und sinnfälligere Annotationen möglich. Die einzelnen Elemente können mit Datenbankinhalten verbunden werden, so daß man – intuitiver als mit Texteingabefeldern – auf Bildern oder Karten suchen und die Suchergebnisse anzeigen können wird. Insbesondere für die historischen Stadtpläne eröffnen sich dadurch weitreichende Perspektiven zur topographischen Präsentation von Daten.

 

Digilib ist ein Forschungsinstrument mit Zukunft, speziell in den Bildwissenschaften. Die Herausforderungen des Internets im Hinblick auf die wissenschaftliche Bildverarbeitung sind gerade erst dabei, sich abzuzeichnen. Dabei spielen nicht allein technische Fragen eine Rolle. Die Probleme, die ein verschärftes Urheberrecht für die Forschung mit sich bringen wird, sind noch lange nicht geklärt. Solange ein digital restrictions management den freien Zugang zu wissenschaftlichen Bildern bedroht, ist der Fortbestand von digitalem Wissen gefährdet.[34]

Die Förderung des Open Access-Prinzips, des weltweiten, freien Zugangs zum kulturellen Erbe Europas, zu Forschungsergebnissen, die aus öffentlichen Mitteln finanziert wurden, und zu der notwendigen Software ist ein Hauptziel des ECHO-Projekts. Digilib trägt dazu bei, diese Ideen, die die Max-Planck-Gesellschaft in der Berliner Erklärung vom 22. Oktober 2003 unterzeichnet hat,[35] zu verwirklichen. Die Weiterverbreitung des Programms für solche Zwecke ist ausdrücklich erwünscht.

 



[1] Acrobat Reader: http://www.adobe.de/products/acrobat/

[2] SVG: http://www.w3.org/Graphics/SVG/. Mozilla Firefox Version 1.5 unterstützt SVG bereits.

[3] Graßhoff, Gerd / Liess, Hans-Christoph / Nickelsen, Kärin: C0MPAGO - der systematische Bildvergleich. Bern Studies in the History and Philosophy of Science, Bern. 2001

[4] BerliOS: http://www.berlios.de/. BerliOS hat als Kommunikationsplattform für Open Source eine ähnliche Funktion wie das wesentlich bekanntere SourceForge.net.

[5] Digilib-Projektseite: http://developer.berlios.de/projects/digilib/

[6] Liess, Hans Christoph: Geschichte, Gehalt und wissenschaftliche Funktion der Planetendiagramme des frühen Mittelalters, Bern 2002. http://www.stub.ch/download/eldiss/02liess_h.pdf

[7] Archimedes: http://archimedes.mpiwg-berlin.mpg.de

[8] Astronomische Diagramme: http://penelope.unibe.ch/docuserver/compago/home_astro.html

[9] Graßhoff, Gerd/ Nickelsen, Kärin: Pflanzenzeichnungen als Ausdruck wissenschaftlicher Inhalte. http://penelope.unibe.ch/docuserver/compago/home_bot.html

[10] Graßhoff, Gerd: The Discovery of the Urea Synthesis. http://philoscience.unibe.ch/docuserver/echo/projekte/urea/

[11] ECHO: http://echo.mpiwg-berlin.mpg.de/home

[12] Lineamenta: http://lineamenta.biblhertz.it/

[13] CIPRO: http://fmdb.biblhertz.it/cipro/

[14] Kassel: http://212.202.106.6/dfg/museumkassel/home.jsp. Krems, Eva: Architekturzeichnungen des 17. bis 20. Jahrhunderts in der Graphischen Sammlung der Staatlichen Museen Kassel. In: Kunstchronik 58, 2005, 304-306.

[15] Verona: http://www.archiviocarloscarpa.it/web/disegni_zoom.php

[16] ArsRoma: http://www.biblhertz.it/deutsch/forschung/ArsRoma.htm

[17] Schede Noack: http://edoc.biblhertz.it/noack/noack.html

[18] Fotothek Florenz: http://www.khi.fotothek.org/

[19] Fotothek ZI München: http://www.zi.fotothek.org/

[20] JPEG: http://www.jpeg.org/; PNG: http://www.libpng.org/pub/png/

[21] Apache Tomcat: http://tomcat.apache.org/

[22] JAI: http://java.sun.com/products/java-media/jai/

[23] TIFF: http://de.wikipedia.org/wiki/TIFF/

[24] Eine Ausnahme in dieser Hinsicht stellt der geographische Server „Google Earth“ (http://earth.google.com/) dar, bei dem individuelle Annotationsdateien erstellt werden können. Das „Zitieren“ eines bestimmten kommentierten Ausschnitts mit Hilfe einer dauerhaften URL ist aber auch hier nicht möglich.

[25] Alcatraz: http://pythia2.unibe.ch/echo/alcatraz/

[26] Firefox extensions: https://addons.mozilla.org/extensions/?application=firefox

[27] COMPAGO: http://www.philoscience.unibe.ch/docuserver/echo/projekte/compago/compago.html. Dazu besonders die Dissertation von Hans-Christoph Liess (s. Anm. 7), Kap. III, 91-93

[28] GPL: http://www.fsf.org/licensing/licenses/gpl.html

[29] CVS: http://developer.berlios.de/cvs/?group_id=251

[30] Ein Treffen von Entwicklern und Betreibern von Digilib, das vom 13.-15. Januar 2006 am Kunsthistorischen Institut in Florenz stattfand, diente insbesondere der Klärung diesbezüglicher Fragen.

[31] Mailing-Liste: https://lists.berlios.de/mailman/listinfo/digilib-devel

[32] URI: http://de.wikipedia.org/wiki/Uniform_Resource_Identifier

[33] Ein vergleichbares „viewer environment“, das allerdings von der Installation serverseitiger Scripts abhängt, wird am MPI für Wissenschaftsgeschichte in Berlin bereits für das Textcorpus „Archimedes“ eingesetzt (s. Anm. 8)

[34] Hoeren, Thomas: Zukunft des Urheberrechts. Vortrag auf der Tagung „Shapes of things to come - Die Zukunft der Informationsgesellschaft“, Berlin, 17. 2. 2006. Vgl. http://www.heise.de/newsticker/meldung/69797

[35] Berlin Declaration: http://www.zim.mpg.de/openaccess-berlin/berlindeclaration.html


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: