Plan działania czyli jak to sobie wyobrażamy

[fjgrabowski]

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!

Jan G.

[Rafał Rufus Magryś]

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,
 

[Kazimierz Schmidt]

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.

[Rafał Rufus Magryś]

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,

[Kazimierz Schmidt]

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?

[Kazimierz Schmidt]

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ć.

[fjgrabowski]

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 i Polon`y. Niby to samo, a jednak nie... A moze to tylko moje odczucie?

ps2. Panie Rafale, dziekuje za rozwianie moich obaw!!!

[Tuptus]

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ą  ) 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.

[fjgrabowski]

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).
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

[Tuptus]

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).
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.

[piotrpsz]

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

[Kazimierz Schmidt]

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)

[Jacek M. S.]

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

[Kazimierz Schmidt]

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