Source: https://forum.kodujdlapolski.pl/t/repozytorium-prawne-w-gicie/2836
Timestamp: 2017-11-22 13:01:50
Legal References Found: Art.18
 Art. 81
 art. 65
 art. 66
 art. 69
 art. 71
 art. 74

Document Content:
Repozytorium prawne w gicie - Projekty - Koduj dla Polski
Repozytorium prawne w gicie
marek.jagielski 2017-02-12 13:51:33 UTC #1
Chciałbym z Wami podzielić się pomysłem na zorganizowanie przepisów prawa w sposób jak organizuje się kod komputerowy.
Pomysł się wziął stąd, że osobiście miałem problem, żeby znaleźć szybko przepisy, które akurat mnie interesują. Także, aby ogarnąć, co się zmieniło w przepisach z roku na rok.
Post ten opublikowałem juz na [1], ale sądzę, że te forum forum.kodujdlapolski.pl jest bardziej odpowiednie na ten post.
I. Wpierw moje założenia i obserwacje (proszę mnie poprawić, jeżeli się mylę):
1. Referencyjnym źródłem aktów prawnych jest strona [1]
2. Referencyjną bazą danych aktów prawnych jest strona [2]
3. W formie elektronicznej ustawy mają format pdf.
4. Ustawy dostępne są w różnych systemach bazodanowych komercyjnych typu lex.pl, których pracownicy konwertują pdfy na formę tekstową.
5. Ustawy można znaleźć na różnych stronach w internecie z tym, że nie zawsze aktualne.
II. Krytyka.
1. Pdf nie jest formatem przyjaznym użytkownikom wykonującym operację kopiuj-wklej.
2. Pdf z pewnością nie jest przyjazym formatem dla systemów informatycznym. Mówię, tu o budowaniu systemów bazodanowych, wyszukujących, automatycznie analizujących, indeksujących.
3. Pdf nie pozwala porównywać konsekutywnych wersji przepisów.
III. Propozycja.
1. Proponuję zgromadzenie przepisów prawa w języku Markdown w systemie kontroli wersji git.
2. Zacząłem już przepisywać Kodeks Pracy [4].
3. Kodeks ten publikuję też jako gitbook [5].
4. Idealnie, by było gdyby każdy komit oznaczał faktyczną zmianę w przepisach. Narazie komituję co zmianę, żeby zobaczyć, czy pomysł się sprawdza.
5. Proponuję przechowywanie każdego paragrafu lub artykułu w osobnym pliku, jako najmniejszych jednostek prawnych.
6. Jako, że każdy artyków ustawy w moim rozumieniu jest równoważny innym, organizację Ustawy (kolejność artykułów) trzymam w osobnym pliku SUMMARY.
7. Dzięki 5 i 6 można porównywać zmianę konkretnych artykułów. A nowe artykuły będą po prostu nowymi plikami, nie afektującym innych plików.
8. Z markdown da się wygenerować inne formaty jak: PDF, HTML, MOBI, EPUB.
IV. Problemy
1. Chciałbym uzyskać najlepszy efekt minimalnym kosztem dlatego też zdecydowałem się na organizację projektu git, który jest zgodny z aplikacją gitbook. Problemy, które napotkałem na razie to:
a. https://github.com/GitbookIO/gitbook/issues/1603
b. https://github.com/GitbookIO/gitbook/issues/507
Liczę na waszą opinię o pomyśle.
[1] https://forumprawne.org/dyskusja-ogolna/723382-repozytorium-prawne-w-gicie.html
[2] http://www.dziennikustaw.gov.pl/
[3] http://isap.sejm.gov.pl/
[4] https://github.com/PrawoPolskie/Kodeks-Pracy
[5] https://www.gitbook.com/book/polskie-prawo/kodeks-pracy
marek.jagielski 2017-02-12 14:03:40 UTC #2
Dodam tylko drogą dygresji:
Kodeks pracy zorganizowany jest trochę jak ulica, na której się co chwila dzieli i usuwa działki budowlane, i żeby nie zmieniać numeracji całej ulicy, tworzy się przedziwny numeracyjny bałagan Art.18^3c. § 1. Myślę, że wynika to z tego, że jak prawnicy raz na blachę wykuli numery przepisów, to renumeracja nie wchodzi w grę.
Z doświadczeń pracy z JIRĄ i innymi takimi narzędziami, proponowałbym raczej, aby artykuły miały swój numer ID, a organizacja artykułów była zrobiona "zewnętrznie" poprzez spis treści.
krzysiekmad 2017-02-13 15:34:10 UTC #3
To super pomysł! Od dłuższego czasu myśleliśmy o tym, żeby go wdrożyć w ramach serwisu https://mojepanstwo.pl/prawo, a ostatnio aktywnie zabraliśmy się za to. @macysz prezentował ten pomysł na jednym z ostatnich warszawskich spotkań Koduj dla Polski i jedna chętna osoba już siedzi nad elementami tego procesu.
- konwersja wszystkich ustaw z PDF do HTML
- 500tys. unikalnych użytkowników na mojepanstwo.pl
- dużo osób korzystających z naszej wyszukiwarki prawa
- prawnika w ekipie Fundacji
- automatycznie przetwarzanie ustaw i orzeczeń w celu ich strukturyzacji [nad tym siedzi w Javie ochotnik]
- wykorzystanie dedykowanej schemy (odnosząc się do twojego pomysłu - zamiast Markdown), potencjalnie tej stworzonej już w Ministerstwie Rozwoju (o ile dobrze pamiętam)
- linkowanie cytowanych aktów prawnych między sobą, ale także w bazie orzeczeń
- z poziomu UX: spis treści oraz linkowanie do cytowanych aktów prawnych
- automatyczne ujednolicanie tekstów (pewnie z manualną weryfikacją), które by się wiązało też z podglądem zmian/historii
Może chciałbyś się przyłączyć do tego projektu? Im więcej osób tym większe szanse powodzenia.
marek.jagielski 2017-02-13 22:57:32 UTC #4
Nie chcę na razie nic obiecywać. Do projektu muszę być przekonany. Chciałbym jednak potwierdzić, to co rozumiem i uściślić.
Ustawy już są przekonwertowane ręcznie lub aplikacją typu [1].
Dygresja: Wolałbym, żeby prawnicy tworzyli prawo w formie tekstowej (patrz przykład RFC dla Internetu, które jest pisane w ASCII). Ale rozumiem, że ciężko byłoby to osiągnąć.
"Brzydki" html jest konwertowany do zestrukturyzowanego w oparciu o schemę XSD/DTD.
Komentarz: Dmyślam się, że wyjściowy html zawiera tylko logiczną dekompozycję ustawy, a nie jej graficzną reprezentację wraz ze stylami.
Czy jeden dokument pdf jest przkonwertowany do jednego dokumentu html? Wydaje mi się, że do póżniejszej indeksacji byłoby wygodniej mieć już ustawę rozbitą. Z drugiej strony sekcje html mogą mieć swoje id. I z tego, co widzę, artykuły się nie zmieniają, a raczej wypdają i pojawiają się nowe i nie byłoby, co porównywać na poziomie artykułów. Temat do przedyskutowania.
Tak, czy inaczej skłaniam się raczej do plikowej reprezantacji ustaw niż od razu bazodanowej.
Czy można zajrzeć do repo projektu i wiki/dokumentacji/'listy mejlingowej'?
Przekonwertowane ustawy przede wszystkim będą publikowane na https://mojepanstwo.pl
Czy oznaczałoby to, że generowany html byłby w taki sposób, by był kompatybilny ze stroną? Twój komentarz o niezależnej schemie sugerowałby, że html byłby niezależny, co uznaję in plus.
Czy będzie możliwość udostępnienia bazy przekonwertowanych ustaw niezależnie? Tak, by ktokolwiek kto chciał zrobić pożytek z już przerobionych danych, nie musiał robić web scrapingu.
[1] https://linux.die.net/man/1/pdftohtml
krzysiekmad 2017-02-14 10:23:05 UTC #5
Odpowiadam poniżej, dopytuj jakby coś było niejasnego.
marek.jagielski:
Tak, są. Dokladnie apką pdf2htmlex (z jakimiś specjalnymi wersjami popplera, itp. dość nietrywialna jest konfiguracja tego).
https://mojepanstwo.pl/dane/dziennik_ustaw/53764,ustawa-konstytucja-rzeczypospolitej-polskiej - treść tego to są pojedyncze HTMLe wynikowe z pdf2htmlex. Źródła ISAPowe podane są w kolumnie po prawej. Mamy to zrobione dla konstytucji, ustaw, rozporządzeń, także lokalnych.
Re Dygresja: Ja bym wolał, żeby tworzyli prawo w formie ustrukturyzowanej (patrz standardy dalej)
Obecnie wyjściowy htm zawiera graficzną reprezentację wraz ze stylami. Jak będzie wyglądał wyjściowy HTML w nowym wydaniu jest to do ustalenia. Pewnie warto byłoby skorzystać z jakiś elementów HTML5.
Obecnie forma wyjściowa pdf2html to plik html (+style +tło) per strona.
Cały serwis mojePaństwo dostępny jest tu https://github.com/epforgpl/_mojePanstwo-Portal. Jesteśmy w trakcie otwierania scraperów. Na specifyczne dyskusje jest miejsce na issues githubowych.
Przekonwertowane ustawy przede wszystkim będą publikowane na https://mojepanstwo.pl1
Tu widzę dwie kwestie. Pierwsza to maszynowy sposób reprezentacji danych. Ja byłbym za wykorzystaniem schemy rozwijanej w MR lub standardów światowych, np. LegalXML, AkomaNtoso. Jedno praktycznie nie wyklucza drugiego, choć czasowo trzeba sobie postawić priorytet.
Druga kwestia to wyświetlanie dokumentów w serwisie. Nie myślałem o tym jeszcze. Wydaje mi się, że dobrze byłoby wykorzystać semantyczne elementy HTML5 (<header>, <footer>, <article>, and <section>) oraz klasy css odpowiadające strukturze. Pytanie, może AkomaNtoso/LegalXML ma już jakieś gotowe XSLT, które by formatowało XML do HTML.
Takie mamy założenie w całej naszej pracy, choć to będzie okazja, aby wynik porządnie udokumentować. Tutaj zamieściłem opis jak się dobrać do danych ustaw obecnie: https://forum.kodujdlapolski.pl/t/analiza-prawa/2557/3
marek.jagielski 2017-02-15 22:18:03 UTC #6
pdf2htmlex + ostylowanie wygląda super. Przyznam, że na pierwszy rzut oka, nie poznałem, że to nie pdf.
Przyjrzę się w weekend standardom LegalXML, AkomaNtoso.
marek.jagielski 2017-02-19 20:31:50 UTC #7
Trochę jestem skonfundowany. W [1] napisane jest, że projekt LegalDocumentML jest kontunuacją projektu Akoma Ntoso. Linki na tej stronie wskazują na wersję 1.0 [2]. Jednakże ze strony [3] wynika, że Akoma pracuje nad wersją 3.0. Znalazłem też edytor Leos [4]. Strona mówi o kompatybilności edytora z wersą 2.
@krzysiekmad, czy możesz objaśnić, jaka jest relacja między projektami? Którą wersja jest rekomendowana w Europie. Którą doradziłbyś do użycia jako uniwersalnego nośniika?
Jaki materiał wejściowy byś proponował? Wygenerowany html?
Czy są w ogóle plany w naszej Legislacji, by przyjąć standardy Akoma i publikować dokumenty w oparciu o nie?
[1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legaldocml
[2] http://docs.oasis-open.org/legaldocml/akn-core/v1.0/akn-core-v1.0-part1-vocabulary.html
[3] http://www.akomantoso.org/release-notes/akoma-ntoso-3-0-schema/
[4] https://joinup.ec.europa.eu/software/leos/description
krzysiekmad 2017-02-20 09:52:21 UTC #8
Niestety nie mam pojęcia. Nie badałem tego jeszcze bardziej szczegółowo.
Materiał wejściowy do dalszego przetwarzania? Wtedy tak: wygenerowany HTML z pdftohtml. Wtedy można to do postaci tekstowej przetworzyć i analizować regexpami, albo analizować położenia elementów bazując na HTML.
Będzie konieczność ustrukturyzowania w jakiś sposób dokumentów. Nie jest jeszcze postanowione jaki standard przyjąć. Jest kilka opcji:
AkomaNtoso / LegalDocumentML
Standard rozwijany w MR (jak uzyskamy do niego dostęp)
Własna propozycja struktury
Osobiście stawiałbym na 1 (globalna półinteroperacyjność; pół, bo to dość generalny standard z tego co wiem) lub 2 w celu promowania wytworzonego standardu w administracji publicznej.
marek.jagielski 2017-02-20 21:25:14 UTC #9
wygenerowany HTML z pdftohtml. Wtedy można to do postaci tekstowej przetworzyć i analizować regexpami, albo analizować położenia elementów bazując na HTML.
Jeżeli html byłby poprawnym xml'em, to może XSLT 2.0 mogłoby to w elegancki sposób przetworzyć.
Ja bym zdecydowanie skłaniał się do 1. Jeżeli legislatywy innych krajów eksperymentują z tymi standardami, a ponadto OASIS się pod tym podpisuje.
@krzysiekmad, mogę prosić o propozycję reprezantywnego materiału wejściowego, nad którym można popracować. Proponowałbym transformatę zgodną ze schemą Akoma Ntoso 3.0 (nawet jeżeli nie jest skończony). Przykłady xmli są dostępne są tutaj [1]. Zasięgnąć wiedzy można też na grupie [2].
[1] http://examples.akomantoso.org/
[2] https://groups.google.com/forum/?fromgroups#!forum/akomantoso-xml
marek.jagielski 2017-02-20 21:28:46 UTC #10
Myślę, że będziemy mogli przenieść dyskusję na inny wątek, jak się zgodzimy mniej więcej, co do kierunku prac.
krzysiekmad 2017-02-22 17:37:05 UTC #11
Tak jak już wspominałem, już ktoś z Koduj pracuje nad strukturyzacją dokumentów, ale nie wiem jak bardzo posunięte są te prace. Mamy w Fundacji w najbliższy poniedziałek spotkanie na temat tego projektu. Zastanowimy się jakie są zadania do wykonania (ustrukturyzujemy prace) i odezwę się wtedy ok?
marek.jagielski 2017-03-01 20:16:51 UTC #12
@krzysiekmad
krzysiekmad 2017-03-02 10:18:48 UTC #13
Początek tego tygodnia był ciężki i nie udało nam się spotkać, przełożyliśmy spotkanie na poniedziałek 6 marca.
krzysiekmad 2017-03-06 15:31:44 UTC #14
Udało nam się dzisiaj spotkać i przegadać ten projekt.
Z naszej strony zaangażowany jestem ja, @macysz i Krzysiek Izdebski. Nad funkcjonalnością strukturyzowania siedzi od jakiegoś czasu Karol Głowacki, który zgłosił się na spotkaniu Koduj w styczniu. Poprosiłem go, aby podzielił się tutaj na forum aktualnym stanem prac.
Proponuję tutaj a forum (powinniśmy wystartować nowy wątek) wrzucać aktualizacje tego co się dzieje, merytoryczne dyskusje prowadzić na Github / System Analizy Prawnej, a bieżący czat mieć na Slacku. Rozpisałem na Github większe funkcjonalności systemu i issuesy do wykonania.
Co ciebie Marku najbardziej kręci? W co chciałbyś się zaangażować? Daj znać jaki masz skillset (języki programowania, itp.)
Karol_Glowacki 2017-03-06 18:06:09 UTC #15
mój pomysł na przetwarzanie HTML'a z pdf2htmlex jest następujcy:
aplikacja Java wykorzystująca parser SAX do przechwytywania i propagowania elementów <page> do parsera DOM, a następnie w DOM'ie analiza drzewa, ujednolicanie danych i zapisanie danych w formie uporządkowanego XML'a (potem takiego XML'a można by już prosto przekonwertować na JSON zgodnie z wymaganiem @macysz) np z (fragment pliku http://docs.sejmometr.pl/xml/348138.xml):
<text width="199" height="15" left="77" top="701" font="1">W Rzeczypospolitej Polskiej j</text>
<text width="361" height="21" left="276" top="696" font="1">ęzykiem urzędowym jest język polski. Przepis ten nie </text>
<text width="315" height="15" left="77" top="721" font="1">narusza praw mniejszo ci narodowych wynikaj</text>
<text width="240" height="21" left="391" top="716" font="1">ących z ratyfikowanych umów mię-</text>
<text width="112" height="15" left="77" top="741" font="1">dzynarodowych. </text>
<text>W Rzeczypospolitej Polskiej językiem urzędowym jest język polski. Przepis ten nie narusza praw mniejszości narodowych wynikających z ratyfikowanych umów międzynarodowych.</text>
Algorytm analizował by dane zawarte w atrybutach elementów text i następne 'merge'ował by je do logicznych części tak jak w przykładzie powyżej.
@marek.jagielski proponował XSLT - też o tym myślałem, tym bardziej ze ciężko będzie stworzyć algorytm który od razu będzie poprawnie przetwarzał wszystkie typy dokumentów (w każdym będą pewnie jakieś charakterystyczne 'kwiatki' w formatowaniu)
XSLT z wykorzystaniem jakiegoś oprogramowania do tworzenia transformat np. Altova było by pewnie prostsze w utrzymaniu podczas 'dostosowywania' się pod konkretny dokument.
Problem w tym że nie wiem czy XSLT jest na tyle 'plastyczne' aby budować element na podstawie wartości atrybutów elementów.
Z drzewem danych natomiast można zrobić wszystko
Gotowy algorytm można by opakować aplikację webową w Java i wrzucić na np. na Tomcat. Samo wywoływanie aplikacji było by do ustalenia.
To są moje przemyślenia. Propozycje mile widziane .
W ten weekend chciałem napisać algorytm ale się pochorowałem i przysiądę w ten weekend.
marek.jagielski 2017-03-07 01:31:49 UTC #16
@krzysiekmad i @Karol_Glowacki,
Proponowałbym, abyśmy przyjrzeli się AkomaNtoso [1], jako kandydatowi na docelowy format. Proponowałbym też, aby ten docelowy format był uniwersalnym nośnikiem informacji, do którego inne systemy powinny się dostosować. Unikałbym, tworzenie xml'a pod konkretny system (n.p. katalog na stronie).
Tak też projekt transformacji html'a do uschematyzowanego xml'a byłby oddzielnym projektem i relatywnie małym.
Ekstrahowanie informacji:
Jeżeli byśmy się zdecydowali na xml'owy format (n.p. AkomaNtoso) to na potrzeby katalogu webowego skłaniałbym się na stworzenie osobnego serwisu, który z uniwersalnego nośnika wyciągałby dane. Nie mam doświadczenia z bazami xml'owymi, ale można byłoby się przyjrzeć na przykład BaseX [2].
Techniczne rozwiąznie:
Nie upierałbym się przy żadnej technologii. Choć, jeżeli rodzina javy, to na pewno wolałbym Scalę lub Groovy'iego, które zgrabniej operują na xml'ach. Można byłoby też usystematyzować procesowanie przy pomocy Spring Boot Batch [3]. Co do xslt/xpath etc. to trzeba uważać, żeby nie przekombinować - kod łatwo staje się nieczytelny. Choć wciąż do xmli jest idealny. Jeżeli bym zaprzągł xslt, to wkomponowałbym to właśnie w spring boot batch i wywoływał transformaty, jako kolejne etapy przetwarzania przy użyciu Saxon HE [4].
Doradzałbym się zastanowić, jaki efekt chcielibyśmy uzyskać. Stworzyć ogólny obraz. Rozbić go na mniejsze projekty. Postawić sobie MVP (pierwszy milestone). Dobrać technologię i napisać, co trzeba.
Mój duży obraz (big picture):
Ja bym sobie wyobrażał, że mamy referencyjną bazę danych artykułów w usystematyzowanym formacie. A poza tym serwisy korzystające zeń, takie jak:
+ katalog, który pozwala zintegrować się przeglądarce artykułów na https://mojepanstwo.pl
+ baza danych wykorzystywania konkretnych artykułów w procesach sądowych lub postępowaniach wykroczeń. Nie wiem, jak jest z jawnością wyroków, ale chociaż sprzężenie zwrotne w postaci statystyki mogłoby być użyteczne.
Taka baza danych mogłaby być podstawą do stworzenia wielu innych serwisów.
@krzysiekmad czy możemy stworzyć na kanale slackowym pod-kanały tylko dla Polski na przykład z przedrostkiem "pl-". Tak, aby każdy z projektów móc omawiać w osobnych wątkach (n.p. pl-html2akoma).
[1] http://www.akomantoso.org/release-notes/akoma-ntoso-3-0-schema/
[2] http://basex.org/
[3] https://spring.io/guides/gs/batch-processing/
[4] http://saxon.sourceforge.net/#F9.7HE
PS. Mój linkedin: https://www.linkedin.com/in/marek-jagielski-27ba5414/
W skrócie, to backend i devops.
marek.jagielski 2017-03-07 01:43:36 UTC #17
@Karol_Glowacki,
Mój wybór na edytor w świecie xml'a byłby Oxygen [1]. Ale nie mam licencji. Do małych transformat xslt, eclipse jest wystarczający.
BaseX wygląda interesująco. Można wystawić wbudowany serwis REST, który wspiera XQuery, którego odpowiedzi można od razu dostać w formacie JSONML [2].
[1] https://www.oxygenxml.com/
[2] http://docs.basex.org/wiki/REST
krzysiekmad 2017-03-07 09:49:58 UTC #18
Nie wiem, jak jest z jawnością wyroków, ale chociaż sprzężenie zwrotne w postaci statystyki mogłoby być użyteczne.
Większość orzeczeń jest jawnych, ma tylko dane osobowe wymazane. Istotne one są nie tyle z powodu statystyk, co tego że to praktyka stanowienia prawa.
Karol_Glowacki:
@marek.jagielski proponował XSLT
Mam relatywnie małe doświadczenie z transformatami, ale wydaje mi się, że dość szybko dojdziemy do momentu , w którym i tak trzeba będzie kodować złożone przypadki. Wydaje mi się, że dużo łatwiej będzie utrzymywać zwykły kod (Javy w waszym przypadku jak słyszę).
Za to XSLT byłyby dobre w interfejsie użytkownika. Mogłyby brać XML wystawiany przez API i formatować go do HTML do wyświetlenia.
mój pomysł na przetwarzanie HTML'a z pdf2htmlex jest następujcy
Ja myślałem jeszcze o xml.totext() i starych dobrych regexpach. Choć wszystkiego one nie wyłapią - np. rozdziałów, które trzeba wyłapywać po stylowaniu (umieszczone w środku, pogrubiony, duży padding).
Wydaje mi się, że za to do wykrywania linków (np. Art. 81. Praw określonych w art. 65 ust. 4 i 5, art. 66, art. 69, art. 71 i art. 74–76 można dochodzić w granicach określonych w ustawie.) choć to kolejny krok analizy.
Proponowałbym, abyśmy przyjrzeli się AkomaNtoso [1], jako kandydatowi na docelowy format. Proponowałbym też, aby ten docelowy format był uniwersalnym nośnikiem informacji, do którego inne systemy powinny się dostosować. Unikałbym, tworzenie xml'a pod konkretny system (n.p. katalog na stronie).Tak też projekt transformacji html'a do uschematyzowanego xml'a byłby oddzielnym projektem i relatywnie małym.
@marek.jagielski mógłbyś zbadać jak mógłby wyglądać dokument AkomaNtoso dla polskiego prawa? Zaproponować jakieś przykłady?
A to ciekawe. Nie myślałem o tym szczerze mówiąc. Myślałem o tym, żeby wewnętrznie operować na bazie relacyjnej, a na zewnątrz wystawiać AkomaNtoso. Nieustruktyryzowana baza to ciekawe podejście pytanie tylko jakie są przypadki jej wykorzystania? Czy skorzystamy na nieustrukturyzowanych danych? Czy skorzystamy na ustrukturyzowanych relacyjnie? Do przegadania.
Komunikacja:@krzysiekmad czy możemy stworzyć na kanale slackowym pod-kanały tylko dla Polski na przykład z przedrostkiem "pl-". Tak, aby każdy z projektów móc omawiać w osobnych wątkach (n.p. pl-html2akoma).
Twórzcie kanały jakie są potrzebne. Ponieważ do innych projektów stosujemy przedrostek projekt (żeby się połapać jak się zrobi tam 100 kanałów) to proponuję przedrostek prsap- (Projekt: system analizy prawa).
Odnośnie komunikacji: gdzie wy mieszkacie? Zastanawiam się, czy byłaby możliwość zobaczenia się twarzą w twarz co jakiś czas.. @Karol_Glowacki, ty pewnie w Warszawie? Zapraszam co tydzień we wtorek na warszawskie spotkania Koduj dla Polski - to dobre miejsce do pracy.
krzysiekmad 2017-03-08 14:12:02 UTC #19
Odnośnie standardu, nad którym pracował Polski rząd: oto jest skrót tego co się działo. Było to w 2012. Od tego czasu prac raczej stanęły nad tym.
http://prawo.vagla.pl/node/9879
Niestety schema jest już niedostępna pod tym linkiem, spróbuję od Vagli ją wyciągnąć. Sprawę będę aktualizował tutaj: https://github.com/epforgpl/_mojePanstwo-Portal/issues/718, ale to jest nice-to-have
marek.jagielski 2017-03-08 22:29:49 UTC #20
Ok. Zajmę się tym.
Tutaj to już zależy od front-end'owców, ale na moje widzenie od tego się raczej odeszło (patrz Apache Cocoon - projekt już raczej słabo rozwijany). Front-end radziłbym robić od razu "ładny dla oka", a dane pobierać z serwisów.
Myślałem o tym, żeby wewnętrznie operować na bazie relacyjnej, a na zewnątrz wystawiać AkomaNtoso. Nieustruktyryzowana baza to ciekawe podejście pytanie tylko jakie są przypadki jej wykorzystania? Czy skorzystamy na nieustrukturyzowanych danych? Czy skorzystamy na ustrukturyzowanych relacyjnie? Do przegadania.
Ja tu relacji bym nie widział. Jeszcze się nie wgryzłem, ale prawo to dla mnie zbiór dokumentów. Nieralacyjne bazy NoSQL typu dokumentowego się narzucają. Mi też by chodziło o to, żeby nie tworzyć wiele równoważnych reprezentacji tych samych dokumentów. Wchodziłby problem synchronizacji. Dlatego tak po cichu upierałbym się przy referencyjnym formacie, jak na przykład AkomaNtoso. I przetrzymywać w nienaruszonym stanie ten referencyjny dokument. I z niego dopiero wytwarzać pochodne dla różnych systemów. A skoro dokument w przypadku AkomaNtoso byłby xml'em, to baza xml'owa jest dobrym dla mnie kandydatem. Dany jest język zapytań xquery.
Ok. Ale to są na razie dywagacje. Proponuję wrócić do tematu, jak przygotuję przykłady AkomaNtoso.
gdzie wy mieszkacie?