logo digitaal depot vliegend één nul één
Digitaal Depot - vzw eDAVID [ bevindingen testcases Digitaal Depot ]
[ publicaties ]
de publicaties en documentatie die specifiek in het kader van dit project aangemaakt zijn.
meer...>
[ zelf aan de slag ]
een samenhangend thematisch overzicht voor iedereen die zelf aan de slag wil gaan met digitaal archiveren.
meer...>
[ links ]
links naar de partners in dit project en een selectie van verwijzingen naar interessante aanverwante projecten
meer...>
In het Digitaal Depot project zijn we aan de slag gegaan met 7 testcases uit Vlaanderen. Het doel van de testcases was om vast te stellen welke uitdagingen zich stellen bij de archivering van websites van culturele instellingen (musea, kunstencentra, kunstenaars, e-cultuur-initiatieven) en particulieren. We onderzochten voornamelijk welke problemen verschillende webtechnologieën voor de archiveringsprocedure betekenen.

Het onderzoek is belangrijk:
1. om te schetsen met welke problemen een digitaal depot moet rekening houden
2. wordt duidelijk hoe men vanaf de creatie van websites rekening kan houden met latere archivering

Hier vatten we de belangrijkste bevindingen samen. We stellen de testcases kort voor en gaan in op de aanpak die we bij de archivering volgden. Als leidraad geven we indien aangewezen aan tot welke case(s) de bevinding betrekking heeft. Bevindingen die al uit eerder eDAVID/DAVID onderzoek bleken halen we maar kort aan. De focus is gericht op bevindingen van websites met audio of video streaming, blogs en wiki's. Deze technologien waren aan het projectbegin vrij recent en verdienen bijzondere aandacht.

Thema's:
Voorstelling cases
  • Case 1: de website van de tentoonstelling De-Regulation van het MuHKA
  • Case 2: de wiki van het kunstencentrum Nadine
  • Case 3: de blog van een particulier
  • Case 4: de blog Gentblogt
  • Case 5: de website van de kunstenaar Hans Op de Beeck
  • Case 6: de website van het initiatief "Droom de stad"
  • Case 7: de website Villa Futura van het Vlaamse Centrum voor Volkscultuur

We kozen de testcases op basis van twee criteria:
1. de verschillende technologien van de websites en
2. hun belang als digitaal cultureel erfgoed.

Meer informatie over de websites geven we in de beschrijving van de testcases.
naar begin van de pagina
Aanpak
De aanpak in dit onderzoek is gebaseerd op de archiveringsprocedure beschreven in het rapport "Archiveren van websites: een kwestie van waardering en 'capture'", Filip Boudrez, Antwerpen, 2005.

Bijgevolg staat aan het begin van elke testcase een analyse van de website. Uit dit onderzoek is een uitgebreide checklist voor de analyse van websites ontstaan. De checklist is gebaseerd op het bovengenaamde rapport en het DAVID metadataschema voor gearchiveerde websites. De checklist helpt reeds bij aanmaak van een website bij het verzamelen van informatie (metadata). Metadata zijn bij de archivering van belang, ondermeer om de context van een website te bewaren.

Archiefwaardering bij websitesarchivering moet rekening houden met vijf componenten:
1. de context van de webpagina,
2. de inhoud (zowel statisch als dynamisch),
3. de structuur,
4. de 'look & feel' en
5. basisfunctionaliteiten zoals hyperlinking en animaties.
(zie "Archiveren van websites: een kwestie van waardering en 'capture'", Filip Boudrez, Antwerpen, 2005)

Om deze componenten zo goed mogelijk te kunnen vastleggen, gebruiken we eerst de bij websitesarchivering gangbare snapshotmethode. Middels een webcrawler (ook webharvester of offline-browser genaamd) wordt een snapshot van de websites genomen. Dit betekent dat de webcrawler alle webpagina's doorloopt en er een statische kopie van maakt. De kopie wordt lokaal opgeslagen en kan dan offline worden bekeken.

Wanneer blijkt dat de snapshot een onvoldoende resultaat geeft, dan kiezen we voor aanvullende methodes bijvoorbeeld het nemen van een screencast. Bovendien geven we aan welke problemen verder onderzoek vragen.
naar begin van de pagina
Websites algemeen
In het algemeen ondervonden we bij het maken van de snapshots problemen die reeds in eerder onderzoek worden opgesomd (zie bijv. "Archiveren van websites: een kwestie van waardering en 'capture' ", Filip Boudrez, Antwerpen, 2005, p. 12 OF "Handboek archivering websites", Jeroen van Oss et al., E-Depot Rotterdam, 2005, p. 12).
In de testcases van het Digitaal Depot project zijn verder volgende problemen bij het maken van snapshots vastgesteld:

- Bij webpagina's met de tekencodering (character encoding) charset=iso-8859-1 worden in de archiefkopie diakritische tekens zoals é, à, ë niet correct weergegeven [case 4, case 6]. Dit probleem was er niet bij pagina's met de tekencodering charset=utf-8 [case 1, case 3].
- Technische vragen kunnen moeilijk worden opgelost als er geen documentatie van de website beschikbaar is en de ontwerper of programmeur van de website niet of moeilijk te bereiken is. Door gebrek aan dergelijke informatie mankeren tegelijk belangrijke metadata die nodig zijn bij de archivering op lange termijn [case 1].
naar begin van de pagina
Flash websites
Bij Flash websites levert het maken van een snapshot niet altijd een voldoende resultaat op. Webcrawlers kunnen links ingebed in Flash ActionScript niet altijd interpreteren. Dit heeft tot gevolg dat delen van een Flash website in een snapshot kunnen ontbreken of links tussen objecten niet functioneren.

- In een eerste case slaat de webcrawler de afzonderlijke pagina's weliswaar als HTML-bestanden op met daarin swf-bestanden ingebed. De animaties (bijvoorbeeld bij mouseovers) op de pagina's zelf werken. De links tussen de verschillende onderdelen functioneren echter niet meer [case 7].
- In een tweede case bevat de snapshot alleen de intro-animatie [case 5].

In de rubriek zelf aan de slag - tools webistesarchivering stellen we enkele oplossingen voor het archiveren van Flash websites voor.
naar begin van de pagina
Audio en video streaming
Alsmaar meer websites integreren audiovisuele inhoud middels zogenaamde streaming media (audio en video streaming). Streaming media worden tegelijkertijd geladen en afgespeeld. De gebruiker hoeft dus een filmpje of geluidsfragment niet te downloaden alvorens het bekijken. Het archiveren van zo'n website met audio en/of video streaming is echter niet evident. Webcrawlers kunnen audio- en video streaming niet altijd automatisch opslaan en in een archiefkopie integreren.
We geven enkele voorbeelden van problemen met audio of video streaming op die we in onze testcases botsten.

YouTube video's

Video streamings van de videoplatform YouTube worden door een webcrawler niet opgeslagen. YouTube laat niet toe om video's rechtstreeks te downloaden. In de archiefkopie verschijnt in plaats van het filmpje een wit veld.

YouTube video's kunnen na het maken van een snapshot handmatig in een archiefkopie worden gentegreerd. En mogelijke oplossing is om de video's via een programma van YouTube te downladen en in de offlineversie te integreren. Voorbeelden van hiervoor geschikte programma's en webapplicaties zijn opgesomd in onze overzicht van tools voor het archiveren van websites.

In de broncode van de archiefkopie moet de YouTube bron door een verwijzing naar het gedownload bestand worden vervangen. Bovendien moet een passende player in de broncode worden gentegreerd (bijv. QuickTime). Een tekst kan aanduiden dat het oorspronkelijk om een YouTube stream gaat. Handmatig kost dit veel moeite, men heeft een tool/script nodig die dit automatisch uitvoert. Op juridisch vlak is dit eerder problematisch. De rechten van de YouTube video's liggen meestal niet bij de website-eigenaar zelf. Dit is vooral een kritische punt men denkt aan de opname van zo'n website of blog in een publiek toegankelijk archiefdepot.

Andere vormen van streaming media

In één case slaat de webcrawler de Flashplayer (Hide Out XSPF Player) op. De speler verschijnt juist op de pagina's van de archiefkopie. Het afspelen van de geluidspeler functioneert echter niet. De geluidsfragmenten worden niet opgeslagen. De webcrawler zet de bijhorende links niet om naar een relatieve pathaanduiding. Dit moet dan manueel aangepast worden [case 4].

Niet alleen het gebruik van streaming media op zich is een uitdaging voor het maken van een archiefkopie. Bepaalde audio- of videospelers werken niet met relatieve pathaanduidingen. Hiermee moet rekening worden gehouden, wenst men de archiefkopie in het verloop van tijd naar een andere locatie te verplaatsen.

Video streams die op een website via de java streaming applet cortado.jar worden getoond, worden door de webcrawler niet opgeslagen [case 1]. Ze moeten indien gewenst achteraf manueel worden opgeslagen en in de archiefkopie worden gentegreerd. De applet vereist een volledig geldige URL (zogenaamde "fully qualified" URL) van de af te spelen film. Men moet de betrokken URL's dus aanpassen naar een absolute pathaanduiding naar het videobestand. (bijv. file:///C:/digitaaldepot/website_deregulation/videonaam.ogg)

Gebruikt men de applet cortado.jar, heeft dit gevolgen voor de archiefkopie. De absolute pathaanduiding heeft tot gevolg dat de archiefkopie gebonden is aan één locatie. Als men de archiefkopie wil verplaatsen, moet de pathaanduiding steeds aangepast worden naar de nieuwe locatie.

Alternatief kan men de video's met een andere videospeler in de pagina's van de archiefkopie inbedden. De pathaanduidingen zijn dan onafhankelijk van de locatie van de archiefkopie. Voorwarde voor een geschikte speler is dat hij relatieve pathaanduidingen ondersteunt (bijv. QuickTime player ondersteunt relatieve pathaanduidingen).

In de betrokken testcase was het bestandsformaat van het filmpje .ogg (open formaat, vrij beschikbaar). Om zo'n bestand met de QuickTime player te kunnen afspelen, moeten specifieke componenten op de computer geïnstalleerd zijn. Een bestand van het type .ogg kan evenzo in websites ingebed worden middels de VLC player en een bijhorend javascript. Om beter te kunnen inspelen op de problematiek van verschillende geluid-/ en videospelers bij het archiveren van websites is meer onderzoek en ervaring vereist.
naar begin van de pagina
Blog

Groot bestandsvolume

Een blog heeft vaak een groot datavolume, bijvoorbeeld als de blog al meerdere jaren in gebruik is en veel bijdragen bevat. Zo kan het maken van een snapshot zeer lang duren. Bij één van de testcases braken we de webcrawl na 11 uren af. In totaal omvat deze lokale kopie een volume van 1,7 GB. Echter zijn er nog niet alle pagina's van de weblog opgeslagen. Het is dus niet gelukt om een snapshot van de website in haar geheel te maken [case 4].

Externe bestanden

Een blog bevat vaak een groot aantal aan externe bestanden, bijvoorbeeld beeld-, video of geluidmateriaal. Veel van het materiaal is in blogs ingebed door verwijzingen naar webservices zoals Flickr (foto), YouTube (video), Google Video (video) of Google Maps (plattegrond). Keuzes maken bij het archiveren van een blog is niet altijd even gemakkelijk. Omdat vele externe bestanden deel kunnen uitmaken van een blog is het niet altijd direct duidelijk welke bestanden wel dan niet tot de inhoud van zo'n blog behoren [case 3].

Video's van YouTube

Voor het maken van een snapshot is video streaming op websites problematisch (zie boven). In onze case betreft dit video streams van de videoplatform YouTube (Flash Video flv) die ingebed zijn in een blog. De webcrawler kan deze niet mee opslaan omdat YouTube het niet toelaat om video's te downloaden [case 3].
naar begin van de pagina
Wiki

Groot bestandsvolume

Is een wiki al meerdere jaren in gebruik bevat deze een groot volume aan mappen en bestanden. Het maken van een snapshot kan daarom veel tijd in beslag nemen. In onze case liep de webcrawler na meer dan 10 uren vast. We moesten de procedure stoppen ook al was het resultaat een onvolledige snapshot [case 2].

Meerdere versies per pagina

Typisch voor een wiki is dat alle veranderingen van een pagina worden bijgehouden. Wanneer een pagina in een wiki wordt bijwerkt, worden de vroegere versies van de pagina steeds bewaard. De webcrawler slaat voor elke pagina alle versies op. Dit is één van de redenen voor de lange duur van onze test.

Pagina's voor het aanpassen of toevoegen van inhoud

Elke wikipagina bevat links om de pagina te bewerken of inhoud toe te voegen zoals 'edit page', 'attach file' of 'add image'. Klikt men in de onlineversie op zo'n link, belandt men op een nieuwe wikipagina. Op deze pagina moet men met een gebruikersnaam en paswoord inloggen. Daarna kan men de wikipagina aanpassen of er inhoud aan toevoegen. De webcrawler slaat telkens voor elke wikipagina een aparte pagina op om in te loggen. Klikt men bij het raadplegen van de snapshot op 'edit page' belandt men dus op een pagina om in te loggen. De snapshot bevat zo een veeltal pagina's die offline nochtans geen groot nut hebben. Hun interactiviteit, bijvoorbeeld aanmelden op de pagina, functioneert immers alleen online.

Snelle groei

Een wiki groeit en verandert snel. Duurt een snapshot veel uren tot dagen is het moeilijk om vast te stellen hoe de website op een bepaald moment eruitzag

Archiveren van bepaalde onderdelen niet vanzelfsprekend

Om binnen aangepaste tijd een snapshot van zo'n wiki te maken, is een mogelijkheid om alleen bepaalde onderdelen van de wiki op te slaan. Zo valt te overwegen om pagina's voor gebruikersinteractie niet mee op te slaan. Ook zou men kunnen kiezen om oudere versies van pagina's niet mee te nemen. Bij de meeste webcrawlers kan dit door ongewenste pagina's of onderdelen middels filterregels uit te sluiten. Om deze keuze verantwoord te kunnen maken, moet men de structuur van de wiki zeer goed kennen. Althans moet men de uit te sluiten locaties/ pathaanduidingen precies kennen om filterregels goed te kunnen gebruiken.

De snapshot van de wiki bevat meer dan 3000 bestandsmappen. De mapnamen zijn verschillende nummers (bijv. 211), letters (bijv. A, B, C, ...) en jaargetallen. De structuur van de mappen is vermoedelijk vastgelegd door de gebruikte wiki software. Voor een buitenstaander lijkt deze structuur zeer complex. Men kan moeilijk inschatten welke mappen men voor een archiefkopie al dan niet kan uitsluiten. Het archiveren van bepaalde onderdelen van een wiki kost dus veel inspanning tijdens de analyse.
naar begin van de pagina
Perspectief op verder onderzoek
Volgende vragen geven aanzet tot verder onderzoek:

- Hoe kan men blogs/wiki's met een groot bestandsvolume archiveren?
- Hoe moet men filterregels bepalen voor het archiveren van een onderdeel van een blog/ wiki?
- Welke soorten van streaming media zijn problematisch?
- Hoe kan men audio-/ video streaming automatisch (middels tool/script) in een archiefkopie integreren?
- Kan men ondanks de hoeveelheid aan geluid- en videospelers een algemene oplossing vinden voor het integreren van audio-/ video streaming in een archiefkopie?
naar begin van de pagina
Impulsen van internationale projecten en instellingen
Uit de literatuur blijkt dat grote internationale instellingen en projecten op dit moment nog geen optimale oplossing voor het archiveren van streaming media, wiki's en blogs hebben. Toch is deze problematiek momenteel een belangrijk een veel behandeld onderwerp. In het volgende geven we enkele voorbeelden van internationale impulsen.

- het International Internet Preservation Consortium (IIPC) vermeldt het harvesten en raadplegen van blogs, wiki's en video content expliciet bij de mogelijke onderwerpen voor de Web Curators Mailing List.


- De National Library of Australia archiveerde rond 350 websites bijhorende de federale verkiezingen van Australië in 2007. Een bijzondere uitdaging bij het archiveren was het grote volume aan streaming videobestanden. In het algemeen moesten de video's individueel worden gedownload. Bovendien moest elke webpagina bevattende zo'n video opnieuw worden gecodeerd.

[Edgar Crook, "The 2007 Australian Federal Election on the Internet", National Library of Australia]


- Library of Congress werkt aan een tool die URLs naar streaming media kan identificeren, extraheren, crawlen en de inhoud kan downloaden. Een probleem van streaming media voor webcrawlers is ondermeer dat webcrawlers gebonden kunnen zijn aan internetprotocollen. Bij streaming media verloopt de communicatie met de streaming media server vaak via andere protocollen dan HTTP, bijvoorbeeld RTSP of MMS. De door de Library of Congress gebruikte webcrawler Heritrix is momenteel echter gebonden aan HTTP.[Ashenfelder, 2006, 126] Het capturen van streaming media met Heritrix is zo niet mogelijk.

Library of Congress plant een oplossing waarbij Heritrix de open source software MPlayer integreert om de streaming media te downloaden. Belangrijk is in eerste instantie om alle video's te kunnen archiveren. Men streeft ernaar om de video's later binnen de gerelateerde gearchiveerde websites te kunnen raadplegen. [Ashenfelder, 2006, 136-138]

[Michael Ashenfelder, "Web Harvesting and Streaming Media", in "IWAW'06 Proceeding of the 6th International Web Archiving Workshop", Alicante, 2006, 125-146]


- European Archive en het Nederlandse instituut Beeld en Geluid leiden onderzoek omtrent het archiveren van streaming media op websites. De voorgestelde oplossing gebruikt als webcrawler Heritrix. Heritrix wordt aangevuld met enkele nieuwe processors en gecombineerd met MPlayer als externe module. [Baly, Sauvin, 167]

[Nicolas Baly, Florian Sauvin, "Archiving Streaming Media on the Web, Proof of Concept and first Results", in "IWAW'06 Proceeding of the 6th International Web Archiving Workshop", Alicante, 2006, 147-181]


- Het project rond de webcrawler Heritrix overweegt voor latere programmaversies het crawlen van video content bij default programma-instellingen te verbeteren.

[Heritrix wiki]


- Het project VidArch ontwikkelt oplossingen voor het bewaren van contextinformatie van digitale videobestanden. Een taak binnen dit project is het archiveren van YouTube video's en bijhorende context met betrekking tot de VS-presidentsverkiezingen 2008. Bij deze zijn tevens enkele tools ontwikkeld om het archiveringsproces te vergemakkelijken. Een voorbeeld is TubeKit. TubeKit is een toolkit die helpt bij het bouwen van een crawler voor YouTube video's en context. De toolkit is vrij beschikbaar.

[Chirag Shah, "YouTube Crawling: A VidArch Year in Retrospect", VidArch, 2008]
naar begin van de pagina
Sjablonen
  • Checklist websiteinfo: Deze checklist helpt reeds bij aanmaak van een website bij het verzamelen van informatie (metadata). Metadata zijn bij de archivering van belang, ondermeer om de context van een website te bewaren.

    De checklist is afgestemd op het DAVID metadataschema voor gearchiveerde websites. Bij archivering kan men de relevante data van de checklist websiteinfo naar de passende velden van het metadataschema overdragen. Verder moet men nog de velden met betrekking tot de archivering (bijv. gearchiveerde onderdelen, aanpassingen aan de snapshot, enz.) aanvullen.
naar begin van de pagina
.: een logo edavidproject :.