Blog archiwistów i bibliotekarzy Instytutu Piłsudskiego

Blog archiwistów i bibliotekarzy Instytutu Piłsudskiego

 

A photo from Władysława’s album with her father among members of the organization “Sokół”, in Silna, Poland, early 1920s.

Zdjęcie z albumu Władysławy z jej ojcem wśród członków Towarzystwa Gimnastycznego “Sokół” w Silnej (poznańskie) we wczesnych latach 1920-tych.

Wprowadzenie

Ciotka mojej żony, Władysława, zawsze trzymała rodzinne albumy gotowe do podróży. W czasie II wojny światowej, kiedy rodzina została wydalona z mieszkania w Łodzi i podczas dalszej przymusowej migracji, albumy zawsze podróżowały razem z nią w plecaku. W ten sposób albumy przetrwały i możemy teraz cieszyć się rodzinnymi zdjęciami do kilku pokoleń wstecz. Trwałość czarno-białej fotografii i dobrej jakości, bezkwasowy papier, na którym zostały wydrukowane, pomogły zachować stuletnie odbitki.

Kolorowe zdjęcia sprzed 20 lub 30 lat nie były takie trwałe. Barwniki organiczne szybko zanikają, niektóre zdjęcia tracą większość kolorów. Pracujemy nad ich digitalizacją, próbując cyfrowo przywrócić kolory, zamieniając je na cyfrowe.

Oczywiście tworzenie kopii cyfrowych starych albumów ma również inny cel, oprócz zachowania. Rodzina jest rozproszona po całym świecie. Bracia i siostry, którzy mieszkali lub pracowali w różnych regionach rozbiorowych Polski przed 1918 rokiem, trafili do różnych krajów; niektórzy powrócili do odrodzonej Polski, niektórzy osiedlili się w Niemczech, Francji, w USA, Wielkiej Brytanii i innych krajach. Pojedynczy album to dziś za mało, ale elektroniczna wersja cyfrowa może być oglądana przez wielu.

Co prowadzi nas do pytania: jak stworzyć trwały, długowieczny album elektroniczny?

Około 15 lat temu zainstalowaliśmy internetowy program otwartego oprogramowania, Gallery2, który zawierał wszystko co niezbędne do zbudowania kolekcji albumów online. Używaliśmy programu Picasa do porządkowania i opisywania zdjęć. Dziś Gallery2 i Picasa już nie istnieją (lub nie są obsługiwane, co oznacza prawie to samo). Poniżej opiszemy nasze starania o odbudowę albumów tak, aby mogły przetrwać przynajmniej przez jedno pokolenie (lub, powiedzmy, 25 lat).

Jak możemy przewidzieć przyszłość, nawet na 25 lat, w szybko zmieniającym się krajobrazie cyfrowego świata? Jednym z czynników, który pomoże (i poprowadzi nas), jest silny konserwatyzm programistów lub budowniczych skomputeryzowanych systemów. Weźmy na przykład Unicode, uniwersalny alfabet lub mechanizm do reprezentowania znaków słowa pisanego w prawie wszystkich językach używanych dzisiaj. Będziemy o tym pisać dalej, ponieważ bez Unicode nie można naprawdę opisywać zdjęć, na przykład reportażu z podróży z Łodzi do Częstochowy do Hajdúböszörmény do Škofja Loka do Besançon do Logroño. Unicode ma około 25 lat, ale nie był pierwszym kodowaniem liter, wcześniej w komputerach dominował kod ASCII alfabetu łacińskiego. Obecnie wiele programów i systemów, nawet zbudowanych całkiem niedawno, nadal nie zapewnia obsługi standardu Unicode. Podobny konserwatyzm wpływa na formaty zapisu zdjęć (grafika rastrowa). Niektóre formaty, takie jak TIFF i JPEG, które wprowadzono 30 lat temu stały się bardzo popularne. Nowe standardy, takie jak JP2, które pod pewnymi względami są lepsze, przyjmują się z dużymi trudnościami.

Cele projektu

Jakie są cele projektu? Zaczynamy od zbioru fotografii w formie cyfrowej. Mogą to być zeskanowane fotografie lub zdjęcia powstałe od razu w formie cyfrowej (born-digital). Obrazy są uporządkowane w albumy lub kolekcje, być może skomponowane na podstawie oryginalnych,  oprawionych albumów lub utworzone od początku. Mamy również metadane: opisy fotografii, osoby, miejsca, daty itp., powiązane z poszczególnymi zdjęciami, a także z albumami lub kolekcjami. Czasem zapisana jest historia albumu i inne wydarzenia związane z tymi zdjęciami.

Celem projektu jest zbadanie i udokumentowanie metodologii zachowania zdjęć, skanów zorganizowanych w opisane albumy tak, by można było je otworzyć i pokazać w przyszłych technologiach online. Chcemy zachować obrazy i metadane dla przyszłych pokoleń, nie dla ulotnego, jednorazowego oglądania (do osiągnięcia dziś w mediach społecznościowych)

Poza zakresem tego projektu jest konserwacja oprawionych papierowych albumów i oryginalnych fotografii, skanowanie i przechowywanie kopii cyfrowych. Tematy te mają mniej lub bardziej obszerną literaturę, chociaż niektóre konkretne tematy mogą być prezentowane na tym blogu później.

OpenRefineZbieranie metadanych podczas digitalizacji zasobów archiwalnych nie jest prostym zajęciem. Nazwy miejsc, wydarzeń, nazwiska osób wymienianych w dokumentach często różnią się od dzisiejszej pisowni. Nazwy mają różne wersje, aliasy, w dokumentach pojawiają się literówki itp. Co prawda nowoczesne przeszukiwarki jak Google często potrafią rozpoznać często spotykane literówki - jeśli wpiszemy “Kowakski” otrzymamy:

Pokazane są wyniki dla Kowalski
Szukaj zamiast tego Kowakski,

ale działa to najlepiej dla często spotykanych nazw czy imion i dla błędów. W projekcie, w którym chcielibyśmy przedstawić dane jako Linked Open Data, ważne jest mieć czyste dane, bez błędów i z zidentyfikowanymi wersjami, jeśli takie istnieją.

Jako przykład weźmiemy nazwiska (zbieramy także nazwy miejsc, wydarzeń historycznych i inne). Samo imię i nazwisko zwykle nie identyfikuje osoby - może być wiele osób o takim samym imieniu i nazwisku. Kiedy już zidentyfikujemy osobę, często okazuje się, że jej nazwisko występuje w wielu wariantach. Są wersje w różnych językach, osoba mogła używać pseudonimu, przydomka, zmienić nazwisko (przed albo po małżeństwie), dodać tytuły itp. Poddani i obywatele często używają przydomka dla określenie swoich przywódców. Jak znaleźć się w tej gmatwaninie?

Dla osób wymienionych w dokumentach archiwalnych wybraliśmy kilka prostych reguł. Sa one nieco arbitralne, ale służa nam dobrze:

  1. Używamy jednego standardowego imienia i nazwiska dla jednej osoby. Nazwiska alternatywne, wersje w innych językach itp. są notowane także, aby ułatwić wyszukiwanie. Używamy wersji polskiej nazwiska, jeśli to możliwe, i wersji używanej w Wikipedie (polskiej lub w innym języku) jeśli jest to stosowne.

  2. Zapisujemy dane osoby jako “nazwisko, imię (imiona)” w tej kolejności. Nawet ta prosta reguła powoduje czasem trudności, gdyż nie zawsze jest łatwo określić, która część jest imieniem a która nazwiskiem. Wyjątkiem od tej reguły są osoby publiczne takie jak królowie, papieże itp. Dla których podajemy popularne lub oficjalne brzmiene (Mieszko I, Jan Paweł II itp.)

  3. Przypisujemy każdej osobie unikalny identyfikator który generujemy sami. O potrzebie używania unikalnych identyfikatorów mozna więcej przeczytać w blogu, Jeśli to możliwe, korelujemy ten identyfikator z dwoma popularnymi (i w miarę trwałymi) rejestrami: Wikidanymi i VIAF. Spotykamy jednak osoby, o których nikt nie napisał artykułu w Wikipedii w żadnym języku, i w konsekwencji brak im identyfikatora Wikidata. Są osoby które nigdy nie napisały książki i brak jest ich w rejestrze VIAF, który zbiera dane z bibliotek narodowych świata. Dla nich tworzymy krótki opis, dodajemy odnośniki i jak dla innych tworzymy nasz identyfikator.

Następnym etapem jest sprawdzenie zebranych zapisów nazwisk (w chwili obecnej mamy ich ok 80 tysięcy) i doprowadzenie ich do standardu. Pracujemy w sekcjach, typowo z danymi jednej kolekcji archiwalnej, ale i tak są to dziesiątki tysięcy rekordów. Można użyć uniwersalne narzędzie - arkusz rozliczeniowy - i wykorzystując takie funkcje jak sortowanie, filtrowanie, wyszukiwanie i zastępowanie wykonać dużą część pracy, Znaleźliśmy jednak bardziej wyspecjalizowany program - OpenRefine - który okazał się być o wiele bardziej przydatny dla wykonania tego zadania. OpeRefine (rozprowadzany jako otwarte oprogramowanie) wyrósł z projektu Google, nazywany wtedy Google Refine (mocno związany z nieistniejącym już projektem Freebase1) i został oddany społeczności otwartego oprogramowania która dalej go udoskonala. OpenRefine został stworzony specjalnie do zadania czyszczenia i udoskonalenia danych.

Metro 2016 Streszczenie

W czwartek 21 stycznia 2016 braliśmy udział w dorocznej konferencji METRO - Metropolitan New York Library Council - która miała miejsce w Baruch College w Manhattanie. Konferencja ta, jak i poprzednie, była doskonałym przeglądem najnowszych inicjatyw, pomysłów, rozwiązań i projektów w dziedzinie humanistyki cyfrowej w społeczności GLAM. Poniżej przedstawiamy omówienie wybranych prezentacji w języku angielskim.

The annual METRO (Metropolitan New York Library Council) conferences are about the best sources of the latest inventions, projects and ideas in the GLAM community, concentrated in one day of intense briefings. This year was no exception - the conference that took place January 21, 2016 at the Baruch College in Manhattan. On the conference a number of “Project briefings” were presented - the intent was to show the projects in progress and discuss their workings, issues and plans, not necessarily the completed works. It was impossible to attend so many parallel briefings; we have selected two in each sessions, and report on them here as a sampling of the conference.

Zegar astronomiczny w PradzeBy Steve Collis from Melbourne, Australia (Astronomical Clock Uploaded by russavia) [CC BY 2.0], via Wikimedia Commo

W jednym z poprzednich wpisów na blogu “Czy umiemy pisać daty?” omawiałem podstawy uniwersalnej notacji  czasu i dat, zdefiniowanej w międzynarodowym standardzie ISO 8601 i jego uproszczonej wersji konsorcjum W3C. Od tego czasu Biblioteka Kongresu Amerykańskiego zakończyła prace nad rozszerzonym standardem, Extended Date/Time Format (EDTF) 1.0. Większa część EDTF dotyczy zapisu nieprecyzyjnych dat. Taka niedokładna lub nieprecyzyjna informacja dotycząca czasu występuje często w zapisach wydarzeń historycznych, np. w archiwach czy naukach bibliotecznych. Standard ISO 8601 nie pozwala na wyrażenie takich konceptów jak “w przybliżeniu rok 1962”, “któryś rok pomiędzy 1920 a 1935” czy “wydarzenie miało prawdopodobnie miejsce w roku 1938, ale nie jesteśmy tego pewni”. Standard EDTF pozwala na zapisanie w postaci zrozumiałej przez komputer takich konceptów, wypełniając potrzeby istniejące w wielu polach wiedzy mających do czynienia z metadanymi o charakterze historycznym.

Mimo tego, że standard EDTF jest stosunkowo nowy i nie ma zbyt wiele narzędzi programowych pomagających wprowadzać takie dane, sądzę, że warto jest zaznajomić się z tą nowa notacją i używać jej w miarę możliwości.

Definicje

Chciałbym rozpocząć dyskusję kilkoma definicjami; symbole pojawiające się przy definicjach będą opisane dalej.

Precyzja

Precyzja jest miarą zakresu, wewnątrz którego mieści się ‘prawdziwa’ wartość [1]. Precyzja jest jednoznacznie zdefiniowana w wyrażeniach daty i daty/czasu. Jeśli wydarzenie miało miejsce w roku 1318, zapis taki posiada precyzję jednego roku (mogło mieć miejsce w dowolnym czasie w ciągu tego roku). Jeśli podamy 1318-05, zwiększamy precyzję do jednego miesiąca, a 1945-09-15 posiada precyzję jednego dnia, itp [2]. W EDTF możemy rozszerzyć tę definicję określając precyzję dziesięcio- lub stulecia używając symbolu x (patrz 'precyzja maskowana' poniżej).

Kto lubi przeprowadzki?

I wszystko, co się z tym wiąże: segregowanie, redukowanie, pakowanie, przewożenie, rozpakowywanie, ustawianie....? O ile

Piłsudski Institute
 Instytut Piłsudskiego

można w miarę sprawnie przenieść się z mieszkania do mieszkania, to przeprowadzenie zmiany lokalu instytucji, która od ćwierćwiecza zajmowała kamienicę w centrum Manhattanu, gromadząc archiwa, dzieła sztuki i eksponaty muzealne, trudno sobie wyobrazić.

Wieść o sprzedaży domu, który wynajmował Instytut Piłsudskiego w Ameryce na swoją siedzibę, była dużym zaskoczeniem dla jego pracowników. Instytut kojarzony był od wielu lat z Drugą Aleją na Manhattanie, miał stałe grono przyjaciół, wielbicieli, odwiedzających oraz badaczy, a tu nagle taka wiadomość! Niełatwo było się z nią pogodzić, ale innego wyjścia nie było. Niezwłocznie zorganizowano Kampanię Na Rzecz Przyszłości w celu zebrania funduszy na to przedsięwzięcie i opracowano logistykę zmiany lokalizacji. Przygotowania trwały ponad rok.  Przede wszystkim musieliśmy znaleźć nową siedzibę, która pomieściłby nasze zbiory i zapewniła sprawne kontynuowanie działalności Instytutu. Najbardziej przypadł nam do gustu lokal zaproponowany przez Polsko-Słowiańską Federalną Unię Kredytową, a także warunki jego wynajmu. Rozpoczęły się prace adaptacyjne: zaprojektowanie i zabudowanie wnętrza, instalacja profesjonalnych zabezpieczeń, regałów oraz montowanie przestronnych szaf. Nieocenioną pomoc otrzymaliśmy z Instytutu Pamięci Narodowej, z którego oddelegowano ośmiu archiwistów, którzy w ciągu dwóch miesięcy profesjonalnie i sprawnie zapakowali archiwa oraz zbiory biblioteczne i pomagali w przenoszeniu ich do nowego lokum. Nie byliśmy w stanie policzyć tych wszystkich pudeł i paczek, które po przewiezieniu na nowe miejsce, zajęły większość powierzchni użytkowej, piętrząc się niemal pod sufit.

Part II: Product

(Guest blog by Rob Hudson)

Arthur Rubinstein (Linked Data)In Part I of this blog, I began telling you about my experience transforming Carnegie Hall’s historical performance history data into Linked Open Data, and in addition to giving some background on my project and the data I’m working with, I talked about process: modeling the data; how I went about choosing (and ultimately deciding to mint my own) URIs; finding vocabularies, or predicates, to describe the relationships in the data; and I gave some examples of the links I created to external datasets.

In this installment, I’d like to talk about product: the solutions I examined for serving up my newly-created RDF data, and some useful new tools that help bring the exploration of the web of linked data down out of the realm of developers and into the hands of ordinary users. I think it’s noteworthy that none of the tools I’m going to tell you about existed when I embarked upon my project a little more than two years ago!

As I’ve mentioned, my project is still a prototype, intended to be a proof-of-concept that I could use to convince Carnegie Hall that it would be worth the time to develop and publish its performance history data as Linked Open Data (LOD) — at this point, it exists only on my laptop. I needed to find some way to manage and serve up my RDF files, enough to provide some demonstrations of the possibilities that having our data expressed this way could afford the institution. I began to realize that without access to my own server this would be difficult. Luckily for me, 2014 saw the first full release of a linked data platform called Apache Marmotta by the Apache Software Foundation. Marmotta is a fully-functioning read-write linked data server, which would allow me to import all of my RDF triples, with a SPARQL module for querying the data. Best of all, for me, was the fact that Marmotta could function as a local, stand-alone installation on my laptop — no web server needed; I could act as my own, non-public web server. Marmotta is out-of-the-box, ready-to-go, and easy to install — I had it up and running in a few hours.

PARTNERZY
Ministerstwo Kultury
Biblioteka Narodowa
Naczelna Dyrekcja Archiwów Państwowych
Konsulat RP w NY
Fundacja na rzecz Dziedzictwa Narodowego
PSFCU
NYC Department of Cultural Affairs