Source: http://epl.icm.edu.pl/viewtopic.php?t=71&sid=f9f7ca03280a8a2f5808ffdf89e0ca76
Timestamp: 2018-10-15 11:33:38+00:00
Document Index: 22938048

Matched Legal Cases: ['art. 6', 'art.18', 'art.6', 'art.18', 'art.6', 'art 6']

epl.icm.edu.pl :: View topic - jak to zapisać w rozporządzeniu?
jak to zapisać w rozporządzeniu?
Posted: Tue Sep 06, 2005 1:36 pm Post subject: jak to zapisać w rozporządzeniu?
(Bardzo ładnie) opisaliśmy prosty w układzie standard metadanych oparty na DC eGMS i AGLS. Napisaliśmy także po co i dlaczego taki standard jest potrzebny. Powiesiliśmy w Internecie i...
I teraz jest pytanie w jaki sposób możnaby toto wykorzystać. Bo standard standardem, ale czym innym jest napisanie go, a czym innym jest zapisanie w rozporządzeniu, że należy go stosować i przede wszystkim... do czego. W załączniku pierwsza (robocza) wersja tego jak mogłoby takie rozporządzenie wyglądać.
Co Wy drodzy forumowicze na to?
Kłopoty z tym do czego stosowac standard wynikają z ustawowej definicji dokumentu elektronicznego z której wynika że niekonicznie będzie nim:
pojedynczy plik tekstowy zapisany w formacie *.txt, ale także *.htm, *.xml, *.rtf, *.doc., *.sxw, itd.
Nawet jeśli do tego dorzucimy jeszcze:
pliki arkuszy kalkulacyjnych popularnych aplikacji biurowych takie jak *.xls, *.xsc itd
pliki prezentacji popularnych aplikacji biurowych takie jak: *.ppt, *.xsi, *.pps,
pliki obrazów nieruchomych *.bmp. *.tif, *.jpg, *.png itd...
pliki audio np. *.mp3, *.bwf, *.wav
pliki video np. *.avi, *.mxf, *.mpg, *.vob
To i tak nie wyczerpiemy definicji dokumentu elektronicznego ponieważ może być nim także byt wieloplikowy, np. aplikcja, baza danych o skomplikowanej strukturze itp. Warto zauważyć, że nawet taki pojedynczy plik doc czy sxw raz będzie dokumentem elektronicznym w rozumieniu ustawy, a raz nie...
Jeżeli pierwszą część listu napiszę i zapamiętam w pliku 01.txt a drugą w 02.txt to wymaganą ustawowo odrębną całość znaczeniową będą stanowiły oba te pliki razem. Każdy z nich osobno raczej nie będzie dokumentem elektronicznym tylko jego fragmentem. Inny szczególny przypadek to sytuacja, w której do wiadomości poczty elektronicznej załączono np. arkusz kalkulacyjny. W takiej sytuacji ani ten arkusz ani sam tekst wiadomości bez załącznika raczej nie spełniają definicji ustawowej ponieważ tylko razem stanowią całość znaczeniową. Co ciekawe sam arkusz kalkulacyjny mógł stanowić odrębną całość znaczeniową dla jego twórcy, natomiast dla adresata już nie...
Na przykład, jeżeli plik o NDAP-12345.sxw. zawiera całą treść pisma z NDAP do MNiI i został zapamiętany na dysku lokalnym komputera służbowego pracownika X to jest to dokument elektroniczny. Jeśli zostanie on zapamiętany w systemie dedykowanym do zarządzania obiegiem dokumentów w urzędzie to powinien otrzymać metadane zgodne ze standardem. Do identyfikatora NDAP-12345 powinno się przyporządkować także twórcę tego dokumentu (instytucję i osobę), tytuł dokumentu, datę jego zapisania, format i znak sprawy lub inny identyfikator pozwalający na agregację z innymi dokumentami. Jeżeli jednak plik ten zostanie przesłany jako załącznik w wiadomości poczty elektronicznej to zostanie stworzony nowy dokument elektroniczny, którym będzie ta wiadomość. I także do tej wiadomości trzeba będzie przyporządkować metadane. Mogą one być różne (najczęściej poza znakiem sprawy umożliwiającym wynikający z art. 6 ustawy archiwalnej zapisywanie dokumentacji w sposób uwzględniający przebieg załatwiania spraw). Wiadomość poczty elektronicznej mogła ponadto wysłać inna osoba niż twórca pliku NDAP-12345.sxw i to ona będzie twórcą kolejnego dokumentu elektronicznego. Inna będzie także data, tytuł, format itd.
Do czego zatem stosować zestandaryzowane metadane? Próba odpowiedzi w załączniku.
struktura_szkic_01a.doc
To jest oczywiście bardzo wstępny materiał do dyskusji a nie projekt rozporządzenia, gdyż te sprawy należą wyłącznie do MNiI
Filename: struktura_szkic_01a.doc
Posted: Mon Sep 12, 2005 10:59 am Post subject: wersja druga poprawiona
W załączeniu druga wersja "przymiarki do projektu" rozporządzenia dotyczącego struktury.
W stosunku do pierszej wersji pojawiły się ważne komentarze (uwidocznione też w tekście załącznika).
Poniżej ich rozwinięcie:
Zapisane w §1 "automatyczne wyodrębnienie" ma na celu podkreślenie, że nie chodzi o to, że w tresci pisma będzie można sobie wyczytać kto jest twórcą (np dane w stopce dokumentu SXW) czy adresatem (zapisany przecież w tekście) itd. Danych o twórcy ze stopki nie da się "automatycznie wyodrębnić", tak jak i danych z treści ... Skrajnym przypadkiem byłby plik graficzny (np TIFF) - skan dokumentu urzędowego zawierający wszystkie wymagane metadane, ale w formie uniemożliwiającej ich automatyczne wyodrębnienie. Chodzi o to aby w przyszłości (np za 10 lat) nie trzeba było otwierać każdego dokumentu w celu odczytania danych o nim, tylko aby standardowe minimum metadanych można było przeindeksować automatycznie.
Temu celowi służy także propozycja ujęta w §5 czyli zaproponowanie
"technicznego sposobu zapisu i wyodrębniania metadanych". Krótko mówiąc chodzi tu o to aby ustalić podstawowe znaczniki <tagi> stosowane w polskiej administracji. Aby "twórca" gdziekolwiek go nie zapisać zawsze był oznaczony jako <tworca>, albo <creator>, albo nawet <kopytko> - ale zawsze tak samo. Tak adnotowane zasoby elektroniczne przekazywane do archiwum, (ale też pomiędzy urzędami) będą mogły być automatycznie przeindeksowane już "na wejściu" do urzędu czy archiwum. Odpadnie cała ogromna praca związana albo z ręcznym "przepisywaniem" danych z rubryki do rubryki, albo z ciągłym przygotowywaniem oprogramowania interfejsowego "tłumaczącego" tagi przychodzące z każdego urzędu...
Kontrowersyjny może się wydawać także §6, który ma na celu przygotowanie listy typów dokumentów do których trzeba standardowe metadane przyporządkowywać. Zwłaszcza zwrot że chodzi o te dokumenty elektroniczne "które mogą być zapisane w jednym pliku danych". Po prostu dlatego że te łatwo uporządkować. W ten sposób "załatwi się" zdecydowaną większośc tego co powstaje w administracji. A powstaje tego dzisiaj w urzędach miliony, potem jest drukowane i pakowane do teczek, które trzeba opisywać. A o pliku "wyjściowym" wiemy najczęściej tyle, że jest to np. "sprawozdanie-kowalski.doc" ... i nic więcej. Ponadto do takich plików (zastępujących pisma) przyporządkowanie zestandaryzowanych metadanych jest logicznie uzasadnione. Podobnie rzecz się ma z fotografiami i nagraniami które też mogą (i z reguły są) być zastępowane przez jeden plik.
Nie można tego natomiast powiedzieć o takich tworach jak bazy danych, strony www, itp "złożonych" dokumentach elektronicznych. Pryporządkowanie obiektowej bazie danych daty, adresata, twórcy agregacji itp. elementów, niekoniecznie daje się logicznie uzasadnić. Dlatego też kolejny kontrowersyjny §8.
Można też "zostawić sprawy" wytwórcom dokumentacji elektronicznej nie wylistowując "do czego" mają być przyporządkowanie standardowe metadane, a do czego nie i nie porządkując w jaki sposób zapisać podstawowe znaczniki. W ten sposób uniknie się niekończących się dyskusji, ale cos za coś: będzie obowiązywała zasada ogólna "dla każdego dokumentu elektronicznego" takie i takie dane. Wydaje się, że spowoduje to, iż albo przepis będzie martwy (nie będzie wiadomo jak go zastosować) albo będzimy mieli do czynienia z tyloma interpretacjami do czego te metadane przyporządkować i tyloma sposobami ich zapisu, że późniejsze porządkowanie tegoż będzie ogromnie kosztowne.
§7 nakazuje agregowanie dokumentów elektronicznych w sprawy co wynika bezpośrednio z artykułu 6 ustawy archiwalnej, a także ze zdrowego rozsądku. Zaletą ustalenia agregacji w określony sposób jest to, że w sprawach prowadzonych przez administrację będą nadal dokumenty papierowe dla których zasady postępowania określa inne rozporządzenie. Ustalenie takich właśnie elementów sprawy pozwoli na sprowadzenie do wspólnego mianownika części papierowej i części elektronicznej dokumentacji, a dalszej przyszłości na przeszukiwanie przez oba zasoby jednocześnie.
struktura_szkic_02.doc
wersja druga propozycji dotyczącej struktury dokumentów elektronicznych
Filename: struktura_szkic_02.doc
Downloaded: 1037 Time(s)
Posted: Thu Sep 15, 2005 11:11 am Post subject: dalszy ciąg komentarzy w wersji 03 - po kolenej burzy mózgów
W załączeniu wersja 03. Najistotniejsza zmiana w stosunku do poprzedniej wersji to wykreślonie w ogóle paragrafu odsyłającego do załącznika 2 (techniczny sposób zapisu metadanych). Jak pisałem w poprzednim poście w takim załączniku chodziłoby o ujednolicenie znaczników XML-owych (tagów) dla podstawowych elementów metadanych (np XML schema).
Może ktoś by się wypowiedział czy powinno coć takiego być czy nie? Jako reprezentujący archiwa wydaje mi się, że bez uporządkowania tej materii będziemy mieli po 20,30,50... 100 latach z dokumentacją elektroniczną to samo co z dziś papierową: będzie się dawała odczytać ale będzie "nie do końca" uporządkowana.
Oczywiście wykreślenie idei technicznego sposobu zapisu nie oznacza wykreślenia na zawsze: Jest opinia, że to po prostu na tyle poważna sprawa, iż nie da się tego zrobić bez poważnych testów, potem badań praktycznych jak coś "tak wyprodukowanego" przekazać potem do archiwum.
Przy okazji zasugerowano, iż z załącznika 1 określającego obowiazkowe, rekomendowane i opcjonalne elementy metadanych, a także wyodrębniającego niezbędne podelementy (ang. refinement) zostanie wykreślone wszystko co będzie sugerowało sposób zapisu w XML-u (zob. standard e-pl na tym forum - w tym przypadku wykreślenie DTD). Zasugerowano także że należy zmienić w samym e-pl słownictwo ponieważ zdefiniowane tam pojęcia "parametr" i "atrybut" powinny być inaczej nazwane gdyż wprowdzają w błąd osoby dla których "artybut" znaczy zupełnie co innego.
Dodano dwa nowe elementy obowiązkowe tematykę i typ (w proponowanym standardzie e-pl były one opcjonalne). Jest natomiast propozycja wykreślenia z elementów obowiązkowych tytułu.
Przyznam się że trudno mie się powstrzymać od komentarza w tym miejscu jako zwolennika pozostawienia jak było w wersji 02:
1. Obowiązkowy tytuł nie pełni roli wyszukiwawczej tylko porządkową: wyobraźmy sobie mejle bez tytułu, albo mejle z tytułem "jan kowalski". Porządkowa rola tytułu polega na tym, że w przypadku potrzeby zwykłego wylistowania dokumentów na ekranie jest potrzeba podania "zwięzłych i odnoszący się do treści" tytułów. Podawanie w tym miejscu tematyki spowoduje że tytuły będą często takie same.
2. Postulowane zastąpienie tytułu przez tematykę będzie w praktyce niezwykle trudne do wykonania. Z doświadczeń angielskich wynika np, że mimo istnienia GCL (government category list) mało kto się do tego stosuje. Ponadto w Polsce nie mamy takiej uzgodnionej listy i znając nasze resorty uzgodnić się jej na dużym poziomie ogólności szybko nie da. Wzięcie zaś gotowego rozbudowanego tezaurusa (od biblioteki sejmowej np) to obarczenie urzędników robotą której i tak nie zrobią... Puszczenie tematyki "na żywioł" czyli niech każdy pisze co chce zaowocuje takimi zwrotami jak opisywane już gdzie indziej słowo kluczowe do pewnych starszych nieco dokumentów: "sprzedaż pączków w dni bezciastkowe"... Warto zwrócić uwagę że jako słowo kluczowe powyższy zwrot nie ma sensu ale jako tytuł już owszem.
3. We wszelkich znanych mi standardach tytuł jest obowiązkowy (np. AGLS, e-GMS, Moreq, DoD5015.2-STD). Przy okazji wyjaśniam że wiem iż w DoD5015 obowiązkowy jest "tytuł lub temat" ale jak przypuszczam wynika to po prostu z nazywania tytułu wiadomości poczty elektronicznej "tematem" - w tym przypadku ów "subject" pełni rolę tytułu - jedynie się tak nazywa. Podobnie w Moreq: tam "temat" jest obowiązkowy ale obowiązkowy jest także "identyfikator" który nie jest niczym innym jak ... tytułem.
zmieniono nazwę elementu "dyspozycja" na "przechowywanie" - chodzi o to samo ale tak się lepiej czyta
Dodano paragraf wprost dopuszczający zapisywanie także i innych metadanych niz te określone w standardzie. Tutaj myślę, że byłoby pole do popisu dla inżynierów JAK zapisywać np. w XML-u te dodatkowe metadane, aby było wiadomo:
- co to za element (nazwa)
- kto (instytucja) go wyodrębnił
To mogłoby znaleźć się w załączniku 2, który (na razie!) proponuje się wykreślić.
Są plany wykreślenia §6 i konsekwentnie §8. W tych paragrafach chodzi o wylistowanie rodzajów dokumentów dla których przypisywanie metadanych byłoby obowiązkowe i podanie przykłądów takich dla których nie trzeba byłoby tego robić wychodząc z założnie, że mają one swoją własnę strukturę (bbjaśnienie dlaczego podane w poprzednim poście).
Propozycja wykreślenia wychodzi z założenia że przecież i duże zbiory danych o określonej strukturze zapisane w wielu plikach (a nawet w wielu aplikacjach) ... też są dokumentami elektronicznymi (np baza danych o skomplikowanej stukturze w której poszczególne dane, same w sobie nie spełniają definicji dokumentu elektronicznego (nie stanowią odrębnej całości znaczeniowej). Taką całością jest właśnie ... baza danych. Powinny przecież dla całej bazy zostać określone:
tytuł (albo i nie)
tematyka,
data... no właśnie: przecież już nie data ale daty...?,
format (Oracle ver.... DB2, ale też Microsoft Access MDB, MAK 3.24 itp.)
typ (baza danych)
struktura_szkic_03.doc
struktura szkic_03
Filename: struktura_szkic_03.doc
Downloaded: 1026 Time(s)
Posted: Mon Sep 19, 2005 1:16 pm Post subject: struktura szkic_06
w stosunku do poprzedniego szkicu nastąpiło maksymalne uproszczenie!
uproszczenie takie nastąpi także w załaczniku, który też będzie okrojony do minimum i pozbawiony przykładów , ponieważ jak mówią "rozporządzenie to nie miejsce przykłady". Broniąc owych przykładów jak niepodległości w ostatnim akcie rozpaczy podam argumenty za:
- w e-GMS version 3 przykłady są
- wykaz akt stanowiący załącznik do rozporządzenia Ministra Kultury jest jedynie "przykładowy"
A oto szczegóły zmian:
Usunięto wszelkie próby wskazywania jakie dokumenty elektroniczne (jakie typy lub może nawet formaty dokumentów) podlegają obowiązkowi dopisania metadanych. Odrzucono też propozycję ograniczenia się jedynie do formatów, które mogą wynikać z Rozporządzenia Rady Ministrów wydanego na podstawie art.18 ustawy o informatyzacji.
Przykłady zapisu w XML w załączniku 1 (e-pl) mają zostać wykreślone. Do rozporządzenia powinien zostać przygotowany znacznie uproszczony, w stosunku do wersji 1 e-pl, załącznik.
Ma to zapewnić pewną ponadczasowość rozporządzenia narzucającego pewne ramy, ale nie porządkującego wprost technicznego sposobu zapisu metadanych. Odpowiednie wskazówki mają się pojawić dopiero po przeprowadzeniu badań empirycznych nad procesem tworzenia, postępowania i wreszcie przekazania dokumentu elektronicznego do archiwum państwowego, a także dalszego zarządzania i udostępniania tego dokumentu przez archiwum państwowe.
Argumenty "za" pozostawieniem w załączniku choćby przykładowego (nieobowiązkowego DTD) były podawane przez mnie w poprzednich postach. Mogę tu dorzucić jeszcze jeden argument: pozostawienie DTD (lub napisanie XML Schema) pozwoli na lepsze zrozumienie o co chodzi i co z czym się łączy. Jednak przeważyło podejście, że tak dokładne sprawy techniczne powinny być już poza rozporządzeniem (przynajmniej na razie)
W §6 pozostawiono metadane dla „sprawy” gdyż wynika to z ustawy archiwalnej, a także pozwoli na późniejsze „złapanie” relacji do spraw gromadzonych w sposób tradycyjny (w teczkach). Ma to zapewnić „ciągłość dokumentacji” i wyszukiwanie w zespole archiwalnym niezależnie od formy zapisu. W paragrafie 6 dopisano także, jakie metadane mają odnosić się do sprawy „w przypadku gdy sprawa będzie tworzona”. Nakaz agregacji w sprawy wynikać powinien z zasad postępowania (odpowiedni art.6 ustawy archiwalnej jest w rozdziale „Postępowanie z materiałami archiwalnymi”) a nie ze struktury.
w §5 dopisano zastrzeżenie nie naruszania przestrzeni nazw ustalonej już w załączniku 1.
Pozdrawiam wszystkich sympatyków takiego "otwartego" sposobu komunikowania się. Dziękuję za mejle! Przypominam że MNiI zaproponuje i tak to co będzie uważał, a zbierane tu przeze mnie opinie mają jedynie chratakter roboczy, doradczy i nieoficjalny. Po pojawieniu się pierwszej propozycji "na papierze" projekt wpadnie w rutynowe tory adnotacji na kartkach zgodne z ustalonym postępowaniem i już nie będzie można go śledzić na forum. Mam jednak nadzieję, że kiedyś się nasza administracja zinformatyzuje.
struktura_szkic_06.doc
wersja robocza szkic_06
Filename: struktura_szkic_06.doc
Posted: Tue Sep 20, 2005 1:30 am Post subject: Re: struktura szkic_06
No to kilka nocnych komentarzy do ostatnich zmian:
w stosunku do poprzedniego szkicu nastąpiło maksymalne uproszczenie! uproszczenie takie nastąpi także w załaczniku, który też będzie okrojony do minimum i pozbawiony przykładów...
Po głębszym zastanowieniu chyba muszę przyznać rację usunięciu przykładów. Prawo to prawo - nawet kodeksy prawne i cywilne nie zawierają przykładów - przykład to interpretacja przepisów i jako taka nie może zostać zawarta w rozporządzeniu. Wniosek jaki się z tego wysnuwa jest dla mnie jeden : e-PL nie powinien być częścią rozporządzenia jako taki. Powinno zostać powołane gremium standaryzujące e-PL. Rozporządzenie jedynie określało by zgodność metadanych ze standardem e-PL - tak jak określa się zgodność z normą ISO ileś tam.
No niby coś w tym jest - ustawa twierdzi o metadanych do dokumentów zdefiniowanych w rozporządzeniu. Ograniczenie tego powodowało by niepełność ustawy. Problemem oczywiście są dane, których nie przewidywano w obrębie e-PL 1.0 - np. bzy danych itp. O tym jednak później się wypowem. Póki co, na potrzeby niniejszej wypowiedzi uznaję, że nie ograniczamy typów dokumentów.
Ad. $2 - W aktualnej postaci w połączeniu z $1 jest sprzeczny. Nie ma fizycznej, technicznej i logicznej możliwości zrealizowania $2 dla pewnych typów danych. Dotyczy to tak naprawdę wszystkich elementów:
twórca - kto jest twórcą dysku z komputera - który w świetle ustawy może być dokumentem elektronicznym ?
tytuł - jaki jest tytuł bazy danych - która jest dokumentem elektronicznym (Przykład (C)K.Schmidt)
identyfikator - jaki jest identyfikator archiwum dokumentów elektronicznych ?
data - rozumiem, że chodzi o datę stworzenia - kiedy utworzono serwis WWW będący jak by nie patrzeć dokumentem elektronicznym - w dniu uruchomienia? każdy plik składowy mógł mieć inną datę powstania.
format - jaki jest format serwisu WWW ? a jaki jest format archiwum ? (to nie jest trywialne - OpenDocument, OpenOffice to tylko zip'y z innymi plikami)
tematyka - jaka jest tematyka bazy danych ? (Przykład (C) K. Schmidt)
typ - jaki jest strony WWW zawierającej w sobie jako linki odniesienia do filmu, flasha i obrazka ?
Analogiczne argumenty można wysnuć w odniesieniu do $3.
Wniosek : aktualna postać jest nielogiczna i niespójna. Należy dodać jeszcze jeden poziom (przed $2 w opisie metadanych).
Przy odrobinie zacięcia można zdefiniować identyfikator, datę i twórcę dla dowolnego dokumentu elektronicznego - to byłby poziom pierwszy. Następnie dla dokumentół zgodnych z Rozporządzenia Rady Ministrów wydanego na podstawie art.18 ustawy o informatyzacji byłyby pozostałe składniki $2, które się teraz tam znajdują (tytuł, tematyka ? , typ ?, format ), $3 pozostaje bez zmian. Jednocześnie jestem za wyrzuceniem tematyki z $2.
3. W §6 pozostawiono metadane dla „sprawy” gdyż wynika to z ustawy archiwalnej, a także pozwoli na późniejsze „złapanie” relacji do spraw gromadzonych w sposób tradycyjny (w teczkach). Ma to zapewnić „ciągłość dokumentacji” i wyszukiwanie w zespole archiwalnym niezależnie od formy zapisu. W paragrafie 6 dopisano także, jakie metadane mają odnosić się do sprawy „w przypadku gdy sprawa będzie tworzona”. Nakaz agregacji w sprawy wynikać powinien z zasad postępowania (odpowiedni art.6 ustawy archiwalnej jest w rozdziale „Postępowanie z materiałami archiwalnymi”) a nie ze struktury.
Generalnie chyba ok - wymaga zmian w e-pl - ostrożnych zmian i nie mylenia opisu sprawy z opisem dokumentu. Możliwe są dwie drogi:
1. Sprawa staje się odrębnym bytem w strukturze e-PL - niezależnym od dokumentu. Przenosi własne informacje, ma własny identyfikator, itp - prosto się ją definiuje i rozszerza.
2. Jeśli zostanie przyjęty podział na 3 poziomu metadanych (wszystkie, z rozporządzenia, te ze spraw) to można się pokusić o zdefiniowanie sprawy jako dokumentu elektronicznego. Potrzebne metadane - nieobecne w standardowym e-PL można za pomocą przestrzeni nazw rozszerzyć o konieczne atrybuty.
Posted: Thu Sep 22, 2005 7:49 pm Post subject: rozporządzenie wersja 07 + załącznik
W załączeniu pierwsza przymiarka do rozporządzenia dotyczącego struktury, z załacznikiem opartym na e-pl_01. Zgodnie z wcześniejszymi dklaracjami wycięto DTD i zmieniono niektóre nazwy (atrybut=cecha, parametr=właściwość, dyspozycja=przechowywanie)
Załącznik został przygotowany w pierwszej wersji roboczej, więc są tam jeszcze teksty typu "trzeba będzie zrobić to", co oczywiście w rozporządzeniu nie może miec miejsca. Jeśli rozporządzenie wejdzie w życie to na jego podstawie zostaną przygotowane wskazówki będące e-pl_02 i powieszone na stronie NDAP. To tam będzie miejsce na wykreślone DTD i/lub XML Schema, ponieważ podobno w rozporzadzeniach się standaryzacji nie robi... (mam sporo argumentów na toże tak nie jest ale nie o to chodzi). Wtedy będziemy mieli dośc czasu na uzgodnienia techniczne.
W rozporządzeniu dodano bardzo wazny paragraf mający na celu ograniczenie działania rozporządzenia jedynie do procesów obiegu dokumentów (najczęściej pism) i załatwiania spraw w urzędach, nie wchodząc w skomplikowane struktury wyspecjalizowanych systemów. Celowo proponuje się takie ograniczenie gdyż objęcie rozporządzeniem wszelkich dokumentów elektronicznych wynikających z definicji ustawowej spowodowałoby konieczność modyfikacji wszelkich rejestrów publicznych stron www, baz danych ... praktycznie ... wszystkiego.
sztruktura_zalacznik_01.doc
struktura załącznik wersja 01
Filename: sztruktura_zalacznik_01.doc
Filesize: 472.5 KB
struktura_szkic_07.doc
struktura szkic wersja 07
Filename: struktura_szkic_07.doc
Posted: Sun Sep 25, 2005 6:37 pm Post subject: wersja z dnia 23 września
W załączeniu propozycja 08 (po zebraniu 23 września). W stosunku do wersji 07:
wykreślono paragraf 6 (konieczność agregacji dokumentów w sprawy wynika z pośredniop załacznika. Powinna także wynikać z instrukcji kancelaryjnej i z zasad postępowania)
wykreślono tematykę jako element obowiązkowy (zespół przygotowujący e-pl zgodnie stwierdził że bez słownika głownych kategorii tematycznych takiego jak np. brytyjski Government Category List, nie sposób jest wymagac obowiązkowości tego elementu). Z doświadczeń bibliotek wiadomo że uzgodnienie takiej listy w trybie pilnym jest nie ro zrealizowania
pozostawiono praragraf 7 jako propozycję mającą na celu ograniczenie zakresu stosowania załącznika 1 do dokumentów dla których ... da się go stosować: przede wszystkim dla czynności kancelaryjnych.
Warto zauważyć że w istniejące rozporządzeniu Ministra Kultury dotyczące postępowania z dokumentacją z głóry zakłąda że prawie cała dokumentacja urzędowa jest ... w teczkach. I dopiero w § 17 się stwierdza że jeśli w teczkach nie jest to:
§ 17: Materiały archiwalne stanowiące dokumentację techniczną, statystyczną, geologiczną, kartograficzną i geodezyjną, fonograficzną i fotograficzną oraz utrwaloną na innych nośnikach należy uporządkować i przygotować do przekazania w sposób uzgodniony z dyrektorem właściwego archiwum państwowego
Czyli w myśl obowiązującegi prawa "inną" dokumentacją porządkuje się
w uzgodnieniu z dyrektorem archiwum państwowego. Co robić z dokumentacją elektroniczną inną niż kancelaryjna jednak może być trudno ustalać z dyrektorem archiwum państwowego ponieważ może on być do tego po prostu nieprzygotowany (nie ma wyspecjalizowanego archiwum "elektronicznego") W myśl tego przepisu ustalenie jak uporządkować archiwalne zapisy systemu IACS trzeba uzgadniać z dyrektorem archiwum akt nowych.
Punkt ten może on być jednak niejasny. Jednak alternatywa nakazująca zapisywanie metadanych dla każdego dokumentu elektronicznego (por. definicję ustawową) wydaje się jeszcze gorsza. Są także opinie że "nie ma sprawy" i JAK zapisywac metadane dla dokumentów złożonych (np. stron www czy skomplikowanych baz danych) nie jest celem tego rozporządzenia - celem jest określenie CO zapisywać.
W załączniku zakończono poprawianie przykładów zgodnie z zasadami określonymi w pkt 4 załącznika (czyli definiowania składników metadanych z podawaniem pałnych nazw składników nadrzędnych) tylko do elementu 5.4 Certyfikat. Taki sposób zapisu przyjęto także w wersji 3 e-GMS.
Konieczność takich zmian wynika też z przyjętego wcześniej wykreślenia przykładów XML, któe przecyzyjnie pokazywały które składniki metadanych zawierają się w których (porównaj standard e-pl wersja 0.1 (też na tym forum). Zgodnie z takim zapisem będzie "przerobiona" całość załącznika 1. Ponadto będa poprawione błedy składniowe wynikające ze zmiany nazw "atrybut" na "cecha" i "parametr" na "właściwość".
(w poniedziałek jest następne zebranie i może się okazać że będą jeszcze jakieś zmiany w propozycji
to idę głosować...
struktura_zalacznik_02.doc
propozycja załącznika_02
(w trakcie poprawek)
Filename: struktura_zalacznik_02.doc
Filesize: 480.5 KB
struktura_szkic_08.doc
szkic rozporządzenia wersja_08
Filename: struktura_szkic_08.doc
Filesize: 35.5 KB
Posted: Mon Sep 26, 2005 8:30 pm Post subject: po spotkaniu w dniu 26 września
Uzgodniono propozycję treści tekstu rozporządzenia - jest to wersja_09. W stosunku do wersji 08 ponownie dodano tematykę jako element obowiązkowy.
Skreślono paragrafy 6 i 7
Treść paragrafu 6 opisująca metadane właściwe dla sprawy (zob. art 6 ustawy archiwalnej) została przeniesiona do załacznika w opisie elementu agregacja. Koniecznośc agregacji dokumentów w sprawy zostanie uwzglądniona w rozporządzeniu dotyczącym postępowania.
Treśc paragrafu 7 opisująca wyjątki od dokumentów elektronicznych zastępujących tradycyjne pisma papierowe została usunięta z powodu:
1. trudności w zdefiniowaniu takich dokumentów
2. braku odpowiedniej definicji w ustawie o informatyzacji która takiego podziału nie wprowadza
Zakłada się że metadane dla dużych zbiorów danych będących dokumentami elektronicznymi, w rozumieniu ustawy o informatyzacji, także powinny być dodawane zgodnie ze standardem, natomiast sposób ich zapisu wykracza poza ramy tego rozporządzenia (jeśli dobrze zrozumiałem i zapisałem tę ideę). Liczę na wypowiedź przedstawiciela MNiI w tym zakresie, albo komentarze użytkowników forum. Moje komentarze do tego w poprzednich wiadomościach.
Załącznik do rozporządzenia:
W stosunku do wersji_02 ponownie zamieniono "cechy" na "atrybuty" i "właściwości" na "parametry" (okazało się że nie chodzi o ich nazwy tylko w ogóle o ich wyodrębnianie - zob. dalej od "nie udało się"). Do zbiorczej listy elementów dodano parametry. Z poprawianiem przykładów pokazujących co jest czym (tj. dodawaniem nazw składników metadanych przed wartością) "dojechano" do elementu Identyfikator. Przypomnę, że taki sposób zapisu przykładów jest potrzebny w związku z wykreśleniem 'przykładów XML" z załącznika (zob. poprzednie komentarze).
Nie udało się wypracować wspólnego stanowiska w kwestii definicji w załączniku (co to jest element, element pomocniczy, atrybut, parametr, składnik). Niżej podpisany uważa, że powinny być definicje aby nastepujące po nich wyjasnienia i przykłady były jasne i zrozumiałe. Dyskutować można o tym jak powinny one brzmieć a nie czy powinny być. Przedstawiciel MNiI uważa, że definicje są niepotrzebne ponieważ takich nazw się nie definiuje.
Ponadto nie ma zgody, nie tylko co do definiowania, ale w ogóle wyróżniania nazw "element pomocniczy", "atrybut", "parametr". Wg przedstawiciela MNiI wszytko to są elementy lub ewentualnie "podelementy", a lista składników metadanych powinna być płaska (ang. flat). Tj. Adres powinien być takim samym równoprawnym elementem jak Adresat, a także każdy z atrybutów tu wymienionych to też powinien być po prostu element na płaskiej liście. Przedstawiciele NDAP (w tym niżej podpisany) uważają inaczej, mając na uwadze że struktura ta nie jest płaska. Przykładowo: element Adresat odnosi się bezpośrednio do dokumentu, zaś Adres nie do dokumentu tylko do elementu Osoba lub Instytucja (to Instytucja ma adres pocztowy, a nie dokument), a w końcu Kod (ten w adresie) do elementu Adres (to adres ma kod a nie podmiot). Itd. Wydaje się, że załacznik to wyjasnia w sposób jednoznaczny. Ale może warto narysować schemat żeby pokazac co się do czego odnosi? I tu liczę na wypowiedzi na forum, gdyż nie wiem czy udało mi się dobrze zrozumieć dlaczego lista metadanych ma być płaska? Podane argumenty (m in. "że na całym świecie tak jest') mnie nie przekonują.
Sprawę pozostawiono do ponownego przedyskutowania.
Być może już po zakończeniu poprawiania załącznika, tak aby przykłady były jednoznancze (przypominam, że jest robiony na podstawie propozycji e-pl wersja_01 gdzie wiele przykładów było specjalnie poddanych pod dyskusję) uda się uzyskać zadowalającą wszystkich jednoznaczność.
Zapraszam do wypowiedzi na forum. To nie jest żadna oficjalna strona tylko próba zapisania rozwoju prac roboczych nad waznymi dokumentami. Przecież ciągle jeszcze jest tak, że zanim MNiI nie napisze na kartce, że coś uzgodnił to taki dokument dla żadnego urzędu nie istnieje, choćby dyskutowały o informatyzacji państwa. Potem (jak sprawa ruszy oficjalnie na papierze) będzie już za późno, ponieważ zaczną obowiązywac procedury kancelaryjno-papierowe.
struktura_zalacznik_03.doc
wersja_03 propozycji załącznika
Filename: struktura_zalacznik_03.doc
struktura_szkic_09.doc
wersja_09 propozycji tekstu rozporządzenia
Filename: struktura_szkic_09.doc
Downloaded: 955 Time(s)
Posted: Tue Sep 27, 2005 12:29 pm Post subject: struktura płaska a hierarchiczna
To ja może też swoje 2 grosze dołożę?
Struktura e-PL 1.0 to trzy pozimy:
element,atrybut,parametr.
Taka konstrukcja została przyjęta z premedytacją - miała na celu istotne wyodrębnienie składników, które według twórców wnoszą coś istotnego (elementy). Atrybuty nie mają możliwości występować poza elementem - mogą zostać zdefiniowane tylko w kontekście konkretnego elementu. Parametry natomiast to próba ustrukturalizowania atrybutów, aby nie było potrzeby definiowania ich jako osobne elementy. Struktura płaska to nic innego jak struktura dwupoziomowa element,atrybut. Jakie wnosi to problemy ?
Przykład: datę zapisujemy jako 2005-09-27 jak natomiast zapiszemy zakres dat ?
albo jednym ciągiem : 2005-09-27/2005-09-28 albo strukturalnie zakresdat (od: 2005-09-27 do: 2005-09-2 .
Zakładając konstrukcję płaską mamy dodatkowy element: zakresdat albo brak struktury.
Z punktu widzenia informatycznego - łatwiejsze jest podejście płaskie. Z punktu widzenia człowieka nienawykłego do informatyki - łatwiej analizować strukturalnie.
Należy zaznaczyć, że definicja strukturalna e-PL 1.0 nie wyklucza zapisu płaskiego e-PL.
Wracając natomiast do nazwy element pomocniczy - to tylko nazwa pomocnicza. W strukturze e-PL jest równoprawny z każdym innym elementem. Jego stosowanie podlega natomiast pewnym ograniczeniom (tak jak inne elementy ze względu na wymagalność elementów)
Posted: Thu Sep 29, 2005 12:59 pm Post subject: Zakres dat
w sprawie zakresu dat uważam, że lepiej trzymać się zapisu strukturalnego - (od: 2005-09-27 do: 2005-09-29). Po pierwsze czytelniej, po drugie data jest czymś, co jest przyzwoicie zdefiniowane i znormalizowane, niech tak zostanie. Wszelkie zlepki mogą być czytelne dla ludzi mających w głowie dokumentację - reszta będzie robić rzeczy dziwne z takim ciągiem...
Posted: Sun Oct 16, 2005 9:17 pm Post subject: struktura załącznik wersja 04
Poprawiono załącznik będacy "okrojoną" z przykładów XML-owych wersją e-pl_01. W związku z tym jak to sygnalizowano poprzednio poprawiono wszystkie przykłady zapisując składniki metadanych w sposób element.atrybut.parametr: wartość, wytłuszczając nazwy składników.
Ważniejsze zmiany merytoryczne dotyczyły następujących elementów:
w objaśnieniach wykreślono zdanie: (Przyszłe wersje standardu powinny dodatkowo określić dostępność danych osobowych zawartych w metadanych.)
w objaśnieniach do zmieniono „kasowanie” na „brakowanie”
dodano: format.specyfikacja w przykładach
zamiast „Standard powinien określać podstawowe typy identyfikatorów (tych, które są istotne” napisano „Należy określić…”
wykreślono zdanie: „Konieczne jest zdefiniowanie słownika typów identyfikatorów standardowych (globalnych).”
w sposobach zapisu zamiast: „konieczne jest stworzenie słownika typów podstawowych. Jest to konieczne z tego powodu, że dla identyfikatora podstawowego nie ma konieczności definiowania elementu podmiot. Słownik musi zawierać, co najmniej następujące wartości: ISBN, URI, ISSN, ISAN, UMID”
teraz jest: „należy przygotować słownik typów podstawowych. Słownik musi zawierać, co najmniej następujące wartości: ISBN, URI, ISSN, ISAN, UMID”
także zmieniono opis objaśnień do atrybutu identyfikator.wartość
w definicji atrybutu kontakt dodano parametr typ
zmieniono definicję atrybutu poziom na „atrybut określający poziom instytucji w strukturze organizacyjnej” zamiast „…poziom instytucji w hierarchii”
w objaśnieniach zmieniono opis parametrów na następujące:
instytucja.id.typ – konieczne jest stworzenie słownika dopuszczalnych typów identyfikatorów. Powinny się w nim znaleźć wartości odpowiadające nazwom referencyjnych rejestrów publicznych np.REGON, NIP
instytucja.kontakt.typ – należy stworzyć słownik typów podstawowych, powinien on zawierać, co najmniej wartości: telefon, fax, email, jednak ze względu na rozwój nowych technologii nie należy ograniczać słownika tylko do tych wartości
Zmieniono opis celu wyodrębnienia. Zmieniono opis atrybutu lokalizacja.adres. Zmieniono odpowiednio przykłady. Pozostaje wątpliwość czy atrybut lokalizacja.adres jest obowiązkowy dla dokumentów fizycznych. Za tym przemawia konieczność posiadania wiedzy gdzie konkretnie w magazynie znajdują się dokumenty o określonych sygnaturach. Przeciw temu przemawia konieczność wprowadzania zmian w przypadku przemieszczania dokumentacji w magazynie, a także mały sens podawania dokładnego miejsca przechowywania w przypadku zbiorów posiadających numerację ciągłą. Jednak standard nie określa jak dokładnie podawać topografię przechowywania, co uwidoczniono na przykładzie drugim gdzie w lokalizacja.adres podano jedynie nr magazynu.
W sposobach zapisu usunięto obowiązkowe dodanie do słownika wartości parametru osoba.id.typ numeru dowodu osobistego.
Zmieniono dodatkowe objaśnienia.
Zmieniono (skrócono) słowniki, sposoby zapisu
Zmieniono przykłady tak aby lepiej odzwierciedlały ogólny charakter słów-haseł.
Ważne: ktoś powinien sprawdzić cały dokument pod kątem jednoznaczności przykładów. Wątpliwości dotyczą zwłaszcza możliwości umieszczenia przykładów w rozporządzeniu. Jednak brak przykładów, i jednioczesny brak schematu technicznego sposobu zapisu (np. DTD, czy XML Schema rekomendowanego przez Radę Europy) spowoduje tak dużą dowolność interpretacyjną, i trudność zrozumienia zasad, że całe rozporządzenie dotyczące struktury stanie pod znakiem zapytania. Innym rozwiązaniem ogłoszenie wskazówek do rozporządzenia (np. XML Schema i przykładów) w osobnym dokumencie. Jak jednak zrobić aby taki osobny dokument był ważny i instytucje publiczne stosowały sie do niego? I kto powinien go wystawić? To już pytanie do prawników. Zwłaszcza w przypadku jeśli zdecydują oni że przykłady w rozporządzeniu nie powinny być pokazane.
W celu łatwiejszej nawigacji dodano także ponownie szkic tekstu proponowanego rozporządzenia w wersji 09 już umieszczonej na forum.
Także w tym celu otwieram dwa nowe tematy: pierwszy dotyczący propozycji treści samego rozporządzenia, a drugi załacznika do tego rozporządzenia czyli ogólnego standardu struktury dokumentów elektronicznych.
struktura szkic wersja 09
struktura_zalacznik_04.doc
struktura załącznik wersja 04
Filename: struktura_zalacznik_04.doc
Filesize: 494.5 KB