Maschinelle Gewinnung technischer Metadaten
für die Langzeitarchivierung elektronischer Publikationen:
Erfahrungen mit JHOVE im Projekt "kopal"
von Matthias Neubauer und Thomas Wollschläger
Das vom BMBF1 geförderte "kopal"2 Projekt hat das Ziel, ein innovatives Langzeitarchivierungssystem für digitale Medien zu entwickeln, das neben der Bewahrung digitaler Dokumente vor allem die Sicherstellung deren zukünftiger Verfügbarkeit zum Ziel hat. Das wird dadurch erreicht, dass zu den gespeicherten Objekten relevante technische Metadaten abgelegt werden, die geeignet sind, gezielte Migrations- oder Transformationsschritte vorzunehmen oder aber eine geeignete Präsentationsumgebung abzubilden.3 Basis für das System bildet das von IBM entwickelte "Digital Information Archiving System - DIAS", dessen Kern ("DIAS-Core") nach einer Anpassung für kopal genutzt wird. Bei der Verwendung des kopal-Langzeitarchivierungssystems sollen unterschiedliche Funktionalitäten bei der Bereitstellung von Metadaten sowie Archivdaten genutzt werden können. Die Deutsche Bibliothek und die Staats- und Universitätsbibliothek Göttingen erstellen dazu auf DIAS-Core abgestimmte Softwareprodukte, die unter einer Open Source Lizenz stehen. Dabei unterstützen "Ingest-Tools" die Zusammenstellung und Aufbereitung der Daten für das Archiv in Form eines Datenpakets aufgrund einer definierten Objektspezifikationen. "Access-Tools" hingegen sorgen für den strukturierten Zugriff der Institutionen auf ihren Datenbestand, um sie ihren Nutzern zur Verfügung zu stellen. Ingest- und Access-Tools bilden zusammengenommen die Software koLibRI4.
Das System basiert also auf der Sammlung und Generierung von deskriptiven und technischen Metadaten für das zu archivierende Objekt. koLibRI verwendet eine Kombination der METS5- und LMER6-Metadatenkonzepte, um Assets7 zu beschreiben. Alle verfügbaren Metadaten werden in das METS Containerformat eingefügt, und in eine Datei namens "mets.xml" geschrieben. Diese wird dann in dem zugehörigen Asset abgelegt, zusammen mit allen objektrelevanten Dateien. Die koLibRI-Tools integrieren dazu die JHOVE8 Software zur Gewinnung der technischen Metadaten.
Der JHOVE-Hintergrund
JHOVE steht für JSTOR9 / Harvard Object Validation Environment und ist zwischen 2003 und 2005 in Zusammenarbeit von JSTOR und der Harvard University Library (HUL) entwickelt worden. Es wurde am 26. Mai 2005 als Open Source Software für die Öffentlichkeit freigegeben. Dieser Release enthält dateitypenspezifische Module für folgende Formate: PDF, TIFF, JPEG, JPEG2000, GIF, AIFF, WAVE, XML, HTML, UTF8, ASCII und BYTESTREAM.
JHOVE selbst ist ein "Skelett", das eine Umgebung für dateitypenspezifische Java-Module bereitstellt. Diese Module übernehmen die Hauptarbeit von JHOVE, nämlich das Parsen einer dem Programm übergebenen Datei nach spezifischen Metadaten. JHOVE bietet großes Potential, um technische Metadaten aller Art aus Dateien zu extrahieren und diese in einem einheitlichen Ausgabeformat (beispielsweise XML) darzustellen oder abzuspeichern. Um dies zu tun, bietet JHOVE ein sehr offenes Modulkonzept, das es jedermann erlaubt, eigene, spezifische Java-Module für ein Dateiformat zu entwickeln. Einmal entwickelt, können diese Module von jedem anderen JHOVE-Benutzer ohne weitere Anpassungen nachgenutzt werden.
JHOVE ist eine Open Source Software und wurde unter der LGPL10 veröffentlicht. Das bedeutet, es ist:
JHOVE erkennt und verarbeitet keine Dateitypen "aus dem Stand". Für jeden Dateityp, der erkannt werden soll, wird auch ein eigenes Modul benötigt. Ursprünglich wurde JHOVE entwickelt, um die Anforderungen der Harvard University Library zu erfüllen. Da diese die Dateiformate festlegen kann, in denen ihnen Veröffentlichungen übergeben werden, gab es keinen Bedarf über die momentan existierenden Module hinaus. Um die breiteren Anforderungen vieler anderer Institutionen abzudecken und eine stabile Umgebung für die Validierung aller möglichen Arten von Objekten zu schaffen, müssen zukünftig noch viele weitere Module entwickelt werden. Das offene und modulare Konzept von JHOVE bietet dazu die geeignete Plattform.
Einsatz von JHOVE in koLibRI
Normalerweise wird JHOVE als Kommandozeilen- oder Swing-basierte Java-Applikation benutzt. Dabei verwendet JHOVE so genannte "Output Handler", um die erzeugten Metadaten auf den Bildschirm auszugeben oder direkt in eine Text- oder XML-Datei zu schreiben.
Für die Ingest11-Software von kopal wurde jedoch der direkte Zugriff auf die von JHOVE erzeugten Metadaten benötigt, bevor diese an den Output Handler übergeben werden. Deshalb wurde entschieden, JHOVE direkt in koLibRI zu integrieren und die Java JAR-Datei12, die dem aktuellen Public Release von JHOVE beiliegt, wurde in die Projektsoftware eingefügt. Die Funktionalität der Klasse "JhoveBase" wird nun von einer eigenen Klasse übernommen, welche die Modulschnittstelle der koLibRI-Tools implementiert. Dadurch konnten einige Methoden an eigene Anforderungen angepasst und unnötiger Code entfernt werden. Diese Klasse kümmert sich um den Aufruf der einzelnen JHOVE-Module und die Speicherung der durch sie erzeugten Metadaten.
Da ausschließlich valide Dateien archiviert werden sollen, müssen invalide Dateien erkannt und dies dem zuständigen Benutzer mitgeteilt werden, damit dieser die zur Korrektur notwendigen Schritte für diese Datei einleiten kann. Dies betrifft auch die Validierung einer einzelnen Datei. Um eine Datei wirklich auf ein bestimmtes Format validieren zu können, muss JHOVE explizit nur mit dem der Datei entsprechenden Modul aufgerufen werden. Auf diesem Weg kann JHOVE bestätigen, ob die übergebene Datei zu einem bestimmten Format gültig ist (vorausgesetzt, das JHOVE-Modul wurde der Formatspezifikation entsprechend implementiert).
Im Moment folgt die eigene Klasse der gleichen Strategie wie die ursprüngliche JHOVE-Klasse. Das bedeutet, sie ruft alle Module nacheinander auf, bis ein auf das Format der übergebenen Datei passendes Modul gefunden wird. Es ist geplant, dieses Verfahren zu verbessern, indem zunächst auf die Datei-Endungen der Dateien eingegangen und, falls verfügbar, explizit das Modul für das hinter der Datei-Endung vermutete Format aufgerufen wird. Nur wenn der Validierungsprozess mit dem so gewählten Modul fehlschlägt, werden nun alle Module der Reihe nach aufgerufen, um das tatsächliche Format der übergebenen Datei zu ermitteln. Dies wäre auch ein Weg, um ein Problem zu umgehen, welches sich mit invaliden Dateien einiger Formate, wie zum Beispiel TIFF, ergab. Wenn ein TIFF-Bild nicht vollkommen gültig ist, wird es von dem eigentlich zuständigen JHOVE-Modul zurückgewiesen, und JHOVE ruft daraufhin alle folgenden Module auf, obwohl das eigentlich passende Modul ja bereits gefunden wurde. Das führt dazu, dass dieses Bild als BYTESTREAM erkannt wird, obwohl eine konkrete Fehlermeldung durch das TIFF-Modul nötig gewesen wäre.
JHOVE enthält ebenfalls eine "Signature Match" Methode, bei der die Module nicht versuchen, die Dateiformate über eigene Verfahren zu erkennen, sondern sich ausschließlich auf die Signatur13 der Datei verlassen. Diese Methode wird jedoch nicht vollständig unterstützt.
Um auf die erstellten Metadaten direkt zugreifen zu können und sie auf die interne Datenstruktur abzubilden, wurde ein eigener Output Handler entwickelt, der die Funktionalitäten des JHOVE-XML-Handlers erbt. Dieser "LmerHandler" wird bei JHOVE als der für die Ausgabe zuständige Output Handler registriert und schreibt die erstellten Metadaten in die interne Datenstruktur, die später auf einfachem Wege von den Softwareteilen gelesen werden kann, welche für die Erstellung der "mets.xml" Datei zuständig sind.
Zudem konnte die Verarbeitungsgeschwindigkeit der Dateien deutlich gesteigert werden, indem die von JHOVE angebotene interne Checksummen-Berechnung der Typen MD5, CRC32 und SHA-1 nicht genutzt wurde. Da kopal ohnehin nur mit der SHA-1 Checksumme arbeitet, wird diese mithilfe eigener Software berechnet. Die Verwendung eines höheren Caching-Wertes als dem von JHOVE verwendeten Standardwert brachte ebenfalls noch einmal einen beeindruckenden Performanceschub.
JHOVE kann unter Umständen sehr viele Metadaten erstellen, abhängig vom Dateiformat und den jeweils verwendeten Features dieses Formats. Bei Assets, die eine hohe Anzahl an Dateien enthalten, kann die "mets.xml" dadurch schnell sehr groß werden. Daher wurden der eigenen Klasse einige Optionsparameter hinzugefügt, die es erlauben, einige Metadatensektionen bei Bedarf auszublenden und nicht in das Archivobjekt zu übernehmen. Diese Optionen werden im Moment jedoch noch nicht aktiv genutzt, da die momentan erstellten Assets noch keine kritischen Größen erreichen.
Eventuelle Nachteile einer eigens angepassten Version von JHOVE könnten bei einem möglichen Upgrading auftreten. Dies könnte bedeuten, dass Code der eigenen Software an die neuen Bedingungen oder Schnittstellen von JHOVE angepasst werden müssten - ein typisches Problem solcher Entwicklungen. Dieses Szenario würde aber lediglich bei einer Änderung der JHOVE-Architektur auftreten, nicht jedoch bei der Einbindung der anstehenden Maintenance Releases, insofern ist dieses Risiko weitgehend minimiert.
Erfahrungen mit JHOVE im Projekt "kopal"
Zunächst sollte erwähnt werden, dass der Support seitens der HUL für JHOVE erstklassig ist. Über die JHOVE Mailingliste gemeldete Bugs wurden meistens schon innerhalb von wenigen Stunden behoben.
Es traten jedoch gewisse Hindernisse auf, die beseitigt werden mussten. Dies betraf beispielsweise das Modul für PDF-Dokumente, in welchem mit der Validierung des XML-Outputs, den JHOVE für bestimmte Dateien erstellte, Probleme auftraten. Der XML-Code enthielt Zeichen, die in der verwendeten Kodierung nicht erlaubt waren, jedoch in dem PDF-Dokument vorkamen. In einem Fall stürzte JHOVE bei der Bearbeitung eines PDF-Dokuments sogar gänzlich ab. In der von kopal mit Hilfe der HUL gefixten und neu kompilierten Version von JHOVE wurde die "Outlines" Sektion der von JHOVE erstellten Metadaten nun erst einmal völlig deaktiviert, d. h., sie wird von dem Modul vorerst nicht mehr erstellt. Die Möglichkeit, dass JHOVE einen Stopp des gesamten Systems auslösen könnte, wurde als weit kritischer eingestuft als der temporäre Verzicht einer nicht essenziellen Metadatensektion. An einer endgültigen Lösung dieses Problems wird gearbeitet.
Betreffend der ungültigen Zeichen innerhalb des XML-Outputs des PDF-Moduls wurden einige Änderungen am Java-Sourcecode vorgenommen, jedoch meist mit intensiver Rücksprache und Hilfestellung der HUL und der JHOVE-Mailingliste. Vor dem Ausgeben der Daten wurden nun zusätzliche Überprüfungen auf ungültige Zeichen eingefügt. Sollte ein solches Zeichen gefunden werden, wird es in der Ausgabe ignoriert. Dadurch ist gewährleistet, dass keine ungültigen Zeichen in der Ausgabe existieren, aber dennoch relevante Informationen nicht verloren gehen.
Ein weiteres Problem, das zu invalidem XML führte, war das Auftreten von leeren Property14-Listen. Das JHOVE-XML-Schema verlangt, dass Property-Listen mindestens ein Property-Element enthalten müssen. Manche Module erzeugten die Listen jedoch schon bevor sie wussten, ob überhaupt Inhalte für diese Listen vorliegen. Das Resultat waren dann leere Listen, die von XML-Validatoren zurückgewiesen wurden. Durch eine erneute Überprüfung des Inhalts - vor Ausgabe der Listen - konnte dieses Problem in den Modulen für XML-Dateien und PDF-Dokumente ebenfalls behoben werden.
Weiterhin wurde festgestellt, dass manche Dateien falsch erkannt wurden. Viele der getesteten Bilder wurden als BYTESTREAM erkannt, sowie manche HTML-Dateien als ASCII oder UTF-8 und umgekehrt. Dafür könnte eine weitere Verbesserung der Dateityp-Erkennung der Module hilfreich sein.
Unterstützte Dateiformate und Ausbauvorhaben
Das DIAS-System verwendet einen eigenen Satz an Dateiformat-Beschreibungen, die momentan die in der folgenden Tabelle aufgeführten Formate umfassen, welche noch nicht vollständig von JHOVE abgedeckt werden:
| Abgedeckt von JHOVE Modulen |
Bisher nicht abgedeckt |
| "Unknown File Type" (Bytestream) | Bitmap Image (BMP) |
| Adobe Acrobat Document (PDF) | PNG Image |
| JPEG | PKZIP File |
| GIF | TAR File |
| TIFF | Executable File |
| TXT File (ASCII) | Postscript |
| Hypertext Document (HTML) | Movie Clip (MPEG) |
| Video Clip (Avi) | |
| PQI Image File | |
| | |
| MS Word | |
| MS Excel | |
| MS PowerPoint | |
| MS Access |
Aus dieser Tabelle wird schnell klar, dass ein Bedarf an mehr JHOVE-Modulen besteht, als momentan existent sind. Auch die DIAS-Dateiformatliste ist noch nicht vollständig. Weitere benötigte und genutzte Dateiformate müssen ihr in naher Zukunft hinzugefügt werden, um die Bedürfnisse der Langzeitarchivierungsstrategie Der Deutschen Bibliothek abzudecken. Es gibt jedoch bereits Pläne für die Entwicklung weiterer JHOVE-Module von verschiedenen Institutionen.
Im Rahmen des Projekts kopal ist geplant, die am dringendsten benötigten Module selbst zu entwickeln. Die folgende Liste zeigt einen kurzen Überblick über die Module, die von den Projektpartnern in naher Zukunft entwickelt werden sollen:
Das Modul für ISO 9660 DISC IMAGES befindet sich bereits in Entwicklung und ist nahezu fertig gestellt. Module für MP3-Dateien und PNG-Bilder sind Anfang 2006 in Entwicklung gegangen. Zurzeit werden auch einige Open-Source-Java-Tools geprüft, die bereits mit Microsoft-Office-Formaten arbeiten, um festzustellen, ob mit diesen Tools ein einfacher Zugriff auf diese Formate möglich ist.
Zusammenfassend sollte gesagt werden, dass es sehr hilfreich wäre, wenn eine größere Entwicklungsgemeinschaft für JHOVE-Module entstehen würde. Im Moment befinden sich keine weiteren Module in Entwicklung oder wurden der Öffentlichkeit angekündigt. Das Konzept von JHOVE steht und fällt jedoch mit seinen Modulen und alle JHOVE-Nutzer würden von einer verteilten Entwicklung vieler Module profitieren. Das könnte JHOVE schließlich zu dem mächtigen Werkzeug machen, als das es ursprünglich entwickelt wurde.
Ein weiterer Aspekt, der JHOVE noch mächtiger machen würde, wäre die Unterstützung einheitlicher Dateiformatbeschreibungen. Hierzu ist die Erstellung einer internationalen Format Registry wünschenswert und notwendig, in welcher Formatspezifikationen und -eigenschaften hinterlegt und kontinuierlich aktuell gehalten werden. Eine Reihe von Institutionen und Projekten beschäftigt sich derzeit mit diesem Thema, so dass in Zukunft ein optimierter Abgleich von Datenformaten möglich werden sollte.
Ergebnisse und Ausblick
Die Verwendung von JHOVE für die maschinelle Erstellung bzw. Extrahierung von technischen Metadaten elektronischer Publikationen erspart viel Zeit und Arbeit für eigene Entwicklungen einer gleichartigen Funktionalität. Zudem erweist sich eine generische Lösung, die von vielen verwendet wird, als vorteilhaft gegenüber einer individuellen Lösung, da sie an und mit ihren Benutzern wächst. Für JHOVE bedeutet dies vor allem die Entwicklung von Modulen für weitere und neue Dateiformate, die von allen anderen JHOVE-Benutzern nachgenutzt werden können.
Es muss berücksichtigt werden, dass JHOVE noch ein recht junges Projekt ist, bei dem es eine Reihe noch nicht getesteter, unvorhersehbarer Einsatzszenarien gibt. Die Lösungen für die von kopal gefundenen und behobenen Probleme werden jedoch in den nächsten Maintenance Release von JHOVE einfließen, so dass alle Nutzer davon profitieren können.
Zu den Autoren
Matthias Neubauer ist Software-Entwickler im Projekt "kopal" an Der Deutschen Bibliothek.
Adickesallee 1
60322 Frankfurt am Main
E-Mail: neubauer@dbf.ddb.de
Dr. Thomas Wollschläger ist Wissenschaftlicher Projektmitarbeiter von "kopal" an Der Deutschen Bibliothek.
E-Mail: wollschlaeger@dbf.ddb.de
Anmerkungen
1. Bundesministerium für Bildung und Forschung - http://www.bmbf.de
2. Kooperativer Aufbau eines Langzeitarchivs digitaler Informationen - http://kopal.langzeitarchivierung.de
3. Downloads mit Informationen zum Projekt unter http://kopal.langzeitarchivierung.de/medien_presse/index_medien_presse.php
4. kopal Library for Retrieval and Ingest. Eine Beta-Version von koLibRI wird über die kopal-Website zum Download zur Verfügung gestellt werden.
5. Metadata Encoding & Transmission Standard - http://www.loc.gov/standards/mets/
6. Langzeitarchivierungsmetadaten für elektronische Ressourcen - http://www.ddb.de/standards/lmer/lmer.htm
7. Als "Asset" wird ein Datenpaket bezeichnet, das ein Archiv-Objekt darstellt.
8. http://hul.harvard.edu/jhove/
9. Journal Storage - The Scholarly Journal Archive - http://www.jstor.org
10. GNU Lesser General Public Licence - http://www.gnu.org/copyleft/lesser.html
11. Als "Ingest" wird der Einspielvorgang eines Assets in das Archivsystem bezeichnet.
12. JAR - Java Archive; binäres Dateiformat für Java-Programme.
13. Auch bekannt als "Magic Number".
14. JHOVE teilt seine Ausgabeinformationen in sogenannte "Properties", also Eigenschaften der Datei ein.