Narodowe Archiwum Cyfrowe > Budowa NAC
Plan działania czyli jak to sobie wyobrażamy
Mariusz Bułkowski:
A ja się zastanawiam jakimi zasobami (ludzkimi / sprzętowymi / finansowymi) dysponują inicjatorzy pomysłu.
To po pierwsze. Czy wszystko ma zostać zrobione na zasadzie pracy wolontariuszy czy tez posiadacie własne zaplecze (ile osób?)
Czy jest ustalone (albo kiedy bedzie) czym ma być ten projekt ? Co ma robić ? Kiedy ma zostać zrealizowany ? Jakie ma spełniać wymagania .....
Czy są jakieś już projekty podobne na których mozna bazowac ?
Rafał Rufus Magryś:
Witam,
Zgodnie z sugestiami podam wszystkie dane oraz rozbije wątek na kilka. W tym momencie będzie ich 3:
1) Budowa lokalnego gui do imagemagicka - ale może napisanie nowego progsa czy dostosowanie do specyficznych potrzeb to co już jest na "rynku" - aby rozpocząć w sumie od czegoś małego, aby zobaczyć jak się nam ułoży współpraca,
2) Budowa webowego gui do imagemagicka czy do gd (jak wyżej z dostosowaniem) będzie go można wykorzystać do Zintegrowanego Systemu Zarządzania Informacją (ZoSIA) jaki planujemy wdrożyć we wszystkich archiwach,
3) Budowa systemu do zarządzania mikrofilmowaniem w Polsce jako fragment systemu ZoSIA,
Pozdrawiam
Rafał
keneida:
czy zastanawialiście się nad dopasowaniem jednego z systemów cms?
Na stronach "open library" można znaleźć info o procesie digitalizacji zasobów i tego jakich programów oni użyli
Rafał Rufus Magryś:
I jeszcze jedna uwaga NAC nie jest jednym wielki programem ale instytucją, która będzie korzystać z kilku systemów wspomagających zarządzanie danymi. Każdy projekt co zobaczycie w opisach będzie trochę inny ale zrealizuje główne zadanie wolny dostęp do polskiej kultury.
Pozdrawiam,
Rafał
thebodzio:
Bardzo ucieszyła mnie informacja o starcie projektu archiwistycznego mającego w założeniu opierać się na otwartych rozwiązaniach. Kudos! :)
Chciałem dorzucić do dyskusji kilka swoich uwag.
mikmach postawił bardzo słuszne pytanie o format, w którym będą przechowywane dane. bla z kolei zauważył, że bardzo ważną rzeczą jest kategoryzacja tych danych. Łącznie z głosem dPeS uważam te głosy za podstawowe dla całości przedsięwzięcia.
Dane są przecież w tym projekcie najważniejsze i odpowiedni dobór strategii ich digitalizacji umożliwi korzystanie z nich niezależnie od trendów w dziedzinie tworzenia oprogramowania. Sam dobór narzędzi programistycznych i aplikacji, które mają zostać przy ich pomocy stworzone jest już, śmiem to tak nazwać, wtórny po opracowaniu dokładnej specyfikacji działania cyfrowego systemu archiwalnego. IMHO specyfikacja ta powinna zawierać opis:
1. Struktury i formy gromadzonych danych (podstawowe dla dalszych działań).
2. Przewidywanych dróg obiegu danych (umożliwia zaplanowanie odpowiednich aplikacji klienckich i serwerowych).
3. Sposobu przeprowadzania digitalizacji (bardzo ścisły – określający możliwy do zastosowania sprzęt, parametry, z którymi należy dokonywać digitalizacji, sposób formułowania ewentualnego opisu).
4. Protokołów używanych w cyfrowych kanałach przetwarzania danych (umożliwia implementację niezależnych narzędzi do korzystania z zasobów archiwalnych).
5. Dokumentów zewnętrznych, na których opiera się specyfikacja, a które nie zostały włączone w jej treść aby uniknąć ich dublowania.
Wydaje mi się, że te kilka punktów wpasowuje się w ogólny plan działania zaproponowany przez dPeS.
Tyle tytułem pomysłów na ogólny kształt systemu, chciałbym się natomiast odnieść do propozycji użycia formatu png do gromadzenia zeskanowanych danych.
Pewne jest, że skanowanie będzie podstawą systemu.
png jest bardzo obiecujący jako format nieobarczony patentami niemniej jednak podobnie jak pozostałe formaty graficzne (pomijając możliwości stosowania takich czy innych przestrzeni kolorów, masek alfa itd.) służyłby do jednej rzeczy – przechowywania płaskiego obrazu strony fizycznego dokumentu. To oznacza, że aby w zeskanowanym dokumencie umieścić jego opis, czy np. jego tekst pozyskany np. metodą ocr należy użyć odpowiedniego formatu tzw. metadanych. Co do „słabego radzenia sobie png'a z danymi drukarskimi” uważam, że nie ma to najmniejszego znaczenia. Dla dzisiejszych skanerów (nie zanosi się na zmianę tego w najbliższej przyszłości) naturalną modelem kolorów jest model RGB. W przypadku większości skanerów model ten ograniczony jest przestrzenią zdefiniowaną profilem sRGB (niestety, jako, że jest to nieco „przyciasna” przestrzeń jak dla RGB). Dla „druku” z kolei przyjazny jest model CMYK (przestrzeń kolorów znów określona odpowiednim profilem) oraz modele wynikające z zastosowania poszczególnych farb drukarskich odpowiedniego systemu np. PANTONE. Konwersja z RGB do np. CMYK w przypadku przechowywania skanowanych dokumentów mijałaby się jednak z celem, gdyż taka konwersja mogłaby pociągnąć za sobą porzucenie lub degenerację części informacji o kolorze. Dlatego uważam, że przestrzeń RGB jest odpowiednia do przechowywania zeskanowanych danych.
Drugą sprawą, którą należy rozważyć poza otwartością danego formatu jest też jego ekonomiczność w porównaniu z pozostałymi formatami. Bardzo ważna jest przestrzeń, którą te same dane zajmują w pamięci masowej w różnych reprezentacjach. Do wyboru mamy formaty stratne i bezstratne. Główną zaletą bezstratnych jest dokładność, a wadą rozmiary. Odwrotnie jest w przypadku formatów stratnych. Z moich doświadczeń wynika, że do przechowywania zeskanowanych obrazów jak najbardziej nadają się formaty stratne o ile tylko próg określający odrzucanie części informacji jest odpowiednio ustawiony. Świetnie radzi sobie w takim wypadku np. JPEG2K, czy w ogóle formaty oparte na kompresji falkowej.
W końcu należy pamiętać, że często dokumenty archiwalne są wielostronicowe. To oznacza, że należy zachować przy digitalizacji również informację o stronach. Można ją umieścić w metadanych, można również wykorzystać natywne możliwości formatu. Możliwość przechowywania dokumentów wielostronicowych posiadają np. TIFF, PDF czy DjVu. TIFF jest formatem bezstratnym i potencjalnie wymagającym rozmiarowo. Poza tym umieszczanie w nim np. hiperlinków jest problematyczne. Z tej trójki PDF i DjVu mogą reprezentować wielostronicowe dokumenty, zawierać hiperlinki, spisy treści itp. Obydwa posiadają otwarte specyfikacje. Ich podstawową różnicą jest to, że PDF został stworzony przede wszystkim jako kontener dla poligrafii natomiast DjVu od początku był pomyślany jako format archiwizacyjny. Istotnie posiada on wiele zalet predestynujących go do takich zastosowań.
Nie chcę już przedłużać tego i tak długaśnego postu, ale konkludując chciałbym zaproponować właśnie DjVu jako format przechowywania zeskanowanych materiałów. Robię to tym chętniej, że istnieją narzędzia na licencji GPL pozwalające na tworzenie dokumentów DjVu i korzystanie z dobrodziejstw tego formatu.
Nawigacja
[#] Następna strona
Idź do wersji pełnej