IFAR
Narodowe Archiwum Cyfrowe => Budowa NAC => Wątek zaczęty przez: Rafał Rufus Magryś w Wrzesień 11, 2007,
-
Witajcie,
I stało się - prawie oficjalnie rozpoczynamy tworzenie Narodowego Archiwum Cyfrowego. Niezmiernie cieszę się, jako gorący zwolennik opensource, że będzimy opierali NAC o otwarte standardy i tworzyli otwarte systemy dla NAC.
W tym momencie chciałbym zarysować wstępne etapy rozwoju projektu i czekać też na Wasze propozycje - myślę, że wymiana wiedzy będzie stanowiło podstawę naszych działań :)...:
1) Chcielibyśmy przy Waszym wsparciu zbudować społeczność która wspomoże budowę NAC przez stworznie unikalnych na skalę światową rozwiązań,
2) Tworzenie oprogramowania:
a) Myślę, że należałoby zacząć od czegoś prostego np. interfejsu do imagemagick
np. w gtk2 żeby był dostępny na wiele platform (zadania: wsadowe
przetwarzanie wielkich i wieluset plików: skalowanie, zmiana formatu,
dodawanie znaku wodnego) - kod byłby dostępny na powstającej stronie NAC w dziale "wolne
oprogramowanie". Przy tej okazji chcielibyśmy zebrać grupę ludzi, którzy będą liderami kolejnych projektów,
b) system zarządzania procesem digitalizacji mikrofilmów w Polsce - rozwiązanie
sieciowe typu klient-serwer ale być może udałoby się to rozwinąć o jakąś
technologię z pożytkiem dla wszystkich rozwiązań open source,
c) system ZoSIA (Zintegrowany System Informacji Archiwalnej) oparty na
światowych standardach archiwalnych (EAD, EAG, EAC, METS etc.) oraz
informatycznych (XML + jakiś wolny język programowania) do implementacji w Archiwach Państwowych i jako open source dostępny dla wszystkich zainteresowanych. System ma pomoć w odejściu od MS Access ktory stanowi jednyną przeszkodę do wdrożenia np. OpenOffice'a w tych instytycjach
d) późniejsza rozbudowa systemu wzbogacanie go o nowe funkcje (może nawet obieg
dokumentów w instytucji np.?),
Obszernie na temat tworzenia NAC w oparciu o open source będę mówił podczas tegorocznej "Jesieni linuxowej" w Rybniku (jeszcze mnie nie ma w agendzie ale dziś jutro powinienem się tam znaleźć).
Wkrótce kolejne wiadomości - bo dzień bez newsa o NAC to dzień stracony... :)
Pozdrawiam,
P.S. jabber do kontaktów: laforza@linux.pl
skype: rufiozol
-
Jesli przydalby sie Wam programista C++ to jestem do dyspozycji.
pozdrawiam
piotr
-
Witam,
chciałbym pogratulować pomysłu, życzyć sukcesu i dodać swoje 3 grosze do początkowej dyskusji, a mianowicie
dodać komentarz do punktu 2)...
Zazwyczaj przy takich projektach programistycznych na początku rozważań wypada ustalić język programowania, w którym będą realizowane poszczególne fragmenty całości. Jeśli taki nie jest oczywiście odgórnie narzucony ;). Żeby nie okazało się potem, że każdy kawałek jest w czym innym, bo integracji to nie pomoże...
Wziąłbym pod uwagę przy wyborze:
a) Grono osób władających tym językiem (ok, lubię OCaml, ale kto w nim będzie programował?)
b) To czy język pasuje do konkretnego zadania, a więc:
* Jego szybkość,
* Dostępność bibliotek.
* Poziom abstrakcji języka.
d) Przenośność między systemami operacyjnymi
I biorąc pod uwagę powyższe, osobiście zaproponowałbym Pythona, wszędzie tam gdzie szybkość języka nie gra głównej roli. (Ma ogromny zasób gotowych bibliotek, wysoki poziom abstrakcji, szybko się w nim pisze, jest przejrzysty i bardzo przenośny). IMHO do oprogramowania imagemagick nadał by się znakomicie.
Wszędzie tam gdzie szybkość odgrywa decydującą rolę użyłbym C lub ostatecznie C++. Bibliotek - pełno, stanowi praktycznie lingua franca wolnego oprogramowania. Choć oprogramowanie, a szczególnie jakieś nakładki GUI na istniejące narzędzia, tworzyć będzie się w nim wolniej niż w Pythonie...
Jakieś komentarze? :)
Pozdrawiam,
Tomasz bla Fortuna
(Jabber Id: bla at af.gliwice.pl)
-
Powitać wszystkich,
Moje kilka uwag :
1. fajno, że projekt jest z założenia otwarty ale jeśli ma brać w nim większa liczba ludzi to dobrze byłoby wiedzieć kilka rzeczy :
- czym dysponujemy (dostepny sprzet - także taki który to wszystko wczyta, poinstalowany soft) ?
- co jest do zrobienia (orientacyjna ilość danych - nikt ,,z internetu'' nie wie tak naprawde ,,o co chodzi'') ?
- jaki jest czasowy plan prac tudzież jak to widzą decydenci (ile czasu na projekt, etc...) ?
... (tu zapewne będzie masa kolejnych pytań - moim zdaniem dla każdego takiego zagadnienia trzeba by zrobić oddzielny wątek)
2. na ogół projekt ma takie dość ważne etapy :
- opracowanie koncepcji - czyli odpowiedź na pytania - co trzeba zrobić? kto to będzie robił? ile czasu mu to zajmie? (tu również powstaje czasowy plan działania)
- stworzenie projektu - czyli odpowiedź na pytanie JAK zrobić to co zostało ustalone wyżej ???
(mały przyład : jeśli klikaniem będzie się zajmowała mało obeznana osoba to tworzenie gui dla narzędzi konsolowych mija się z celem bo i tak parametry będą ustalane ,,na sztywno'' i lepiej byłoby zrobić formatkę z kilkoma przyciskami odpalającymi skrypty, które np same się aktualizują przez sieć - słowem brakuje KONCEPCJI I PLANU)
- implementacja - jak już będzie wiadomo co, jak i gdzie ma działać można brać się do roboty - to w jakim języku co i jak pisać można będzie powiedzieć dopiero po długich rozmowach i stworzeniu projektu
- testy i WDROŻENIE od którego tak naprawde będzie zależało wrażenie jakie zostawią otwarte standardy i oprogramowanie...
warto też zapoznać się z opisami wdrożeń, których w sieci jest sporo (są również poradniki jak prowadzić otwarte projekty programistyczne)
dPeS
-
Witam,
Bardzo dziękuję za poważne potraktowanie tematu. Chcieliśmy rozpocząć już całą akcję, żeby się działo i się nie zmieniło. Do poniedziałku (17 września, ale pewnie wcześniej) powstaną wszystkie opisy, oraz zostaną uruchomione również odpowiednie narzędzia.
W tym momencie cieszę się bardzo, że jest spora grupa, która będzie wspomagała NAC.
Damy radę... I NIE MA INNEJ OPCJI... ;)...
Pozdrawiam
-
Co z formatem przechowywania plików cyfrowych? W pełni Open Source jest PNG, ale o ile się nie mylę są problemy z dołączaniem informacji "drukarskich".
Jakie metadane? EXIF można chyba sobie darować, IPTC szeroko wspierany, ale powoli odchodzi do lamusa. XMP to a) dopiero wchodzi w szersze użycie b) to tylko kontener, w jego ramach nadal trzeba wybrać jakiś standard: IPTC Core, Dublin Core czy coś bardziej specjalistycznego?
Czy jest sens wyważać otwarte (częściowo) drzwi i pisać od zera program? W dodatku taki program powinien nie tylko pozwalać na podstawowe operacje na plikach, ale i szersze zarządzanie. Jest już obecnie kilka dostępnych, a za kilka miesięcy na MS-Windows wachlarz aplikacji będzie jeszcze szerszy kiedy w końcu programy na KDE będą tam normalnie działać (Digikam, Kphotoalbum).
-
Co z formatem przechowywania plików cyfrowych? W pełni Open Source jest PNG, ale o ile się nie mylę są problemy z dołączaniem informacji "drukarskich".
Dla ułatwienia przeszukiwania plików (jakiekolwiek one by nie były tekstowe, graficzne) część danych można trzymać w bazie danych. W tym wszystkie, które mógłby zawierać taki nagłówek. Wtedy niezależnie od rodzaju pliku masz ujednolicony interfejs dostępu do autora, daty powstania, zaarchiwizowania; wszystkiego co by było potrzebne.
Myślałem czy w ogóle do tego brać bazę danych...:
1) Zbiór plików na nośniku
2) Zbiór plików indeksowany w bazie danych
3) Baza danych z danymi binarnymi + opisem
Ale takie coś już nie raz nie dwa sprawdzili w praktyce i na pewno wiadomo jak każdy przypadek by działał. (Mi się najbardziej podoba 2).
4) Rozważał ktoś zastosowanie repozytoriów? Myślałem czy da się tutaj do czegoś wykorzystać GITa. Ale prócz rozwoju aplikacji do zarządzania archiwum chyba się nie przyda...
dPeS dobrze mówi, że warto zacząć od ogólnego opisu tego co chce się stworzyć. Zbioru założeń, opisu potrzebnych interfejsów i podsumowania dostępnego materiału. Może jakieś WIKI? Forum to jedno... Potem (lub równolegle!) można dyskutować takie techniczne szczegóły. Można by drugi wątek założyć... ;-) Ja o technikaliach chętnie porozmawiam, a w ogóle założenia mieszałbym się z rozwagą (archiwistyki nie kończyłem; choć mam znajomego, którego mogę męczyć).
Pozdrawiam,
-
jeśli byście potrzebowali administratora do serwerów linuxowych to służę radą i pomocą.
Nie jestem może mistrzem programowania, ale co nie co o tworzeniu projektów wiem. I naprawdę radzę starannie wybrać platformę na jakiej będzie to tworzone. Dobrze by było wiedzieć na jakie zaplecze możecie liczyć. Co macie na początek? Na jaką pomoc możecie liczyć? Zrobienie ankiety na temat umiejętności ochotników dałoby wam obraz sytuacji kto bierze udział w projekcie:
Ilu ich jest?
jakie mają umiejętności?
wiek
można by było wstępnie wyłonić osoby które mają predyspozycje do kierowania teamami - ankieta musiałby być dobrze zrobiona.
-
Myślałem czy w ogóle do tego brać bazę danych...:
2) Zbiór plików indeksowany w bazie danych
Jakaś forma bazy danych jest niezbędna. Choćby po to by można ją sobie można było ściągnąć i robić kwerendy niezależnie od samych plików przedstawiających archiwa. Patrzę w tej chwili od strony potrzeb użytkownika. To zresztą osobna kwestia. Dla kogo obecnie jest ten projekt? Czy ma ułatwić pracę archiwistom, czy ostatecznym użytkownikom archiwów?
dPeS dobrze mówi, że warto zacząć od ogólnego opisu tego co chce się stworzyć. Zbioru założeń, opisu potrzebnych interfejsów i podsumowania dostępnego materiału.
Pełna zgoda. OP był dość ogólnikowy. Szczegółów, szczegółów :)
-
(...) I stało się - prawie oficjalnie rozpoczynamy tworzenie Narodowego Archiwum Cyfrowego. Niezmiernie cieszę się, jako gorący zwolennik opensource, że będzimy opierali NAC o otwarte standardy i tworzyli otwarte systemy dla NAC.(...)
Świetnie, że ruszacie z tym projektem. Bibliotekarze 2.0 zaczynają Wam kibicować :) (zob. wątek archiwiści robią to w NAC (http://forum.biblioteka20.pl/viewtopic.php?p=968#968)). Mam przy okazji pytanie. Czy zamierzacie udostępniać oraz zbierać metadane przez OAI-PMH? Umożliwiłoby to zintegrowanie bibliotek cyfrowych z NAC oraz usprawniłoby przeszukiwanie większego zasobu cyfrowego. Czekam z niecierpliwością na szczegółowe opisy projektu.
-
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 ?
-
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ł
-
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
-
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ł
-
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.
-
istnieją narzędzia na licencji GPL pozwalające na tworzenie dokumentów DjVu i korzystanie z dobrodziejstw tego formatu.
A moglbys podac nazwy tych narzędzi i ew. linki do stron.
-
A moglbys podac nazwy tych narzędzi i ew. linki do stron.
To może wyręczę: http://djvu.org/links/
Najbardziej interesującym projektem wydaje się DjVuLibre.
-
Witam,
Djvu to fajny format ale wolna implemetacja (wg moich testów) jest wolna. Zastrzegam, że testowałem wcześniejsze wersje. (Pliki wyjściowe jpegi rozmiar 3-4mb, czas produkcji djvu ok. 5 minut na plik).
Pozdrawiam,
-
Djvu jest mocno stratnym formatem. Wg mnie najlepsze byłoby archiwum dwupoziomowe:
1) wysokiej jakości zdjęcia/skany w PNG/TIFF, plik na stronę opisany metadanymi; obraz poddany minimalnej obróbce graficznej, z miarką, kolorystycznym paskiem kalibracyjnym.
2) opracowane w pewnym stopniu dokumenty PDF/DjVu, wielostronicowe w jednym pliku, itd.
W ten sposób badacze potrzebujący wielu informacji o warstwie zewnętrznej źródła mobliby wykorzystać warstwę pierwszą, wszystkim innym możnaby udostępnić warstwę drugą jednocześnie oszczędzając pasmo.
-
W przypadku posiadania odpowiedniej ilości mocy przerobowej (hmmm... BOINC (http://boinc.berkeley.edu/), microwulf (http://www.calvin.edu/~adams/research/microwulf/)?), żadna konwersja nie jest straszna ;) DjVu jest kilkukrotnie szybszy w odczycie niż PDF czy nawet JPEG. No i fakt, że został specjalnie zaprojektowany dla celów archiwalnych chyba jednak coś znaczy?
Pomysł z dwupoziomowym archiwum nie jest zły.
Co do samego procesu digitalizacji, to popieram opinię, żeby brać przykład z OpenLibrary i Internet Archive.
Jeśli natomiast chodzi o późniejsze udostępnianie - proponuję torrent, żeby możliwie odciążyć serwery. W ten sposób w najgorszym razie użytkownik będzie pobierał bezpośrednio z Archiwum, jeśli nikt inny nie będzie miał danego pliku u siebie. W ten sposób można też łatwo rozdzielić transfer na kilka serwerów umieszczonych w kraju. Opera już ma klient torrentów, Firefox ma wtyczkę. Niedługo torrent będzie standardem pobierania plików z sieci, bo ściąganie indywidualne jest po prostu nieekonomiczne. To jednak w odleglejszej przyszłości.
Poza tym trzymam kciuki i deklaruję pomoc w miarę możliwości oraz promocję wśród młodzieży stale.
-
Jeśli wybierzecie bit torrent musicie zdawać sobie sprawę z kilku rzeczy:
*im więcej osób ściąga i wysyła daną rzecz tym mniejsze wykorzystanie serwera głównego (+)
*kwestia mirrorowania - jeśli by istniało kilka serwerów na których by były te pliki udostępniane można te same dane ściągać z kilku serwerów naraz. Pada jeden nic wielkiego z udostępnianiem plików się nie dzieje, ludzie nadal mogą to ściągać (+)
*jeśli będziecie popularni mogą ze względu na używanie bit torrenta wykorzystać w wojnie pomiędzy piratami i organizacjami takimi jak ZAiKS (-)
*duża ilość plików hostowana przy użyciu bit torrenta skutecznie zabija serwer (-)
Bit torrent idealnie nadaje się do rozprowadzania dużych plików lub dużej ilości kopi naraz - serwery wysyłają dane pomiędzy sobą - ale rozprowadanie małych plików to zabijanie serwera.
Kolejna ważna kwestia:
Jakie rzeczy chcecie archiwizować ?
Należy jasno i precyzyjnie określić jakie pliki mogą być archiwizowane, a jakie nie. Bo jak ludzie będą archiwizować dobra kulturalne polskiej kinematografii i muzyki, to zostanie warezem z polskimi filmami i muzyką, przy okazji wymiatając mniejsze strony tego typu. Lekkie rozeznanie w tej materii mam i jeśli będą tutaj filmy to przyciągniecie rzesze piratów.
A teraz istotna rzecz:
Miejsce. Takie archiwa potrzebują znaczne ilości miejsca na dysku. Jaki macie pomysł na to? - Ten problem będzie wracał jak bumerang.
-
Witam,
Pozwolę sobie na odniesienie się do uwag jakie się tu pojawiły. Po pierwsze jak zauważyliście powoli zaczynają się pojawiać informacje na temat tego co jest potrzebne w tym momencie dla NAC w dziale bezpośrednio dotyczącym tego zagadnienia.
Już niedługo (gdzieś koło soboty) pojawią się informacje dokładnie jak wydzimy zasadę działania NAC (w aspekcie technicznym).
Co do samego procesu digitalizacji to akurat on nie jest problemem mamy kadry (oczywiście za mało) i specjalistów którzy na formatach plików do archiwizacji potracili zęby. Znamy też z oglądu na żywo czy z netu najważniesze sprawy związane z tą materią, ale cieszę się, że pomagacie i poddajecie wartościowe informacje.
Naszą piętą achillesową jest oprogramowanie. W tym momencie Apy (archiwa państwowe) pracują na rozproszonych bazach danych które zazebiają się informacyjnie ze sobą ale nie technicznie i często należy uzupełniać jedną informacje po koleji w kilku bazach jednocześnie. Nie będę też wspominał o komforcie pracy na Accesie oraz innych licencyjnych problemach... w każdym razie jeśli chodzi o problemy to można je mnożyć w nieskończoność. System główny z jakiego będą korzystać i archiwiści i userzy (przez wyszukiwanie informacji w zasobie APów) w pierwszej fazie powstanie ze scalenia i konwersji danych z baz accessowych. Bazy te zawierają w tym momencie ponad 5 milionów rekordów. No ale o tym szerzej w głównych założeniach...
Co będziemy udostępniać? Głównie opis wzbogacane obrazami - tak więc chyba, podkreślam chyba bittorrent nie będzie tu się sprawdzał.
Jak musimy składować aby było to zgodnie ze sztuką? Conajmniej dwie wersje plików jedna kopia matka w tiff (gdzie mamy doczynienia z formatem o znanej specyfikacji i bezstratnym) trafia do głównego archiwum NAC, druga użytkowa stanowi podstawę do dalszej pracy czy/i stanowi podstawę do wypuszczania kolejnych np. wglądowek (ze znakiem wodnym).
Jak będzimy trzymać dane w systemie? Osobno opisy materiałów archiwalnych (np. kto wytworzył, zawartość akt), osobno metadane obrazów (rozmiar, rozdzielczość) i osobno same obrazy.
Czy będziemy mirrorować? Tak w kilku archiwach w Polsce,
Czy Djvu będziemy używać? W tym moemencie nie wiem jeszcze, obawiam się tylko niecheci userów którzy będą musieli doinstalować coś aby oglądać djvu, i wciąż uważam, że to format dla biliotekarzy,
to na tyle w tym miejscu - sukcesywnie będą się pojawiały nowe informacje o potrzebach projektach etc.będźcie w kontakcie! :)
pozdrawiam,
Rafał
P.S. Patrząc na tego posta muszę czem prędzej zrobić FAQ NAC :)
-
Rufus, co rozumiesz przez "format dla bibliotekarzy"? Przecież podobnie jak PDF został stworzony do przechowywania wszystkiego, co drukowane. Na djvu.pl są świetne przykłady map w tym formacie. Proponuję przełączyć widok na czarno-biały, by docenić ten format. Doszukałem się kiedyś przecudnych kopii starodruków w tym formacie. Fantastycznie zdobiony Koran zajmował kilka skromnych megabajtów. Same jpgi zajmowałyby kilkakrotnie więcej, podobnie z resztą jak pdfy. DjVu może tworzy się wolno, ale są pewne powody (z resztą, komu ja to tłumaczę? :P). Wykonywane jest np. wydzielanie warstw danych i przeprowadzany jest OCR. Dzięki temu korzystanie z tak przygotowanych danych jest czystą przyjemnością, bo łatwo można wszystko wyszukać - w przypadku map jest dość pomocne, szczególnie że np. nazwy rzek mogą się wyginać wraz z rzeką, a i tak są rozpoznawane i udostępniane do szukania. Już nie wspominam o tym, że jakieś programy (np. kartograficzne czy CAD) mogłyby eksportować dane bezpośrednio w DjVu.
Wspomnianym już wcześniej kolejnym argumentem za DjVu jest rozmiar. Wczoraj trafiłem na stronę jakiegoś archiwum, gdzie różnica między plikami DjVu, a PDF była ~ sześciokrotna. Przy zwykłym tekście. Przy tekście z grafiką te różnice mogą być wręcz powalające. Do tego dochodzi jeszcze szybkość. Weźmy pliki djvu i pdf z taką samą zawartością, np. Biblią, i spróbujmy przejść ze strony tytułowej prosto do Apokalipsy. Ładnych "kilka" stron, prawda? Kto pracował z dużymi tekstami w pdf wie czym to skutkuje. Szczególnie na starszym sprzęcie. Jeszcze korzystniej DjVu wypada przy przeglądaniu przez sieć, bo nie musi być cały wczytany, by mieć możliwość skoku na koniec, bo każdą stronę można wczytać niezależnie.
Czekam na konkretne argumenty przeciwko DjVu. Tylko błagam, nie szybkość przerabiania czy stratność formatu. Stratność można sobie ustalić, a szybkość tworzenia jest niczym przy późniejszej wygodzie korzystania. Jeszcze kwestia wtyczki. Jak chcę oglądać filmiki/animacje Flash, to instaluję wtyczkę. Jak chcę czytać PDF, instaluję Acrobata. Chcę oglądać film kodowany w x264 czy Theora - instaluję kodeka. Dlaczego jak ktoś chciałby skorzystać z zasobów NAC, nie może sobie zainstalować wtyczki do DjVu? Naprawdę nie widzę problemu.
-
Reaktywując się na forum pozwolę sobie na kilka uwag:
przepraszam że wziąłem część z innego mojego postu który jest tu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=840.0
ale nie chce mi się jeszcze raz pisać.
w tej kwestii:
Bo jak ludzie będą archiwizować dobra kulturalne polskiej kinematografii i muzyki, to zostanie warezem z polskimi filmami i muzyką, przy okazji wymiatając mniejsze strony tego typu. Lekkie rozeznanie w tej materii mam i jeśli będą tutaj filmy to przyciągniecie rzesze piratów.
A teraz istotna rzecz:
Miejsce. Takie archiwa potrzebują znaczne ilości miejsca na dysku. Jaki macie pomysł na to? - Ten problem będzie wracał jak bumerang.
Otóż w Planie Informatyzacji Państwa
w części 7g PIP mamy:
"Opracowanie metodologii i prezentacji zasobów archiwalnych audio i wideo oraz udostępnianie ich na nośnikach informacji i przez Internet wraz z cyfryzacją zasobów archiwalnych" na co jest czas do grudnia 2009.
Co ważne, to zadanie wpisane jest z konkretnymi pieniędzmi w "Tabela 2. Zestawienie i charakterystyka sektorowych projektów teleinformatycznych" pt. PREZENTACJA I UDOSTĘPNIANIE ZASOBÓW ARCHIWALNYCH AUDIO I WIDEO. na to w latach 2007-2010 ma być przeznaczone 97 mln zł (15 % budżet państwa, 85 % Europejski Fundusz Rozwoju Regionalnego). To zresztą pokazuje jaką siłę przebicia mają ... inni. Oby NAC dostało (dodatkowo do tego co dotąd ADM!) choć połowę tych środków co Filmoteka Narodowa...
W kwestii formatów plików, metadanych, zarządzania w długim czasie, jakości itd... tematów poruszanych w tym wątku
PIP nakłada także inne obowiązki:
"Tabela 1. Działania w zakresie rozwoju społeczeństwa informacyjnego" w części 7a:
"Opracowanie metodologii archiwizacji cyfrowej (digitalizacji) różnego rodzaju zasobów archiwalnych, bibliotecznych i muzealnych oraz innych dokumentacji związanych z zabytkami, a także sposobów udostępniania ich w wersji cyfrowej. " Plan zakłada że zdarzy się to do końca czerwca 2007 (a więc mamy już kwartał opóźnienia).
Przypominam, że pracuje nad tym Zespół ds Digitalizacji powołany przez MKiDN który ma taką strategię digitalizacji przygotować - czyli odpowiedzieć na pytania co digitalizować i po co, a także w jaki sposób, za pomocą jakiego sprzętu, jakie wymagania techniczne dotyczące jakości (rozdzielczość, głębia bitowa, jakość koloru, częstotliwość próbkowania) formatów, metadanych (technicznych, opisowych, administracyjnych i "behawioralnych") itd. Nie będę jednak wieszał na nim psów bo sam jestem członkiem a problem jest bardzo złożony...
Co do pracy zespołu roboczego w zakresie standardów metadanych opisowych to była krótka piłka:
bibliotekarze mówili MARC, archiwiści EAD, muzealnicy SSWIM, a niżej podpisany złożył zdanie odrębne.
Otóż jak pokazuje praktyka krzyżują się dwa podejścia a mianowicie
- takie które zajmuje się tylko digitalizacją tego co już jest w bibliotekach i archiwach
- i takie które dotyczy archiwizacji dokumentów elektronicznych powstałych w wyniku działania podmiotów zewnętrznych.
Na razie są to działania osobne ale planując digitalizacje materiału analogowego trudno nie dostrzegać także i tego, że jednocześnie powstają obiekty cyfrowe nie mające "tradycyjnego" pierwowzoru. Można też przypuszczać, że dla użytkownika archiwów i bibliotek w niedalekiej przyszłości nie będzie istotne czy informacja do której dotarł, powstała najpierw w postaci analogowej czy cyfrowej. Ważna będzie treść informacji, jej wiarygodność oraz możliwość szybkiego odnalezienia. I szlag go trafi jeśli dla dokumentów elektronicznych powstałych od razu w takiej formie będzie miał inne zasady wyszukiwania, dostępu itd a dla tych zdigitalizowanych - inne. Prędzej czy później więc trzeba będzie znaleźć wspólny mianownik dla dokumentów elektronicznych - niezależnie od ich pochodzenia. Oczywiście można olać problem i stwierdzić że jak dotąd "rekordy" złapane przez bibliotekę opisuje się w MARC21 a przez archiwum w ISAD(G) (dla wielu: czytaj EAD). Obojętnie czy jest to film w MPEG4 (obojętnie czy tak powstały in statu nascendi czy w wyniku digitalizacji) czy też "strategia informatyzacji RP" w PDF-ie czy zeskanowane listy Cypriana Kamila Norwida bibliotekarze opiszą to w MARC21 a archiwiści w EAD... Prawda, że to byłoby co najmniej dyskusyjne? Więcej na tym forum już o tym pisałem np. tu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=626.0
Co do pracy zespołu roboczego w zakresie standardów technicznych to po zebraniu materiałów dotyczących tego co robią inni okazało się, że nie ma tu jakichś najlepszych rozwiązań, które można po prostu wskazać. Oczywiście są i tacy którzy zdecydowanie opowiadają się za konkretnymi przykładami (celowo nie podam jakie żeby nie zaogniać).
Rzucę garść problemów:
Otóż w zakresie standardów technicznych ważna jest specyfikacja techniczna dotycząca nie tylko samych plików (to w miarę proste) ale także (a może przede wszystkim) metadanych (technicznych, administracyjnych i behawioralnych).
Wszystko jest fajnie jak trzymamy nasze kopie cyfrowe uporządkowane np tak: jeden folder zawiera jedną pozycję książkową mającą 200 stron. Każda strona to osobny TIFF (wszyscy go kochają a więc i u nas tak będzie - zapomnijcie o PNG!). Skąd wiemy która jest która? Będziemy nadawać odpowiednie nazwy plikom?. Jeśli nie rozwiążemy tego problemu (metadane behawioralne) to nie da się automatycznie tworzyć np przeglądowych PDF-ów (czy jak kto woli DjVu). Tylko czy nasz "folder" będziemy w stanie utrzymać przez długo czas? A kto powiedział, że "foldery" w ogóle mają być ? A może po prostu zrobić to tak, że w każdym pliku zapisać metadane wskazujące do jakiej pozycji należy i jaka jest przed a jaka po... a może nie - tylko zapisać to w osobnym miejscu?
Oczywistym są postulaty żeby (tylko tam gdzie kolor lub odcienie szarości są ważne) skanować materiał wraz z wzorcem koloru lub szarości (jakim)? I tu pytanie: czy użytkownik cały czas ma widzieć ten wzorzec? Zwłaszcza w postaci przeglądowej mogłoby to go denerwować. A więc czy oprogramowanie NAC o którym tu już była mowa nie powinno umieć takiej "linijki" wycinać "w locie" przy przetwarzaniu masowym (wsadowym) do formatu przeglądowego? Przy okazji: może mi ktoś doradzi w jaki sposób ten wzorzec kłaść (może na jakim "czerwonym suknie" - w odróżnieniu od białego tła ... reszty tła) żeby oprogramowanie radziło sobie łatwo z "wycinaniem" wzorca? Inaczej będziemy mieli robotę głupiego dla ludzi. Robotę która kosztuje. Jeśli teraz pomyślimy nad standardowym tłem dla wzorca i standardowym miejscem jego umieszczania to może potem będzie taniej...
Kolejny problem to wiarygodność naszych skanów. I tu dochodzi problem tzw. "preservation metadata", które będą potrzebne aby pokazać historię powstania i przenoszenia danych... I te powinny być na zewnątrz obiektów cyfrowych które opisują, po prostu po to aby nie naruszać ich integralności.
Część metadanych technicznych z cała pewnością będzie zapisana bezpośrednio w plikach obrazów bez względu na to czy tego chcemy czy nie. Jeśli urządzenie będzie zapisywało w EXIF to z cała pewnością powinniśmy takie metadane zachować. Dla wiarygodności naszych kopii cyfrowych mogą to być istotne informacje a ich zachowanie nic nie kosztuje. Dlaczego jednak mielibyśmy to jeszcze wyprowadzać na zewnątrz? Wbrew pozorom to jest też ważne pytanie...
itd itp...
przepraszam ale może lepiej wrócę do pracy dla Zespołu ds Digitalizacji... bo tam trzeba coś konkretnego i do tego jeszcze wykonalnego zaproponować
aha, pewnie już tam byliście nie raz, ale jeśli nie to rzućcie okiem tu:
http://www.loc.gov/premis/ (standard metadanych do długoterminowego przechowywania obiektów cyfrowych)
i tu
www.loc.gov/mix (standard matadanych technicznych do obrazów rastrowych - także norma NISO)
a potem koniecznie tu:
http://www.prov.vic.gov.au/vers/vers/default.htm (cała polityka przechowywania dokumentów elektronicznych)
i zobaczyć w samej specyfikacji metadanych która jest tu: http://www.prov.vic.gov.au/vers/standard/pdf/99-7-2_Std_ver2-0.pdf jakich elementów VERS nie uwzględnia a które były w "NAA recordkeeping metadata standard" wymienione...
jak jeszcze dołozymy doń to:
www.archives.gov/research/arc/digitizing-archival-materials.html
http://memory.loc.gov/ammem/about/techStandards.pdf
http://www.nla.gov.au/digital/standards.html
to zobaczymy jakże wiele spraw jest do ustalenia.
Oczywiście można podejść do problemu standardów jak Australijczycy z instytutu od Aborygenów:
http://www.aiatsis.gov.au/__data/assets/pdf_file/7034/Technical_Standards_inc_video_V8.pdf
krótko, węzłowato i na temat... no nie?
albo (jak zwykle w Polsce) poczekać na to co zrobią Amerykanie... czy też przetłumaczyć ogłoszony przed 3 laty materiał NARA i wskazać jako wskazówki obowiązujące....
i w takim otoczeniu działa (działać ma) NAC :))))
trzeba życzyć powodzenia i wpisania do kolejnego planu informatyzacji państwa z kwotą nie mniejszą niż na Filmotekę Narodową - co niniejszym czynię.
-
Minder,
Chyba zastosowałem za duże uproszczenie - dla bibliotekarzy (ale nie tylko) bo ma całe mnóstwo "ficzerów" dla nich dobrych czyli właśnie OCR (niemożliwy w archiwach jakie mają w 85% zasób pisany ręcznie) warstwy (niejednorodne tła w archiwaliach generują kosmiczne problemy z ich wydobyciem). Z tego co się orientuje i co twórcy sami piszą na stronie Djvulibre (a więc wolnego Djvu): " Decoders and simple/experimental encoders are open sourced and included in DjVuLibre, but the best encoders (as of today) are owned by LizardTech Inc and kept proprietary". Pewnie w jakiejś części w NAC wykorzystamy zamknięte oprogramowanie (to nawet będzie zgodne z filozofią testowania nowych technologii) ale na razie nie możemy już na starcie korzystać z zamkniętego jeśli chodzi o wykorzystanie "przemysłowe" standardu... Możemy zrobić inaczej: pod egidą NAC powłać projekt optymalizacji i rozwoju Djvulibre, jeśli zbierzmyu grupę ludzi gotową się w to zaangażować...
Pozdrawiam
-
Rafale,
"projekt optymalizacji i rozwoju Djvulibre" brzmi tak ambitnie, że może tez warto zapytać czy takie zadanie realizowane "pod egidą NAC" w ogóle powinno być rozpatrywane? A może nie złapałem dokładnie o co chodzi?
Zgadzam się Minderem że "Jak chcę czytać PDF, instaluję Acrobata. Chcę oglądać film kodowany w x264 czy Theora - instaluję kodeka. Dlaczego jak ktoś chciałby skorzystać z zasobów NAC, nie może sobie zainstalować wtyczki do DjVu?"
Z całą pewnością format przeglądowy musi być nie tylko "lekki" ale też przede wszystkim dobrze rozpowszechniony. Po to żeby nie zostać z ręką w nocniku gdy okaże się że nie ma rynku wsparcia (bo nie ma już kodeków do zainstalowania które użytkownicy "sobie wezmą"). A wtedy trzeba będzie z takiego formatu uciekać. Bez względu na to czy rozwinęliśmy Djvulibre czy nie.
Jak się wydaje i PDF jest już wystarczająco rozpowszechniony, żeby nie musieć wchodzić w nieśmiertelnego JPEGa którym trudno się zarządza (bo aby prezentować cały dokument wielostronicowy trzeba wielu plików) i jest znacznie "cięższy". Z całą pewnością więc wsparcie dla PDF-a będzie więc i za 20-30 lat dostępne. Czy możemy to samo powiedzieć o DjVu? Porównując do formatów analogowych: w swoim czasie na rynku "przeglądowym" walczyły gorszy VHS i lepszy Hi8. Wygrał gorszy VHS. I dziś można go ciągle łatwo odtwarzać.
Jeśli nawet odpowiemy sobie na pytanie że DjVu jest już OK i ludzie go powszechnie używają to nie znaczy żeby samemu rozwijać DjVuLibre. Najpilniejszym zadaniem wydaje się bowiem oprogramowanie do zarządzania tym co wyprodukujemy. Oprogramowanie które poradzi sobie z najróżniejszymi metadanymi, a może nawet (jak sądzą niektórzy) będzie umiało jeszcze "wyczesać" metadane z plików TIFF (tak jak robi to np. JHOVE zob. http://hul.harvard.edu/jhove/ ) aby potem można było zarządzać nimi niezależnie od plików.
A swoją drogą dlaczego w najróżniejszych wskazówkach publikowanych przez duże instytucje jako format prezentacyjny ciągle króluje JPEG? Przyzwyczajenie? Zespoły wskazujące na zastosowanie tego formatu nie znały innych?
O DjVu nie pytam jednak bez kozery. Otóż trwają prace nad nowelizacją Rozporządzenia Rady Ministrów w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2005 Nr 212 poz. 1766). Do końca września trzeba przekazać do Departamentu Informatyzacji MSWiA propozycje zmian do obecnej wersji rozporządzeń (NDAP jest w rozdzielniku). Zajrzyjcie więc drodzy Forumowicze do załącznika 2 do tego rozporządzenia i zobaczcie co teraz jest wpisane do "danych zawierających informację graficzną" a co do "danych zawierających dokumenty tekstowe i tekstowo-graficzne". I tam nie ma DjVu. Czy przy okazji prac nad nowelizacją należy sugerować jego dopisanie? I jak to uzasadnić. I to nie jest takie sobie pytanie bo jeśli potem instytucja publiczna będzie oficjalnie stosować formaty niewymienione w rozporządzeniu to potem kontrola NIK-u stwierdzić może że niezgodnie z prawem coś jest robione.
Aha: jakby ktoś naprawdę kochał DjVu to w rozdzielniku jest też oprócz organów państwa także parę wyższych uczelni oraz: Stowarzyszenie PEMI, Krajowa Izba Gospodarcza Elektroniki i Telekomunikacji, Polska Izba Informatyki i Telekomunikacji, Polskie Towarzystwo Informatyczne, Polskie Towarzystwo Społeczenstwa Informacyjnego, ISOC Polska, Fundacja Wolnego i i Otwartego Oprogramowania, Koalicja na Rzecz Otwartych Standardów...
A więc pole do działania (czyli legalnego lobbingu na rzecz DjVu) jest bardzo szerokie.
-
Witam,
według mnie, jeżeli jest taka możliwość, to DjVu powinno zostać dopisane do rozporządzenia w ramach nowelizacji. Nie jako przymusowe i obowiązujące, ale właśnie po to, że jeżeli wybierzemy ten format (co nie jest powiedziane), to w przypadku kontroli NIK lub innego organu kontrolującego nikt nam za to głowy nie urwie. O ile mi wiadomo, to PW korzysta (a przynajmniej korzystało w ubiegłym roku) z DjVu przy pracach nad obrazami w medycynie i wielu naukowców zdecydowanie podkreśla jego zalety w porównaniu z JPEG. Również moje badania do pracy magisterskiej wskazały na zalety tego formatu przy pracy ze skanami akt, jak również fotografii i innych dokumentów archiwalnych. Szybkość przetwarzania, jak również kwestie związane z wielkością plików mają istotne znaczenie w środowisku archiwalnym. Jedynym problemem była kwestia OCR, gdzie Lizard Tech. zastrzegł patenty dotyczące tworzenia warstwy tekstowej dla tych dokumentów. Nie wiem jak sprawa wygląda w chwili obecnej, ponieważ od ponad roku nie miałem już do czynienia z DjVu. Czy jest już jakiś mechanizm otwarty umożliwiający bezpośredni odczyt warstwy OCR z dokumentu? Jeżeli tak, to zajęcie się kwestią DjVu staje się według mnie koniecznością, która może pozwolić na oszczędności budżetowe związane z zakupami olbrzymich macierzy oraz jeszcze większych bibliotek taśmowych. Myślę, że wykorzystując DjVu takie koszty można zmniejszyć nawet czterokrotnie, co przy obecnych cenach sprzętu ma chyba spore znaczenie.
-
Przede wszystkim, jako że to moja pierwsza wypowiedź na tym forum, witam wszystkich bardzo serdecznie.
Pomysł stworzenia archiwum w konwencji Open Source wydaje mi się bardzo interesujący i bardzo chętnie się weń włączę. Nie przeczytałem jeszcze wszystkich Waszych wypowiedzi, więc wybaczcie, jeżeli w jakiejś kwestii się powtórzę. Bardzo interesuje mnie kwestia, jaki jest plan techniczny składowania tych wszystkich danych. Uważam, że przy takiej objętości i różnorodności jest to naprawdę dużym wyzwaniem. Zarówno baza, jak i technologia składowania plików, muszą być zoptymalizowane pod kątem odczytu. Czy istnieją już jakieś założenia dotyczące tych technologii?
-
Muszę się poprawić bo trochę za bardzo "pojechałem" z tym NIK-iem. Otóż MSWiA w specjalnym Komunikacie (http://www.mswia.gov.pl/index.php?dzial=2&id=3607)objaśniło, że:
" W związku z pojawiającymi się mylnymi interpretacjami Rozporządzenia Rady Ministrów w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz. U. Nr 212 poz. 1766 z dnia 28 października 2005r.) dotyczącymi możliwych do stosowania formatów plików dokumentów tekstowych i tekstowo-grafcznych, Ministerstwo Spraw Wewnętrznych i Administracji informuje, że rozporządzenie to określa jedynie minimalne wymagania.
Oznacza to, że podmioty podlegające zapisom ustawy z dnia 17 lutego 2005r. o informatyzacji działalności podmiotów realizujących zadania publiczne są obowiązane do stosowania zawartych w rozporządzeniu formatów danych, natomiast nie ogranicza ono w żaden sposób możliwości korzystania z innego rodzaju formatów plików dokumentów tekstowych i tekstowo-graficznych. Rozporządzenie to wskazuje również na kilka równoważnych formatów i nie narzuca ani nie preferuje w żaden sposób któregokolwiek z nich"
Tak więc na podstawie tego można zrozumieć, że DjVu w rozporządzeniu będzie oznaczać, że podmioty publiczne będą obowiązane do stosowania m.in DjVu. Tj. nie do tego żeby DjVu stosować do tworzenia wersji przeglądowych ale tylko do tego aby umiały DjVu "wyprodukować" i "odczytać". Praktycznie rozumiałbym to jako przymus prawny do tego żeby (jeśli użytkownik by sobie zażyczył otrzymać nie w JPG tylko w DjVu to trzeba byłoby mu tak dać). Chyba że format uznany byłby jako "tylko do odczytu" - warto zauważyć że PDF i doc. są w obecnej wersji rozporządzenia są właśnie "wyłącznie do odczytu" a więc archiwum nie musi umieć ich "produkować" a jedynie odczytać.
Jeśli więc nie będzie DjVu w rozporządzeniu to też nic się nie stanie... no chyba żeby pojawiła się kolejna interpretacja.
Ale i to niekoniecznie tak będzie ponieważ nie wiadomo w którą stronę zmiany w rozporządzeniu w ogóle pójdą. Być może w ogóle nie będzie listy formatów?
Dziękuję
-
I to ja napisałem bezsensowne "Dziękuję" na koniec poprzedniego postu?
Dobrze, że nie co innego... Jak bym się wtedy wytłumaczył, że nie przypominam sobie... Widać jak mnie zamroczy to kulturalne rzeczy wypisuję.
Czas się chyba wybrać do lekarza.
Albo robić zrzuty ekranów... :)
-
Jak się wydaje i PDF jest już wystarczająco rozpowszechniony, żeby nie musieć wchodzić w nieśmiertelnego JPEGa którym trudno się zarządza (bo aby prezentować cały dokument wielostronicowy trzeba wielu plików) i jest znacznie "cięższy". Z całą pewnością więc wsparcie dla PDF-a będzie więc i za 20-30 lat dostępne. Czy możemy to samo powiedzieć o DjVu? Porównując do formatów analogowych: w swoim czasie na rynku "przeglądowym" walczyły gorszy VHS i lepszy Hi8. Wygrał gorszy VHS. I dziś można go ciągle łatwo odtwarzać.
Pozwole sobie sie wtracic, jako "typowy przyklad genealoga amatora".
Nie Hi-8 vs. VHS tylko Betamax vs. VHS!!!
PDF jest rozpowszechniony, jednak przedstawianie go jako zastepce wstretnego JPEG`a, ktory zejsc ze sceny nie chce jest bledem. PDF jest oparty o JPEG! Oczywiscie ma dodatkowe funkcje, ale w przypadku materialow archiwalnych wiekszosc z nich jest niedostepna (typu warstwa tekstowa itp.).
Poza tym, PDF ma wiele innych wad - wielkosc plikow (bo JPEG), fatalne przegladanie online (troche lepsze offline, ale w przypadku obrazkow wrzuconych pod przykrywka PDF`a jest niezbyt milo). Wydawaloby sie, ze zaleta PDF`a jest mozliwosc ograniczenia praw uzytkownika do kopiowania/drukowania zawartych w nim informacji - zlamanie tych zabezpieczen zajmuje pare minut (przy otwartym pliku do odczytu/znanym hasle).
Jezeli chodzi o wsparcie za 30 lat dla DjVu vs. PDF - nie widze powodu, zeby mialo sie czyms roznic. A nawet gdyby stalo sie tak, ze DjVu zostaloby zastapione innym formatem, to NAC moglby umiescic na swojej stronie otwarta przegladarke - czyli nie ma klopotu. W najczarniejszym scenariuszu mozna zawsze rozkompresowac DjVu i ponownie stworzyc plik w innym formacie (chociaz mam nadzieje, ze orginalne TIF`y pozostana w repozytorium...).
Dlaczego DjVu? 5 216 211. Co to za liczba?
Łączna liczba czytelników od dnia 2004-06-10
Oczywiscie nie wszystkie zbiory nadaja sie do przeksztalcenia w pliki formatu DjVu - sadze, ze nie ma przymusu trzymania sie jednego jedynego formatu - gdzie jest szybciej, latwiej i skuteczniej zrobic PDF`a, to czemu nie? Ale np. nie jestem w stanie sobie wyobrazic przegladania np. ciechanowskich ziemskich wieczystych powiedzmy 1758-68 (lata wziete z kosmosu) w PDF`ie - to sa takie ksiazeczki, co maja pol metra grubosci ;) )
I na koniec:
Co będziemy udostępniać? Głównie opis wzbogacane obrazami - tak więc chyba, podkreślam chyba bittorrent nie będzie tu się sprawdzał.
W tym punkcie oblecial mnie blady strach. Opis wzbogacony obrazami? ??? To w takim razie wszystko to, jest wielkim zawaracaniem gitary! >:( I tu juz nie pisze z punktu widzenia "typ. przyp. gen. am.", ale z punktu widzenia podatnika/amatora historyka (bo przeciez i tak w perspektywie 10 lat ucyfrowionych/udostepnionych nie bedzie tych materialow, ktore mnie interesuja z genealogicznego punktu widzenia)!
Po jakiego grzyba organizowac instutucje, ktora wyda pieniadze na stworzenie "opisu wzbogaconego obrazami"?
Przeciez takie rzeczy, to mozna pokazywac dzieciom na prelekcji! Gdzie w tym jest logika? Dla kogo to ma byc w takim razie?
AAAAaaa!!! Juz widze WBC, ktora umieszcza opis ksiazki wzbogacony obrazami!!! A co autor ma na mysli??? AAAAAA!!! >:(
Ide na piwo! ;D
Jan G.
-
Witam,
Nie będę się odnosił na razie do dyskusji na temat rodzaju plików w jakich mają być prezentowane dane, rozważamy wszystkie za i przeciw i to wg mnie nie jest problem - możemy badaczowi udostępniać dane w formacie jaki sobie zażyczy - tiffy faktycznie pozostaną w repozytorium i zawsze można będzie je w całości czy w części "przemielić".
Chcę natomiast uspokoić gwałtowną reakcję przedmówcy na skrót myślowy "obrazy+opis" - chodziło o to, że obraz (tzn. skan dokumentu) będzie wzbogacony o wszelką dostępną informację archiwalną która jest dostępna i oczywiście z roku na rok dzięki pracom archiwistów uzupełniana...
Pozdrawiam,
-
Pozwolę sobie na dwa małe sprostowania ponieważ mam jakiś poziom miłości własnej:
1.
Nie Hi-8 vs. VHS tylko Betamax vs. VHS!!!
Czy te trzy wykrzykniki mają oznaczać mnie więcej "pomyliłeś się!!!"? Otóż wyjaśniam, że faktycznie taka wojna była, ale niejeden miała etap. Parę lat temu w Gazecie Wyborczej napisano "O Betamax pamiętają już tylko ludzie z telewizji" (jakby Betamaxa w telewizji używano...), a ostatnio w jednym z wysokonakładowych tygodników polskich przy okazji wojny HD-DVD z Blue-Ray przypomniano wojnę Betamaxa z VHS-em. W polskiej Wikipedii napisano że wojna była pomiędzy Betamax i VHS ... Czy to znaczy że o innych nośnikach "po drodze" nie może być mowy?
Istotnie wojna ta zwykle nazywana jest VHS-Betamax. Ale proszę na mnie psów nie wieszać!
Sony próbował różnych innych chwytów jak okazało się, że Betamax nie zaskoczył co można przeczytać np. w angielskiej Wikipedii zob. http://en.wikipedia.org/wiki/Betamax
I tam to jest w miarę po kolei wyjaśnione (jeszcze od U-matica...)
A ja po prostu przytoczyłem przykład kierując się własnym doświadczeniem życiowym z sprzed wieeeelu lat gdy zastanawiałem się czy kupić kamerę VHS czy Hi8 - i to był dla mnie wybór - a nikt juz wtedy nie myślał o Betamaxie.
Bo Betamax przegrał od razu na starcie i to była tylko bitwa (no może blitzkrieg - a wojna toczyła się potem pomiędzy Video8 (potem Hi8) i VHS (i S-VHS).
Jeśli to nie jest przekonujące zobaczcie co można kupić dziś na rynku (kasety VHS i Hi8 ciągle jeszcze są dostępne a Betamax...). Proponuję też zarzucić do gugla takie zapytanie: (kasety vhs hi8), a potem takie (kasety vhs betamax). Albo popytać w sklepach o taśmy do Betamaxa. Różnica będzie (że użyję modnego słowa) "porażająca"
PDF jest rozpowszechniony, jednak przedstawianie go jako zastepce wstretnego JPEG`a, ktory zejsc ze sceny nie chce jest błędem.
I znowu niemiłe zaskoczenie. Ja przecież niczego takiego nie napisałem. Tym bardziej to dziwne, że autor nawet mnie wyżej wprost cytuje.
Dlatego bardzo proszę nie napadajmy na siebie w ten sposób. Zostawmy to politykom i ich specom od PR. Będziemy mieli tego dosyć na ulicach w gazetach i tv...
trochę życzliwości...
Co do księgi półmetrowej grubości to chętnie otworzyłbym nowy temat na tym forum:
"jakie technologie do czego zastosować". Otóż wydaje mi się że właściwy format, rozdzielczość, głębia bitowa, kompresja (a dlaczego nie?) a czasem wzorzec koloru powinny być dobierane zależnie do materiału przeznaczonego do cyfryzacji. Po to żeby znaleźć rozsądny kompromis koszt/jakość. Już tu raz pisałem że nie życzę sobie wydać kilkudziesięciu milionów złotych (moich bo publicznych!) więcej na sprzęt tylko dlatego że są badacze duktu pisma (w liczbie powiedzmy dziesięciu), którzy potrzebują jakości 600 dpi w kolorze i bez kompresji.
-
Witam,
Panowie, Panowie - dyskutujmy ale nie róbmy na razie czegoś co się zwie "święta wojna" czyli dyskusja z której nic nie wynika - bo wtedy przerzucę to do "silva rerum" ;)... ale poważnie - za niedługo urchomimy mechanizm wiki NAC, który jasno będzie opisywał co i jak. Na razie konfigurujemy jeszcze pewne sprawy dotyczące generaliów Projektu.
Pozdrawiam,
-
Tak jest. Żadnej wojny. Pokój.
Myślę, że nie przekroczyliśmy z fjgrabowski granicy przenoszalności do silva rerum. Mam nadzieję że przyzna to też i mój znakomity Przeciwnik.
Poszukajmy zatem sensu w tej "świętej wojnie".
Myśle że się zgodzimy że bez względu na to czy chodzi tu o Betamax, Video 8, Hi8, VHS, S-VHS itd czas wsparcia na rynku zależy od popularności formatu.
Myślę że zgodzimy się też że w przypadku formatów cyfrowych zapisujących materiały w plikach (a nie liniowo jak np. Digital Betacam) problem ten występuje nie wprost. Wszak konwersja załóżmy 20 milionów plików na nowy format może odbywać się "w tle" i wcale nie trzeba do tego angażować ludzi jak w przypadku konwersji z analogowych taśm 2- i 1-calowych (profesjonalnych). Dlaczego jednak o tym piszę i czy coś z tego wynika? Sądzę że przykład analogowego zapisu wideo jest tu jednak nie bez kozery:
Z własnego doświadczenia wiem jak ogromnym przedsięwzięciem organizacyjnym jest "ucieczka" a kilkudziesięciu tysięcy zagrożonych nośników na inne: ciągle się coś nie klei: głowice do magnetowidów regeneruje już tylko jedna firma na rynku, nośnik magnetyczny na taśmie odkleja się o podłoża, nie ma już ludzi do takiej roboty bo nikt nowy nie umie tego sprzętu obsługiwać, nie ma po prostu pieniędzy na ślęczenie godzinami przy przegrywaniu co najmniej dwóch osób (jeden śledzi jakość pracy maszyn a drugi co się przegrywa. Wreszcie nawet gdyby grać 24h na dobę to przy tych kłopotach ... i tak się nie zdąży. W telewizjach na całym świecie po prostu od pewnego czasu przegrywa się na okrągło. Najpierw 2-cale na Betacam SP a potem na Digital Betacam albo na DVC-Pro (albo inaczej zależy co kto miał). Za chwilę trzeba będzie uciekać z przestarzałego Betacam SP, a w magazynach ciągle zalegają dziesiątki tysięcy zagrożonych 1-calówek.
Piszę o tym bo to doświadczenie pokazuje, że jeśli nie zaprojektujemy dobrego, długoterminowego zarządzania plikami dla NAC to możemy wpaść w pułapkę "nośnikową". I być może gdy takie zarządzanie będziemy mieli to dyskusje o tym czy jpeg czy djvu czy pdf będą mało istotne.
Po zastanowieniu się w przyznaję że w tym coś jest co napisał minder że nie będzie to większy problem: "Chcę oglądać film kodowany w x264 czy Theora - instaluję kodeka" . Faktycznie jakoś przecież nigdy nie miałem większego problemu nawet z odczytaniem formatów "nieotwartych" za pomocą darmowego oprogramowania. A zawsze miałem kłopot z odnalezieniem pliku (nawet na własnym twardym dysku a co dopiero na nośnikach off-line)
Czy zgodzicie się zatem, że największym problemem nie jest tak naprawdę format plików (choć też ważny, ale z nim sobie zawsze poradzimy) ale raczej informacja o tym co na nich jest i zintegrowane zarządzanie nimi w długim czasie (czyli metadane) Tak aby ucieczka do kolejnego formatu była wykonywana automatycznie. Jeśli tak będzie, to faktycznie można będzie pokusić się o konwersję dla końcowego użytkownika "w locie" na taki format jaki sobie zażyczy? Z dodatkową informacją dla niego że DjVu choć wygląda ładnie i jest "najlżejszy" to może przekłamywać w pewnych szczegółach? A za to że JPEG choć cięższy nieco jak nie "widzi" szczegółów to ich po prostu nie widzi i tyle... A że PDF ... A jak ktoś chce mastera w TIFF-ie to proszę bardzo tu można złożyć zamówienie i po wpłaceniu x zł ...zostanie wysłane na wskazany adres?
Czy może jednak format jest bardzo ważny, ale powinno tu decydować przede wszystkim kryterium przydatności a nie popularności jego stosowania jak to sugerowałem na nie najlepiej dobranym przykładzie poprzednio i mało nas za to Moderator nie przesunął do śmietnika?
-
Sam się skrytykuję bo format może być bardzo ważny. Tu też można się wpuścić w maliny. Spróbujcie np przekonwertować plik *.oma na mp3... Ja już to robiłem. Oczywiście miałem legalne oprogramowanie zakupione wraz z urządzeniem (przy okazji "zepsułem" sobie konfiguracje komputera) ale ono nie konwertowało do niczego innego. Trzeba było łapać "w locie" z karty dźwiękowej.
Podsumowując: po prostu wszystko jest ważne i trzeba bardzo uważać aby nie zrobić jakiegoś błędu, który może potem dużo kosztować.
-
Czy te trzy wykrzykniki mają oznaczać mnie więcej "pomyliłeś się!!!"?
Oczywiscie! ;) Glowna wojna byla taka i dlatego zwrocilem na to uwage - ale zgadzam sie tez z tym, co Szanowny Pan napisal, wiec nie widze potrzeby ryzykowania przeprowadzki do SR!
Dlatego bardzo proszę nie napadajmy na siebie w ten sposób.
Nie bylo moja intencja napadanie Pana! Chodzi mi wylacznie o to, ze PDF (moim zdaniem...) nie jest najlepszym formatem do prezentacji skanow - co innego gdy sa to dokumenty tekstowe / mieszane.
Co do księgi półmetrowej grubości to chętnie otworzyłbym nowy temat na tym forum:
"jakie technologie do czego zastosować".
Tak! Tak! Tak!
Moze jeszcze niesmiertelny problem - co skanowac w pierwszej kolejnosci... Jezeli to nie jest decyzja wylacznie "gory".
Już tu raz pisałem że nie życzę sobie wydać kilkudziesięciu milionów złotych (moich bo publicznych!) więcej na sprzęt tylko dlatego że są badacze duktu pisma (w liczbie powiedzmy dziesięciu), którzy potrzebują jakości 600 dpi w kolorze i bez kompresji.
Dodalbym do tego jeszcze jeden aspekt - czas potrzebny na skanowanie w wyzszej rozdzielczosci! Przy olbrzymich ilosciach materialow, staje sie to powaznym problemem...
Sam się skrytykuję bo format może być bardzo ważny. Tu też można się wpuścić w maliny. Spróbujcie np przekonwertować plik *.oma na mp3... Ja już to robiłem. Oczywiście miałem legalne oprogramowanie zakupione wraz z urządzeniem (przy okazji "zepsułem" sobie konfiguracje komputera) ale ono nie konwertowało do niczego innego. Trzeba było łapać "w locie" z karty dźwiękowej.
Podsumowując: po prostu wszystko jest ważne i trzeba bardzo uważać aby nie zrobić jakiegoś błędu, który może potem dużo kosztować.
I dlatego wlasnie tak wazna jest otwartosc przyjetych formatow - oczywiscie to niczego nie gwarantuje, ale zwieksza szanse na to, ze niespodzianka sie nie trafi. Znam przyklady bibliotecznych baz danych robionych na poczatku lat 90... Zostala skopiowana baza, a programu nie ma (po szybkiej analizie autor doszedl do wniosku, ze taniej bedzie przepisac od nowa, niz odtwarzac zamkniete oprogramowanie).
Pozdrawiam
JG
ps. Czy sposob udostepnienia danych podpada pod ten watek? Dla przykladu prosze porownac sobie funkcjonalnosc WBC (http://www.wbc.poznan.pl) i Polon`y (http://www.polona.pl). Niby to samo, a jednak nie... A moze to tylko moje odczucie?
ps2. Panie Rafale, dziekuje za rozwianie moich obaw!!!
-
Jako, że pierwszy raz na forum ... witam szanowne towarzystwo.
Nie jestem archiwistą więc nawet nie będę próbował dyskutować o formatach, metadanych itp. Natomiast chciałbym zwrócić uwagę na dwa tematy, których nie zauważyłem w dyskusji.
Pierwsza sprawa to zasilanie zbioru danymi. Jest tu mowa o aplikacji standby oraz interfejsie www. I bardzo dobrze ale czy to wystarczy? Komunikacja między większymi ośrodkami załatwi sprawę ale wspomniano tu również o małych ośrodkach a tutaj już może być problem z komunikacją. W naszym kraju nadal są rejony, w których dostęp do internetu pozostaje w sferze marzeń. Nawet tak popularna Neostrada nie załatwia problemu. Proszę pamiętać, że reklamowana prędkość 1Mbps to prędkość do klienta (download). Transfer w drugą stronę (upload) to zaledwie 128kbps a w lepszych konfiguracjach 256kbps. To stanowczo za mało do przesyłania danych "ważących" po kilka/kilkanaście MB nie mówiąc już o przesłaniu efektów pracy całego dnia. Nie chodzi tu o czas pracy komputera - można upload wykonać w nocy (choć tutaj BHPowcy dostaną białej gorączki) ale o sam mechanizm przekazywania danych. Z różnych względów skrypt działający na serwerze, odbierający dane musi się wykonać w określonym przedziale czasu. Jeśli się nie wykona to jest brutalnie zabijany i komunikacja jest zrywana a dane już przesłane znikają z serwera. Przy tak dużych ilościach danych i szybkościach transferu dostępnych obecnie na rynku za rozsądną cenę nie ma szans na realizacje takiego planu. Pewnym rozwiązaniem mogłoby być zastosowanie rozwiązania z dawnych lat nazywanego żartobliwie "floppy network". Wymagałoby to dodania do aplikacji "standby" funkcji eksportu na nośnik wymienny a do aplikacji działającej na serwerze funkcji importu danych z takiego nośnika.
Kolejna sprawa to samo przechowywanie danych. Szukając informacji o polskich archiwach trafiłem na przetarg ogłoszony przez AAN i na tym przykładzie wyjaśnię o co chodzi. W SIWZ podano, że dostarczonych ma być 12 dysków po 500GB (to tak na początek). Przyjmując że będą pracować w RAID 1 to daje 3TB danych. W jaki sposób wykonać backup takiej ilości danych? SIWZ wymienia jeden napęd LTO4. Teoretyczna prędkość wykonania kopii na tym streamerze to 430GB/h, w praktyce ok. 300GB/h. Zatem wykonanie pełnej kopii zajmie ok. 10h. Czy w tak długim czasie nie nastąpią żadne zmiany w zbiorze danych? Jeśli nastąpią to kopia będzie nic nie warta bo dane będą niespójne. Oczywiście można zamiast pełnego backupu wykonywać kopie przyrostowe. Ale w jaki sposób określimy na której taśmie znajdują się określone dane?
Analizując dalej problem przechowywania danych ... Jak miałby być określony sposób dostępu do danych? Początkowo wszystkie dane będą się znajdować na dyskach serwera ale z czasem danych będzie tyle, że zabraknie miejsca. Oczywiście można dokupić kolejne dyski ale w pewnym momencie skończą się możliwości rozbudowy sprzętu a dokładanie kolejnych elementów spowoduje zbyt duży stopień skomplikowania konfiguracji systemu. Tutaj pewnym rozwiązaniem mogłoby być zastosowanie klas dostępu: dokumenty bieżące, dokumenty często przeglądane, dokumenty rzadko przeglądane ... W oparciu o tak zdefiniowane klasy i ich wymogi czasu dostępu można dobrać różnego rodzaju nośniki i sposób przechowywania danych oraz oprogramowanie do zarządzania takim zasobem.
Skoro wspomniałem o oprogramowaniu ... Do backupu tak dużych danych zwróciłbym uwagę na aplikacje Legato oraz TSM (niestety obie własnościowe i kosztują :o ) oraz system Bacula (to już OS).
Niestety wszystkie te aplikacje mają na celu zabezpieczenie danych przed utratą a nie ich archiwizację. Wszystkie one zakładają możliwość "znikania" danych po określonym czasie (retencja danych). Zresztą nie jest to takie dziwne. Z doświadczenia wiem, że taśmy, nawet przechowywane w warunkach wręcz laboratoryjnych, po trzech latach zaczynają sprawiać problemy przy próbie odtworzenia danych. Więc pojawia się kolejny problem do rozwiązania: okresowe odtwarzanie danych i ponowny zapis na taśmach.
MSZ temat przechowywania i udostępniania danych jest na tyle istotny, że należałoby go ująć jako kolejny projekt.
-
Pozwole sobie odpowiedziec:
Ad1
Nie jest mozliwym, aby w kazdym archiwum znalazl sie odpowiedniej jakosci skaner i osoba(y), ktora by przy nim pracowala. Przypuszczam, ze bedzie pare (pewnie nawet nie tyle, ile wojewodztw) osrodkow skanowania i tam beda trafialy akta z mniejszych placowek.
Ad2
Przechowywanie to spory problem. Wystarczy to sobie policzyc! Przykladowy skan, ktory dostaje sie od AGAD ma 20MB (a pewnie beda lepszej jakosci), ksiega ma np. kart 400 (czyli 800 skanow). Daje to 15,5GB. Ksiag w serii jest np. 200. Co daje nam dla jedenego zespolu (?) 3TB danych. Na jedna tasme nie ma szansy tego upchnac (chyba najwieksze w tej chwili maja 400GB - po kompresji 800). Zmian w tym materiale juz nie ma, wobec czego mozna nagrywac tak dlugo jak sie chce.
Zywotnosc? Firma SUN daje 30 lat (zrodlo (http://www.sun.com/storagetek/tape_storage/tape_media/t10000/specs.xml)).
Nie bardzo chce mi sie wglebiac w ich strone, zeby sprawdzic na ile daja gwarancje.
Oczywiscie jedna kopia, to jest zbyt malo. Trzeba miec odpowiednie pomieszczenia do przechowywania itd. Ale to i tak wyjdzie taniej, niz trzymanie tego calego materialu na macierzach (bo jaki jest sens, jezeli to maja byc kopie bezpieczenstwa?).
Nie wglebiam sie bardziej, bo juz pozno - a pisac mozna duzo na ten temat.
Pozdrawiam
JG
-
Ad1
Nie jest mozliwym, aby w kazdym archiwum znalazl sie odpowiedniej jakosci skaner i osoba(y), ktora by przy nim pracowala. Przypuszczam, ze bedzie pare (pewnie nawet nie tyle, ile wojewodztw) osrodkow skanowania i tam beda trafialy akta z mniejszych placowek.
W takim razie po co aplikacja na PC. Przecież te kilka jednostek może pracować online dostarczając dane bezpośrednio na serwery.
Czy nie prościej jest wykonać skan materiałów w archiwum, w którym materiały są przechowywane i taką "surówkę" już w postaci elektronicznej dostarczyć do ośrodka przetwarzania?
Ad2
Przechowywanie to spory problem. Wystarczy to sobie policzyc! Przykladowy skan, ktory dostaje sie od AGAD ma 20MB (a pewnie beda lepszej jakosci), ksiega ma np. kart 400 (czyli 800 skanow). Daje to 15,5GB. Ksiag w serii jest np. 200. Co daje nam dla jedenego zespolu (?) 3TB danych. Na jedna tasme nie ma szansy tego upchnac (chyba najwieksze w tej chwili maja 400GB - po kompresji 800). Zmian w tym materiale juz nie ma, wobec czego mozna nagrywac tak dlugo jak sie chce.
Zywotnosc? Firma SUN daje 30 lat (zrodlo (http://www.sun.com/storagetek/tape_storage/tape_media/t10000/specs.xml)).
Nie bardzo chce mi sie wglebiac w ich strone, zeby sprawdzic na ile daja gwarancje.
W zeszłym roku do sprzedaży weszły napędy i media LTO4 o pojemności 800/1600 GB i o takich właśnie pisałem. Rozwiązania takie jak podane w linku traktowałbym bardzo ostrożnie gdyż nie jest to standard i wybierając takie rozwiązanie skazujemy się na dożywotnie związanie z jednym producentem.
A co do żywotności:
HP warrants LTO4 Ultrium 1.6TB RW and WORM cartridges for up to 30 years archival life and/or 260 full backups. This ensures businesses can meet the ever increasing demands of regulation for data retention and archiving.
Faktycznie czas życia jest dłuższy od tego co wcześniej pisałem ale czy możemy przyjąć 30 lat? Taki okres przydatności do użycia ma medium ale czy dane tyle przetrwają. Mam co do tego poważne wątpliwości. Jakikolwiek jest to okres i tak nie zmienia to faktu, że dane na taśmach należy okresowo "odświeżać" i dobrze by było mieć jakiś automat, który będzie o tym pamiętał.
Oczywiscie jedna kopia, to jest zbyt malo. Trzeba miec odpowiednie pomieszczenia do przechowywania itd. Ale to i tak wyjdzie taniej, niz trzymanie tego calego materialu na macierzach (bo jaki jest sens, jezeli to maja byc kopie bezpieczenstwa?).
Kopie bezpieczeństwa jak najbardziej na tasiemki i przechowywanie w innej lokalizacji niż oryginały.
Ale przecież celem projektu jest ułatwienie dostępu do danych a więc możliwość szybkiego i prostego dostępu do nich. Właśnie dlatego wspomniałem o klasach dostępności. Przykładowo:
1. dane w formie "bezpośredniej" zgromadzone na głównej macierzy dyskowej
2. dane w formie skompresowanej na dodatkowej macierzy dyskowej - są już dostępne dyski o pojemności 1TB, dostęp bezpośrednio do poszukiwanego zasobu po jego rozkompresowaniu
3. dane w formie skompresowanej przechowywane w bibliotece taśmowej dostępne na żądanie oprogramowania - dostęp do danych jest sekwencyjny (długi czas dostępu do danych), wymaga przeniesienia na wyższy poziom dostępności w celu rozkompresowania
4. dane na taśmach dostępne po wcześniejszym zamówieniu dostępu - znajdują się w magazynie danego ośrodka
Ten przykład pokazuje sposób przechowywania i udostępniania danych a nie ich zabezpieczenia bo to odrębna problematyka.
Oczywiście powyższe dotyczy przechowywania danych właściwych bo metadane muszą być dostępne online i umożliwiać identyfikację klasy dostępności i tutaj właśnie dochodzimy do problemu spójności danych. Jeśli w czasie wykonywania backupu klient zgłosi zapotrzebowanie na dany zasób to zostanie on przeniesiony na wyższy poziom dostępności i zostaną dokonane odpowiednie zmiany w informacji o tym zasobie. Ale czy wszystkie te zmiany zostaną przeniesione do backupu? Tutaj nie mamy pewności. Oczywiście jest to problem stary jak informatyka i istnieje wiele mechanizmów zabezpieczających ale trzeba je zaimplementować do konkretnej instalacji.
Nie chodzi mi w tej chwili o rozwiązanie przedstawionych problemów ale o to aby o tych problemach nie zapominano i uwzględniono je przy projektowaniu całego systemu. Jest to temat bardziej dla informatyków i dlatego sugeruję wydzielenie go jako odrębny podprojekt w ramach NAC.
-
Kolejna sprawa to samo przechowywanie danych.
...
Zastanawiam sie czy nie nalezaloby pomyslec o systemie rozproszonym, taki ogolnopolski grid skladajacych sie z glownych osrodkow archiwizacji.
pozdrawiam
piotr
-
Zawsze uważałem że to co należy zostawić informatykom należy ... im zostawić.
Problem: długoterminowe przechowywanie 100 petabajtów danych
Dane mają przy tym być:
- bezpieczne (ewentualna awaria nie może zniszczyć całego zbioru)
- stale dostępne (przy czym "stale" nie oznacza w tym przypadku 24/7/365 ponieważ archiwum to nie pogotowie ratunkowe czy elektrownia i nawet kilkudniowa przerwa nie będzie krytyczna)
A jak to będzie technicznie rozwiązane - tym archiwiści w ogóle nie powinni się zajmować. To czym powinni sie zająć to wskazanie "obiektów cyfrowych" do tego długoterminowego przechowania będących całościami LOGICZNYMI a nie FIZYCZNYMI. Czyli krótko mówiąc nie zajmować się nośnikami a dokumentami elektronicznymi (i tymi powstałymi w drodze digitalizacji i tymi naturalnymi). Jeśli archiwiści będą umieli wydzielać logiczne, oderwane od nośnika całości znaczeniowe to informatycy będą umieli je przechować. Jeśli jednak archiwiści nie będą umieli takich obiektów wyodrębniać (nie czarujmy się: ani zespół archiwalny, ani płyta DVD, ani pojedynczy plik TIFF takimi odrębnymi "całościami" nie są).
chciałbym zauważyć że w tym wątku znajdujemy cytaty które na to wskazują:
"Jest to temat bardziej dla informatyków i dlatego sugeruję wydzielenie go jako odrębny podprojekt w ramach NAC"
i:
Nie jestem archiwistą więc nawet nie będę próbował dyskutować o formatach, metadanych itp.
Dlatego jak najbardziej trzeba oddzielić tematy "archiwistyczne" i "techniczne". Z pewną dość dużą rezerwą (jako nie-inżynier) odnoszę się też do dyskutowanego na tym forum oprogramowania które miałoby konwertować pliki do DjVu (jako zadania NAC). Dlaczego? Otóż to mniej więcej tak jakby przedsiębiorstwo transportu miejskiego projektowało tramwaj zamiast go po prostu kupić.
Natomiast poruszone tu problemy długoterminowego przechowywania to jest właśnie ZADANIE dla NAC.
Jak czytam dyskusję o wtyczkach a nie widzę dyskusji o metadanych strukturalnych i administracyjnych (np czy PREMIS to nie za dużo? czy EXIF trzeba zachować? czy norma Z39.87 w ogóle jest warta zwrócenia uwagi) to tym bardziej widzę że jeszcze dużo pracy przed nami...
PS. Zespół roboczy ds. standardów technicznych pracujący w ramach Zespołu ds Digitalizacji przygotowuje stosowny raport na temat formatów, metadanych i polityk digitalizacji (wersja wsępna powinna być gotowa na początku października)
-
Witam
Jak kolega wyzej zauwazył:
że to co należy zostawić informatykom należy ... im zostawić.
Ale dla ciekawskich wyjasnie
Ilość danych które archiwa są w stanie wyprodukować jest ogromna i liczona w petabajtach.
Na dzień dzisiejszy zasób "cyfrowy" ( czyli zditalizowane materiały archiwlane) nawet nieduzego archiwum to co najmiej kilka TB.
Aplikacja zajmująca sie przetwarzaniem tych danych bedzie widziała zasób plikowy i tyle.
A ten zasób to biblioteki teasmowe i macierze dyskowe "przykryte" odpowiednim oprogramowaniem które zapewni redundancje danych i wykonywanie np. kopii bezpieczenstwa.
Dla aplikacji bedzie to po prostu zasób o pojemnosci np. 100 TB ( na poczatek), a to ze fizycznie na macirzy bedzie np. tylko 10TB,a reszta to np. tasmy to juz nie ma znaczenia. Co wiecej dzięki takiemu oprogramowaniu mozemy wykorzystac zasoby z wielu fizycznych lokalizacji, a aplikacja dalej bedzie widziła jeden "udział"
Mam nadzieje ze trochę rozjasnilem
POzdr dla wszytskich zaangazowanych
-
Aplikacja zajmująca sie przetwarzaniem tych danych bedzie widziała zasób plikowy i tyle.
Przy okazji pojawienia się tego cytatu pozwolę sobie i w tym wątku zwrócić uwagę na to iż owemu zasobowi plikowemu (obojętnie gdzie fizycznie składowanemu) MUSI towarzyszyć informacja o powiązaniach pomiędzy poszczególnymi plikami wskazująca na to jakie konkretnie pliki składają się na obiekt (tzw. metadane strukturalne).
Jeśli więc jesteśmy w tak poważnym wątku jak "Plan działania czyli jak to sobie wyobrażamy" nie bez kozery będzie zauważyć że nadawanie nawet najbardziej rozbudowanych nazw plikom powstającym w procesie digitalizacji nie będzie wystarczające.
A to dlatego że pliki składać się będą na obiekty (jeszcze nie jednostki archiwalne!)
A dopiero te obiekty na jednostki.
Trochę na ten temat jest w tym wątku http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=49.msg4831#msg4831