epl.icm.edu.pl Forum Index epl.icm.edu.pl
Forum dyskusyjne o tematach związanych z e-Administracją i digitalizacją
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

propozycja projektu rozporządzenia dotyczącego struktury

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    epl.icm.edu.pl Forum Index -> Struktura metadanych 0.2
View previous topic :: View next topic  
Author Message
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Sun Oct 16, 2005 9:41 pm    Post subject: propozycja projektu rozporządzenia dotyczącego struktury Reply with quote

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


struktura_szkic_09.doc
 Description:
szkic projektu rozporządzenia dotyczącego struktury dokumentów elektronicznych

Download
 Filename:  struktura_szkic_09.doc
 Filesize:  34 KB
 Downloaded:  826 Time(s)


_________________
--
Kazimierz Schmidt
Back to top
View user's profile Send private message Send e-mail
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Thu Oct 20, 2005 11:39 am    Post subject: struktura szkic wersja 010 Reply with quote

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.



struktura_szkic_10.doc
 Description:
struktura_szkic wersja 010 z 19 października 2005

Download
 Filename:  struktura_szkic_10.doc
 Filesize:  34 KB
 Downloaded:  757 Time(s)


_________________
--
Kazimierz Schmidt
Back to top
View user's profile Send private message Send e-mail
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Tue Jan 03, 2006 4:22 pm    Post subject: szkic wersja 11 Reply with quote

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?"



struktura_szkic_11.doc
 Description:
struktura_szkic wersja 11 z dnia 2006-01-02

Download
 Filename:  struktura_szkic_11.doc
 Filesize:  36.5 KB
 Downloaded:  810 Time(s)


struktura_zalacznik_04a.doc
 Description:
załacznik do struktury wersja 04a z 2005-11-18

Download
 Filename:  struktura_zalacznik_04a.doc
 Filesize:  495 KB
 Downloaded:  926 Time(s)


_________________
--
Kazimierz Schmidt
Back to top
View user's profile Send private message Send e-mail
Wojciech Woźniak



Joined: 11 Jan 2006
Posts: 1
Location: Opole

PostPosted: Fri Jan 20, 2006 12:59 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
pemi



Joined: 18 Jan 2006
Posts: 12

PostPosted: Sat Feb 04, 2006 2:00 pm    Post subject: Reply with quote

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 Sad. 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
View user's profile Send private message Send e-mail Visit poster's website
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Sun Feb 05, 2006 9:32 pm    Post subject: metadane: jakie to jeden problem, a jak zapisać to drugi... Reply with quote

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
View user's profile Send private message Send e-mail
pwegrzyn



Joined: 06 Feb 2006
Posts: 2
Location: NASK

PostPosted: Mon Feb 06, 2006 9:36 am    Post subject: Reply with quote

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
View user's profile Send private message
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Mon Feb 06, 2006 5:39 pm    Post subject: agregacja w górę czy w dół Reply with quote

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
View user's profile Send private message Send e-mail
pwegrzyn



Joined: 06 Feb 2006
Posts: 2
Location: NASK

PostPosted: Tue Feb 07, 2006 4:02 pm    Post subject: Re: agregacja w górę czy w dół Reply with quote

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! Smile 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. Smile 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
View user's profile Send private message
Wojtek



Joined: 07 Apr 2006
Posts: 3

PostPosted: Mon Apr 10, 2006 8:25 am    Post subject: Zakres podmiotowy Reply with quote

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
View user's profile Send private message
kschmidt
Site Admin


Joined: 20 Mar 2005
Posts: 153
Location: NDAP

PostPosted: Mon Apr 10, 2006 10:33 am    Post subject: Re: Zakres podmiotowy Reply with quote

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 Smile

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
View user's profile Send private message Send e-mail
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    epl.icm.edu.pl Forum Index -> Struktura metadanych 0.2 All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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