porozmawiajmy o EAD

[Kazimierz Schmidt]

dziś w Warszawie (w AGAD) miała miejsce konferencja "STANDARYZACJA W ARCHIWACH - WARSZTATY". Jak znajdujemy w programie konferencji było "II. Dlaczego EAD?".
Niestety program konferencji był tak naładowany, że nie dało się już podyskutować. Szkoda.
Dlatego niniejszym zaczynam temat "porozmawiajmy o EAD".

[Kazimierz Schmidt]

Przyznam, że wg mnie EAD jest bardzo potrzebny i dobry do wykorzystania, ale w celu do którego został pomyślany a więc do zakodowania inwentarza archiwalnego w pliku XML o ustalonej strukturze. EAD jest jeszcze przydatny do wymiany danych (łącznie z "ucieczką" z systemu informatycznego, który staje się przestarzały, niewydajny lub po prostu za drogi).
Ale do wprowadzania danych, przechowywania tych danych, zarządzania tymi danymi potrzebny jest system informatyczny a nie EAD. Wg mnie zwrot "wdrożenie EAD" to nieporozumienie. Pisałem o tym już na naszym forum tutaj:
http://lublin.ap.gov.pl/ifar/ifarforum/viewtopic.php?p=2661#2661

Natomiast dziś usłyszałem po raz któryś z rzędu, że do opisu obiektów cyfrowych będacych wynikiem digitalizacji ma być zastosowany standard EAD. Bo tak rekomenduje Komisja ds Digitalizacji. To następne nieporozumienie. Niech przemówią za mnie sami Amerykanie. Zacytuję tutaj fragment postu który pisałem na innym forum (ukryte więc link nic nie da)
"Myślę że warto zauważyć iż sami Amerykanie z U.S. National Archives and Records Administration (NARA) w pracy czerwca 2004 roku (a więc w miarę nowej) o długim tytule:
"Technical Guidelines for Digitizing Archival Materials for Electronic Access: Creation of Production Master Files - Raster Images: For the Following Record Types- Textual, Graphic Illustrations/Artwork/Originals, Maps, Plans, Oversized, Photographs, Aerial Photographs, and Objects/Artifacts"
... wskazują Dublin Core jako standard do opisu minimum metadanych dla obiektów cyfrowych... bo innego standardu nie ma. Jeśli zaś Dublin Core nie jest bezpośrednio stosowany to mapowanie na elementy Dublin Core jest rekomendowane. Cytuję ze strony 7:
"„Descriptive metadata is not specified in detail in this document; however, we recommend the use of the Dublin Core Metadata Element set to capture minimal descriptive metadata information where metadata in another formal data standard does not exist. Metadata should be collected directly in Dublin Core; if it is not used for direct data collection, a mapping to Dublin Core elements is recommended."
Jako absolutne minimum uznawane jest podanie:
- identyfikatora
- tytułu
- twórcy
- wydawcy (jak sądzę, w tym przypadku tego kto kopię cyfrową udostępnia)
za ważne uznaje się podanie także dwóch dodatkowych elementów Dublin Core czyli typu i formatu.

Co do EAD znajdujemy tamże na stronie 7, ważne wg mnie spostrzeżenie: "... because ARC (Archival Research Calalog) will be used as the primary source for descriptive information about the holdings of permanent records at NARA, we refer readers to the LCDRG (NARA’s Lifecycle Data Requirements Guide) framework rather than discuss Encoded Archival Description (EAD) of finding aids.”
Jak widać specjaliści z NARA nie pozostawiają wątpliwości co jest "primary source for descriptive information"
Co to jest LCDRG można zobaczyć tutaj:
http://www.archives.gov/research/arc/lifecycle-data-requirements.doc

Podsumowując, pozwolę sobie zauważyć, że przyjęcie wprost EAD jako standardu metadanych dla kolekcji cyfrowej jest dyskusyjne. Jest to standard do cyfrowego opisu kolekcji (zespołu, zbioru) a nie do opisu cyfrowego obiektu cyfrowego, a to nie to samo.
Przypomnę, że na ostatnim spotkaniu Zespół roboczy ds. platformy wymiany informacji o digitalizowanych obiektach sugerował aby ustanowić minimum metadanych dla każdego digitalizowanego obiektu (opróćz metadanych technicznych, które i tak będa). Wydaje się zasadne aby takie minimum nazwać i określić. Sądzę, że oprócz ww. minimum koniecznie potrzebne jest jeszcze określenie przynależności do grupy (zbioru) dokumentów, a także (jeśli występuje) adresata dokumentu.

Dodam, że własnie dodanie informacji o przynależności do danej grupy dokumentów będzie kluczowe dla określenia kontekstu zdigitalizowanego dokumentu. Za pomocą tegoż spokojnie "trafimy" do właściwego inwentarza.

Dlatego ewentualna rekomendacja do stosowania tego (skądinąd przydatnego!) standardu powinna brzmieć mniej więcej tak:
"do tworzenia inwentarzy archiwalnych w formie elektronicznej stosuje się sandard EAD"
albo nawet lepiej tak:
"systemy informatyczne stosowane do opracowanie materiałów archiwalnych muszą posiadać możliwość prezentacji inwentarzy archiwalnych oraz eksportu i importu danych zgodnego ze standardem EAD"
oraz tak:"opis obiektów cyfrowych powstałych w wyniku digitalizacji materiałów archiwalnych musi zawierać co najmniej nastęujące elementy opisu:
- identyfikator
- tytuł
- twórcę zdigitalizowanego materiału archiwalnego
- adresata zdigitalizowanego materiału archiwalnego (jeśli można okreslić)
- twórcę obiektu cyfrowego
- okreslenie przynalezności do zbioru(zespołu) archiwalnego i jednostki archiwalnej"
Do tego ostatniego trzeba dodać XSD dla takiego opisu. Nic nie stoi na przeszkodzie aby użyć angielskich nazw znaczników elementów zgodnych z EAD.
W ten sposób będzie można np zlecac digitalizację całych partii materiałów archiwalnych wyspecjalizowanym firmom razem z wykonaniem podstawowego opisu. Digitalizacja będzie mogła ruszyć "z kopyta" i ruszyć z sensem. Będzie można szybko wykorzystać środki na nia przeznaczane.


ale na pewno nie tak:
"do opisu obiektów cyfrowych powstałych w wyniku digitalizacji materiałów archiwalnych stosuje się standard EAD"
ani tak:
"do opracowania materiałów archiwalnych stosuje się standard EAD"
mam nadzieję że widzą Państwo różnicę.

Oczywiście docelowo potrzebny jest system informatyczny który "widzi" jednocześnie wszystkie opracowane materiały archiwalne i ich skany. Ale struktura systemu i wymagania wobec systemu muszą być znacząco nadmiarowe w stosunku do EAD, który służy tylko do wymiany danych a nie do zarządzania nimi. Choćby dlatego żeby można było dla NDAP albo dla Ministra Kultury albo dla Komisji Europejskiej przygotować raporty specjalne zawierające informacje o realizowanych wskaźnikach przewidywanych rezultatów realizacji zadania (potrzebne do rozliczenia się z prawie każdych ekstra pieniędzy UE).
Takie "wskaźniki rezultatu" jak:
- liczba opracowanych jednostek archiwalnych w systemie,
- liczba zeskanowanych dokumentów dostępnych on-line,
- ilość zapytań do systemu (roczna),
- ilość zamówionych za pomocą systemu materiałów,
-  itd,
będą mogły być przygotowane jedynie w przypadku posiadania systemu informatycznego o większych niż EAD wymaganiach. Zob. powyżej link do opisu struktury systemu NARA.
Wtedy będziemy mieli wiedzę na temat potrzebnych kierunków digitalizacji, ewantulanego uszczegółowienia opisów w miejscach gdzie interesuje to naszych klientów itd.
cdn

Uprzejmie proszę o głosy polemizujące. Nie ma nic gorszego jak się człowiek napracuje żeby zebrać argumenty a potem słyszy w polemice tylko dwa przeciw:
- bo tak
- bo wszyscy tak robią (i Francuzi też)

Róbmy to, ale z sensem.
Aha, właśnie gada do mnie z telewizora minister Gajl. O co mówi? Innowacja jest potrzebna i na tym można zarobić. Są środki na innowację itd.

[kocibrzuch]

Urodziłem się nieco przytępy, a w dodatku po paru latach pracy w archiwum mam maleńkie fiksum dyrdum, tym niemniej wypowiedzieć się i popytać pragnę wielce:

1) Co do obiektów cyfrowych upierać się nie zamierzam, choć wydaje mi się, że wszystko powinno być w miarę możliwości w jednym.
2) Widok EAD/XML od kuchni mnie nie przeraża, w końcu można zamówić/zrobić nakładkę do wpisywania, i niech ona będzie nawet podobna konstrukcją do IZY, skoro już się ludziska przyzwyczaili. Inni sobie poradzili z tym „problemem”, a my boimy się nawet patrzeć na tagi?
3) Bardzo mi się spodobało rozwijalne drzewo w okienku po lewej, przedstawiające konstrukcję inwentarza, z możliwością dotarcia do konkretnego działu. Tak właśnie skonstruowane inwentarze akt staropolskich niekiedy mamy, a seria i podserie w IZIe sprawy nie rozwiązują (przy często bardzo głębokiej konstrukcji działów) w sposób satysfakcjonujący.
4) Sposób ułożenia w inwentarzu opartym na EAD jednostek wg. ich zawartości, a nie sygnatury (księgi błońskie) - to je ono! Tak można, za przeproszeniem, wtranżolić nie tylko późniejsze dopływy, ale także zgrabnie poukładać nasze (woj. krakowskie) księgi grodzkie i ziemskie, zgodnie z  Katalogiem Kutrzeby, w jednym ciągu, czyli z sensem. Nie wiem tylko jak rozwiązać sytuację, gdy jedna księga przynależy de facto do 2 lub 3 (lub więcej) różnych serii i we wspomnianym Katalogu widnieje w kilku miejscach.
5) Rozumiem, że EAD łyknie info dowolnych rozmiarów, możliwe więc jest nie tylko umieszczenie regestów co cenniejszych dokumentów w jednostce, ale także ewentualnie upchanie treści całej jednostki bądź jej części, która będzie widoczna niekoniecznie w inwentarzu, lecz po kliknięciu (nie mam na myśli przekierowania do dokumentu zapisanego w jakiejś aplikacji pod innym adresem, lecz tekst nieodrodnie obecny w systemie).
6) Zrobiła na mnie wrażenie możliwość oglądania inwentarza w różnych wersjach „widokowych” XML/standard/”ozdobny i przyjazny”/pdf/Word – jedno kliknięcie i szybkie przejście.
7) Porównanie IZY przez p. Wajsa do możliwości dokonań Boba Budowniczego się mi spodobało wielce . Nic, że zjadliwe, grunt, że trafne. Do spraw technicznych powinna być firma zewnętrzna - będzie lepiej i suma sumarum zapewne... taniej.
Czy fakt, że odbyło się w Warszawie kilka konferencji międzynarodowych dotyczących EAD oraz ostatnio warsztaty oznacza, że opcję przejścia się poważnie rozważa. Wyczuwam, może się mylę, pewien opór NDAP, być może związany ze znacznym zaangażowaniem się archiwów w IZĘ (dla kontrastu widzę znaczny entuzjazm AGAD-u). Jeśli już a priori nic by z tego miało nie wyniknąć, to po co te zjazdy i wydatki?
9) Co jest tańsze wreszcie? Dalsze „własnoręczne” dłubanie przy IZIe i współpraca z równie przyjazną dla użytkownika jak i jego portfela firmą Microsoft (kolejne wersje, kolejne stacje), czy konwersja z IZY (ze słów p. Wajsa wnosząc, niespecjalnie kłopotliwa) i wynajęcie, przykładowo obecnej na warsztatach przez swego przedstawiciela firmy Aleph Polska, która będzie się martwić o stronę techniczną, a archiwiści zajmą się tym, czym mają się zajmować? Zresztą nawet gdyby koszty miały być większe, tak duża instytucja państwowa, było nie było usługowa, powinna iść w stronę profesjonalizmu, a nie chałupnictwa.

[Maciej Zdunek]

Choc przyjechałem do Warszawy na warsztaty (to jednak zdecydowanie nieodpowiednie słowo) poświęcone EAD nastawiony optymistycznie i "z otwartą głową", jak radził mi nasz Admin, ale musze powiedzieć że nie czuję się dużo mądrzejszy. Chyba zabrakło konkretów, dyskusji, mozna było za to usłyszeć mnóstwo zachwytów, zaś argumenty mniej więcej odpowiadają temu, co wyżej zauważył Pan Kazimierz:

Nie ma nic gorszego jak się człowiek napracuje żeby zebrać argumenty a potem słyszy w polemice tylko dwa przeciw:
- bo tak
- bo wszyscy tak robią (i Francuzi też)

Jak ma to wygladać w praktyce? Jak ma wygladać "proces produkcyjny"? Czy EAD ma być narzędziem do inwentaryzacji, czy tylko narzadziem do jego publikowania w Internecie? Na czym bedzie polegała rola archiwisty?
Jest jeszcze wiele pytań i zagadek (warto przyjrzeć się temu, co pisze wyżej i w wątku o tym czy IZA jest potrzebna, Pan Kazimierz), natomiast jeśli chodzi o opis archiwalny nie zobaczyłem w Warszawie nic, co rzuciłoby mnie na kolana, a czego nie byłbym w stanie osiągnąć za pomoca IZY. Jeśli chodzi o sposób prezentacji w Internecie, to z wierzchu wyglada to porządnie, jednak naprawdę osłabiło mnie stwierdzenie, które padło w pewnym momencie prezentacji, że do wyszukiwania można użyć kombinacji CTRL + F  :shock: ... Sprawa wyszukiwania (co jest kluczowe dla prezentacji w Internecie) jest kluczowa i została poruszona dopiero w ostatniej prezentacji (DigiTool firmy ALEPH). Oprócz niej chyba jeszcze wystąpienie naszego Admina Rafała było dość konkretne (prezentacja kilku narzedzi do EAD - płatnych i bezpłatnych).
Również kwestia finansowa nie wyglada tak różowo jak to Kocibrzuchu przedstawiasz. Summa summarum wychodzi to chyba drożej niż licencje na Office`a.
Jestem za tym, abyśmy przyjrzeli się EAD i poznali bliżej. Ale chciałbym więcej konkretów, a mniej stwierdzeń w stylu "a bo inni używają", a więcej "dlaczego go używają?". Naprawdę, mam wielki głod wiedzy na temat EAD, ale na razie niezaspokojony. Korzystanie z doświadczeń zachodnich jest ze wszech miar chwalebne, ale chyba nie powinniśmy do tego podchodzić bezkrytycznie. Nie stać nas na to.

[Wojciech Woźniak]

Witam
Szanowny Kocibrzuchu pozwolę sobie odnieść się do wybranych części Twojej wypowiedzi:

4) Sposób ułożenia w inwentarzu opartym na EAD jednostek wg. ich zawartości, a nie sygnatury (księgi błońskie) - to je ono! Tak można, za przeproszeniem, wtranżolić nie tylko późniejsze dopływy, ale także zgrabnie poukładać nasze (woj. krakowskie) księgi grodzkie i ziemskie, zgodnie z  Katalogiem Kutrzeby, w jednym ciągu, czyli z sensem. Nie wiem tylko jak rozwiązać sytuację, gdy jedna księga przynależy de facto do 2 lub 3 (lub więcej) różnych serii i we wspomnianym Katalogu widnieje w kilku miejscach.

To nie jest zasługa xml, ani tym bardziej EAD. Takie sortowanie jest do zrobienia w... IZIE.

6) Zrobiła na mnie wrażenie możliwość oglądania inwentarza w różnych wersjach „widokowych” XML/standard/”ozdobny i przyjazny”/pdf/Word – jedno kliknięcie i szybkie przejście.

To również kwestia aplikacji. Z IZY też można wyprowadzić dane do Excela, Worda, a dalej do pdf. Nie jest to może kwestia jednego klinięcia, ale dla chcącego...

7) Porównanie IZY przez p. Wajsa do możliwości dokonań Boba Budowniczego się mi spodobało wielce . Nic, że zjadliwe, grunt, że trafne. Do spraw technicznych powinna być firma zewnętrzna - będzie lepiej i suma sumarum zapewne... taniej.

Tu akurat prawie zgoda. IZA jest tym na co nas - podobno - stać. Zintegrowany System Informacji Archiwalnej jest tym do czego zmierzamy. Może byłoby łatwiej, może taniej gdybyśmy mieli wlasną apliakcję bazodanową taką jak np. niemiecka Midosa niezależną od Microsoftu, ale jaki to ma związek ze stosowaniem EAD?

9) Co jest tańsze wreszcie? Dalsze „własnoręczne” dłubanie przy IZIe i współpraca z równie przyjazną dla użytkownika jak i jego portfela firmą Microsoft (kolejne wersje, kolejne stacje), czy konwersja z IZY (ze słów p. Wajsa wnosząc, niespecjalnie kłopotliwa) i wynajęcie, przykładowo obecnej na warsztatach przez swego przedstawiciela firmy Aleph Polska, która będzie się martwić o stronę techniczną, a archiwiści zajmą się tym, czym mają się zajmować? Zresztą nawet gdyby koszty miały być większe, tak duża instytucja państwowa, było nie było usługowa, powinna iść w stronę profesjonalizmu, a nie chałupnictwa.

Tyle że prezentacja wspomnianej powyżej firmy ograniczała się do pokazania narzędzi do prezentowania danych zakodowanych w xml zgdonie ze standardem EAD. Nie było mowy o narzędziu pozwalającym taki opis wygenerować. Takie narzedzia zaprezentowal Rafał. Nie są one zapewne złe, ale czy dziś jesteśmy gotowi porzucić IZĘ i zacząć stosować ktoreś z nich, choćby i freewarowe?

EAD na pewno jest użytecznym standardem i zapewne warto budować inwentarze zgodne z jego wskazaniami. Ale nie będziemy tego przecież robić w Notatniku  :twisted: Ważna jest więc kwestia narzędzia, aplikacji. Tu dochodzimy do tego o czym pisze pan Schmidt (powyżej i w wątku poświęconym ZSIA). Nie jestem informatykiem i moje zainteresowania tą tematyką są - powiedzmy - natury hobbistycznej, ale wydaje mi się, że mówiąc o wprowadzeniu EAD mówimy przede wszystkim o formacie w jakim mają być przechowywane dane (xml, z odpowiednimi znacznikami). Zgadzam się więc z panem Kazimierzem Schmidtem:

Dlatego ewentualna rekomendacja do stosowania tego (skądinąd przydatnego!) standardu powinna brzmieć mniej więcej tak:
"do tworzenia inwentarzy archiwalnych w formie elektronicznej stosuje się sandard EAD"
albo nawet lepiej tak:
"systemy informatyczne stosowane do opracowanie materiałów archiwalnych muszą posiadać możliwość prezentacji inwentarzy archiwalnych oraz eksportu i importu danych zgodnego ze standardem EAD"

Rodzi mi się w głowie (a właściwie narodziło we czwartek na ulicy Długiej) pytanie: a co z ISAD(G)? Szkoda, że zabrakło zestawienia obu standardów i wskazania róznic - myślę, że to by uporządkowało wiedzę i ewentualną dyskusję. Jak na mój obecny stan wiedzy EAD to ISAD(G) wzbogacony o wskazanie formatu zapisu danych (xml) oraz o dokładny opis znaczników (tagów) zamiast elementów opisu. A może inaczej - może EAD to uzupełnienie ISAD(G) o te właśnie elementy? Może ktoś z Szanownych Kolegów mnie tu oświeci?

[Kazimierz Schmidt]

EAD to ISAD(G) wzbogacony o wskazanie formatu zapisu danych (xml) oraz o dokładny opis znaczników (tagów) zamiast elementów opisu. A może inaczej - może EAD to uzupełnienie ISAD(G) o te właśnie elementy?

Właśnie tak. Jesli więc ktoś trzyma się struktury określonej w ISAD to zawsze może przedstawić dane w EAD. Z dobrego systemu informatycznego to jest automat. Ale jeśli ma dane dokładniejsze niż w ISAD (w rozumieniu "bardziej ustrukturalizowane") to też można to wyeksportować w EAD, bo bogactwo zdefiniowanych znaczników tego standardu na to pozwala. Jesli zaś ma jeszcze dokładniejsze (ponieważ specyfika archiwum tego wymaga)... to zawsze może to zgeneralizować do EAD.
I to jest OK cecha tego standardu. I nikt mu tego nie odmawia.
Gdyby jednak bibliotekarze mieli tworzyć opisu katalogowe w MARCu (każdy osobno) bez dedykowanego narzędzia typu "tu w tym okienku wpisz to" to ... hmm. Są poza tym narzędzia proste które pozwalają robić więcej błędów i takie które bardziej pilnują danych (wbudowane słowniki itp.). Czy to zły pomysł żeby wykorzystując środki UE na informatyzację (miliardy euro) zrobić coś więcej niż ręcznie rzeźbione inwentarze w EAD? A EAD byłby znakomitym pomysłem na zwiększenie "nośności" pomysłu jako podstawowy, uznany format do wymiany danych. Tym bardziej, że jak się wydaje dostępne dziś narzędzia to nie są systemy informatyczne do zarządzania materiałami archiwalnymi tylko raczej ... do tworzenia inwentarzy w EAD. Tak więc byłaby to innowacja jak najbardziej wpisująca się w "przekomercyjne zamówienia publiczne" o których coraz głośniej. Zwłaszcza nośna w momencie gdy przy okazji i2010 mówi się głośno o masowej digitalizacji. Taki system sprostałby tworzeniu opisów obiektów cyfrowych w standardzie opartym o Dublin Core (ale dokładniejszym nieco) i jednoczeńnie tworzeniu inwentarzy EAD-owych. Nie wspominając o module CRM wzorowanym na komercyjnych rozwiązaniach i WIKI dla naukowców... I to do nas będą przyjeżdzać się uczyć. W projektowaniu samochodów dobrzy raczej nie będziemy, gazu ani ropy też nie mamy... ale mamy głowy na karku i duże szanse na sukces.
Przepraszam, znowu sie rozpisałem. To już może lepiej przygotuję mejla do MNiSW, że jest taki pomysł na innowację. Może tym razem się uda. Na pewno jednak kto nie próbuje zdobyć naprawdę poważnych środków - nie dostanie ich.
Liczę, że NDAP poprze nie ograniczając się do "wdrożenia EAD".

[Wilknis]

Standard opisu jest znany od lat (modyfikowany oczywiście). Czy zdecydujemy się na eurepejski ISAD(G), czy anglosaski EAD, to mniejszy problem. Osobiście, jako tradycjonalista, wybrałbym pierwszy z nich. Większym problemem jest wybór narzędzia, a tym samym odcięcie pępowiny mającej drug koniec w Redmond. Wiadomo, że fundusze polskie nie pozwalają na szaleństwa, ale czy zakup licencji któregoś ze stosowanych narzędzi (albo właściwie systemów) nie byłoby tansze od produkcji od podstaw? Tu można sobie przejrzeć jak to robią za Odrą:
http://www.bundesarchiv.de/imperia/md/content/stab/daimo/1.ppt
A gdyby tak rozpisać projekt i zdobyć na to fundusze z UE?
A może jeszcze taniej - nawiązać współpracę z którąś z uczelni i niechby studenci w ramach projektów (prac magisterskich) zrobili całą czarną robotę?
Może niektóre z tych pomysłów wydadzą się bujaniem w obłokach, ale.. kto pyta nie błądzi  

[Kazimierz Schmidt]

Czy zdecydujemy się na eurepejski ISAD(G), czy anglosaski EAD, to mniejszy problem.

Małe wyjasnienie: jedno drugiemu nie zaprzecza
ISAD to standard (ogólny!) opisu, a EAD to sposób zapisu w formacie XML.
Tak więc:
1. Można przygotować inwentarz w EAD niezgodny z ISAD.
2. Można przygotować inwentarz zgodny z ISAD, ale nie w EAD.
3. Wreszcie, można przygotować inwentarz w EAD zgodny z ISAD. I do tego dążyć powinniśmy.

Ale z tym celem problemu nie ma i jak sądzę jest pełna zgodność. Tylko że taki cel jednym wystarcza a innym nie.
Staram się w tym wątku zwrócić uwagę, że aby przypilnować wykonania pkt 3 potrzebna jest aplikacja, która wspomoże wykonanie tegoż. Aplikacja któa tak jak IZA przypilnuje "tu wpisz to". O paru rowziązaniech mieliśmy okazję się dowiedzieć na seminarium. Między innymi o niemieckim "MIDOSA".
Ja uważam, że czy to IZA (bez względu czy zostanie przygotowany eksport inwentarzy archiwalnych w EAD z IZY), czy MIDOSA, czy ARCHON to nieco za mało - zwłaszcza w sytuacji gdy polskie archiwa państwowe mają wspólny mianownik = NDAP. NDAP który nie tylko wymaga robienia inwentarzy archiwalnych, ale także niemiłosiernie męczy archiwa państwowe sprawozdawczością i to na coraz inne sposoby. I to nie jest jego widzimisię tylko działania wynikające z tego, że jego męczy Minister Kultury. A może po prostu dlatego żeby wykazać zasadność wydawania środków publicznych przeznaczanych na archiwa.
A teraz gdy nadejdzie digitalizacja (w części za środki UE) to sprawozdawczość rozkwitnie jeszcze bardziej. Aby pokazac nie tylko co i ile zdigitalizwoano, ale jak to jest wykorzystywane. W zestawieniach miesięcznych na przykład. Gdyby był system zintegrowany to by raporty robił automatycznie. Życzę powodzenia tym którzy zechcą wyciągać takie dane z inwetarzy EAD. Za chwilę zacznie się tworzenie lokalnych baz danych do skanów. Żeby sprawozdać właśnie. A potem (jeśli nie będzie zestanadaryzowane) te dane będa wysyłane bez ładu i składu do NDAP i tam ręcznie przepisywane do raportów zbiorczych. Żeby MK mógł się wykazać w Komisji Europejskiej.
A poza tym czymże jest taki system w porównaniu w budową 1km autostrady, albo nawet z ilością roboczogodzin spędzanych przez pracowników archiwów na sporządzaniu sprawozdań. Nie mówiąc o korzyściach dla użytkowników dla których w końcu pracujemy.

[Wojciech Woźniak]

Witam
Dzięki tej dyskusji coraz bardziej klaruje mi się problemtyka, której jednak w ubiegły czwartek nie wyczerpano.  
Druga część konferencji nosiła zaczepny tytuł: "Dlaczego EAD?" Najczęstszą odpowiedzią było: inni stosują, więc my też powinniśmy. A czy nie jest tak, że jeśli chcemy stworzyć metadane wymienialne w skali międzynarodowej to wyboru nie ma? Może zamiast pytać: dlaczego? należy zacząć pytać: kiedy? I nie pytać: kiedy EAD?, lecz - jak słusznie "wałkuje" pan Kazimierz Schmidt - kiedy ZSIA?

[Rafał Rufus Magryś]

Witam,

I nie pytać: kiedy EAD?, lecz - jak słusznie "wałkuje" pan Kazimierz Schmidt - kiedy ZSIA?

-słusznie!
 
Czy się zdecydujemy na EAD czy się zdecydujemy na coś innego to nie jest takie istotne, ważne wg mnie są dwie sprawy: żeby były narzędzia i żeby były to narzędzia open source no i żeby przechowywały dane w otwartym formacie...  nie możemy "wiecznie" dziergać musimy mieć narzędzia żeby zacząć pracować...
A powracając do dyskusji na temat EAD czy jest to dobre rozwiązanie czy złe -najlepiej wyrobić sobie  opinie wpisując się na listę mailingową EAD

ead listserv

An unmoderated listserv (ead@loc.gov) is open to developers and implementers of the EAD DTD. To subscribe to the forum:

1. send email message to:
    listserv@loc.gov

2. the text of the message should be:
    subscribe ead your name

----> ze strony http://www.loc.gov/ead/

Pozdrawiam

[Wojciech Woźniak]

Witam
Na stronach NDAP pojawiła się część materiałów z warsztatów:
http://www.archiwa.gov.pl/?CIDA=777

[Wojciech Woźniak]

Witam
Na stronach ArchNetu (http://www.archiwa.net/) pojawiła się informacja o III Europejskiej Konferencji o EAD, EAC i METS (http://www.bundesarchiv.de/instada/de/index.html?lang=de)