Praxisreport Verfahren zur Evaluierung der Archivierbarkeit von Webobjekten Steffen Fritz Deutsches Literaturarchiv Marbach [email protected] 29. Januar 2015 Zusammenfassung Der vorliegende Report beschreibt die semiautomatische Evaluierung der Archivierbarkeit von komplexen Webseiten. Es wird die Verwendung von Standardtools sowie eigens entwickelter Programme beschrieben. 1 Einleitung Die Archivierung von Webseiten gehört heutzutage in vielen Archiven zum Aufgabenspektrum und wird dort mit verbreiteten Anwendungen wie den Webcrawlern Heritrix 1 oder HTTrack 2 in bestehende Arbeitsabläufe integriert. Deren Bedienung wird mittels durchdacht gestalteter Oberﬂächen auch technisch nicht speziell ausgebildeten Mitarbeitern zugänglich gemacht. Komplexer hingegen stellt sich die Beurteilung der Archivierbarkeit von Webpräsenzen dar. Die Praxis zeigt, dass in vielen Fällen eine Webseite gespiegelt, das Ergebnis beurteilt und anschließend versucht wird, durch die Trial-and-Error Methode das Ergebnis des Kopiervorgangs zu optimieren. Diese Herangehensweise bindet technische und personelle Ressourcen und erfordert erfahrene Personen, die einen neuerlichen Crawlvorgang auf Grund gewonnener Erkenntnisse auch außerhalb vorgegebener User Interfaces optimieren können. Oft wird überdies nicht sichergestellt, dass ein solcher Optimierungsvorgang nachvollziehbar ist und strukturiert durchgeführt wird. Das DFG-geförderte Projekt Netzliteratur authentisch archivieren und verfügbar machen im Deutschen Literaturarchiv Marbach ist seit 2013 damit befasst, komplexe, digitale Objekte zu archivieren und sich mit Werken auseinanderzusetzen, die nicht ohne größeren Aufwand mit herkömmlichen Mitteln aus dem World Wide Web kopiert werden können. Der Testkorpus des Projekts umfasst 46 Werke aus dem Zeitraum 1996 bis 2011, die von unterschiedlichster Beschaﬀenheit sind. Dies betriﬀt die Struktur der Publikationen als auch die verwendeten Techniken. Um problematische Fälle mittels oben beschriebener Trial-and-Error-Methode zu identiﬁzieren, wäre ein erheblicher Aufwand nötig gewesen. Daher musste ein Verfahren entwickelt und implementiert werden, das eine Beurteilung der Archivierbarkeit vor dem Spiegeln sowie eine strukturierte Optimierung anschließender Crawls ermöglicht. Der vorliegende Report beschreibt dieses Vorgehen. 2 Grundlagen Als Grundlage für die Beurteilung der Archivierbarkeit mittels Crawler dient das Paper CLEAR a credible method to evaluate website archivability 3 von Banos et al. Darin werden Eigenschaften von Webseiten identiﬁziert, die den Erfolg eines Crawlvorgangs positiv oder negativ beeinﬂussen. Die Eigenschaften werden unter den fünf Kategorien Accessibility, Standards Compliance, Cohesion, Performance und Metadata zusammengefasst, die Banos Archivability Facets nennt. 1 The Heritrix archival crawler project. https://webarchive.jira.com/wiki/display/Heritrix/Heritrix. Zugegriffen am: 13.11.2014 2 HTTrack Website Copier. http://www.httrack.com/. Zugegriffen am: 13.11.2014 3 V. Banos, Y. Kim, S. Ross, Y. Manolopoulus. CLEAR: a credible method to evaluate website archivability. 2013. 1 Accessibility bezeichnet die Zugänglichkeit zu allen Dokumenten, die konstitutiv für die Webpräsenz sind. Dies bedeutet, dass alle referenzierten Dokumente über HTTP-Abfragen erreicht werden können und dass Crawlern bekannt gemacht wird, welche Dokumente dies sind. Üblicherweise erfolgt dies durch Feeds, sitemap.xml- oder robots.txt-Dateien und eine Validierung der darin gelisteten Hyperlinks. Die zweite Facete Standards Compliance gibt an, ob alle Objekte gängigen Standards entsprechen. Dies umfasst Webseiten-Komponenten wie HTML und CSS, Mediendateien wie Graﬁken und Videos sowie weitere Ressourcen, beispielsweise die zuvor genannten Dateien robots.txt und sidemap.xml. Für einen erfolgreichen Crawl ist auch die Netzwerk-Performance entscheidend. Liefert ein Webserver Daten zu langsam aus oder erschwert eine Firewall parallele Zugriﬀe, so ist es möglich, dass ein Crawler seine Arbeit vorzeitig beendet. Daten einer Webpräsenz können über mehrere Hostsysteme verteilt sein, was eine Spiegelung erheblich behindern kann. Die Cohesion untersucht den Grad dieser Dispersion. Die fünfte Kategorie Metadata schließlich bewertet die Verwendung weiterer Informationen wie identiﬁzierter MIME-Types, das Rendering von Objekten oder das Encoding von Dokumenten. Diese Beurteilungen setzt Banos praktisch in Form des Webservices archiveready.com4 um. Die Seite nimmt einen URL entgegen, berechnet an Hand gewichteter Facetes die Archivierbarkeit und erstellt neben einem ausführlichen Report auch eine Zusammenfassung, die die Archivierbarkeit übersichtlich in Prozent ausdrückt. Abbildung 1 zeigt die Seite nach einem Testlauf. Abbildung 1: Webseite von archiveready.com Archive Ready bietet überdies ein REST API an, um Abfragen in eigenen Programmen implementieren zu können. Das Ergebnis wird in diesem Fall als JSON-Dokument zurückgegeben. Das API ist unter http://archiveready.com/api?url=WEBRESOURCE zu erreichen5 . Die Verwendung von Archive Ready ist für den privaten Gebrauch kostenlos. Wird der Service für Anfragen im großen Umfang benutzt, so bittet das Projekt um eine geringe Gebühr, die sich am Validierungsservice von w3.org6 orientiert. Dies waren zum Zeitpunk dieses Reports 0.015 Euro pro Evaluation. 4 http://archiveready.com. Zugegriffen am: 14.11.2014 http://archiveready.com/docs/?page_id=7. Zugegriffen am: 17.11.2014 6 https://validator-suite.w3.org/pricing. Zugegriffen am 17.11.2014 5 2 3 Verfahrensbeschreibung Archive Ready crawlt nicht eine Webressource, sondern untersucht einzelne Webdokumente. Daher musste eine Liste aller URL erstellt werden, die auf die Dokumente verweisen, die die Werke bilden. Hierfür wurde das Programm wget 7 eingesetzt. wget wird üblicherweise verwendet, um Dateien aus dem Internet zu laden. Dafür wird dem Kommandozeilenprogramm ein URL übergeben und die verlinkte Datei wird lokal gespeichert. wget kann aber auch eine Textdatei als Argument entgegennehmen, die pro Zeile einen URL enthält und das Ziel jeweils herunterlädt. Wird wget mit dem Schalter –spider aufgerufen, so wird kein Download durchgeführt, sondern rekursiv alle Links vom übergebenen URL ausgehend erfasst. # !/ usr / bin / env bash wget - nv -r -- spider -i $1 2 >&1 | egrep " ␣ URL : " | awk ’{ print $3 } ’ | sed " s@URL : @@g " >> korpus_link_liste . txt Listing 1: spider.sh Das Skript spider.sh aus Listing 1 nimmt als Argument eine Textdatei mit den Start-URLs von 68 Webressourcen8 entgegen, spidert jede Ressource und schreibt alle gefundenen Links in die Textdatei korpus_link_liste.txt. egrep, awk und sed dienen der Extraktion von Strings, die URLs beinhalten und der Formatierung der Ausgabe. Um Dubletten aus der Liste zu entfernen, wurde die Linkliste durch die Befehle in Listing 2 weiter verarbeitet. Das Ergebnis des Vorgangs wird in die Datei korpus_link_liste_sorted.txt geschrieben. cat korpus_link_liste . txt | sort | uniq >> korpus_link_liste _sor ted . txt Listing 2: Sortierung Bei der Überprüfung, ob die Anzahl der Links pro Werk plausibel ist, ﬁel auf, dass der Spider bei sieben Ressourcen nicht alle Links erfassen konnte. Dies hatte folgende Ursachen: • Generierung von Links mittels JavaScript • Unterschiedliche Subdomains. Um die betroﬀenen Werke evaluieren zu können, mussten nachträglich Links in die Datei korpus_link_liste_sorted.txt eingefügt werden. Bei den Werken mit JavaScript wurden die Seiten besucht und alle Links dokumentiert. Die Probleme mit den Subdomains konnten behoben werden, indem die Subdomains in eine Textdatei geschrieben und wieder an spider.sh übergeben wurden. Die Dateien mit diesen Ergebnissen wurden mit korpus_link_liste_sorted.txt zusammengeführt. Diese Datei umfasst insgesamt 3458 Links, die an Archive Ready übergeben werden. Dafür wurde das Skript arrr.py9 geschrieben, das jeweils einen URL an das API übergibt, auf das Ergebnis der Evaluation wartet und dies nach erfolgreicher Evaluierung aufbereitet in eine Textdatei schreibt. Für jedes Ergebnis wird eine Textdatei angelegt, die die prozentuale Zusammenfassung sowie den ausführlichen Report enthält. Wird arrr.py statt einer Textdatei mit Links eine warc-Datei als Argument übergeben, so extrahiert das Programm alle Links der zuvor gecrawlten Seiten und schreibt sie in die Datei url_list.txt. Diese Datei kann dann mit dem Code in Listing 2 optimiert werden und wiederum als Eingabe für arrr.py dienen. Sollte ein Crawl nicht das gewünschte Ergebnis liefern, so lassen sich so mit arrr.py problematische Eigenschaften auch nachträglich identiﬁzieren. 7 http://www.gnu.org/software/wget. Zugegriffen am 14.11.2014 Der Korpus besteht aus 46 Werken. Ein Werk, Kyon’s Metapage, besteht allerdings aus 23 Bänden, die jeweils separat untersucht wurden 9 https://github.com/netzliteratur/arrr 8 3 4 Auswertung Das Zusammenspiel des Skripts arrr.py mit Archive Ready gestaltete sich problemlos, die Evaluation aller 46 Werke mit 3458 Links dauerte unter fünf Stunden. Die Ergebnisse, die Archive Ready lieferte, wurden im Anschluss kontrolliert. Hierfür wurde für jedes Werk überprüft, ob alle aufgeführten Eigenschaften tatsächlich vorliegen. Tabelle 1 gibt Auskunft über den Ausgangsdatensatz, Tabelle 2 über die Ergebnisse der Auswertung. Webressourcen 68 verlinkte Dokumente 3458 Testergebnisse 31454 Tabelle 1: Anzahl Werke, Einzeldokumente, Testergebnisse Die Anzahl der Testergebnisse gibt die Anzahl aller Meldungen wieder, die Archive Ready nach der Evaluation aller Dokumente zurückgegeben hat. Besteht beispielsweise eine Ressource aus zwei Dokumenten und liegt ein Problem vor, das für beide Dokumente gilt, so werden zwei Einträge generiert. Testergebnisse 31454 korrekt 31178 nicht korrekt 276 Tabelle 2: Identiﬁkationen 274 der 276 fehlerhaften Identiﬁkationen sind vom Typ Sitemap vorhanden. Obwohl keine vorhanden, wurde sie als vorhanden markiert. Ursache war, dass der Webserver die Anfrage auf eine Fehlerseite umleitete und Archive Ready diese nicht als solche erkannte. Nachdem dem Betreiber das Fehlverhalten mitgeteilt wurde, wurde der Fehler behoben. Sitemap-Dateien werden nun korrekt identiﬁziert. In den beiden anderen Fällen wurden proprietäre Dateiformate nicht erkannt. Einmal war dies auf ungültiges HTML zurückzuführen, das andere Mal lag tatsächlich ein Fehler auf Serviceseite vor, der jedoch nicht reproduziert werden konnte. 5 Beurteilung und Aussicht Die Beurteilungen der Archivierbarkeit von Webressourcen mittels Archive Ready kann erheblich dazu beitragen, Arbeitszeit zu sparen und die Konﬁguration von Crawlern zu optimieren - die entstehenden Kosten fallen dabei nicht ins Gewicht. Im Übrigen kann das Ergebnis Autoren und Entwickler dabei unterstützen, ihre Webpräsenzen standardkonform zu programmieren und damit eine authentische Archivierung begünstigen. Die Ergebnisse der Evaluierungen sind überaus positiv zu beurteilen, allerdings ist eine anschließende Plausibilitätsüberprüfung unerlässlich, weshalb das Verfahren auch als semiautomatisch bezeichnet werden muss. Es gilt zu bedenken, dass die Entwicklung von Archive Ready aktuell in der Hand nur einer Person liegt. Allerdings wird der Dienst stetig weiterentwickelt und verbessert und es ist davon auszugehen, dass der Service Bestand hat. Eine weitere Optimierungsmöglichkeit im Workﬂow der Webarchivierung wäre, mittels der Ergebnisse ein System zu entwickeln, das automatisch eine optimale Konﬁgurationsdatei für Webcrawler generiert. 4