Wspólny katalog zbiorów bibliotecznych

Czyli migracja z MAK do Koha

W sierpniu 2012 roku została podpisana umowa o współpracy Instytutu Józefa Piłsudskiego i Instytutu Naukowego w Nowym Jorku. Jej pierwszym owocem jest wspólny katalog zasobów bibliotecznych obu instytucji, który został uruchomiony w listopadzie 2012. W październiku 2012 roku podobna umowa została podpisana z Polską Fundacją Kulturalną w Clark, NJ, której biblioteka wkrótce rozpocznie dodawanie swojej kolekcji do naszego katalogu.  Wspólny katalog ma na celu ułatwić badaczom dostęp do zbiorów naszych instytucji tworząc jedno, docelowe narzędzie do przeszukiwania. Wspólny katalog powinien także usprawnić i przyśpieszyć sam proces katalogowania zasobów dzięki “współkatalogowaniu”, co jest szczególnie ważne w związku ze skromnymi środkami jakie nasze instytucje mogą przeznaczyć na ten cel. O ile nasze kolekcje nie są identyczne to jednak posiadają sporo duplikatów. Łatwo sobie wyobrazić sytuację, gdzie opisy bibliograficzne stworzone przez katalogujących jednej instytucji, będą mogły być wykorzystane przez drugą, oszczędzając w ten sposób czas i wysiłek.Biblioteki Polonii Amerykańskiej

Tutaj chciałbym przedstawić techniczną stronę łączenia bazy zbiorów biblioteki Instytutu Józefa Piłsudskiego i Instytutu Naukowego. 

Czytaj dalej „Wspólny katalog zbiorów bibliotecznych”

Pamięć masowa dla archiwów cyfrowych

NetgearW miarę wzrostu wykorzystania cyfowego zapisu informacji, archiwa zaczynaja przywiązywać coraz większą wagę do mediów w postaci elektronicznej. Dotyczy to zarówno archiwów klasycznych które digitalizują swoje zasoby, jak i instytucji ktore archiwizuja dokumenty i zapisy powstałe w ostatnich dekadach, które sa w coraz większym stopniu cyfrowe od początku ich powstania (‘born digital’).

Zapis cyfrowy wymaga zupełnie innego podejścia do problemu zachowania i zabezpieczenia zasobów archiwalnych. W jednym z poprzednich blogów rozważaliśmy oprogramowanie do inwentaryzacji zasobów, tutaj chciałbym przedyskutować problem pojemności pamięci cyfrowej, potrzebnej do przechowywania zasobów.

Zapis informacji w postaci cyfrowej poprzedza oczywiście powstanie komputerów. Karty dziurkowane były uzywane od poczatku 19 wieku – w krosnach (Joseph Jacquard), w przetwarzaniu informacji (Siemion Korsakow), w opracowywaniu danych spisu powszechnego (Herman Hollerith). Jeszcze niedawno maszyny cyfrowe Odra używaly (za IBM) kart dziurkowanych do zapisu programów i danych. Wkrótce zostały one zastąpione papierową taśmą perforowaną, ale prawdziwe przyspieszenie spowodowało dopiero użycie zapisu magnetycznego. Rewolucja komputerowa to pamięc dyskowa: najpierw mainframe, potem stacje robocze, komputery osobiste, laptopy – to wszystko istniało dzieki możliwości zapisu informacji na dyskach twardych i przenośnych dyskietkach. Dysk twardy ma chyba najdłuższa historię rozwoju technologicznego, i jest do dziś podstawowym medium zapisu danych w Internecie oraz w większości komputerów stacjonarych i laptopów.

Czytaj dalej „Pamięć masowa dla archiwów cyfrowych”

Chmura i Powstania śląskie

Crowdsourcing z użyciem Google Docs

slaska-mala-260

Fragment mapy z okresu Powstań śląskich z archiwów Instutytu Józefa Piłsudskiego, zespół 8 jedn. 164.

Przy pracy nad kolekcją  “Powstania Śląskie” w archiwum Instytutu pojawił się dylemat. Archiwa są już zmikrofilmowane a mikrofilmy zeskanowane, ale z ponad 800 jednostek (teczek) udostępnione zostało tylko 50. Wynika to z braku metadanych, szczególnie danych o powstańcach, którzy walczyli w trzech Powstaniach Śląskich w latach 1919-1921. Brak finansowania powodował odsuwanie dokończenia projektu, gdyż nie umieliśmy wykorzystać pomocy wolontariuszy pracujących w domu. Co prawda istniały podobne projekty crowdsourcing, ale były one oparte na specjalnie napisanym oprogramowaniu i sporym finansowaniu projektu.

Wpadliśmy wtedy na pomysł, aby użyć gotowego, publicznie dostępnego systemu. Google Docs (teraz Google Drive) wydawał się być użyteczny dla tego projektu. Wymagało to dopasowania naszych wymagań do możliwości systemu, i narażało nas na wpadkę jeśliby Google w sposób istotny zmienił format dokumentów (co już się raz zdarzyło). Ale postanowiliśmy zaryzykować.

Materiałem źródłowym są skany dokumentów, głownie dużych i mniejszych ksiąg – spisów osobowych powstańców w różnych jednostkach wojskowych. Nasz system opisywania dokumentów archiwalnych oparty jest na DSpace, bardzo szeroko stosowanym otwartym oprogramowaniy do opisu metadanych. Trzeba było więc zbudować system rozproszonej pracy (crowdsourcing) a potem pożenić ze sobą dane zbierane w lokalnie i zdalnie. Wymaganiem podstawowym było to, że system musiał być prosty na tyle, żeby osoby bez specjalnego szkolenia w obsłudze mogły pracować i wprowadzać dobrej jakości dane. Zdecydowaliśmy się na bezpośrenie użycie arkusza kalkulacyjnego, bez specjalnych formularzy wprowadzania danych. Arkusze kalkulacyjne są dość powszechnie stosowanym narzędziem, i liczyliśmy na to, że użytkownik mając wgląd w całość swojego fragmentu pracy będzie mógł łatwo poprawić błędy. Wymaganymi polami były numer jednostki archiwalnej, strona i nazwisko; inne pola były opcjonalne. Jedynym polem zaopatrzonym w walidację było pole daty (z uwzględnieniem możliwości wpisania tylko roku, co nie jest trywialne w polach formatowanych jako data).

Jak jednak dostarczyć widoku skanu? Do tego celu użyliśmy Google+, które pozwala w bardzo granularny sposób udostępniać albumy – kolekcje zdjęć. Zastosowanie programu Picasa do wybierania i umieszczania w ‘chmurze’ albumów odpowiadających jednostkom pozwoliło na uproszczenie całego procesu. Arkusz kalkulacyjny  'Powstancy’, udostępniony pracującym, posiada podstronę zadań, w której przypisane każdemu wolontariuszowi zadanie jest związane z linkiem do albumu w Google+. Brak jednej z podstawowej funkcji, powiększania (niezbędnego do przyjrzenia się szczegółowi ręcznie pisanego tekstu), udało się ominąć przez użycie opcji pobrania obrazu na swój komputer. Wolontariusz ma więc teraz możliwość ustawienia na ekranie obok siebie oryginalnego obrazu i tabelki, do której może wpisywać dane.

Obróbka danych ulegała ewolucji. Zaskoczyła nas liczba chętnych, i szybko okazało się, że jedna tabela nie wystarczy, ze względu na ograniczenia liczby rzędów i kolumn w Google Docs. Trzeba też było dokładnie sprawdzać dane, nie wszyscy wolontariusze zwracali uwagę na dokładnośc pracy. Rozdzieliliśmy więc pracę na kilka tabel, korzystając z świetnej obsługi programowej (API) Google. Funkcje bazodanowe w języku SQL pozwalały na łatwą agregację danych, możliwe też było robienie linków pomiedzy tabelami. Dane surowe, dane w trakcie sprawdzania i dane już gotowe są teraz umieszczone w oddzielnych dokumentach.  Dane już sprawdzone są dalej przerabiane w kilku etapach, i udostępniane na stronie Powstań Śląskich. Połaczenia między dokumentami i funkcje powodują, że tabele są ‘żywe’ i w każdej chwili odzwierciedlają postęp prac każdego wolontariusza jak i dane podsumowujące.

Dzięki pomocy przyjaciół Instytutu, którzy rozpropagowali ideę zdalnego wolontariatu, i dzięki pracy i zaangażowaniu Agnieszki Petli (teraz Brissey), która od początku zajmuje się archiwami Powstańców i bardzo cierpliwie szkoli wolontariuszy, organizuje dane, przydziela zadania i sprawdza wyniki ich pracy, projekt crowdsourcing archiwum Powstań Śląskich z użyciem chmury bitowej (cloud computing) spotkał się z dużym sukcesem. Wolontariusze wprowadzili już ponad 50 tysięcy rekordów, które będa sukcesywnie udostępniane. Oczywiście chętnie przyjmujemy dalszych wolontariuszy, bez których projekt nie byłby możliwy.

Marek Zieliński

Artykuł ukazał się 23 czerwca 2012 w Blogu archiwistów i bibliotekarzy Instytutu Piłsudskiego

Może Cię też zainteresować:

Czy umiemy pisać daty – część 2: EDTF

Zegar astronomiczny w Pradze

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

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

Czytaj dalej „Czy umiemy pisać daty – część 2: EDTF”

Instytut Piłsudskego w Ameryce zmienił siedzibę.

Piłsudski InstituteKto lubi przeprowadzki?

I wszystko, co się z tym wiąże: segregowanie, redukowanie, pakowanie, przewożenie, rozpakowywanie, ustawianie….? O ile 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. Instytut PiłsudskiegoNajbardziej przypadł nam do gustu lokal zaproponowany przez Polsko-Słowiańską Federalną Unię Kredytową, a także warunki jego wynajmu. Archiwiści z IPNRozpoczęł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.

Czytaj dalej „Instytut Piłsudskego w Ameryce zmienił siedzibę.”

MoReq2010 – co jest w środku

moreq2010Jednym z najważniejszych zadań systemu zarządzania aktami (RM) jest dokumentowanie działalności instytucji czy organizacji, tworzenie zapisanej i niezmienialnej pamięci jej działalności i historii, zapisywanie dowodów które mogą być użyte (np. przez historyka lub sąd) z pewnością, że nie zostały one zmienione czy zafałszowane. W tym aspekcie MoReq2012 jest istotny również dla archiwów, których funkcja pokrywa się w dużym stopniu z tymi zadaniami.

Moduły MoReq2010

MoReq2010  – wymagania sytemu zarządzania aktami –  jest podzielone na moduły, które opisują różne działy albo funkcje oprogramowania. Moduły to jednocześnie serwisy, części oprogramowania które te funkcje spełniają. Niektóre rodzaje serwisów są  już w powszechnym użyciu w prawie każdym systemie wielo-użytkownikowym, niektóre są specyficzne dla MoReq.

Moduły obsługujące użytkowników to Grupy Użytkowników i modelowy Moduł Ról. Zadaniem modułu użytkowników jest zarządzanie użytkownikami i ich grupami, podobnie do istniejących użytkowników w systemach komputerowych, ale z konkretnymi ograniczeniami (np. nie wolno ponownie używać identyfikatorów itp.). Moduł ról opisuje role jakie moga przyjmować użytkownicy, i możliwości dostępu do przypisane tym rolom. Jan Kowalski może więc na przykład należeć do grupy Działu Handlowego, i posiadać rolę Administratora z prawami dodawania nowych użytkowników, ale tylko w tym dziale.

Czytaj dalej „MoReq2010 – co jest w środku”

Wstęp do MoReq2010

Czym jest a czym nie jest MoReq2010

moreq2010MoReq2010 jest najnowszym europejskim standardem opisującym wymagania systemu zarządzania aktami (RM = record management).

Dlaczego powinniśmy się w ogole interesować RM? Zarządzanie aktami dotyczy przede wszystkim instytucji czy firm które takie akta wytwarzają. Pozornie dobry system szafek na dokumenty, segregatorów, ksiąg korespondencji przychodzącej i wychodzącej powinien być całkowicie wystarczający. Stare biurokracje o tradycji sięgającej Bizancjum (a do takich należy w dużym stopniu Polska) posiadają takie zwyczaje w nadmiarze. Ale system o tak starej tradycji jest trudny do zmodyfikowania, a czas dokumentów elektronicznych, łatwości kopiowania informacji, rozproszenia geograficznego firm itp. tworzy wyzwania którym trudno jest już dziś sprostać. Archiwa, jak każe tradycja, wcześniej lub później dostaną  takie kolekcje dokumentów generowanych masowo wewnątrz ministerstw, ambasad, firm i instytucji użyteczności publicznej, i powinny być żywotnie zainteresowane, w jakim stanie i w jakiej formie te dokumenty będą przekazane.

Zarządzanie dokumentami (RM) zajmuje się konceptualnie prostymi problemami. Dla ułatwienia można sobie wyobrazić zapis narady prezydenckiej w Białym Domu albo zapis wizyty i badania u lekarza. Dokument trzeba przechować i opublikować, aby był dostępny dla jego użytkowników. Trzeba go zaklasyfikować do właściwej kategorii (szuflady, teczki, przegródki). Trzeba określić, kto w ogóle może go czytać, a kto (i kiedy) może go zmodyfikować. Czy można robić kopie, a jeśli tak, to gdzie będą przechowywane. Trzeba zapisać historię tego dokumentu. Trzeba określić, jaki jest jego czas życia, i jaki będzie jego los po tego czasu upłynięciu: dokument może być np. usunięty, poszatkowany albo przekazany archiwum.

Czytaj dalej „Wstęp do MoReq2010”

Visualizing Cultural Heritage: Linked Open Data and the Carnegie Hall Archives p. 2

Wizualizacja spuścizny kulturowej: otwarte Linked Data w Carnegie Hall cz. 2

Przedstawiamy drugą część gościnnego blogu Roberta Hudsona, archiwisty z Carnegie Hall w Nowym Jorku. W drugim odcinku Rob opowiada o wynikach swojej pracy nad przekształceniem bazy danych Carnegie Hall w postac otwartego Linked Data. Po dokonaniu konwersji i uzyskaniu ok miliona „trójek” RDF, pora na dotarcie do narzędzi pozwalających na wizualizację i przeglądanie danych. Blog jest ilustorowany nagraniami pokazującymi na żywo eksploracje danych, z komentarzem autora.

Part II: Product

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.

In addition to giving me the capability to serve up, query, and edit my RDF data, Marmotta has some great built-in visualization features. The screencast below demonstrates one of the map functions, with which I can make use of the GeoNames URIs I’ve used in my dataset to identify the birthplaces of composers and performers.

Czytaj dalej „Visualizing Cultural Heritage: Linked Open Data and the Carnegie Hall Archives p. 2”

Visualizing Cultural Heritage: Linked Open Data and the Carnegie Hall Archives p. 1

Wizualizacja spuścizny kulturowej: otwarte Linked Data w Carnegie Hall cz. 1

Rob Hudson

Rob Hudson – Photo by Gino Francesconi

Przedstawiamy gościnny blog Roberta Hudsona, archiwisty z Carnegie Hall w Nowym Jorku. Rob jest z wykształcenia muzykiem, zainteresowany archiwami, pracuje w Carnegie Hall od 1977 roku. Odkrywszy bazę danych występów w Carnegie Hall sięgających 19 wieku, Rob postanowił nauczyc sie programowania i dokonać konwersji danych w postać otwartego Linked Data tak, aby można było odkrywać powiązania i informacje o kompozytorach, wykonawcach i koncertach. Wielu polskich twórców i wykonawców przez lata brało udział w przedstawieniach w Carnegie Hall. Inicjatywa Roba przyczyni się, miejmy nadzieję, do udostępnienia ciekawego rozdziału z historii muzyki również polskim fanom.

Part I: Process

My name is Rob Hudson, and I’m the Associate Archivist at Carnegie Hall, where I’ve had the privilege to work since 1997. I’d like to tell you about my experience transforming Carnegie Hall’s historical performance history data into Linked Open Data, and how within the space of about two years I went from someone with a budding interest in linked data, but no clue how to actually create it, to having an actual working prototype.

First, one thing you should know about me: I’m not a developer or computer scientist. (For any developers and/or computer scientists out there reading this right now: skip to the next paragraph, and try to humor me.) I’m a musician who stumbled into the world of archives by chance, armed with subject knowledge and a love of history. I later went back and got my degree in library science, which was an incredibly valuable experience, and which introduced me to the concept of Linked Open Data (LOD), but up until relatively recently, the only lines of programming code I’d ever written was a “Hello, World!” – type script in Basic — in 1983. I mention this in order to give some hope to others out there like me, who discovered LOD, thought “Wow, this is fantastic — how can I do this?”, and were told “learn Python.” Well, I did, and if I can do it, so can you — it’s not that hard. Much harder than learning Python — and, one might argue, more important — is the much more abstract process of understanding your data, and figuring out how to describe it. Once you’ve dealt with that, the transformation via Python is just process — perhaps not a cakewalk, but nonetheless a methodical, straightforward process that you can learn and tackle, step by step.

Czytaj dalej „Visualizing Cultural Heritage: Linked Open Data and the Carnegie Hall Archives p. 1”

Standardy metadanych dla archiwów: płaskie czy hierarchiczne? (Cz. 2)

Część 2

Wszystkie nowoczesne standardy zapisu informacji używają jednego języka zapisu, XML. Jest to język uniwersalny, prosty i łatwy do opanowania, a jednoczesnie ma ogromną moc ekspresji. Adres Instytutu możemy w XML zapisac płasko:

<adres>180 Second Avenue, New York, NY</adres>

albo hierarchicznie:

<galaktyka nazwa=”Droga Mleczna„>
   <gwiazda nazwa=”Sol„>
     <planeta nazwa=”Mars„/>
     <planeta nazwa=”Ziemia„>
       <kontynent nazwa=”Ameryka Północna„>
         <panstwo nazwa=”USA„>
           <stan nazwa=”Nowy Jork„> […] itp.
           </stan>
         </panstwo>
       </kontynent>
     </planeta>
   </gwiazda>
</galaktyka>


EAD jest standardem (wyrażanym w XML) opracowanym dla archiwów i jest bardzo typowym przykładem opisu hierarchicznego. Jest odbiciem typowej organizacji archiwum, gdzie kolekcja (zespół archiwalny, fonds) może byc podzielona na pod-zespoły (subfonds), te z kolei na serie, podserie, grupy, podgrupy itp. Często organizacja taka nie jest sprawą wyboru, gdy na przykłład oryginalny twórca danej kolekcji tak ją właśnie uporządkował. Zasada szacunku dla oryginalnego twórcy kolekcji (respect de fonds) wymaga pozostawienia w miarę możności oryginalnej organizacji.

Czytaj dalej „Standardy metadanych dla archiwów: płaskie czy hierarchiczne? (Cz. 2)”