![epl.icm.edu.pl Forum Index](templates/subSilver/images/logo_phpBB.gif) |
epl.icm.edu.pl Forum dyskusyjne o tematach związanych z e-Administracją i digitalizacją
|
View previous topic :: View next topic |
Author |
Message |
jarwyp
Joined: 14 Mar 2005 Posts: 138 Location: ICM
|
Posted: Tue Jun 28, 2005 9:36 am Post subject: Zapisywanie metadanych i dokumentów - razem czy osobno ? |
|
|
Pytanie to padło na forum o zasadach postępowania, i wydało mi się na tyle istotne, że przonoszę je tutaj. Poniżej cytuję oryginalne posty:
madyogi wrote: | Stoję (i dwóch współpracowników) przed problemem utworzenia e-urzędu. Jasne jest dla mnie, że z czasem w urzędzie zacznie się gromadzić mnustwo dokumentacji podpisanej cyfrowo (głównie będą to z pewnością jakieś dok'i).
1. Chciałem zapytać jak powiązać te pliki z formatem XML, tak by można było je poddać archiwizacji zgodnie z opracowywanym standardem EPL? Czy pojedyncze dokumenty (bądź całe ich archiwa) będą musiały zostać "opakowane" w tagi XML'owe i zapisane w formacie XML? (Czy nie uszkodzę w ten sposób cyfrowo podpisanego dokumentu, unieważniając go tym samym?) Czy też pliki XML'owe będą faktycznie tylko "metainforamcją" o innych plikach. Tak, że ingerencja w cyfrowo podpisane materiały nie będzie konieczna? Przykład: "archiwumrada2004.zip" (z uchwałami rady za 2004r.) bedzie sobie leżało na jakimś serwerze ftp, ktoś zainsteresowany zaprzęgnie do pracy wyszukiwarkę, której zadaniem będzie odszukanie w zbiorach XML odpowiedniej informacji, o archiwum łącznie z linkiem na serwer FTP do szukanego zbioru?
Dodam, że nie wszystkie materiały mają charakter publiczny - np sprawy obywatelskie (paszporty). Tu się kłania drugie elektroniczne archiwum, do którego nikt nie ma wejścia poza adminem (i szefem Very Happy, no i grupą pracowników merytorycznie zajmującym się danym tematem). Czy takie archiwum też "standaryzować" domniemam, że tak. Smile |
oraz drugi:
wkuk wrote: | może jest tu miejsce na coś, co byłoby odpowiednikiem HTMLowego <BODY></BODY> ? wewnątrz tego byłoby miejsce na KOMPLETNY dokument zapisany w tagach XML, a jeśli się nie da (jeśli jest to plik typu JPG/PDF), zawartość binarna byłaby zakodowana np. w BASE64, lub zawarty byłby tam odnośnik do załącznika, wraz z danymi typu suma kontrolna, md5, typ mime....
myślę, że gdyby istniała możliwość bezpośredniego umieszczenia, czy transportu dokumentu w formie XMLowej, byłoby to z pożytkiem dla całej technologii - wymusiłoby na producentach oprogramowania, a w dalszej kolejności na ich klientach, pewne zdrowe nawyki - przeciwne do opisanych przeze mnie poniżej:
...(editor's cut)... |
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
madyogi
Joined: 24 Jun 2005 Posts: 2 Location: Chodzież
|
Posted: Wed Jun 29, 2005 2:00 pm Post subject: |
|
|
Quote: |
myślę, że gdyby istniała możliwość bezpośredniego umieszczenia, czy transportu dokumentu w formie XMLowej, byłoby to z pożytkiem dla całej technologii - wymusiłoby na producentach oprogramowania, a w dalszej kolejności na ich klientach, pewne zdrowe nawyki. |
Jeśli mam być szczery to jestem jak najbardziej za tym by nsz XML'owy pliczek był oddzielony od oryginału. Naprawdę ułatwi to życie (przynajmniej mi, jako temu który ma pisać cały serwis dla urzędu). Próba wbicia do głowy info, o tym że nie wypada wysyłać komuś 130MB'ajtowej wiadomości z skanów naprawdę graniczy z cudem (nawet jeśli technicznie serwer dawał by taką możliwość).
Co do producentów oprogramowania - hmm nie wiem jak w innych miejscach ale ulubionym standardem biurowym jest dzieło Mic....u, którego namówić się pewnie nie da na cokolwiek. OpenOffice tak nielubiany przez kochanych urzedasów (bo sie im spacje rozjeżdżają) to darmowa alternatywa z otwartym kodem i tu programiści C++ już mogli by popis dać.
Na siłę można by pozostać przy wykonywalnym małym exe'ku, który by nam dowolny plik (już bez znaczenia czy obraz czy grafikę czy cokolwiek) "opakował" w tagi xml tak jak standard EPL tego wymaga.
Pozostaje jeszcze czas wyszukiwania... Czy ktoś kto po wpisaniu zapytania i wciśnięciu wyszukaj ma na wynik czekać 10 sekund/ godzinę czy tydzień??? bo nasz biedny serwer będzie parsował ogromne pliki XML.
Prościej będzie wszelkie info o dokumentach gromadzić w SQL'owych bazach i małych plikach XML i na zapytania z wyszukiwarek odpowiadać poprzez parsowanie takich plików (zwłaszcza na szczeblu centralnym, mały urząd jakoś sobie jeszcze pewnie poradzi).[/i] |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
jarwyp
Joined: 14 Mar 2005 Posts: 138 Location: ICM
|
Posted: Wed Jun 29, 2005 8:14 pm Post subject: Według mnie osobno |
|
|
Osobiście byłbym za rozdzieleniem obu rzeczy. Dokument to dokument. Metadane to metadane. Jedyny istotny zysk to uproszczenie przekazywania dokumentów, jako przy opakowywaniu każdy dokument jest samoopisujący (niestety ten argument może się okazać dominujący). A tak przesyłając dokument elektroniczny trzeba będzie dodatkowo przesyłać jego metadane. Tak więc pakowanie obu części w jedno może okazać się elementem koniecznym w administracji - ale to paskudne utrudnienie. Nie widze tutaj prostego wyjścia. Nie ma możliwości narzucenia konkretnych formatów dokumentów (przynajmniej na dzień dzisiejszy). Pozostaje określić odpowiedni format (może właśnie z takim dołączeniem dokumentu do metadanych) paczek na przesyłanie dokumentów elektronicznych i rozporządzeniem o postępowaniu z dokumentacją elektroniczną narzucić wszystkim od razu ten format jako jedyny dopuszczalny przy wymianie dokumentów elektronicznych pomiędzy podmiotami określonymi ustawą ... . Konieczne będzie dostarczenie odpowiednich narzędzi, umożliwiających takie przekazywanie, ale ... to pieśń przyszłości. Chyba, że jest jakiś lepszy pomysł. Tak czy owak trzeba się jeszcze nad tym zastanowić. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
AO
Joined: 01 Apr 2005 Posts: 14 Location: NDAP
|
Posted: Thu Jul 21, 2005 2:54 pm Post subject: A email? |
|
|
A gdyby wyobrazić sobie dokumenty na wzór emaila, gdzie metadane "opakowują" dokument i/lub dokumenty właściwe. FW daje możliwość dodania metadanych do przesyłanego dokumentu itd.
Opakowywanie dokumentów metadanymi rozwiązuje wiele problemów: np. znika problem kategoryzacji poziomów.
1. metadane opisujące dokument
2. metadane opisujące zbiór dokumentów (jakie kryteria?)
3. a elektryczny podpis?
Metadane - raczej z dokumentem, ale też z możliwością exportu do oddzielnego pliku. Czyli: itak i tak. Nasuwa się analogia do rozwiązań znanych z PGP, sprawdzonego od lat.
AO |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kwojsyk
Joined: 22 Mar 2005 Posts: 13 Location: UM Częstochowy
|
Posted: Thu Jul 21, 2005 10:08 pm Post subject: |
|
|
Szanowni,
uważam, że przed dalszą dyskusją warto byłoby zapoznać się z materiałami zamieszczonymi u dołu strony http://www.ms.gov.pl/homologacja/homologacja.shtml
(materiały spakowane do ściągnięcia).
Dotyczy to sądownictwa i specyficznego sformalizownia tamtejszej "przestrzeni informacyjnej", ale w administracji publicznej mamy do czynienia dokładnie z tym samym problemem. Przykład - akta stanu cywilnego (druki i ich zawartość) dzisiaj i 100 lat temu...
Pozdrawiam
Kajetan Wojsyk |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Mon Aug 01, 2005 11:27 am Post subject: zapoznałem się czyli co standaryzować? |
|
|
zapoznałem się z http://www.ms.gov.pl/homologacja/homologacja.shtml
(przy okazji: materiały spakowane zip-em sygnalizuje mi jako uszkodzone, spakowane rar-em udało mi sie rozpakować dopiero najnowszym 7-zip-em - przypominam że Winrar nie jest darmowy!)
Wszystko wskazuje na to że juz niedługo będziemy mieli do czynienia z tak różnymi strukturami dokumentacji elektronicznej że ... nie da się potem nad tym zapanować. Mówiąc "po archiwalnemu" co zespół archiwalny to inna struktura. I cóż z tego, że będzie to "odczytywalny" XML jeśli nijak "jego" metadane nie będą się "mapować" na metadane wytworzone przez np. Ministerstwo Skarbu. Mając za 50 lat zebraną w archiwum państwowym dokumentację elektroniczną zamiast papierowej i tak w obrębie każdego zaspołu będą dokumenty elektroniczne o tak różnej strukturze, że bardzo trudno będzie zadać np takie np pytanie:
"znajdź mi wszystkie dokumenty audiowizulane lub prezentacje multimedialne dotyczące budowy autostrad w województwie mazowieckim, sporządzone w październiku 2009, pogrupuj dokumenty i posortuj wyniki wg instytucji w których zostały odnalezione, w każdej instytucji pokaż listę spraw w których zostały odnalezione"
Wyobrażam sobie że takie pytanie zadaje ktoś kto prowadzi studia nad klapą kolejnych programów budowy autostrad w Polsce w pierwszej dekadzie XXI wieku.
Niestety przeszukanie wszystkich instytucji i posortwanie wg zadanych kryteriów będzie niemożliwe ponieważ dla różnych instytucji te kryteria będą inne (oczywiste), ale jednocześnie nie będzie jednego wspólnego mianownika. Czasem obawiam się że skończymy na takim samym poziomie ogólności jak dzisiejszy spis zdawczo-odbiorczy dla dok. papierowych tj.:
znak teczki
tytuł teczki (to samo co znak teczki tylko niezakodowane)
liczba stron
daty skrajne
Przecież daty i liczba stron "zapisują się" w metadanych technicznych - To może wystarczy tedy wynaleźć w treści znak akt i sprawa załatwiona...
Parę szczegółów:
Przeglądając XSD (np spraw) nie mogę się oprzeć wrażeniu, że mówiąc w uproszczeniu "upchnięto dane w strukturze rekordu". Inaczej mówiąc zamiast standardu metadanych mamy standardowe formularze. Nie jest dla mnie przekonujące wchodzenie w tak duży poziom szczegółowości. Np. Po co wyróżniać "wniosek o zatrzymanie prawa jazdy" jako oddzielny typ dokumentu? Np. nie ma osobno wniosku o zatrzymanie licencji pilota? I wniosku o zatrzymanie praw do wykonywania zawodu lekarza? Takie dokładne podejście obejmujące na całą sferę publiczną spowodowałoby konieczność powstania kilku tysięcy (albo i więcej) typów dokumentów. Konsekwencje takiego dokładnego podejścia będą takie, że nigdy nie uda się domknąć listy typów, a jesli się nawet uda to każda drobna zmiana w przepisach spowoduje konieczność kosztownych zmian w systemach (homologowanych!) - tak aby były w stanie odczytywać nowe formularze.
Daltego wydaje mi się, że przy okazji ogromnej pracy wykonanej przez CORS należy zadać sobie następujące pytanie czy w standaryzacji należy iść w kierunku:
1. prób stworzenia bardzo ogólnego standardu metadanych możliwego do zaakceptowania przez wszystkich (jak e-pl czy przejęcie wprost DublinCore)
2. tylu standardów metadanych ile rodzajów działalności
3. po prostu skupienia się na możliwości odczytywania dokumentacji bez jej porządkowania = pozostania na poziomie metadanych technicznych i formatów zapisu.
4. I co wynika z pkt 3: standaryzacji pliku w którym zapisane byłyby pisma formularze itp. (np . ostatnio prowadzona w zespole powołanym przez MNiI dyskusja o tym czy OpenDocument czy nie).
mam nadzieję że tu zabłądzi ktoś z CORS i stworzymy nowy temat do dyskusji. _________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kwojsyk
Joined: 22 Mar 2005 Posts: 13 Location: UM Częstochowy
|
Posted: Fri Aug 05, 2005 11:53 pm Post subject: Razem, czy osobno - głos w dyskusji... |
|
|
Szanowni,
od dłuższego już czasu w moim urzędzie używany jest przez kilkaset osób elektroniczny obieg dokumentów. Wypowiem się więc jako użytkownik, a jednocześnie ktoś, kto obserwuje zachowania innych użytkowników, bo ktoś musi nad tym czuwać, nie można działać na oślep. A zatem po kolei:
W moim przekonaniu metadane powinny być oddzielone od dokumentu. Traktowałbym to jak ogniwa łańcucha stanowiące pewien zestaw, ale jednak odrębnych funkcjonalnie elementów.
W elektronicznym obiegu dokumentów (mówię o konkretnej implementacji) metadane są dwojakiego rodzaju; jedne są niesione wraz z samym dokumentem - są to metadane różne - zależnie od tego, w jakim edytorze były wytworzone dokumenty. Proszę w tym samym dokumencie wytworzonym np. w Wordzie zobaczyć "właściwości" w Wordzie właśnie i w OpenOffice - widzimy różnice). Inne metadane są OBOWIĄZKOWO dopisywane w trakcie dalszego przetwarzania - bez nich nie da się sprawy elektronicznie ruszyć dalej. Np. nie można zadekretować pisma na konkretnego pracownika, jeśli wcześniej nie zostanie on wprowadzony do systemu (nazwisko, imię, komórka organizacyjna itd.). W świecie realnym wystarczyłoby wręczyć komuś dokument i nie zaznaczyć tego nigdzie - w elektronicznym obiegu każde przeczytanie (otwarcie) dokumentu skutkuje dopisaniem nazwiska osoby zalogowanej do systemu i otwierającej dokument do listy czytelników wraz z datą i czasem odczytu. Krótko mówiąc, tych metadanych wprowadzanych przez operatora DOŁĄCZAJĄCEGO plik (w postaci *.txt, *.tif, *.jpg, *.sxw, *.sxc, *.xls, *.zip) czy jakiejkolwiek innej jest ileś tam. Jedne pochodzą ze słowników, inne wpisywane są "z palca", ale wszystkie POZA TREŚCIĄ samego pliku dołączanego. Istnieje jeszcze, oprócz stale poszerzanego słownika słów kluczowych bardzo cenne pole "opis" - w którym mieszczą się teksty dopisków, uwag, komentarzy osób przetwarzających dokumenty. Np. u nas wymyślono umowny znak "(!)" oznaczający pismo ważne, które nie powinno w żadnym wypadku zniknąć z pola widzenia. Jeśli więc w wyszukiwarce (bardzo wyrafinowanej) w polu opisu wpiszemy "(!)", znajdziemy wszystkie ważne dokumenty w zadanym okresie czasu...
Zmierzam do tego, że tak naprawdę wystarczy, by absolutnie obowiązkowo stosować metadane, które już są utrwalone w naszej archiwalnej tradycji, lecz dodatkowo znormalizować je i poszerzać o takie dodatkowe pola, które są pomocne, ale w istocie inaczej jak "opis" nazwać ich nie można.
Pan Kazimierz S.(człowiek, który z mojego punktu widzenia ma jedną zasadniczą wadę: nie mogę z Nim dyskutować, bo niestety zawsze się z Nim w 100% zgadzam) zauważył, że można zadać skomplikowane pytanie dotyczące budowy autostrad... Otóż wystarczyłoby właśnie owo jedno jedyne słówko "autostrada" wpisać w pole "opis" - i po sprawie...
Gdyby przyjąć pewien ELEMENTARNY zestaw metadanych i wprowadzić w administracji wymaganie, (takim samym wymaganiem jest instrukcja kancelaryjna), że systemy informatyczne służące do przyjmowania, przetwarzania, składowania i archiwizowania danych MUSZĄ spełniać określone kryteria techniczne, do których zaliczyłbym właśnie tworzenie owych metadanych dołączanych do dokumentu, zaś sam dokument mógłby być czymkolwiek (*.txt, *.tif, *.jpg, *.sxw, *.sxc, *.xls, *.zip), to i tak byłbym do przodu. A do tego wszystkiego można jeszcze znaczącą grupę dokumentów tak rozłozyć na elementy pierwsze, że metadane stałyby się częścią samej treści dokumentu. Tyczy się to w szczególności wszystkich druków, jakie funkcjonują w administracji. Np. tzw. formularze ekranowe pozwalałyby na wprowadzanie danych w postaci czystego tekstu, bez żadnych ozdobników, a dane osobowo-adresowe mogłyby być pobierane bezpośrednio z odpowiednich rejestrów i baz...
Wróćmy do dokumentu tworzonego np. w Wordzie czy OpenOffice - jeśli tekst samego dokumentu widoczny na ekranie wkleimy do NotePada to pozbawimy ten dokument od razu wielu metadanych - i tak naprawdę znowu okaże się, że część metadanych wprowadzonych jest świadomie przez użytkownika i stanowi część treści dokumentu (kto pisze, do kogo pisze, w jakiej miejscowości, którego dnia itd. Część zgubiona (np. data na dokumencie i rzeczywista data wytworzenia dokumentu mogą być zupełnie odległymi datami) niepokoi nas - i to jest przyczyna naszego rozchwiania.
Podszedłbym do tego tak: elektroniczne urządzenia przyjmujące dane czy dokumenty w administracji (skanery i sprzężone z nimi obiegi dokumentów, infomaty) dołączają swoje dane w postaci standardowej - które to standardy ustaliłby Minister Nauki i Informatyzacji, odpowiednie pola formularzy ekranowych przyjmują dane podawane przez interesanta, a reszta jest już bajką i poezją - czyli technologią.
Całego świata naraz uporządkować się nie da, ale można robić to pewnymi obszarami.
W administracji znaczącą część dokumentów daje się sparametryzować i rozbić na elementy (o tym na naszym forum już dłuższy czasu trwa dyskusja). Ja poprzestałbym na elementach ABSOLUTNIE niezbędnych - zostały one ujęte w e-PL i już wystarczy.
Pozdrawiam
Kajetan Wojsyk |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Tue Sep 06, 2005 2:00 pm Post subject: metadane w pliku czy poza nim? |
|
|
Jeszcze parę przemyśleń:
Pierwsza odpowiedź nasuwa się taka: nie narzucajmy tego JAK ma być zapisane tylko CO, gdyż sposoby zapisu danych (JAK) będą się w czasie zmieniać a zapisane dane nie...
Zawsze będzie tytuł, autor, data, adresat, tematyka, kategoria archiwalna itd... Ale nie zawsze będzie SXW, DOC, XML... pamiętacie jeszcze, że kiedyś był CHI, TAG...?
OK, problem dowiązywania metadanych do samych plików nie istnieje dla plików SXW, DOC, HTM, JPG, TIF itd... ale schody zaczynają się i przy plikach txt i przy "dokumentach elektronicznych złożonych" czyli np wieloplikowych bazach danych, a także przy "dokumentach elektronicznych fizycznych" czyli płytach z zawartością stanowiącą całość... Taki fizyczny nośnik może być wszak dowodem w sprawie sądowej... Tedy może tak być, że podawanie nie tylko formatu zapisu ale i fizycznego nośnika będzie ważne. Taki sąd nie wyobraża sobie pracy inaczej, jak odniesieniu do konkretnego nośnika fizycznego (warto zauważyć że przedmiotem badań były np. "dyski Jakubowskiej" a nie "poczta elektroniczna Jakubowskiej"
Dlatego wg mnie odpowiedź jest chyba następująca:
Metadane poza plikiem "przywiązane" do pliku za pomocą trwałego identyfikatora i jezeli to możliwe to zapisane także w samym pliku.
To, że nie zawsze jest to możliwe opisałem powyżej.
Trwały identyfikator to: np nazwa pliku skonstruowana na zasadzie REGON+kodkomórki+rok+nrkolejny - to jest do ustalenia jak m się wydaje?
Dlaczego boję się zapisywania metadanych tylko w samym pliku? Przypomnę przykład standardu IPTC stosowanego do wymiany fotografii cyfrowych do i z agencji prasowych. Standard zaproponowany przez Adobe'a "przenoszony" jest przez pliki TIF i JPG. Otóż przesyłając fotkę np do AFP czy Reutersa (ale także i do Gazety Wyborczej i wielu innych polskich tytułów ) dziennikarz musi zapisać metadane w tym standardzie. Dzięki temu zczytywanie i indeksowanie informacji w agencji (gazecie) odbywa się błyskawicznie. Znakomicie działa tu zasada samopoprawiającej się jakości opisu: otóż jeżeli fotoreporter nie poda metadanych zgodnych z IPTC wydawca nie wyszuka takiej fotki wśród 1000 innych z tego dnia i... nie będzie publikacji = nie ma kasy. Proste. Podobnie "działa" amerykański standard ONIX (Online Information Exchange) dla publikacji. Biznes sobie radzi bo ... musi.
Jest jednak tu małe ale: jeżeli w instytucji publicznej "coś" zlikwidowałem. usunąłem albo co gorsza zostało usunięte w wyniku działalności jakiejś "grupy trzymającej władzę" to powinien gdzie indziej zostać slad co takiego usunięto. Jeżeli cała metainformacja jest "/itself/" w pliku to niestety usuwając plik nie mam już nic. Pustka, amba... Na takie coś nie pójdą chyba prawnicy, ale nie tylko oni. Np. mnie się to też nie podoba.
(Dość nowa historia z jednej z telewizji: mieli parę ważnych plików wizyjnych zapisanych na dyskach twardych. Metadane były oczywiście "w pliku". Zabezpieczenia standardowe czyli macierz dyskowa. Dyski padły naraz. I koniec. Nie ma nic. Teraz sami nie wiedzą nawet co stracili i co powinni próbowac odzyskać od kooperujących stacji) _________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
AO
Joined: 01 Apr 2005 Posts: 14 Location: NDAP
|
Posted: Wed Sep 14, 2005 10:30 am Post subject: Razem czy osobno? c.d. |
|
|
Być może wyraziłem się niezbyt precyzyjnie, za co przepraszam. Spróbuje dokładniej.
Według mnie:
1. Z pojedynczym dokumentem - razem (np. p. Czesiek piszacy w domu pismo do Wodociągów)
2. W systemie przetwarzajacym wiele dokumentów - osobno (np. pisma wytworzone w Wodociągach - osobno, a w przypadku konieczności lub chęci wydzielenia (wyeksportowania) takiego pisma na zewnątrz metadane są wstawiane do środka (razem)
AO |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|