search

MKM-ITAO / riigiteenused

Riigiteenuste kaardistamise ja kirjeldamise projekt
5 stars 2 forks source link

ITAO: JSON viia JSON-LDle #12

Closed RRisto closed 7 years ago

RRisto commented 9 years ago

Viia masinloetav andmestik https://www.riigiteenused.ee/api/et/all JSON formaadist JSON-LDle

tormi commented 9 years ago

:+1:

tormi commented 8 years ago

@RRisto, saan aru, et muudatuse eesmärgiks on tuua sisse linkimise dimensioon. Kas JSON-LD kõrval olete kaalunud ka teisi seda toetavaid variante, eelkõige HAL (spets)? Muuseas, Drupal 8-s on HAL vaikimisi out-of-the-box toetatud formaadiks.

Vt. ka:

RRisto commented 8 years ago

ei ole teisi variante kaalunud. Hetkel on RIA poolt tulnud soov, et võiks olla JNSO-LD. Kas oleks vaja teisi toetatavaid variante? Hetkel on olnud põhiline, et meie lahendus oleks võimeline tulevase RIHAga andmeid vahetama.

tormi commented 8 years ago

Hetkel on olnud põhiline, et meie lahendus oleks võimeline tulevase RIHAga andmeid vahetama.

@priitparmakson, kas RIHA (või ka KVR) kui riigi infosüsteemi kuuluv andmekogu saab riigiteenused.ee rakendusega andmeid vahetada x-teed kasutamata? Vt. ka https://github.com/MKM-ITAO/riigiteenused/issues/30#issuecomment-152103532

Ja teiseks sama küsimus, mis Ristolegi sai esitatud: https://github.com/MKM-ITAO/riigiteenused/issues/12#issuecomment-155766781

PriitParmakson commented 8 years ago

Tere! Doktrinaalne seisukoht on olnud, et X-tee ja ainult X-tee kaudu; mingeid muid alternatiive pole mõtet arutadagi. See poliitika on hoidnud kokku aega, mis muidu kuluks erinevate ühendusviiside valikuks ja (suure tõenäosusega ebaturvaliseks) teostamiseks, taganud ühetaolise, multilateraalse andmevahetusstandardi koos kõigi hüvedega, mida selline unikaalne standard kaasa toob. Samas ei ole infotehnoloogia seisnud paigal. Kui tsiteerida guru Martin Fowlerit, siis XML ei ole see andmevorming, mida tänapäeva arendaja hea meelega näha tahaks. Eelistused on liikunud kergemate märgendkeelte, eelkõige JSON-i suunas. Teiseks RESTful stiilis liidesed. Kolmandaks uued krüptotehnoloogiad nagu JWT (JSON Web Token). Avalike teenuste masinloetavad kirjeldused peaksid olema kättesaadavad kõigile. Seetõttu tuleks neid pakkuda formaatides ja protokollidega, mida kirjelduste kasutajad eelistavad. Konkreetselt juhul pakuksin, et HTTPS protokollil RESTful API liidese kaudu, mõnes "lightweight" masinloetavas keeles pakutavatel andmetel oleks kõige rohkem reaalset kasutusväärtust. Sellest lähtudes, kui asutus niikuinii publitseerib oma avalike teenuste masinloetavad kirjeldused oma veebilehel, siis võiks ju täiesti kasutada ühtse riigivaate moodustamiseks andmekorjet nendest masinloetavatest avalikest liidestest. Paralleelselt neid andmeid X-tee kaudu saata poleks erilist mõtet. Samas, kui soovime andmetelt kõrget kindlust, siis X-tee annab kindlad garantiid - mida muude andmeühenduste puhul kas ei ole võimalik saavutada või mille olemasolu tuleks tõestama hakata. X-tee seega annab kindlad garantiid. Probleemiks võib olla X-tee keerukusbarjäär. Kokkuvõttes, kui rõhume lihtsusele, siis võiks olla protokoll ja moodus, mille kasutamist asutused kõigel lihtsamaks peavad. Seejuures peaks protokoll ja moodus olema ühetoaline, s.t tuleb kokku leppida. X-tee näol on kokkuleppe alus olemas.

tormi commented 8 years ago

kui asutus niikuinii publitseerib oma avalike teenuste masinloetavad kirjeldused oma veebilehel, siis võiks ju täiesti kasutada ühtse riigivaate moodustamiseks andmekorjet nendest masinloetavatest avalikest liidestest.

Nõus, aga praegune AvTS para3b1lg1 käsitleb seda pigem teabe taaskasutamisena erasektori poolt. Tuleks algatada regulatsiooni muutmine.

Kokkuvõttes, kui rõhume lihtsusele, siis võiks olla protokoll ja moodus, mille kasutamist asutused kõigel lihtsamaks peavad. Seejuures peaks protokoll ja moodus olema ühetoaline, s.t tuleb kokku leppida. X-tee näol on kokkuleppe alus olemas.

Absoluutselt nõus. Siiski ei piisa ilmselt vaid kokkuleppest, vaid see tuleks viia ka AvTS-i. Hetkel on riigi infosüsteemi kuuluvate andmekogude infovahetusel x-tee kohustuslik. Võimalik, et AvTS'i muutmisest saaks mööda minna rakendusakti vastavalt täiendades.

tormi commented 8 years ago

Priit, kas Sina oled ka uue RIHA töörühmas? Äkki saaks selle nõuete kaardistamise ja edasise issue managemendi Githubi tõsta?

PriitParmakson commented 8 years ago

Tänu HAL-i viite eest. Ei, meie vaatevälja see ei ole varem sattunud. JSON-LD peale jäime peatuma mitmel põhjusel: a) EL ruumiliste metaandmete INSPIRE varamu kavatseb JSON-LD-d kasutada; huvi on ka meie partneril Soomel; b) Google jt "suured äritegijad" kasutavad muu hulgas JSON-LD-d Schema.org skeemides; c) JSON-LD säilitab võimaluse kasutada RDF-i. Siinkohal väike eestikeelne JSON-LD tutvustus. Vaja oleks JSON-LD-d rohkem katsetada. Meie riigi väiksuse tõttu on suur oht, et kui võtame OWLi, RDFi vms esituskeele, siis meie jõud ei käi sellest üle.

PriitParmakson commented 8 years ago

RIHA ärianalüüs käib, lõpeb aasta lõpuks. Tehnoloogiline analüüs järgneb sellele. GitHub on hea mõte, kindlasti tahame ka GitHubi tulla.

PriitParmakson commented 8 years ago

Siiski ei piisa ilmselt vaid kokkuleppest, vaid see tuleks viia ka AvTS-i. Hetkel on riigi infosüsteemi kuuluvate andmekogude infovahetusel x-tee kohustuslik. Võimalik, et AvTS'i muutmisest saaks mööda minna rakendusakti vastavalt täiendades.

Õigus peab arenema. Siin on aga terve kimp väiksemaid ja suuremaid probleeme lahendada. Õigusteksti valamine, pärast seda õigusteksti tõlgendamine. Kui vaadata X-teed ennast, siis X-tee käivitati 2001. aastal, ettevalmistusi alustati veel varem. Õiguslikult vormistati aga alles 2007. a novembris, X-tee määrusega. Move Fast and Break Things (Mark Zukerberg). Human laws versus man-made laws versus tehnoloogia seadused. Kiireid tehnoloogia arenguid on raske õiguslikku vormi valada. Meie inimesed soovivad ikkagi õnneks olla õiguskuulekad. Siin tekib teatud dissonants - mida see "break things" avalikus sektoris tehnoloogia osas peaks tähendama?

tormi commented 8 years ago

mida see "break things" avalikus sektoris tehnoloogia osas peaks tähendama

See on kenasti kaetud UK GOV teenuse disainimise käsiraamatus (tegin tehnoloogia break things kohad rasvaseks):

Discovery phase

Before you start building a service you need to build up a picture of what the context for that service is. That means lots of user research, close analysis of policies, laws and business needs, and workshops and interviews which establish the criteria for success of your service.

Alpha phase

The objective is to build a working prototype. This will be used by stakeholders or a closed group of end users to:

Beta phase

The objective of this phase is to build a fully working prototype which you test with users. You’ll continuously improve on the prototype until it’s ready to go live, replacing or integrating with any existing services.

This is achieved by providing the user stories in the backlog created in the alpha phase. This is the time to resolve any outstanding technical or process-related challenges, get the service accredited and plan to go live.

Live phase

To provide a fully resilient service to all end users the service should now meet all security and performance standards. You have configured your analytics to accurately monitor the key performance indicators identified in the building of your service, and you have planned the transition or integration of any existing services.

You have liaised with the team governing the Digital by Default Service Standard to make sure that you have met the requirements of new and redesigned services.

And, most importantly, you have met the user needs identified in the discovery, alpha and beta phases.

You’ll repeat the whole process (discovery, alpha, beta and live) for smaller pieces of work as the service continues running. Find something that needs improvement, research solutions, iterate, release. That should be a constant rhythm for the operating team, and done rapidly.

RRisto commented 7 years ago

versioon 2 viidud üle JSON-LDle