Papier, płyta, dyskietka
Gros pozyskanych zasobów to materiały papierowe, zarówno pi-sane odręcznie, jak i maszynopisy. Choć byliśmy przygotowani na to, że trafią w nasze ręce także materiały na dyskietkach i kasetach magnetofonowych, dotychczas tak się nie stało. Istnieją archiwa, które zbierają nagrania audio i wideo z badań, a nawet skupiają się właśnie na takim rodzaju materiałów, uznając go za znacznie peł-niejszy niż tekstowy (np. amerykańskie Murray Center39). Zgodnie z radykalniejszym stanowiskiem40, sama tekstowa transkrypcja
wy-36 Zob. http://www.adj.ifispan.pl/o_archiwum, [dostęp: 7 III 2019]. Przedsta-wicieli ADJ zaprosiliśmy do udziału w seminarium wyjazdowym (Zespół Pałaco-wo-Parkowy UAM w Gułtowach, 2–3 czerwca 2017 roku) oraz organizowanej przez nas konferencji („Zastane. Pracując z materiałami zastanymi w naukach społecznych i humanistycznych”, Centrum Kultury Zamek w Poznaniu, 23 lutego 2018 roku).
37 http://archiwum.edu.pl/2018/02/26/zastane–pracujac–z–materialami–za-stanymi–w–naukach–spolecznych–i–humanistycznych/, [dostęp: 7 III 2019].
38 http://www.ads.org.pl/, [dostęp: 7 III 2019].
39 Zob. J. B. James, A. Sørensen, Archiving Longitudinal Data for Future Research.
Why Qualitative Data Add to a Study’s Usefulness, „Forum Qualitative
Sozialfor-schung” 2000, nr 3(1).
40 Zob. A. Deppermann, Interviews as Text vs. Interviews as Social Interaction, „Fo-rum Qualitative Sozialforschung” 2013, nr 3(14).
wiadu pozbawiona wskazówek dotyczących rekrutacji, przebiegu wywiadu, kontekstu sytuacyjnego, zachowań niewerbalnych oraz nagrania (choćby dźwiękowego) jest bardzo ryzykownym, jeśli nie w ogóle nieuprawnionym rodzajem materiału badawczego. Uzna-liśmy jednak, że same materiały pisane również mają bardzo dużą wartość poznawczą. Naszym podstawowym narzędziem pracy były skanery i aparaty cyfrowe. W większości przypadków zrezygno-waliśmy z poddawania materiału rozpoznawaniu znaków (OCR) z uwagi na ilość dodatkowej pracy, jaką by to generowało oraz pro-blemy większości oprogramowania z rozpoznawaniem znaków na dokumentach pisanych odręcznie i cechujących się rozmazanym lub blaknącym tuszem. Przygotowaliśmy też możliwość elektroniczne-go pozyskiwania materiałów – przesyłania do nas tych spośród nich, które nigdy nie wyszły poza postać elektroniczną (np. prace nauko-we z ostatnich lat). W tym celu stworzony został na stronie projektu formularz kontaktowy41 połączony z naszym oficjalnym adresem pocztowym (archiwumcodziennosci@gmail.com). Ten ostatni, po-dany do wiadomości wszystkich zainteresowanych, służy zatem nie tylko do utrzymywania korespondencji z otoczeniem zewnętrznym Archiwum, ale pełni także funkcję skrzynki podawczej, do której wpływają zgłoszenia materiałów i ich skany wysyłane za pośrednic-twem formularza. Nadal jednak znacząca większość materiałów po-chodzi z prac terenowych i działań digitalizacyjnych prowadzonych przez osoby związane z Archiwum.
Zaniedbania
Nasze pierwsze zetknięcie ze zbiorem archiwalnych materiałów miało miejsce w Archiwum IS UAM. Już po znalezieniu dla niego nowego miejsca na początku 2014 roku, nastąpił okres porządkowa-nia i selekcjonowaporządkowa-nia zasobów, a następnie opisywaporządkowa-nia materiałów przeznaczonych do digitalizacji. Trwało to około cztery miesiące, ale pozwoliło na zorganizowanie systemu wypożyczania materiałów (w oparciu o szczegółowe rewersy, opisujące zawartość każdej
ki, jej stan fizyczny, liczbę stron itd.) oraz oszacowanie stanu samych zbiorów. Z 33,27 metrów akt bieżących ponad 60% (wedle wstępnej oceny) wymagało fumigacji w komorze próżniowej. Początkowo rozważaliśmy skorzystanie z usług zewnętrznej firmy, lecz w toku prac okazało się, że podobne usługi świadczy Pracownia Restauracji Książki działająca w ramach Oddziału Magazynowania i Ochrony Zbiorów Biblioteki Uniwersyteckiej UAM. W okresie wzmożonych prac projektowych (2014–2018), skorzystanie z usług dezynfekcyj-nych wykluczyłoby znaczącą część materiałów z możliwości opra-cowania i digitalizacji z powodów czasowych (transport materiałów w obie strony, kilkudniowy proces gazowania, wentylacja mate-riałów itd.), a realizowanie całego procesu w transzach znacząco podwyższałoby koszty tego przedsięwzięcia, co przy ograniczo-nych środkach grantowych nie wchodziło w rachubę. Dodatkowo materiały po przeprowadzeniu fumigacji nie powinny trafić do tego samego pomieszczenia, jeśli i w nim nie zostały wykonane stosow-ne zabiegi chemiczstosow-ne (osuszanie ścian, odgrzybianie powierzchni, izolacja itd.). Niestety, problem ten nie został i nie zostanie rozwią-zany do czasu znalezienia nowego pomieszczenia (obecnie, Archi-wum IS UAM znajduje się na poddaszu budynku, gdzie nie można wykonywać prac remontowych ani konserwacyjnych). Ostatecznie pracowaliśmy na materiałach w takim stanie, w jakim udało się je odnaleźć, zachowując przy tym szczególną ostrożność w zakresie ochrony zdrowia własnego, jak i stanu fizycznego samych materia-łów. Na szczęście w innych miejscach i miastach, w których pozyski-waliśmy materiały, nie były one w tak opłakanym stanie.
Serwer, strona, interfejs, skanowanie
Początkowo planowaliśmy zbudowanie internetowej platformy dla Archiwum od podstaw, jako sieciowego repozytorium danych (głównie tekstowych), które – w zakresie dostępnych funkcji – po-zwalałoby na ciągłe dodawanie nowych zbiorów, ich tagowanie i opisywanie słowami kluczowymi oraz przeszukiwanie, czytanie online oraz pobieranie na dysk lokalny. System miał też uwzględ-niać kilka poziomów dostępu do poszczególnych materiałów oraz
zawierać interaktywną mapę Polski z zaznaczonymi na niej miej-scami pochodzenia zdigitalizowanych dokumentów, możliwością wyświetlania szczegółowych informacji na temat lokalizacji oraz powiązań pomiędzy nimi.
Niestety, pomimo wysokiej oceny merytorycznej projektu (100/100 pkt. oraz 95/100 pkt. od dwóch recenzentów, przy maksy-malnym wymiarze punktów w ramach kryterium „Zasadność pla-nowanych kosztów projektu badawczego w stosunku do przedmio-tu i zakresu badań”), przyznane środki grantowe zostały radykalnie zredukowane. Operując w ramach ograniczonych możliwości finan-sowych, zmuszeni zostaliśmy do rezygnacji z ambitnych zamierzeń, decydując się na skorzystanie z gotowego oprogramowania repozy-toryjnego, przy jednoczesnym zarezerwowaniu środków na pierw-sze trzy miesiące zewnętrznej opieki technicznej nad repozytorium (zamiast czterech lat) oraz na opłacenie domeny i serwera dedyko-wanego o pojemności min. 300 GB na okres czterech lat. Najlepszym (o ile nie jedynym) wyjściem okazało się skorzystanie z infrastruk-tury Wielkopolskiej Biblioteki Cyfrowej (dalej: WBC)42, z możliwo-ścią wydzielenie naszej kolekcji (jako odrębnego tworu) w ramach jej struktury. WBC ma zapewnioną praktycznie dożywotnią obsługę ze strony Poznańskiego Centrum Superkomputerowo-Sieciowego (dalej: PCSS), dzięki czemu po zakończeniu finansowania projek-tu grantowego zasoby Archiwum będą nadal udostępniane. Wraz z tym wyborem przesądzony został także wybór oprogramowania repozytoryjnego, którym stał się pakiet dLibra przygotowany przez PCSS43. Z uwagi na ograniczenia interfejsu stron opartych na tej platformie, zdecydowaliśmy się na przygotowanie odrębnej witry-ny (zawierającej m.in. opis założeń, charakterystykę zbiorów, aktu-alności i wydarzenia z życia projektu, sylwetki członków zespołu
42 Wielkopolska Biblioteka Cyfrowa została powołana do życia przez Po-znańską Fundację Bibliotek Naukowych (PFBN), a Fundacja, m.in. przez UAM. Por. http://www.wbc.poznan.pl/dlibra/text?id=library–desc, [dostęp: 7 III 2019]; http://www.pfsl.poznan.pl/, [dostęp: 7 III 2019].
43 Por. https://dingo.psnc.pl/dlibra/, [dostęp: 7 III 2019]; https://pl.wikipe-dia.org/wiki/DLibra, [dostęp: 7 III 2019].
projektowego, opis kwestii prawnych itp.)44. Dzięki temu częściowo udało się połączyć nasze autorskie podejście z korzystaniem z goto-wych rozwiązań. Jedna z członkiń zespołu projektowego została re-daktorem Archiwum, obsługującym platformę, dodając odtąd opisy i skany do zasobów naszego cyfrowego repozytorium. Centralizacja prac wymogła konieczność deponowania zeskanowanych materia-łów i ich opisów w jednym miejscu (skorzystaliśmy z usługi Google Dysk), z którego osoba pełniąca funkcję redaktora może je pobierać i umieszczać w serwisie dLibra. Powodów do zadowolenia dostar-cza nam identyfikacja wizualna Archiwum rozciągająca się zarówno na stronę projektu, jak i na repozytorium cyfrowe, zapewniając toż-samość graficzną obu środowisk.
Oparcie się na zasobach WBC i PCSS z jednej strony umożliwi-ło realizację projektu w budżecie wyznaczonym przez grantodawcę i to, że mozolnie zebrane zasoby Archiwum nie znikną z sieci nawet wówczas, gdyby projekt nie uzyskał dalszego finansowania. Z dru-giej strony tworzenie cyfrowego Archiwum świetnie ilustruje tezę, zgodnie z którą rzeczywistość społeczna45, w tym świat akademicki46, są kształtowane przez relacje aktorów ludzkich i nieludzkich oraz ukryte, przeszłe, arbitralne rozstrzygnięcia wszyte w infrastrukturę codzienności. Poczucie względnej sprawczości towarzyszyło jeszcze wyborowi domeny internetowej, natomiast decyzja o wyborze opro-gramowania i opartego na nim interfejsu była już, jak widać, mocno ograniczona. Tymczasem to ten właśnie element wyznacza „reguły gry”, w tym zwłaszcza możliwe sposoby deponowania, opisywania i udostępniania danych.
Co do zasady, przyjęliśmy, że większość materiałów skanuje-my w rozdzielczości 300 dpi, z możliwością wykonywania lepszych
44 Strona projektu została zlokalizowana pod adresem: http://archiwum.edu.pl/, a repozytorium danych pod powiązaną domeną: http://archiwum.edu.pl/dlibra.
45 M. Krajewski, Są w życiu rzeczy. Szkice z socjologii przedmiotów, Warszawa 2013.
46 K. Abriszewski, M. Frąckowiak, Jak rozciągnąć demokrację na rzeczy?
Rozmo-wa z Krzysztofem Abriszewskim, [w:] (red.) Maciej Frąckowiak, Lechosław Olszewski,
jakościowo skanów (600 dpi) dla szczególnie zniszczonych, zabru-dzonych i nieczytelnych fragmentów. Skany wykonywaliśmy tak-że w kolorze – zwłaszcza wtedy, gdy monochromatyczna digitali-zacja mogła prowadzić do utraty czytelności pewnych elementów (np. notatek na marginesach, dopisków długopisem na maszyno-pisie, blaknących adnotacji itd.). Szczególnym wyzwaniem było też skanowanie materiałów o różnych, często nietypowych formatach (zmuszające nas albo do cyfrowego łączenia skanów o formatach większych niż A3 albo do łącznego skanowania materiałów o for-macie mniejszym niż A4).
Wewnętrzna pamięć zespołu
To, co ostatecznie materializuje się w postaci strony internetowej (archiwum.edu.pl) i repozytorium (archiwum.edu.pl/dlibra), to czubek archiwalnej góry lodowej. Większa część danych, które są generowane w trakcie budowania Archiwum, znajduje się w jego niewidzialnej części, dostępnej tylko dla zespołu.
Pierwszym tego typu narzędziem jest Dysk Google współdzielo-ny przez członków zespołu, na którym znajduje się cała wytworzo-na w trakcie trwania projektu pamięć instytucjowytworzo-nalwytworzo-na – od notatek ze spotkań poprzez wzory licencji, logotypy, szablony prezentacji aż po fiszki i skany zebranych materiałów. Ponadto duże pliki były też przesyłane między członkami zespołu przy użyciu usługi wetrans-fer.com.
Drugie narzędzie to wspomniane już arkusze kalkulacyjne. Mia-ły one wiele zastosowań. Przede wszystkim dla każdego z miast, w których odbywa się archiwizacja, powstał arkusz liczący 40 ko-lumn i kilkaset wierszy. W kolejnych wierszach takiego pliku wpi-sywane są (w ramach odpowiadających im kolumn) dane dla ko-lejnych pozycji, zakwalifikowanych do Archiwum, które można podzielić na kilka kategorii:
(1) numer porządkowy i opiekun materiału,
(2) informacje o pracy/materiale/projekcie (autor, tytuł, typ, data powstania i in.),
(4) parametry materiału (liczba stron drukowanych i pisanych, wymogi w kwestii skanowania i anonimizacji),
(5) prawa autorskie (instytucje, nazwiska, adresy), podjęte pró-by kontaktu i ich efekty.
Również w arkuszach kalkulacyjnych sporządzono m.in. takie używane na bieżąco pliki, jak: szablony, w których opiekun da-nego materiału wypełnia wszystkie opisujące go metadane; kosz-torysy projektu; wykazy osób objętych wywiadami; spisy odnale-zionych prac magisterskich. W sumie powstało kilka tysięcy tego typu plików.
Trzeci typ narzędzia to edytor tekstów MS Word oraz Doku-menty Google służące do wspólnego sporządzania i komentowania notatek, dokumentów prawnych, raportów z terenu i wielu innych opracowań. Czwarty to opisana wcześniej baza w programie Zotero, używana we wcześniejszej fazie projektu. Piąty to z kolei narzędzie do zarządzania pracą grupową (dashboard) Asana, które miało po-móc dbać o pilnowanie terminów wykonania poszczególnych prac. Jednak z uwagi na to, jak nowe i obce było dla większości uczestni-ków projektu, zostało szybko zarzucone. Efektem projektu jest za-tem zbiór liczący kilka tysięcy plików o różnych formatach, o łącznej wielkości kilkudziesięciu gigabajtów, który sam zaczyna wymagać redukowania złożoności i prac archiwizacyjnych.
Metadane
Członkostwo w WBC pociągnęło za sobą konieczność dostosowania się do istniejącego układu metadanych („atrybutów”47), tzn. pól opi-sujących deponowane w cyfrowym repozytorium materiały. Jako że na gruncie naszego projektu interesowało nas zarówno deskryp-cyjne, jak i analityczne podejście do pozyskiwanych prac, postano-wiliśmy rozbudować dostępny zakres metadanych o kilka nowych pozycji oraz uszczegółowić już istniejące. Metadaną „Typ obiektu”
47 Por. https://confluence.man.poznan.pl/community/display/DLI6/02.+ Edytor+opisu+bibliograficznego, [dostęp: 7 III 2019].
(opartą o rozwijaną listę wyboru) poszerzyliśmy o kilka, istotnych z naszego punktu widzenia, kategorii klasyfikacyjnych (m.in. „pa-miętnik”, „sprawozdanie z obserwacji”, „transkrypcja wywiadu”, „notatka terenowa”, „materiały od badanych” itd.), a metadaną „Lokalizacja oryginału” o kilka nowych metadanych towarzyszą-cych – „Archiwum”, „Miejsce w archiwum”, „Dodatkowe infor-macje” oraz „URL”. Dodaliśmy także kilka metadanych, służących dokładniejszemu opisywaniu kontekstu powstania poszczegól-nych elementów kolekcji48: „Nazwiska powiązane” (obok „Twórca” i „Współtwórca”), „Tytuł projektu badawczego”, „Towarzyszące wydarzenia historyczne”, „Postacie życia społeczno-politycznego pojawiające się w tekście”, „Dziedzina, dyscyplina, subdyscyplina”, „Problemy badawcze”, „Kategorie społeczne, których dotyczy do-kument”, „Obszary tematyczne” (oparta o listę rozwijaną dziesięciu dziedzin praktyk życia codziennego, o których wspominaliśmy na początku tego tekstu) oraz „Informacje o badaniu”. Poza tym sta-raliśmy się rozwinąć zakres informacji na temat samego procesu digitalizacji (dodając metadaną „Sposób pozyskania” jako powią-zaną z metadaną „Digitalizacja”) oraz statusu prawnego digitali-zowanych materiałów (za pośrednictwem metadanych: „Podmioty dysponujące prawami autorskimi do badań”, „Zakres anonimizacji” oraz „Regulaminy, przepisy”)49.
Logika projektu kontra oprogramowanie
Negocjowanie zgodności pomiędzy opracowanymi przez nas struk-turami (układ kolekcji, kryteria podziałów tematycznych itd.) a tymi oferowanymi przez oprogramowanie dLibra wymagało licznych kompromisów i przystosowania się do ograniczeń programowych.
Przede wszystkim konieczne okazało się rozróżnienie dwóch ro-dzajów pól. Pierwsze z nich to takie, które składa się z wielu
odręb-48 Zapleczem dla ich wyodrębnienia były „Etykiety”, które tworzyliśmy w Zote-ro podczas początkowego porządkowania pozyskanych materiałów archiwalnych.
49 Pełen wykaz metadanych (wraz ze sposobem ich zapisu oraz interpretacji), stosowanych do opisywania materiałów w ABnŻC został zawarty w zał. 1 (metada-ne ogól(metada-ne) oraz zał. 2 (metada(metada-ne praw(metada-ne) do niniejszego tekstu.
nych pojęć. Za dobry przykład mogą służyć takie pola, jak „Nazwi-ska powiązane”, „Towarzyszące wydarzenia historyczne”, „Postacie życia społeczno-politycznego pojawiające się w tekście”, „Kategorie społeczne, których dotyczy dokument”, „Pozostałe tagi” oraz kilka innych. W ramach każdej z tych metadanych może pojawić się kilka informacji (nazwisk i nazw własnych, wydarzeń, słów kluczowych itp.), których nie można prezentować w formie narracyjnego, lite-go tekstu, lecz rozdzielnych, rzeczownikowych określeń. Zamiast umieszczania ich w jednym polu przypisanym do jednej metada-nej dokonujemy więc zwielokrotnienia pól tyle razy, ile odrębnych nazw/informacji chcemy z daną metadaną powiązać. Dzięki temu każde takie pole można wykorzystać jako hiperłącze odsyłające do innych metadanych w ramach opisu (jeśli dana informacja pojawia się także w polu innej metadanej) oraz do metadanych w ramach opisów innych materiałów (np. jeśli ta sama postać lub miejsce po-jawiają się opisie zupełnie innych, niepowiązanych ze sobą w inny sposób, materiałów). To tworzy dodatkową strukturę, umożliwia-jącą przeszukiwanie repozytorium „w poprzek”, zgodnie z logiką układu słów kluczowych, niezależnie od standardowych form prze-szukiwania (po tytule, nazwisku autora, usytuowaniu w kolekcji itp.). Drugi rodzaj pól to długi, rozbudowany opis (np. metadana „Problemy badawcze”). W przypadku kontekstu wielu prac badaw-czych niemożliwe okazuje się bowiem opisanie go tylko przy pomo-cy zestawu odrębnych pojęć.
Choć tworzenie długich i wielokrotnie złożonych opisów w ra-mach pól metadanych jest możliwe w systemie dLibra (z ograni-czeniem do 1000 znaków), to jednak system traktuje taki wpis jako jeden obiekt. Utrudnia to znacząco nawigowanie w systemie (ponie-waż długie opisy i pojedyncze wyrazy figurują obok siebie na listach metadanych) oraz myli użytkownika (ponieważ długie opisy także mają status hiperłączy, ale ich kliknięcie nie prowadzi do wskazania żadnych nowych obiektów). Mimo to zdecydowaliśmy się na stoso-wanie obu rodzajów pól, rezerwując mniejszą część metadanych na użytek szerszych opisów, przy jednoczesnym wprowadzaniu skró-towych haseł w większości z nich.
Ryc. 1. Fragment metadanych jednej z prac zawartych w Archiwum. Pole „Problemy badawcze” to przykład jednolitego pola opisowego. Odrębne, oddzielone średnika-mi słowa zawarte w takich polach, jak np. „Dziedzina, dyscyplina, subdyscyplina” to przykład pola z wieloma osobnymi wyrazami, z których każdy funkcjonuje jako hiperłącze – klikając na nie, otrzymujemy wykaz wszystkich innych prac i materia-łów, w których opisie także pojawia się dany wyraz
Jeszcze jednym rodzajem negocjacji na linii: system dLibra – lo-gika działania projektowego było kilkustopniowe strukturyzowanie danych. W pierwszej kolejności musieliśmy uporządkować pozy-skane archiwalia, które następnie spisywaliśmy i segregowaliśmy (za pośrednictwem MS Excel i Zotero). W kolejnym kroku
stworzy-liśmy wewnętrznie jednorodną kolekcję (z podziałem na publikacje pojedyncze i grupowe) w systemie dLibra, do którego także zaim-portowaliśmy etykiety z Zotero, dokonując rozdziału ich zawarto-ści pomiędzy pola poszczególnych metadanych. W żadnym z tych przypadków nie istnieją proste, automatyzujące proces rozwiąza-nia, które pozwoliłyby na przyspieszenie tych działań. Przełożenie wcześniej utworzonych struktur i etykiet na system dLibra następo-wało więc w procesie dyskusji grupowych oraz na drodze negocjacji między redaktorką a elementami systemu: (1) pojęciami istniejącymi już w słowniku metadanych WBC oraz (2) hierarchiczną strukturą metadanych WBC/dLibry50.
Najważniejsze zderzenie logiki dLibry z potrzebami Archiwum dotyczyło możliwości ustalenia, jakie prawa dostępowe będą przy-znawane czytelnikom naszego repozytorium. Pierwotnie chcieliśmy dokonać rozdziału na użytkowników zarejestrowanych (z większymi uprawnieniami) i będących „gośćmi” na naszej stronie (z umniejszo-nymi uprawnieniami). Okazało się jednak, że taka struktura upraw-nień nie jest możliwa do odwzorowania w systemie dLibra (możliwe jest przyznanie wyłącznie uprawnień wszystkim, publicznym i zare-jestrowanym użytkownikom lub wybranym, zarezare-jestrowanym, ale nie wszystkim zarejestrowanym, z jednoczesnym pominięciem pu-blicznych), w związku z czym wszystkie opisy oraz wszystkie ma-teriały (których dotyczyły zawarte licencje) zostały udostępnione dla każdego czytelnika, włącznie z możliwością ich pobrania na dysk lo-kalny, bez konieczności zakładania konta51. Tylko w przypadku części materiałów widoczny jest sam opis – tam, gdzie materiał jest dostęp-ny w ramach indostęp-nych źródeł (artykuł prasowy, publikowadostęp-ny artykuł itd.) lub jeśli nie udało się nam uzyskać praw do dysponowania nim.
50 Ponadto okazało się, że wprowadzanie zmian w układzie kolekcji cyfrowych materiałów (mającej charakter drzewiasty) po jakimś czasie funkcjonowania zbioru (tzn. po momencie opublikowania choć części opisów i skanów) stanowi w syste-mie dLibra dużą komplikację (wymaga przepisania dotychczas tworzonych opisów zgodnie z nową logiką układu i rozdziału informacji).
51 Na przełomie września i października 2019 roku zasady dostępu do Archi-wum ulegną radykalnej zmianie – korzystać z zawartych w nich materiałów będą mogli wyłącznie zarejestrowani użytkownicy.