Prideme o to, ze schema nie je unifikovana a tym padom aj tahsie prepojitelna lebo nemusi byt jednoznacna. Zaroven ako som napisal, narocnejsie je to aj z pohladu toho ze neviem ake presne data sa kde pouzivaju.
Rozdiel je cca asi takyto:
X si nazve atribut nazve "meno"
Y si nazve atribut ako “meno” a ma aj dalsi atribut "priezvisko"
Je mozne povedat ze X meno == meno z Y? alebo X meno == meno + priezvisko z Y?
Ak ten atribut bude https://data.gov.sk/def/ontology/physical-person/familyName tak je hned jasne ze nie je meno ako meno a raz je to meno a priezvisko dokopy a raz je to iba krstne meno (pri API len cez externe mapovanie v MetaIS).To je to co razi Google, Microsoft, EU a spol tym ze tvoria unifikovany model udajov, ktory oni nazyvaju schema.org resp Core Vocabulary pre EU a u nas Centralny model udajov od nich “dedi” a rozsiruje ho pre slovenske specifika.
Google vie taketo URIfikovane data na urovni schemy strukturovane indexovat, vyhladava ich podstatne lepsie a zaroven vie robit semanticke infoboxy (query do Google “Dunaj” alebo “Andrej Kiska”). Proste neindexuje ten obsah hlupo ale vie ze co je to tam popisane.
Tym ze je nejaky spolocny jazyk jednoznacnych identifikatorov a to nie len hodnot (long identifikatorov) ale aj modelu (atributy su tiez ako URI) tak sa nad nim daju robit strojove spracovania. Takze atribut “meno” pomoze Google len ako fulltext token, ak je to ale otagovane v JSON-LD ako https://schema.org/familyName a je to vlozene ako metadata do HTML stranky tak si to zaraduje do svojho knowledge grafu a pracuje s tym ako so strukturovanou informaciou. : https://developers.google.com/search/docs/guides/intro-structured-data
Vsetky nase datasety tak mozu byt vyhladavatelne nasobne lepsie uz cez Google. Verim ze tento Google priklad ukazal, preco ma zmysle mat atributy URI a nie len texty. Kazdopadne znova len pripomeniem ze v navrhu je rozdiel medzi API a datasetom.
Presne, ale ked chce na ne niekto iny odkazat tak to vlastne nevie inak ako slovne. Proste ked chce niekto povedat ze v sluzbe XY atribut Z tak to musi takto napisat namiesto toho ze to vie vyjadrit jednoznacnym identifikatorov. Takisto ked chce povedat ze obe sluzby posielaju rodne cislo tak to vedia len tak ze pouziju URI identifikator na urovni modelu (znova problem ze ci je to personID, rodCislo, rodneCislo…)
Tak to je viac menej aj zapisane. Pretoze jedine 3 hviezdicky su na 100% a zvysne urovne maju nizsie percenta + aj tahsie podmienky ako “iba pre nove alebo inovovane” alebo len “z vysokym potencialom znovupouzitia”. Preto ak sa na to pozerame takto tak baza/minimum su stale 3 (ak sa dohodneme na minimum 3.5 tak o to lepsie). Proste len pokracujeme v nastolenom trende.
Vyhody su ako som povedal jednoznacna identifikacia toku dat v sluzbach a datach, strukturovane vyhladavanie na narodnej urovni (dopytovanie prirozdenym jazykom - mozem ukazat ukazku ale neoficialne 
), dohladatelnost aj cez Google na vyssej urovni, unifikacia modelu nad ktorym sa daju robit unifikovane validacie( ked poviem ze meno = https://data.gov.sk/def/ontology/physical-person/familyName a vieme ze familyName ma constrain maxLength = 255 znakov, tak automaticky viem centralne poskytovat validacne constrainy a nebude to rozbite tak ako teraz. Datasety je taktiez mozne validovat nie len na zaklade syntaxe ale aj semantiky, zladenie s EU,semanticke mashupy a dopytovanie cez SPARQL endpointy,… nakonci dna by to mal byt hlavne poriadok a setrenie penazi.
Som za.
