Sekce 2.2.1 Bod obsahuje i komentář k Multipoint. Buďto je třeba sekci rozpadnout na 2, nebo ji pojmenovat Bod a Multipoint (Vícebod se asi neřiká co :)) a uvést příklad multipointu.

Příklady v OFN Adresy jsou vytržené z kontextu - je to jen samotná adresa. To je dobré pro získání přehledu o tom, co za položky adresa má. Takhle se ale typicky v datech nevyskytuje. Je tedy třeba uvést příklady toho, jak to vypadá, když se vyskytuje v kontextu jiných dat (lze vypůjčit data z úředních desek, nebo vymyslet jiný kontext).

V sekci Přehled je jednoduchý a složitý konceptuální model. Vůbec nebyl popsán a popis významu položek byl až v sekci "zjednodušený příklad CSV". Nyní tedy tento popis položek je v sekci Specifikace. Je tedy třeba popis na konceptuální úrovni doplnit o chybějící položky.

V minimalistickém diagramu i příkladu je sejmuto. Je to opravdu nutné? Není minimalističtější případ ten, kde oznámení visí a sejmuto ještě není?

V draftu úředních desek je třeba mít konzistentní příklady. Teď je tam nejvíce JSONů, jedno velké XML a žádné CSV. Je tedy třeba pro každý příklad v JSONu přidat ekvivalentní příklad v XML. Tam, kde je to možné (tedy ty jendodušší) i příklad v CSV.

U položky měna není jasné, k čemu se vztahuje. Některé položky jsou totiž bez měny, některé v CZK. Může tedy být měn více? Neměla by mít každá položka částky svoji měnu?

Faktura:

• částka_bez_dph, částka_s_dph, částka_uhrazená - v popisku mají v Kč.
• sleva_bez_dph nemá měnu uvedenu

Položka:

• částka_bez_dph_czk_jednotka, sazba_dph - v CZK
• částka_bez_dph_czk_celkem, sleva_bez_dph_celkem - měna neuvedena

Proč se odstavec pro datový typ (např. 1.2.1 Složený typ agenda) skládá z několika odstavců nestrukturovaného textu, zatímco odstavec pro jeho vlastnosti (např. 1.2.1.1 Vlastnost název) je strukturovaný (Typ, Popis, Příklad), atd.

Mám obavy, že pro některé s dobrými účetními znalostmi bude příliš velkou bariérou mašinérie okolo (vytvoření účtu, obsluha nového prostředí, možná i samotná En). Rozhodně ani "Nahlaste bug" nemám za běžnou znalost ;)
Což ještě doplnit o možnost zaslat e-mail? (na https://data.gov.cz/otev%C5%99en%C3%A9-form%C3%A1ln%C3%AD-normy/faktury/draft/)

Viz číselník států z RPP

Obraz 1 a 2 obsahují "Oznámeni" místo "Oznámení"

Jedná se o položky:
zveřejněno, sejmuto, vytvořeno
kde jsem navrhoval string proto, aby bylo možné zaznamenat různé situace:

• někdo má k dispozici jen datum (ruční publikace na úřední desce)
• někdo má k dispozici datum i čas (a to ještě může být různě přesně)

Pokud by tam měl být jiný datový typ, tak jsem pro date, protože např. u zveřejnění někdy v průběhu dne 25.6.2018 uvádět třeba 2018-06-25T00:00:00 nebo 2018-06-25T23:59:59 by bylo vymýšlení si dat. Akorát se tím ale naopak ztratí kus informace u těch, kteří ten čas k dispozici mají.

Tady prostě chybí datový typ iso 8601 ( https://en.wikipedia.org/wiki/ISO_8601 ), protože šedé jsou datové typy a zelený strom iso 8601

v XSD to lze řešit pomocí:

<xs:simpleType name="dateOrDateTime">
    <xs:union memberTypes="xs:date xs:dateTime" />
</xs:simpleType>

ale v JSON schema to neni

sazba_dph má nejasný popis "Částka v Kč s DPH". Další otázky jsou, zda by to měla být částka, zda v Kč, zda by to neměla být procenta.

Příklad GML v sekci 2.2.2 a příklad GML v sekci 2.2.3 mají nekonzistentně uveden SRS, jednou jako

<gml:Curve srsName="urn:ogc:def:crs:EPSG::5514" srsDimension="2">

a jednou jako

<gml:Polygon gml:id="CPX.2384051101" srsName="EPSG:4326" srsDimension="2">

Toto je potřeba buď sjednotit, nebo do specifikace napsat, že oba zápisy jsou možné.

Momentálně se vyskytují oba termíny - Faktura a Daňový doklad. Je třeba je sjednotit, nejlépe v návaznosti na legislativu.

Zjistil jsem, že některé naše podřízené organizace neúčtují položky rozpočtu, cituji:

Jsme jiný typ organizace než je ministerstvo, jsme příspěvková organizace a naše účetnictví je vedeno v odlišné struktuře v souladu s vyhláškou 410/2009 Sb. Naše náklady a výnosy jsou vedeny na základě směrné účtové osnovy dle přílohy 7 této vyhlášky.

Takže od příspěvkových organizací bychom mohli dostávat členění dle směrné účetní osnovy. Toto bude potřeba asi zanést do specifikace standardu faktur.

Např. u číselníku států z RPP.

V aktuální verzi je u subjektů oznámení geosložka. Ta je nyní namodelována přesně podle špatné praxe na našem webu. Mělo by to být v souladu se otevřenou formální normou (OFN) pro geodata od @MichalMed. Zřejmě to bude znamenat toto:

• Zvážit, zda v rámci úředních desek standardizovat. Byl by to ale hezký případ užití standardu pro geodata, takže nejspíše ano. V tom případě to chce odkázat na příslušnou OFN (původně standard, nově otevřenou formální normu) a přidat to do relevantních příkladů.
• Pro CSV použít WKT
• Pro XML použít GML
• Pro JSON použít GeoJSON

Na https://data.gov.cz/otev%C5%99en%C3%A9-form%C3%A1ln%C3%AD-normy/faktury/draft/#vlastnost-faktura-identifik%C3%A1tor-smlouvy jsem si všiml, že osobu (např. teda dodavatel) vyčleňujeme do samostatné třídy.

Chápu to dobře tak, že výsledný export se má skládat ze 3 souborů?

• Faktury
• Položky
• Osoby

OFN používají nástroj Respec, který pro reference na ostatní specifikace používá online nástroj specref. Řada odkazovaných specifikací se dá ve specref nalézt. Je třeba je tedy správně použít.

Příklad: GML v Úvodu lze odkázat jako [[gml]], viz GML ve specref.

To samé pro ATOM, WMTS a další.

Na více místech dokumentu jsou zmíněny pojmy vysvětlené v jiné části dokumentu. U nich by čtenář očekával link na místo, kde je pojem definován. Ten tam ale často není, je nutno přidat.

Příklad: WGS84, JSON, GML:

sleva_bez_dph_celkem - není jasné. zda se jedná o všechny jednotky dohromady, či o jednotkovou slevu.

V úředních deskách je stále několik nejasností na konceptuální úrovni. Zkusil jsem si to namodelovat a ten diagram vychází trochu jinak

1. Specifikace hovoří o oznámení na úřední desce, ale aktuálně tam ta úřední deska vůbec není reprezetována. Přidal jsem ji. Měla by ale mít své URL, ne?
2. Provozovatel je provozovatelem té úřední desky, nikoliv toho oznámení.
3. Oznámení patří na úřední desku.
4. Organizací je dle doku myšlen provozovatel. Tedy je to třída Organizace, ale v rolích provozovatel (úřední desky), autor a subjekt oznámení. Čili položka v datech by se pak neměla jmenovat organizace, ale provozovatel, ne?
5. Agenda je samostatný objekt, která má mít svůj název.
6. Je třeba ještě pořešit ty kardinality. Úřední deska má jednoho provozovatele, může mít provozovatel více desek?
7. Oznámení má jednoho autora nebo více?
8. Organizace má jednu adresu nebo více?
9. Subjekt má jedno umístění nebo více?
10. Umístění subjektu je jeho sídlo, provozovna, nebo místo práce...?

Moje schéma je spíše podklad k diskuzi:

Propojená data: Přidat info o CORS

Navrhuji upravit standard formátu daňových dokladů ze stránky https://opendata.gov.cz/datova-sada:faktury , a to tak, že:

1. Export bude rozdělen do dvou souborů
   a) CSV soubor s informacemi o faktuře (dodavatel, odběratel, datumy, apod.)
   b) CSV soubor s položkami faktur

2. Upravit názvy pojmenování mezi "příjemce" a "plátce" tak, aby bylo zřejmé, která strana je která.
   Ideální by bylo využít slov "dodavatel" a "plátce", jelikož příjemce může být interpretován jako příjemce faktury/služby. Trochu jsem se nad tím pozastavoval. Nízká priorita.

3. Ke kapitolám rozpočtu přidat nějaký odkaz, který by vysvětlil, co to kapitola rozpočtu je a kde jsou definované. Jako neznalec státní správy jsem to ze začátku nevěděl, že to vychází ze zákona nebo vyhlášky. Trochu by to usnadnilo orientaci nově příchozím.

Cílem prvního navrhovaného bodu je umožnit export položky rozpočtu k jednotlivým řádkům faktur, protože na jedné faktuře se mohou objevit položky s rozdílnými položkami rozpočtu.
Úprava nám pomůže v kategorizaci výdajů.

Faktury: Aktualizovat obrázek

"Jejich seznam je ve vzorových publikačních plánech." Očekával bych odkaz na "seznam" připravovaných formálních norem, nikoliv na pojem "publikační plán". Je-li obsažen unitř některého z plánů, bude prakticky nedohledatelný.

Nebylo by přehlednější 2.1.1 a 2.1.2 vyrenderovat do tabulek o 4 sloupcích ...

Např. RPP > Působnost v agendách : Filtrovací dotazy nad působností mají nevalidtní FILTER (...). Pro netypované části (registrace, úkony) nejsou SPARQLy vygenerovány vůbec.

Položky s DPH a bez DPH jsou nekonzistentní. Někde je obojí, někde jen jedno, je třeba zkontrolovat a vysvětlit kde je co a proč.

Faktura:

• částka_bez_dph, částka_s_dph
• částka_uhrazená - čili s DPH?
• částka_bez_dph_czk - a s dph tedy v kč není
• sleva_bez_dph - a není s dph

Položka:

• částka_bez_dph_czk_jednotka a chybí s DPH
• částka_bez_dph_czk_celkem a chybí s DPH
• sleva_bez_dph_celkem a chybí s DPH

Např. RPP > Převod činností v rámci působností.

Je třeba vytvořit standard pro reprezentaci adresy. V Úředních deskách byl popsán 3x, pro organizaci, autora a subjekt. Mělo by stačit adresu popsat samostatným dokumentem, a v Úředních deskách na příkladu popsat, jak se struktura zanořuje, pro JSON, XML i CSV.

Viz https://data.gov.cz/otevřené-formální-normy/registr-práv-a-povinností/převod-úkonů-v-rámci-působnosti/draft/

Found linkless <a> element with text "CHYBA: I/O error reported by XML parser processing https://xn--slovnk-7va.gov.cz/sparql?default-graph-uri=https%3A%2F%2Fslovn%C3%ADk.gov.cz%2Fisvs&query=define%20sql%3Adescribe-mode%20%22CBD%22%20%20DESCRIBE%20%3CCHYBA%3A%20An%20empty%20sequence%20is%20not%20allowed%20as%20the%20first%20argument%20of%20gen%3AgenerujHodnotuVlastnostiPrvkuSIRIVS%C3%A9mantick%C3%A9mSlovn%C3%ADkuPojm%C5%AF%28%29%20V%20s%C3%A9mantick%C3%A9m%20slovn%C3%ADku%20pojm%C5%AF%20odpov%C3%ADd%C3%A1%20prvek%20typu%20%2C%20jeho%C5%BE%20definici%20se%20nepoda%C5%99ilo%20na%C4%8D%C3%ADst.%3E&output=application%2Frdf%2Bxml: Server returned HTTP response code: 400 for URL: https://xn--slovnk-7va.gov.cz/sparql?default-graph-uri=https%3A%2F%2Fslovn%C3%ADk.gov.cz%2Fisvs&query=define%20sql%3Adescribe-mode%20%22CBD%22%20%20DESCRIBE%20%3CCHYBA%3A%20An%20empty%20sequence%20is%20not%20allowed%20as%20the%20first%20argument%20of%20gen%3AgenerujHodnotuVlastnostiPrvkuSIRIVS%C3%A9mantick%C3%A9mSlovn%C3%ADkuPojm%C5%AF%28%29%20V%20s%C3%A9mantick%C3%A9m%20slovn%C3%ADku%20pojm%C5%AF%20odpov%C3%ADd%C3%A1%20prvek%20typu%20%2C%20jeho%C5%BE%20definici%20se%20nepoda%C5%99ilo%20na%C4%8D%C3%ADst.%3E&output=application%2Frdf%2Bxml(Server returned HTTP response code: 400 for URL: https://xn--slovnk-7va.gov.cz/sparql?default-graph-uri=https%3A%2F%2Fslovn%C3%ADk.gov.cz%2Fisvs&query=define%20sql%3Adescribe-mode%20%22CBD%22%20%20DESCRIBE%20%3CCHYBA%3A%20An%20empty%20sequence%20is%20not%20allowed%20as%20the%20first%20argument%20of%20gen%3AgenerujHodnotuVlastnostiPrvkuSIRIVS%C3%A9mantick%C3%A9mSlovn%C3%ADkuPojm%C5%AF%28%29%20V%20s%C3%A9mantick%C3%A9m%20slovn%C3%ADku%20pojm%C5%AF%20odpov%C3%ADd%C3%A1%20prvek%20typu%20%2C%20jeho%C5%BE%20definici%20se%20nepoda%C5%99ilo%20na%C4%8D%C3%ADst.%3E&output=application%2Frdf%2Bxml) V sémantickém slovníku pojmů odpovídá prvek typu CHYBA: An empty sequence is not allowed as the first argument of gen:generujHodnotuVlastnostiPrvkuSIRIVSémantickémSlovníkuPojmů() V sémantickém slovníku pojmů odpovídá prvek typu , jehož definici se nepodařilo načíst., jehož definici se nepodařilo načíst." but no matching <dfn>.
Found linkless <a> element with text "CHYBA: Document has been marked not available: https://xn--slovnk-7va.gov.cz/sparql?default-graph-uri=https%3A%2F%2Fslovn%C3%ADk.gov.cz%2Fisvs&query=define%20sql%3Adescribe-mode%20%22CBD%22%20%20DESCRIBE%20%3CCHYBA%3A%20An%20empty%20sequence%20is%20not%20allowed%20as%20the%20first%20argument%20of%20gen%3AgenerujHodnotuVlastnostiPrvkuSIRIVS%C3%A9mantick%C3%A9mSlovn%C3%ADkuPojm%C5%AF%28%29%20V%20s%C3%A9mantick%C3%A9m%20slovn%C3%ADku%20pojm%C5%AF%20odpov%C3%ADd%C3%A1%20prvek%20typu%20%2C%20jeho%C5%BE%20definici%20se%20nepoda%C5%99ilo%20na%C4%8D%C3%ADst.%3E&output=application%2Frdf%2Bxml V sémantickém slovníku pojmů odpovídá prvek typu CHYBA: An empty sequence is not allowed as the first argument of gen:generujHodnotuVlastnostiPrvkuSIRIVSémantickémSlovníkuPojmů() V sémantickém slovníku pojmů odpovídá prvek typu , jehož definici se nepodařilo načíst., jehož definici se nepodařilo načíst." but no matching <dfn>.

Pro RPP působnost v agendách se vygenerovaly dvě sekce SPARQL dotazů se stejným názvem "Ukázky SPARQL dotazů nad typem Působnost v agendě"

Text samotný je dobře prolinkován. Je ale těžké si udělat přehled o tom, co je tam za entity a jak jsou propojené bez počátečního obrázku.

@michalskop Není jasný vztah mezi id a identifikátorem u oznámení. Navíc u identifikátoru v popisu je, že je to identifikátor dokumentu. Neměl by pak být právě u dokumentu?

Sekce 4.5: ESRI Shapefile.
Není uveden příklad. Je to proto, že je tento formát binární? Pak by to mělo být ve specifikaci uvedeno.

Je uvedeno, že uchovává informace ve více souborech. Hodila by se přesnější specifikace, pokud souborů není neomezeně. Pokud ano, pak aspoň typově - co je to za soubory, jak je to děleno, musí něco splňovat? Adresářovou strukturu? Pojmenování?

Mělo by tam být alespoň "V této sekci je popsána struktura JSON distribuce této datové sady."

V OFN Prostorová data chybí reference na GeoSPARQL a příklady v RDF (Turtle).

Viz https://github.com/w3c/respec/wiki/data--cite

V příkladech je WKT uveden vždy bez systému souřadnic, zatímco GML s ním. Pokud máme například jedno CSV kde v jednom sloupci chceme WGS84 a v druhém Křováka, jak budou tyto 2 WKT sloupce vypadat?

Pokud není uveden "type", tak není možné generovat ?item a ?type .

Např. RPP > OVM > Adresní místo

Sekce 6 má špatnou strukturu. 6.1 a 6.2 jsou definice služeb WFS a WCS a pak následují 3 odstavce až do sekce 7, které spadají (ale spadat nemají) do sekce 6.2. Sekci 6 je tedy třeba přestrukturovat.

K definicím služeb WFS a WCS je třeba přidat příklady běžících služeb v ČR.

Přidat RDF reprezentaci do OFN

Sekce 2. Geometrické objekty nemá úvod a hned je tam sekci 2.1. Je třeba sekci uvést alespoň jednou větou.

U každého formátu by měly být odkazy na pár nástrojů, které s tím daným formátem umí pracovat (zřejmě zobrazit něco na mapě). Preferujeme open-source, ale lze zmínit i komerční

Týká se jak vektorových, tak rastrových formátů.

V porovnání s jinými specifikacemi, jako např. DCAT, chybí v Úředních deskách úvodní text - co to je, kde se to používá, pro koho je to určeno, atd. Je třeba ho přidat.

Místo názvu třídy se tam dostal název vlastnosti: RPP veřejnoprávní smlouvy > Má rozhodnutí o schválení předání působnosti

V sekci 3 jsou jednotlivé souřadnicové systémy. Bylo by dobré je ilustrovat - například zvolit nějaký jeden bod, a uvést jeho souřadnice v různých systémech, ve WKT i GML, ideálně doplněné o odkazy do nějakých webových zobrazovátek, které je umí, pokud existují.

Zvážit, zda v abstraktu říkat, že je dokument generován (Tento dokument je strojově generován ze schématu JSON-LD reprezentace a z dokumentace prvků v sémantickém slovníku pojmů veřejné správy ČR.). Info je to zajímavé spíše koncepčně, než pro čtenáře dokumentu.

Tohle je trochu dlouhodobější problém, ale když se v sekci 7 mluví o metadatech, je třeba také popsat, jak lze otevřená geodata dostat do NKOD. Z krátkodobého hlediska by tam mělo být že je třeba je popsat DCAT-AP v1.1 (ještě nemáme odkaz na specifikaci API, ale bude). Dále je třeba na zvolených českých typových geodatech ověřit a popsat cestu do NKOD přes GeoDCAT-AP.