Performatywne archiwa Webu i ich ograniczenia

Małopolski Instytut Kultury, koordynując projekt Wirtualne Muzea Małopolski, niemałym nakładem sił i środków doprowadził do udostępnienia trójwymiarowych wizerunków wybranych artefaktów. Z poziomu przeglądarki możemy oglądać je z wielu stron – nie ogranicza nas dwuwymiarowa postać strony WWW, na której zostały opublikowane. Oglądamy je w sposób zbliżony do tego, w jaki robilibyśmy to na miejscu w muzeum. Czy można powiedzieć, że Wirtualne Muzea Małopolski pozwalają nie tylko – w zdalny sposób – poznać wizerunki tych artefaktów, ale także w pewien sposób je doświadczyć? Czy podobnie nie jest w przypadku skanowania 3D budynków i wnętrz (tak jak robi to Pracownia Skanerów 3D LaCH) lub skanowania rzeźb i drukowania ich kopii na drukarkach 3D, tak, że każdy ma szansę dotknąć materialnej rekonstrukcji obiektu?

W humanistyce „performatywność” to zdolność niektórych aktów mowy lub gestów do tworzenia rzeczywistości (można poczytać tu choćby Paula Connertona). W perspektywie archiwów Webu, inspirując się „performatywnością”, powinniśmy raczej mówić o emulowaniu, tzn. udostępnianiu użytkownikowi specyficznej rekonstrukcji dawnych zasobów w taki sposób, żeby korzystanie z nich przypominało (symulowało) natywne korzystanie z Internetu. Chodziłoby o przekazywanie odbiorcy nie tylko wizerunku jakiejś strony WWW (tak jak w przypadku udostępniania statycznych screenshotów), ale także umżliwienie mu dynamicznego nawigowania po stronie, korzystania z linków czy skryptów java script. Odwołując się do koncepcji performatywności można wówczas stwierdzić, że archiwum rekonstruuje, tworzy rzeczywistość na podstawie zabezpieczonych statycznych plików.

Performatywność, emulacja

Doskonałym przykładem takiej performatywności archiwum – tym razem z dziedziny archiwistyki gier komputerowych – mogą być zbiory starych gier przechowywane i udostępniane przez fundację Internet Archive. Niektóre z nich dostępne są tam w postaci kodu źródłowego do ściągnięcia (jako wolne oprogramowanie lub abandonware), ale też w postaci emulowanej, co po prostu oznacza, że można w nie zagrać bezpośrednio w przeglądarce. W pewien sposób archiwum łączy się tutaj z muzeum, w którym każdy może dotykać eksponatów. Podobnie rzecz ma się w przypadku archiwów cyfrowego wideo – nikomu nie zależy przecież wyłącznie na tym, aby udostępniać metadane czy pliki źródłowe do ściągnięcia – ważna jest możliwość ich obejrzenia już w przeglądarce. Struktura i interfejs archiwum w takiej sytuacji schodzi na plan dalszy.

A jeśli zdolność archiwum do performatywnego rekonstruowania rzeczywistości starego Webu możliwa byłaby także poza przestrzenią Internetu i dwuwymiarowym interfejsem przeglądarki? Holenderski projekt RE:DDS z 2014 roku miał za cel upamiętnienie 20. rocznicy powstania holenderskiego serwisu społecznościowego Digital City. W ramach akcji prowadzonej przez Amsterdam Museum podjęto próbę rekonstrukcji tego portalu, przy czym nie chodziło o jego ponowne uruchomienie i techniczne odtworzenie. W ramach spotkań i dyskusji z jego dawnymi użytkownikami próbowano zebrać jak najwięcej informacji o codziennym z niego korzystaniu, proszono ich także o udostępnienie przechowywanych na prywatnych nośnikach screenshotów i innych materiałów cyfrowych mogących pomóc w przypomnieniu wyglądu Digital City i mechanizmów jego działania. To dość ciekawy eksperyment, w którym zadanie archiwistyczne realizowane jest we współpracy ze społecznością i także poza przestrzenią cyfrową.

Postulat archiwizacji doświadczenia („archiving of experience”), który chciałbym łączyć z performatywnością, pojawia się w opublikowanym w 2009 roku roku tekście Franka McCowna i Michaela L. Nelsona poświęconym wyzwaniom związanym z archiwizacją Facebooka (What Happens When Facebook is Gone?). Autorzy, opisując poszczególne elementy treści tego serwisu (mającego wówczas około 150 mln. użytkowników), zastanawiają się, czy i jak można je wyeksportować z infrastruktury serwisu w ramach standardowego interfejsu programistycznego aplikacji (API). W pewnym momencie pojawia się jednak problem: czy samo wyciągnięcie danych wystarczy? Czy nie powinniśmy zachować i udostępniać w ramach archiwum także graficznego interfejsu użytkownika, zabezpieczając „doświadczenie” tego serwisu? Przecież przez API uzyskujemy jedynie surowe dane, pozbawione jakiejkolwiek warstwy wizualnej i kontekstu. Zarchiwizowanie doświadczenia Facebooka powinno natomiast umożliwić użytkownikowi natywne przeszukiwanie w wersjach archiwalnych czy swobodną, dynamiczną nawigację, czyli jakąś performatywną rekonstrukcję dawnego serwisu.

WARC vs API

W „klasycznej”, uprawianej od prawie 20 lat archiwistyce Internetu to standard WARC stał się obietnicą „archiwizacji doświadczenia”. Pliki WARC pozwalać mają na zachowanie nie tylko merytorycznej treści dokumentu (strony WWW) dostępnej pod określonym adresem URL w określonym czasie, nie tylko metadanych i nagłówków http, ale też warstwy wizualnej. Archiwalne wersje stron WWW w postaci WARC oglądać można w zwykłej przeglądarce, przy czym – w odróżnieniu od statycznych screenshotów – wciąż daje się klikać w linki i czasem nawet uruchamiać proste skrypty java script.

O ile w przypadku „klasycznych” stron WWW „zachowanie doświadczenia” nie jest takie trudne, w przypadku Facebooka czy Twittera i archiwizacji przez API niezbędna do performatywnej rekonstrukcji warstwa wizualna jest pomijana. Problem ten dotyczy zresztą też w coraz większym stopniu nawet „klasycznych” stron WWW, o ile coraz częściej wykorzystują one dynamizujące warstwę wizualną skrypty java script czy widżety i rozszerzenia publikowane przez zewnętrzne źródła (jest tak np. przy umieszczaniu facebookowego systemu komentarzy na stronie WWW). Jednak problem „archiwizacji doświadczenia” nie dotyczy wyłącznie warstwy wizualnej i możliwości klikania w odnośniki.

Wróćmy na chwilę do Internet Archive i kolekcji starych gier. Czy kiedy gramy w nie w przeglądarce (dzięki emulatorowi) jesteśmy jeszcze w archiwum czy już poza nim? Czy emulator jest częścią systemu archiwum, czy raczej pozwala w prosty sposób na „wyniesienie” z archiwum określonego artefaktu cyfrowego i korzystanie z niego tak, jak korzystamy z wszystkich dostępnych przez przeglądarkę zasobów WWW?

Reference rot

Takie teoretyczne dywagacje zaczynają mieć sens, kiedy rozważymy następujący problem. Być może zdarza się Państwu robić przypisy do internetu (na szczęście to wciąż legalne). Przypis zawiera dane o autorze czy autorce, tytuł oraz link (URL) i informację o dacie dostępu. Data wskazuje na to, że dotarliśmy do tego zasobu w określonym czasie i w jakiś podstawowy sposób zabezpiecza nas przed sytuacją, w której po latach okazuje się, że linkowany zasób nie jest już dostępny, mimo, że na niego wskazaliśmy.

Oczywiście, można zabezpieczać sobie cytowane zasoby, korzystając z usług takich jak Perma.cc, archiwizując cytowane strony i dokumenty w Internet Archive lub nawet trzymając je na własnym dysku. Ale gdyby tak wyobrazić sobie sytuację, w której nie musimy się bać o to, że cytowany link przestanie istnieć kilka miesięcy po publikacji naszego artykułu? Co gdyby sama natywna struktura protokołu HTTP pozwalała docierać do archiwalnych wersji dokumentów WWW? Wystarczyłoby tylko wyposażyć przeglądarkę w możliwość budowania odpowiednich zapytań do serwera. Po latach od opublikowania naszego artykułu ktoś kliknąwszy w link w przypisie otrzymywałby albo oryginalny przywoływany zasób (jeśli dana strona byłaby wciąż dostępna pod oryginalnym adresem), lub, gdyby tej archiwalnej wersji pod oryginalnym URLem nie było, w prosty sposób mógłby wyświetlić wersję historyczną.

Oczywiście HTTP to protokół komunikacji między przeglądarką (klientem) a serwerem i nie ma w nim miejsca na przechowywanie jakichkolwiek treści. To po prostu system ustandaryzowanych zapytań i odpowiedzi. Oznacza to, że wciąż musiałyby istnieć archiwa Webu, które działałyby jako pośrednicy, którzy – odpytani w odpowiedni sposób – proponowaliby adres historycznej wersji żądanego zasobu. W systemie takim przeglądarka, pytając o archiwalną wersję jakiejś strony, kierowana byłaby przez protokół do wybranego pośrednika (przecież nie tylko Internet Archive archiwizuje Web) i w przypadku dostępności wersji archiwalnej otrzymywałaby ją z jego serwera i wyświetlała użytkownikowi.

Na poziomie komunikacji klient – serwer, w nagłówkach http wyglądałoby to mniej więcej tak (na podstawie Van de Sompel, H., Nelson et al., 2009):

headers

Archiwum Webu jako pośrednik

Ten archiwistyczny komponent możliwy byłby do wdrożenia dzięki pewnej właściwości protokołu HTTP, pozwalającego na negocjowanie przez przeglądarkę różnych wersji strony, obecnej pod tym samym URLem. To tzw. „content negotiation”, dziś pozwalający przeglądarce wymuszać np. wyświetlanie wybranej wersji językowej strony (o ile ta oczywiście istnieje).

Jaki to jednak ma związek z ideą „archiving of experience” i z performatywnością archiwum? Taki, że wdrożenie rozwiązania proponowanego przez projekt Memento doprowadziłoby do sytuacji, w której archiwum internetu emuluje stary, historyczny Web wpływając na podstawowy mechanizm komunikacji między klientem (przeglądarką) a serwerem; w tej komunikacji chowany jest interfejs archiwum, pośredniczącego jako TimeGate wyświetlaniu historycznych wersji wybranej strony internetowej. Archiwum Webu staje się w takiej sytuacji częścią podstawowej infrastruktury WWW. Już dziś w taki sposób przeglądać można WWW, korzystając jednak wciąż nie tyle z nowych, natywnych właściwości protokołu HTTP, ale z API udostępnionego przez twórców projektu Memento. Niezbędne jest też zainstalowanie odpowiednich wtyczek do przeglądarek.

undsfsdfnamsdfed

Zaproponowana oficjalnie w 2014 roku przez zespół Memento propozycja wprowadzenia nowych nagłówków dla protokołu HTTP wciąż nie została przyjęta, jednak instytucje archiwizujące Web już mogą się przyłączać do tego projektu. Takie „chowanie” interfejsu archiwum, maskowanie jego obecności oraz standard współpracy i wymiany treści między archiwami wydają mi się ważnym kierunkiem rozwoju archiwistyki cyfrowej i archiwistyki Webu. Już dziś nawet w przypadku klasycznych archiwów cyfrowych udostępniających skany papierowych dokumentów czy analogowych obrazów i zdjęć taka współpraca istnieje: wystarczy spojrzeć na sposób działania Europeany, gdzie ponad 2 tys. instytucji z całej Europy udostępnia metadane swoich zbiorów i pozwala do nich dotrzeć bez konieczności przeszukiwania poszczególnych repozytoriów oraz odpowiednie API, omijające ich interfejs wizualny.

McCown, F., & Nelson, M. L. (2009, June). What happens when Facebook is gone?. In Proceedings of the 9th ACM/IEEE-CS joint conference on Digital libraries (pp. 251-254). ACM.

Van de Sompel, H., Nelson, M. L., Sanderson, R., Balakireva, L. L., Ainsworth, S., & Shankar, H. (2009). Memento: Time travel for the web. arXiv preprint arXiv:0911.1112.

Udostępnij na na Twitterze | Udostępnij na Facebooku

Przeczytaj także

Newsletter bezpieczny dla Twojego adresu email dostarcza tinyletter.com. Dowiedz się więcej