![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 |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Sun Oct 16, 2005 9:41 pm Post subject: propozycja projektu rozporządzenia dotyczącego struktury |
|
|
W załączeniu propozycja projektu rozporządznia dotyczącego struktury. Nie jest to projekt tylko jego propozycja. Jest to dotychczasowy rezultat prac zespołu roboczego MNiI-NDAP. Intergralną cześcią tej propozycji jest załącznik opisany w temacie "standard struktury wersja 02.1".
Description: |
szkic projektu rozporządzenia dotyczącego struktury dokumentów elektronicznych |
|
![](images/icon_clip.gif) Download |
Filename: |
struktura_szkic_09.doc |
Filesize: |
34 KB |
Downloaded: |
3756 Time(s) |
_________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Thu Oct 20, 2005 11:39 am Post subject: struktura szkic wersja 010 |
|
|
W załączeniu uzgodniona propozycja projektu rozporządznia dotyczącego struktury po zmianach wprowadzonych w dniu 19 października. W stosunku do wersji 09 Wprowadzono następujące zmiany:
1. Dopisano paragraf 1 ustalający co określa rozporządzenie (tak jak to jest przyjęte dla tego typu dokumentów)
2. Wprowadzono zmiany polegające na odróżnieniu pojęcia samej struktury od wypełniania tej struktury danymi. W poprzedniej wersji (09) nie było to jasne. Teraz paragraf 2 mówi o zapisywaniu dokumentów elektronicznych w okręslonej w załaczniku strukturze a dopiero paragrafy 4 i 5 określają dla których elementów struktury podawanie wartości jest obowiązkowe. W ten sposób mamy do czynienia z dwoma "szczeblami":
- pierwszym jest uwzględnienie w minimalnej strukturze metadanych możliwości zapisania wszystkich wymienionych w załączniku elementów (czyli chodzi o zdefiniowanie struktury)
- drugim jest obowiązek wypełnienia danymi wskazanych elementów (czyli chodzi o wypełnianie tej struktury).
3. Do osobnego paragrafu (3) wyłączono obowiązek zapisywania metadanych w sposób umożliwiający ich "automatyczne" czyli maszynowe wyodrębnienie.
Uwaga! Uzgodnienie w zespole roboczym tej propozycji nie oznacza:
1. Że zostanie ono zaakceptowane przez MNiI w tej formie (przed tym tekstem cała droga konsultacyjna określona przepisami prawa).
2. Że uzgodniono kluczowy dla tego rozporządzenia załacznik będący ogólnym standardem metadanych. Niestety tu jeszcze nie udało się wypracować wspólnego stanowiska. Postaram się opisać problemy w wydzielonym osobno temacie "standard struktury wersja 02.1".
Dodatkowe objaśnienia
dla tych którzy uważają że "automatyczne wyodrębnianie" metadanych jest niepotrzebne:
Chodzi o to aby nie "załatwiano" sprawy podawania wartości metadanych za pomocą zeskanowanej pieczęci nagłówkowej, albo tekstu treści dokumentu. Spotkaliśmy się już z opinią że przecież jeśli w treści piśma stworzonego za pomocą edytora tekstu jest już i adresat, i twórca, i data to sprawa jest załatwiona... Wszak informacje te są dostępne. Ideą standaryzacji metadanych jest właśnie to aby nie tylko dawały się one przeczytać ale i automatycznie wyodrębnić a nie być ... przepisywane przez pracowników kancelarii czy też archiwum.
Nie podano jednak w jaki sposób (technicznie) zapisać owe metadane. Dlaczego objasniono to na tym forum w temacie "jak to zapisać w rozporządzeniu" Temat postu: "struktura szkic_06".
dla tych którzy uważają że powinno okręslić się wyłącznie strukturę nie podając jednocześnie w jakiej częsci powinna ona być wypełniona danymi:
Takie podejście nie jest niczym nowym. Podobnie sprawę rozwiązano w australijskim AGLS, brytyjskim eGMS, amerykańskim DOD5015 i UEuropejskim Moreq (linki do znalezienia na tym forum). Tamże także narzucono obowiązującą strukturę podając jednocześnie które elementy mają być wypełnione danymi.
Dla przykładu podam, że w AGLS obowiązkowe wypełnianie danymi jest dla elementów:
Twórca
Tytuł
Data
Tematyka lub Funkcja
Identyfikator lub Dostęp
dla eGMS dla elementów:
Twórca
Tytuł
Data
Tematyka (tylko kategoria główna - GCL)
(oraz, jeśli występują):
Identyfikator, wydawca, dostęp.
a dla DoD5015.2-STD:
Unikatowy identyfikator
Temat lub Tytuł
Typ
Format
Daty (zapisania, publikacji, otrzymania)
Autor (osoba)
Adresaci
Instytucja odpowiedzialna
dla Moreq są to:
unikatowy identyfikator
identyfikator (uwaga to tytuł!)
Temat
Autor
Media Type
Preservation metadata (format, itp.)
Daty (zapisania, publikacji, otrzymania)
Warto zwrócić uwagę, że Moreq najbardziej "odstaje" od pozostałych.
Dlatego mapowanie na elementy AGLS i eGMS (poza oczywistym mapowaniem na Dublin Core) jest w wersji 02.1 załącznika uwzględnione.
Description: |
struktura_szkic wersja 010 z 19 października 2005 |
|
![](images/icon_clip.gif) Download |
Filename: |
struktura_szkic_10.doc |
Filesize: |
34 KB |
Downloaded: |
3254 Time(s) |
_________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Tue Jan 03, 2006 4:22 pm Post subject: szkic wersja 11 |
|
|
W załączeniu wersja 11 szkicu rozporządzenia. W stosunku do wersji 10 ważniejsze zmiany to
1.
Uproszczenie zapisów bez zmiany ich znaczenia. Na przykład zamiast:
"Metadane, powinny być zapisywane w sposób umożliwiający ich automatyczne wyodrębnienie"
jest:
"Metadane zapisuje się w sposób umożliwiający ich automatyczne wyodrębnienie"
itd.
2.
Zmiana merytoryczna w §2 polega na tym, że metadane nie są powiązane z treścią dokumentu tylko z dokumentem.
To wbrew pozorom ważna poprawka gdyż np. format odnosi się do dokumentu jako takiego a nie do jego treści, tematyka już tylko do treści...
3.
Zmieniono MNiI na MSWiA zgodnie ze zmianami w kompetencjach ministerstw.
Dodaję też ostatnią wersję załącznika który jest kluczowy dla rozporządzenia. W stosunku do wersji 04 z 2005-11-18 nie ma żadnych zmian poza "dodaniem" właściwego ministra To tu jest podstawowy materiał do dyskusji. Dlaczego ma on taki kształt opisano w temacie "jak to zapisać w rozporządzeniu?"
Description: |
struktura_szkic wersja 11 z dnia 2006-01-02 |
|
![](images/icon_clip.gif) Download |
Filename: |
struktura_szkic_11.doc |
Filesize: |
36.5 KB |
Downloaded: |
3262 Time(s) |
Description: |
załacznik do struktury wersja 04a z 2005-11-18 |
|
![](images/icon_clip.gif) Download |
Filename: |
struktura_zalacznik_04a.doc |
Filesize: |
495 KB |
Downloaded: |
3433 Time(s) |
_________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Wojciech Woźniak
Joined: 11 Jan 2006 Posts: 1 Location: Opole
|
Posted: Fri Jan 20, 2006 12:59 pm Post subject: |
|
|
Witam
Wydaje się że należy śpieszyć się z uchwaleniem rozporządzeń, bo rzeczywistość pędzi. Oto na Opolszczyźnie rozstrzygnięto właśnie przetarg na realizację projektu eUrząd, w ramach którego zachodnia firma zbuduje do 30 VI 2006 (sic!) system infromatyczny i wyposaży weń 70 % gmin naszego słonecznego województwa. Wątpliwości budzi więc kwestia: czy ów system będzie dostosowany do projektowanych wymagań, a ściślej czy rozporządzenie zdąży wejść w życie, czy też... trzeba będzie firmie dopłacić za przystosowania systemu już po jego uruchomieniu? Więcej infromacji nt. projektu: http://miasta.gazeta.pl/opole/1,35086,3105548.html
_________________ pozdrawiam
wojtek w. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pemi
Joined: 18 Jan 2006 Posts: 12
|
Posted: Sat Feb 04, 2006 2:00 pm Post subject: |
|
|
Witam,
Od razu nasuwa się pytanie czy jest to to samo rozporządzenie o którym mowa w ustawie „kodeks postępowania administracyjnego” (patrz. źródła punkt 2 i 3). Może pierwsze rozporządzenie określa wszystkie metadane dla dokumentu elektronicznego a rozporządzenie dla Archiwów dotyczy tylko tych danych niezbędnych do celów archiwalnych ?
Jeżeli to są różne rozporządzenia to mam pytanie czy metadane zawarte w tym rozporządzeniu dotyczą opisu dokumentu czy jego treści (patrz przykład poniżej) ?
Istnieje szereg możliwości zdefiniowania struktury dokumentów oraz ich opisów. Dlatego też jednoznaczne zdefiniowanie ich w omawianych rozporządzeniach jest bardzo istotne.
Przykład dokumentu elektronicznego z metadanymi:
<dokument1 – zawartość dokumentu>
<autor> Marek Markwoski </autor>
<stanowisko_autora> Wójt Gminy XYZ </stanowisko_autora>
<tresc_odpowiedzi> wyrażam pozytywna opinię w sprawie xyz 124 </tresc_odpowiedzi>
<data_wydania_opini> 24-10-2005 </data_wydania_opini>
<adresat_odpowiedzi> Pan Jan Janowski </adresat_odpowiedzi>
</dokument1>
<metadane1 – opis dokumentu>
<autor_dokumnentu> Wojciech Mirecki <autor_dokumnentu>
<adresat_dokumnetu> Pan Jan Janowski <adresat_dokumnetu>
<tematyka> Administracja Gruntami <tematyka>
</metadane1>
Pierwsza rzecz która rzuca się w oczy to nadmiarowość danych ... bo przecież jeżeli w dokumencie mamy adresata dokumentu to po co zapisywać go jeszcze raz w metadanych do dokumentu ?
Jednym z wariantów byłoby gdyby metadane do dokumentów elektronicznych były generowane w momencie przekazania dokumentów do archiwum – rodzi to jednak obawę że skoro będziemy musieli generować metadane za x lat to zbagatelizujemy problem.
Kolejny przykład pliku wordowego - Twórcą dokumentu jest Pan Kowalski (fizycznie go napisał i we właściwościach pliku istnieje jako twórca) ale jako autor w dokumencie ( w nagłówku) istnieje Pan Zieliński . Kogo dotyczą metadane z tego rozporządzenia Czy Pana Zielińskiego czy pana Kowalskiego?
1. Żeby było łatwiej zrozumieć moje wątpliwości przeanalizujmy kilka praktycznych przykładów: nie jestem pewien jak to interpretować
a. Zgodnie z http://www.piit.org.pl/piit/index.jsp?layout=2&page=text&place=Text01&news_id=1503&news_cat_id=136&lang=pl dokumenty elektroniczne mogą być publikowane klientom w dowolnym formacie czyli np w doc’u. Co gorsza można wywnioskować że dokumenty te mogą być również tworzone w docu . Niestety wszyscy wiemy ze plik wordowy zapisany jako doc a nie xml nie jest w stanie spełnić wymagań nałożonych przez powyższe rozporządzenie ... tutaj kolejne pytanie czy plik wordowy i pdf są dokumentem elektronicznym ? Zapis mówiący o tym że pliki doc i pdf służą tylko do odczytu był jak najbardziej słuszny ale nowy minister chyba nie zrozumiał intencji zawartej w rozporządzeniu w sprawie minimalnych wymagań dla systemów teleinformatycznych. Idealną z punktu widzenia „danych”, byłaby sytuacja gdy dokumenty elektroniczne są przetwarzane jedynie w standardzie XML a tylko do celów prezentacyjnych są exportowane do doc’a pdf’a itp.
b. Tylko zastosowanie xsd, xsl, i xml zapewni odpowiedni dostęp do danych i metadanych. Jeżeli nie oddzielimy warstwy prezentacji od danych to dane te będą się mieszały
c. Jeżeli dokumentem elektronicznym może być plik pdf np dokument1.pdf wtedy powinniśmy dołączyć plik xml z zawartością metadanych - w tym przypadku zakres proponowanych w rozporządzeniu danych jest uzasadniony bo wtedy jedynym źródłem informacji są metadane (z pdf’a nic nie wyciągniemy)?
2. Zgodnie z rozporządzeniem z dnia 29 września 2005r „w sprawie warunków organizacyjno-technicznych doręczenia dokumentów elektronicznych podmiotom publicznym” paragraf 4.1 - struktura logiczna dokumentu elektronicznego przysyłanego do urzędu jest określana przez urząd (czyli wnioski składane do urzędu) . Do określenia struktury logicznej używa się XML’a zgodnie z rozporządzeniem w sprawie minimalnych wymagań dla systemów teleinformatycznych.
W związku z tym może warto byłoby dodać zapis że do określenia układu informacji w dokumencie elektronicznym stosuje się formaty danych zgodne z rozporządzeniem z dnia 11 października 2005 w sprawie minimalnych wymagań dla systemów teleinformatycznych. ( juz w samym rozporządzeniu jest podział na standardy do określania struktury dokumentu jak i standardy do ich przetwarzania np w celu wyświetlenia). Dzięki takiemu zapisowi zostanie potwierdzone że metadane powinny być zapisane w standardzie XML’owym
3. Analizując aktualne rozporządzenia rysuje się podział na dwie grupy dokumentów
a. Dokumenty przesłane przez Petenta (kto inny określa schemat niż w przypadku b)
b. Dokumenty wytworzone w urzędzie
Źródła:
1. Struktura dokumentu przesyłanych urzędowi określana jest przez podmiot (urząd) np. pole zawierające dane dokumentu .. wyjątkiem są dane z rozporządzenia z dnia 11 października 2005 (Dz.u nr 214 poz 1781) „w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej”
2. W kodeksie postępowania administracyjnego w artykule 39a paragraf 2 dodany jest punkt „Minister właściwy do spraw informatyzacji określi w drodze rozporządzenia, strukturę i sposób sporządzania pism w formie dokumentów elektronicznych w rozumieniu przepisów ustawy z dnia 17 lutego 2005 o informatyzacji działalności podmiotów ......” mowa tu oczywiście o dokumentach tworzonych w urzędzie.
3. W ustawie o narodowym zasobie archiwalnym w artykule 5 ustęp 2a jest natomiast zapis „Minister właściwy do spraw informatyzacji po zasięgnięciu opinii Naczelnego Dyrektora Archiwów Państwowych, określi w drodze rozporządzenia, niezbędne elementy struktury dokumentów elektronicznych powstałych i gromadzonych w podmiotach o których mowa w ustępie 1 uwzględniając minimalne wymagania dla rejestrów publicznych i wymiany informacji w formie elektronicznej, a także potrzebę zapewnienia integralności dokumentów elektronicznych „
4. W ustawie o narodowym zasobie archiwalnym w artykule 5 ustęp 2b jest natomiast zapis „Minister właściwy do spraw informatyzacji po zasięgnięciu opinii Naczelnego Dyrektora Archiwów Państwowych, określi w drodze rozporządzenia, szczegółowy sposób postępowania z dokumentami elektronicznymi w podmiotach o których mowa w ustępie 1. w szczególności zasady ewidencjonowania, klasyfikowania, kwalifikowania dokumentów elektronicznych oraz zasady i tryb ich brakowania, uwzględniając potrzebę zapewnienia integralności dokumentów elektronicznych i długotrwałego ich przechowywania „
5. W ustawie o narodowym zasobie archiwalnym w artykule 5 ustęp 2c jest natomiast zapis „Minister właściwy do spraw informatyzacji, w porozumieniu z ministrem właściwym do spraw kultury i ochrony dziedzictwa narodowego na wniosek Naczelnego Dyrektora Archiwów Państwowych, określi w drodze rozporządzenia, wymagania techniczne jakim powinny odpowiadać formaty zapisu i informatyczne nośniki danych ....., przekazywanych do archiwów państwowych materiałów archiwalnych utrwalonych na informatycznych nośnikach danych „
Pozdrawiam
Mirosław Januszewski
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Sun Feb 05, 2006 9:32 pm Post subject: metadane: jakie to jeden problem, a jak zapisać to drugi... |
|
|
Bardzo dziękuję za celne uwagi.
Aby podjąć temat zacznę od pewnego założenia: co to jest struktura dokumentu elektronicznego? Faktycznie można ją rozumieć na wiele sposobów. Skoro mają istnieć jakieś „niezbędne elementy” struktury, to co to może być? Przecież nie wstęp, rozwinięcie i zakończenie… Trudno także wyobrazić sobie, że minister określi strukturę treści dla każdego powstającego w podmiotach objętych ustawą archiwalną rodzaju dokumentu. Strukturę dokumentów elektronicznych określają metadane, czyli „dane opisujące kontekst, zawartość i strukturę dokumentów oraz zarządzanie nimi w czasie” (PN-ISO 15489-1 Informacja i Dokumentacja − Zarządzanie Dokumentami − Część 1). Ja nie mam co do tego najmniejszych wątpliwości. Ale rozumiem, że ktoś może rozumieć strukturę jako układ treści pisma. Można wszak bezpośrednio w treści pisma odpowiednio wyróżnić znacznikami XML-owymi metadane tj. tytuł, twórcę, adresata, słowa kluczowe itp. Odsyłam tu do projektu TEI (Text Encoding Initiative).
Aby przekonać, że nie chodzi tu treść dokumentu przywołam prosty przykład: wyobraźmy sobie, że naszym dokumentem elektronicznym będzie zamiast pisanego tekstem protokołu z posiedzenia komisji nagranie dźwiękowe tego posiedzenia albo nawet nagranie wideo. I mowy nie ma aby udało się "otagować" znacznikami XML treść tego nagrania. To samo będziemy mieli z fotografiami, tekstami zapisanymi w formacie TIFF itp. Tu uwaga! tekst zapisany w pliku TIFF jest nadal tekstem a nie fotografią. Nie nalezy mylić formatu z typem dokumentu! Tak więc metadane aby zawasze mogły być przeczytane muszą być oddzielone od treści. Otwartym pozostaje pytanie czy mogą być zapisane w jednym pliku. Tu odsyłam do dyskusji która na tym forum już miała miejsce.
zob. http://epl.icm.edu.pl/forum/viewtopic.php?t=69
Podsumowując: oczywistym dla mnie jest oddzielenie warstwy prezentacji od metadanych.
pemi wrote: | ... Jeżeli nie oddzielimy warstwy prezentacji od danych to dane te będą się mieszały |
Tak więc zgadzam się z powyższym, ale z nieco innego powodu.
pemi wrote: | Kolejny przykład pliku wordowego - Twórcą dokumentu jest Pan Kowalski (fizycznie go napisał i we właściwościach pliku istnieje jako twórca) ale jako autor w dokumencie ( w nagłówku) istnieje Pan Zieliński . Kogo dotyczą metadane z tego rozporządzenia Czy Pana Zielińskiego czy pana Kowalskiego? |
Przykład z pismem które przygotował Kowalski dla Zielińskiego jest codziennością w urzędach i ... z cała pewnością będzie. Trudno sobie wyobrazić żeby np. minister sam pisał wszystkie pisma które podpisuje. Kowalski jest Twórcą który dokument przygotował, a Zieliński... Twórcą, który podpisał. Obaj są więc twórcami dokumentu tylko, że każdy z nich pełnił inną funkcję przy jego przygotowaniu. I teraz najważniejsze: tylko oddzielenie metadanych od pliku doc, pdf, odt, rtf czy jakiegokolwiek innego pozwoli na bezproblemowe używanie ich wszystkich. Dołóżmy teraz do tego proponowane wymogi z rozporządzenia dotyczącego postępowania z dokumentami (wersja szkic_17)
§7.
Postępowanie z dokumentami ewidencjonowanymi i metadanymi prowadzi się przy użyciu systemu informatycznego, który:
(...)
9)zachowuje dokumenty i metadane w strukturze określonej w przepisach wydanych na podstawie art. 5 ust. 2a ustawy ...
W propozycji nie ma napisane JAK system ma owe metadane zapisać. To jest w propozycji szkicu rozporządzenia dotyczącego struktury dokumentów elektronicznych:
§3
Metadane zapisuje się w sposób umożliwiający ich automatyczne wyodrębnienie
Tak więc kto jest tym który przygotował dokument i tym który go zaakceptował (podpisał) ma "złapać" dedykowany do tego celu system informatyczny. Nie czarujmy się: "ręcznie" nie da się tego zrobić.
Proszę zwrócić uwagę na to, że nie ma zapisane w propozycji JAK to zrealizować technicznie. Cały załacznik do szkicu propozycji struktury zawiera tę strukturę ale nie zawiera sposobu zapisu (np. XML scheme) Dlaczego?
Założenie było takie, że rozporządzenie dotyczące minimalnych wymagań dotyczących struktury ma odpowiedzieć na pytanie "CO" ma być wyodrębnione pozostawiając otwartym pytanie "JAK" to ma być wyodrębnione. W wersji 0.1 e-pl było DTD ale je wykreślono z powodów które już były tu wyjaśniane. Przed wyskoczeniem z propozycją XML w wersji nr... proponuję zwrócić uwagę na to że "CO" się nie będzie zmieniać w czasie a "JAK" - będzie.
Pewnie że byłoby miło i wygodnie, aby napisać wprost, że do każdego przesyłanego z urzędu pocztą elektroniczną doc-a (a także do samej wiadomości pocztowej) był dodawany "pliczek" XML z metadanymi odnoszącymi i do tego doca i do tej poczty. "Pliczek" wygenerowany z systemu informatycznego obiegu dokumentów danego podmiotu. Hm... ale czy uda się w rozsądnym czasie i bez testów praktycznych to wykonać? zob. na tym forum:
http://epl.icm.edu.pl/forum/viewtopic.php?p=306&highlight=#306
Przywołuje Pan inne rozporządzenia wynikające wprost z ustawy o informatyzacji, a także kpa gdzie zapisano "„Minister właściwy do spraw informatyzacji określi w drodze rozporządzenia, strukturę i sposób sporządzania pism w formie dokumentów elektronicznych".
Pod zwracaniem uwagi na to aby wszelkie te rozporządzenia były spójne i "właziły na siebie" tylko uzupełniały mogę się podpisać oburącz. Wierzę, że czuwa nad tym MSWiA (który jest właściwy do spraw informatyzacji).
Nie mam jednak wątpliwości, że rozporządzenia wynikajace z ustawy archiwalnej są tu kluczowe ponieważ ustalają właśnie CO a nie JAK. Ponieważ JAK jest wtórne do CO... Ale to już temat rzeka nie na jeden post.
I ostatnie:
pemi wrote: | 3. Analizując aktualne rozporządzenia rysuje się podział na dwie grupy dokumentów
a. Dokumenty przesłane przez Petenta (kto inny określa schemat niż w przypadku b)
b. Dokumenty wytworzone w urzędzie |
Oczywiście że tak. Nie wyobrażam sobie aby w dniu dziesiejszym narzucić obywatelowi żeby zaopatrywał swoje dokumenty w metadane o strukturze określonej w rozporządzeniu. Można to narzucić instytucjom publicznym. Niech choć one porozumiewają się automatycznie. To już będzie ogromny krok naprzód. Obywatelowi należy umożliwiać a nie nakazywać. Myślę że można się zgodzić że musimy skanować 1-stronicowy wniosek (pismo) obywatela i dowawać ręcznie metadane po zeskanowaniu go i zamianie na TIFF-a... ale dlaczego skanować kilkunastostronicowe pisma z innych urzędów? Dlaczego porozumiewać się na kartkach wewnątrz urzędu? To można szybko (choć nie łatwo) rozwiązać. A minimalne wymagania dotyczące struktury to ważny krok w tym kierunku.
Liczę na równie cenne uwagi dotyczące samego załącznika - choćby ze względu na jego objętość zwłaszcza tam może być wiele niejasności.
_________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pwegrzyn
Joined: 06 Feb 2006 Posts: 2 Location: NASK
|
Posted: Mon Feb 06, 2006 9:36 am Post subject: |
|
|
Przeglądając proponowaną strukturę nasunęło mi się kilka pytań:
1. Czy podejście z "agregacją" wskazującą wyżej na grupę dokumentów jest optymalne? Może lepiej wyodrębnić "dokumenty podrzędne"?
Są możliwe 2 podejścia:
a. dokument zawiera odnośnik, do jakiej grupy dokumentów należy. (obecne)
b. grupa dokumentów zawiera odnośniki, jakie dokumenty zawiera.
Te 2 podejścia modelują tę samą relację i są równoważne z punktu widzenia efektu końcowego (powiązanie dokumentów w grupy). Jednak korzystanie z modelu (a) przy wprowadzaniu danych może być niewygodne np.: po wprowadzeniu dokumentu do archiwum dołączono ten dokument do jakiejś sprawy -> trzeba jeszcze raz wprowadzić dokument do archiwum. Jest to komplikacja po stronie systemów w urzędach itd., wszystkie te systemy muszą pilnować, aby w momencie dołączenia już "zamkniętego" dokumentu do sprawy jeszcze raz go eksportować. Podejście (b) w tym przypadku byłoby, moim zdaniem, bardziej naturalne.
2. Co z walidacją struktury metadanych w momencie, gdy składniowo dokument i grupa dokumentów są opisane w taki sam sposób?
Czy dopuszalne jest, aby np. "grupa dokumentów" posiadała element "format" albo "relacja"? Oczywiście możemy zgodzić się na elastyczny model, jednak należy wziąć pod uwagę, że może to prowadzić do bałaganu w archiwum (zwłaszcza w pierwszej fazie, gdy systemy będą niedopracowane).
Pozdrowienia,
Patrycja Węgrzynowicz
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Mon Feb 06, 2006 5:39 pm Post subject: agregacja w górę czy w dół |
|
|
pwegrzyn wrote: | a. dokument zawiera odnośnik, do jakiej grupy dokumentów należy. (obecne)
b. grupa dokumentów zawiera odnośniki, jakie dokumenty zawiera. |
Szczerze przyznam, że jako współautor pierwszej wersji e-pl jestem przywiązany do sposobu a. To znaczy każdy dokument zawiera odnośnik(i) do jakiej grupy należy. Jeżeli należy do wielu grup to zawiera odpowiednią ilość odnośników. Moje przywiązanie bierze się z:
- bezpośredniego zaproponowania Agregacji w standardzie e-Government Metadata Standard Version 3.0 29 April 2004 (w stosunku do proponowanego w e-GMS rozwiązania trochę "podrasowaliśmy" propozycję dodając że znak sprawy jest jednym z przypadków agregacji).
- bardzo istotnej możliwości stąd wynikającej: posiadanie najmniejszej "cegiełki" czyli dokumentu elektronicznego od razu będzie nam mówiło do czego on (na wyższym poziomie agregacji) należy. Podejście odwrotne spowoduje, że mając sam dokument elektroniczny pozbawiamy się informacji o kontekście jego wytworzenia.
- nawet w dzisiejszym "papierowym" systemie bezdziennikowym każdy dokument ma mieć wypisany znak sprawy (a więc przynalżeności do grupy dokumentów). Mając dowolny dokument papierowy mamy natychmiast informacje do jakiej sprawy on należy.
- obawiam się, że może się zdarzyć "awaria" systemu teleinformatycznego polegająca na "padnięciu" części odpwiedzialnej za grupowanie dokumentów. Nijak już tego z powrotem nie odtworzymy.
- z reguły jest tak że dokument należy do jednej - góra kilku spraw. Tak więc będziemy mieli do dokumentu przyporządkowaną krótką listę agragacji - najczęściej jedną pozycję. Podejście odwrotne to koniecznośc wpisywania do sprawy długiej listy identyfikatorów dokumentów (też wszystkich wersji dokumentów połączonych elementem relacja).
- Podejście odwrotne to pewne zaburzenie klarownego układu metadanych polegającego na tym że na każdym poziomie struktura się powiela... (lub choć jest do siebie podobna). Sprawa należy z reguły do jednej agregacji wyższego poziomu (serii, zespołu). Tam to dopiero byśmy mieli długą i niedokończona listę spraw...
Mam nadzieję że się jeszcze ktoś wypowie w tej kwestii którą bym sprowadził do tematu "agregacja w górę czy w dół". Jeśli temat się "pociągnie" przeniosę go w osobne miejsce na forum.
Agregacja wzbudzała także dyskusje zespołu APUW (rok temu) co trochę ilustruje ten kawałek forum http://epl.icm.edu.pl/forum/viewtopic.php?t=15
Do drugiego pytania odniosę się później. Faktycznie coś w tym jest...
_________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pwegrzyn
Joined: 06 Feb 2006 Posts: 2 Location: NASK
|
Posted: Tue Feb 07, 2006 4:02 pm Post subject: Re: agregacja w górę czy w dół |
|
|
kschmidt wrote: | Podejście odwrotne spowoduje, że mając sam dokument elektroniczny pozbawiamy się informacji o kontekście jego wytworzenia. |
Ależ nie, ta informacja jest! Jednoznacznie wynika z definicji grupy dokumentów i może być automatycznie wypełniana przez system Archiwum.
kschmidt wrote: | nawet w dzisiejszym "papierowym" systemie bezdziennikowym każdy dokument ma mieć wypisany znak sprawy (a więc przynalżeności do grupy dokumentów). Mając dowolny dokument papierowy mamy natychmiast informacje do jakiej sprawy on należy. |
A czy w papierowym systemie mamy natychmiast informację jakie dokumenty należą do sprawy? W systemie informatycznym możemy mieć obydwie te informacje natychmiast. I to z automatyczną kontrolą poprawności - bez potrzeby sprawdzania spójności dwóch list (lista dokumentów w grupie, lista grup do których należy dokument).
kschmidt wrote: | - obawiam się, że może się zdarzyć "awaria" systemu teleinformatycznego polegająca na "padnięciu" części odpwiedzialnej za grupowanie dokumentów. Nijak już tego z powrotem nie odtworzymy. |
Nie sądzę, aby była oddzielna część odpowiedzialna tylko za grupowanie dokumentów (to jest cały system powiązań - grupa dokumentów ma swoje metadane, grupa dokumentów zawiera inne dokumenty itp.). Tak więc jak będzie "awaria" to pójdzie całość/wycinek losowy dokumentów/grup dokumentów (ale trwałość danych to inny temat - trwałość powinna być zapewniona przez synchroniczną replikację itp.).
kschmidt wrote: | -Podejście odwrotne to pewne zaburzenie klarownego układu metadanych polegającego na tym że na każdym poziomie struktura się powiela... (lub choć jest do siebie podobna). |
Ależ nie, jeśli zależy nam na takiej samej strukturze to nie ma problemu - można zaprojektować strukturę ogólną - jedną dla wszystkich! (element dokument-podrzędny byłby po prostu opcjonalny). Proszę wziąć pod uwagę (pytanie 2. z poprzedniego maila), że już teraz sytuacja jest podobna. Są elementy (np. format, język, relacja), które występuje w strukturze, ale np. nie mają one racji bytu dla grupy dokumentów czyli: składniowo są dopuszczalne, ale semantycznie są niedopuszczalne/niepożądane.
kschmidt wrote: | Sprawa należy z reguły do jednej agregacji wyższego poziomu (serii, zespołu). Tam to dopiero byśmy mieli długą i niedokończona listę spraw... |
Hm, w takim razie chyba źle zrozumiałam opis metadanych. Wydawało mi się, że do grupowania w serie i zespoły nie używamy agregacji (wydawało mi się, że zespół/seria nie posiadają własnego zestawu metadanych - a przynajmniej takiego zestawu jak dokument elektroniczny). Myślałam, że grupowanie w serie i zespoły następuje implicite na podstawie nazwy jednostki/nazwy wydziału. Czy podmiot wprowadzający dane jest zobowiązany do podania elementu agregacja, aby pogrupować w serie i zespoły? Może te dane są wypełniane automatycznie przez system Archiwum? (jeśli automatycznie, to tak jak wyżej napisałam system również może automatycznie wypełniać dla dokumentu do jakich spraw należy).
Pozdrawiam,
Patrycja Węgrzynowicz
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Wojtek
Joined: 07 Apr 2006 Posts: 3
|
Posted: Mon Apr 10, 2006 8:25 am Post subject: Zakres podmiotowy |
|
|
Paragraf 1 propozycji rozporządzenia określa zakres podmiotowy. Czy należy rozumieć, że rozporządzeniu temu podlegają wszystkie podmioty realizujące zadania publiczne (w myśl ustawy o informatyzacji)?
W którym momencie dokumenty będą musiały być opisane metadanymi? Dokumenty tworzone w urzędzie od razu? A dokumenty otrzymywane od petentów?
Pozdrawiam
_________________ Wojtek |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Mon Apr 10, 2006 10:33 am Post subject: Re: Zakres podmiotowy |
|
|
Wojtek wrote: | Paragraf 1 propozycji rozporządzenia określa zakres podmiotowy. Czy należy rozumieć, że rozporządzeniu temu podlegają wszystkie podmioty realizujące zadania publiczne (w myśl ustawy o informatyzacji)? |
Nawet więcej: wszystkie podmioty w myśl ustawy o archiwach (zakres jest szerszy)
Wojtek wrote: | W którym momencie dokumenty będą musiały być opisane metadanymi? Dokumenty tworzone w urzędzie od razu? A dokumenty otrzymywane od petentów? |
Dobre pytanie. Wydawało mi się to oczywiste, że aby zarządzać informacją trzeba ją najpierw wyprodukować. Z dotyczas praktyki kancelaryjnej dla papieru (a także z przepisów prawa) wynika, że dokument który wszczyna sprawę opisuje się od razu podając dla niego w tzw. "dzienniku korespondencji" następujące dane:
- data wpływu
- data pisma
- znak pisma
- nazwa podmiotu (twórcy dokumentu)
- określenie sprawy (czyli tak naprawdę tytuł lub krótki opis)
- komu przydzielono
Z kolei dla każdej sprawy podaje się dodatkowo trochę jeszcze danych w formularzu spisu spraw... powtarzając niektóre dane z dziennika korespondencji... Potem jeszcze opisuje się każdę teczkę zgodnie z jeszcze innym wzorcem, który powtarza dane ze spisu spraw. I ten system co byśmy o nim nie mówili ma jedną zaletę: działa i ludzie potrafią się nim psługiwać. A nawet jak nie potrafią to nie ma katastrofy
Warto zauważyć że to samo dzieje się w systemach obiegu dokumentów elektronicznych: część z nich będzie zarejestrowanych w systemie jako wszczynające sprawę (mające znaczenie jako dowód działalności podmiotu publicznego) a część nie. Takim dokumentem będzie mógł być wypełniony formularz powieszony na WWW, mejl który przeszedł do urzędu (i wcale nie był podpisany podpisem elektronicznym!), a także ... papier który przyszedł listem lub został dostarczony osobiście. I dla wszystkich tych dokumentów MUSI być w urzędzie zapisane minimum metadanych i to w identycznym układzie bez względu na format, nośnik, rodzaj sprawy, tematykę, czy wewnętrzną strukturę pisma.
I tu jest najważniejsze: jeżeli ten papier zeskanujemy czyli zamienimy na dokument elektroniczny to musimy go w tym systemie zarejestrować aby w ogóle dalej można było dalej pracować. I nie czarujmy się że będzie on miał "w sobie" jakąkolwiek strukturę. To będzie goły TIFF do któego trzeba będzie dopisać od kogo przyszedł, kiedy przyszedł, jaka data jest na nim, do kogo był adresowany, czego dotyczył itd... I to będzie to minimum struktury, które będziemy musieli "dorobić" aby w ogóle móc załatwiać sprawę wewnątrz urzędu elektronicznie.
A dokumenty tworzone wewnątrz urzędu? Oczywiście i dla nich minimum metadanych ma być zapewnione i to nie dla każdego "wzorcowego formularza" inne ale dla każdego dokumnetu elektronicznego stanowiącego dowód. A więc także dla nagrania z obrad a nie tylko dla protokołu pisemnego z tych obrad.
_________________ --
Kazimierz Schmidt |
|
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
|