Yleiset

• Kysymys 1, käyttöoikeusrajoitukset: Muokkauksien osalta olisi kriittistä, että käyttöoikeuksia voidaan jakaa tarkemmalla tasolla jolloin esim. yksi organisaatio voi toimia ns. yhden sateenvarjon alla. Oikeuksia pitäisi pystyä perimään organisaation tasolta alemmalle tasolle.
• Kysymys 6, Suosituimmat (eli viitatuimmat) listauksen kärkeen: Voi johtaa tärkeän tiedon ”hautautumiseen”, omat suosikit voisi olla toimivampi. Vertaisarviointiin tms. menettelyyn perustuva laatumerkintä olisi perustellumpi.
• Kysymys 8 (tilatietoon lisää vaihtoehtoja): Tilatieto voisi olla edelleen Luonnos, mutta kun tietosisältö on kommentointikierroksella, sille tulee näkyviin jokin symboli. Näin ei tarvittaisi uutta tilaluokitusta.
• Tilaluokituksen tulkinnan ja käytön tulisi olla mahdollisimman helppoa, sillä ison aineiston tilatietojen muokkauksesta tulee helposti työlästä. Toisaalta on hyvä, jos luokitustietoihin voi kohdistaa massamuokkauksia, mutta kaikissa tapauksissa kaikkia sanaston käsitteitä ei ole tarkoitus luokitella samalla tavalla. Lausunnolla-tila todennäköisesti vaikeuttaisi tilamerkintöjen tulkintaa ja sen käyttöaikaa on vaikea hahmottaa.
• Ei järkevää, että julkisesti olisi näkyvillä, missä sisäisen käsittelyn vaiheessa aineisto on. Keskeneräinen riittää hyvin. Yksittäisten aineistojen osalta voi olla erittäin perusteltua pystyä laatimaan ja ylläpitämään hienosyisempiä sekä yksityisiä tilaa kuvaavia tunnuksia. Ehdotan status-tiedon pilkkomisen kahteen statustietoon: julkinen sekä sisäinen. Julkiseen status-koodistoon voisi olla tarkoituksenmukaista liittää uusi status: lukittu, jota käytetään sellaisen tietosisällön kanssa, joka on jostakin syystä lukittu esimerkiksi lainsäädäntöviittauksen osalta.
• Saattaisi olla hyödyksi. Valikon pidentyminen muutamalla rivillä ei ole hyvä peruste kieltää.
• Kysymys 9 (Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä): Tehdään tästä optio käyttäjän valittavaksi: koodistolistauksen suodatus käyttäjän toimesta; mahdollisesti lajittelujärjestyksen muutos jne.
• Käytännöllinen kysymys. Jos koodistoja on miljoona, varmaan näkymän supistaminen on fiksua. Voisiko näkymän itse päättää esim. kirjautuneena käyttäjänä?
• Kysymys 10, rajapinnan muutokset: Rajapinnan tekninen muutostieto ei riitä, kun sen käyttäjien järjestelmät eivät välttämättä pysy samassa muutostahdissa. Tarvitaan viestintää ihmisille selväkielisesti, konekielistä ennakoiden, jotta muutoksiin osataan varautua
• Missä API-rajapinnan dokumentaatio? Swagger ei anna riittävästi vastauksia.
• Rajapintamuutokset: voisi olla menettely, että sähköinen rajapintapalvelu antaa ilmoituksen (muutostyypistä?) siten, että prosessi jatkaa palvelun käyttöä, ellei käyttäjä keskeytä.

Sanastot-työkalu

• Sanastotyökalulle olisi käyttöä myös organisaation sisäisessä käytössä siten, että sanasto ei olisi julkinen. Sisäisille sanastoille on tarve, kovin spesifit määrittelyt eivät ole muille organisaatioille kiinnostavia eikä kaikkia kuvauksia välttämättä saa jakaa oman organisaation ulkopuolelle.
• Export ja import Sanastot-työkaluun
• Versionhallinta Sanastot- työkaluun
• Visuaalisuutta parannettava: tällä hetkellä kuva käsitteiden suhteista ei tuo mitään lisäarvoa määritelmään.
• Sanastojen vientiin CSV-muoto on liian suppea, käytämme XML-muotoa. Käyttöohjeesta sisällöntuottajille ei kuitenkaan löytynyt NTRF-XML -rakennetta kuvaavaa DTD- tai XML-skeematiedostoa. Pelkän esimerkin avulla oli erittäin vaikeaa tuottaa edes auttavasti toimivaa XML-siirtotiedostoa. Sisällön tuontiin käytettävään rajapintaan pitää tarjota sen käyttöön tarvittava dokumentaatio.
• Tarvitaan laaja hakutoiminnallisuus (koko tietopohja & hakuoperaattorit & ml. regex-vapaatekstihaku) ja/tai listausten käsittelytoiminnallisuus
• Sanaston tietomallin laajennus omilla kentillä
• Tietomallin & toiminnallisuuden laajennus: koodistossa on nyt 'lisää linkki'-toiminnallisuus, vastaava myös sanastoon
• Yksinkertaisempi tehokkaampi asiakirjatyyppinen käyttöliittymä luonnosteluvaiheeseen, jossa terminologikäyttäjä pystyy määrittämään tietokenttien (ja esim. käsitejärjestelmäkaavion) näkyvyyttä. Vaihtoehtoisesti kevennetty muokkausnäkymä.
• Yksittäisen käsitteen sivulle käyttäjäpalautteen antaminen ja lähetys suoraan 'oikeaan paikkaan'; esim. suoraan sanastoon omalla statuskoodilla.
• UML-muotoiset käsitejärjestelmäkaaviot (ml. käsitemäärityksen esitys kaaviokuvassa)
• Excel-tiedostomuoto import-formaatiksi.
• Listamuotoiseen import-formaattiin mahdollisuus lisätä yhteen sarakkeeseen useita erillisiä alitietoja (esim. synonyymit eroteltuna jollakin kenttäerottimella esim. '|' tai <br /> ...). Mahdollisuus ohjata, mitä tähän päivitystoiminnallisuuteen sisällytetään (esim. kielivalinta) - Sama toiminnallisuus NTRF-XML-formaattiin
• Koodistossa nyt oleva excelin export-modify-import -päivitystoiminnallisuus sanastoon. Tavoite saada koko sanasto ulos.
• Kirjallisuus- sekä henkilölähdeviittausten -hallinnointi määritelmiin, selitteisiin, synonyymeihin...
• Laajan hakutoiminnallisuuden lopputuloksena syntyvä poimintajoukon massapäivitys, päivitykset voivat kohdistua kaikkiin kenttiin.
• Käyttöliittymään pitäisi saada enemmän vaihtoehtoja ulkoisiin tietomalleihin viittaamiseen. Käytännössä nyt on vain kaksi ominaisuutta owl:equivalentProperty sekä rdfs:subPropertyOf - tämä on liian vähän. Pitäisi voida määritellä tarvittaessa myös esim. owl:inverseOf, rdfs:seeAlso, rdfs:comment ja myös rdfs:domain, kun nyt on vain rdfs:range.
• Voisiko mallista viitata myös ulkopuoliseen sanastoon esim. Finton sanastoihin, joissa käsitteillä on myös pysyvät URIt?

Koodistot-työkalu

• Koodistojen XML export on kovasti tarpeen
• Koodistojen väliset linkitykset ja mäppäykset olisi toivottava ominaisuus

Tietomallit-työkalu

• Export ja import Tietomallit-työkaluun
• UML-mallinnuksen tuki Tietomallit-työkaluun tai yhteensopivuus muihin mallinnustyökaluihin (kuten Enterprise Architect)
• Versionhallinta Tietomallit-työkaluun
• Selkeä koulutuspaketti mallintajille, jonka voi opiskella "kuka vain". Lisäksi oma koulutuspaketti "mitä huomioida tiedon yhtenäistämistyössä" --> ettei sekoitu asiat tietokantamallinnuksen, tai miten käyttöliittymässä toimitaan, vaan ymmärretään, että ollaan puhtaasti tiedon harmonisoinnin äärellä.
• YAML: Resurssit kannattaa käyttää tärkeämpiin kehityskohteisiin.
• Tietomallien paranneltu XML export olisi erityisen tärkeää. Erityisesti se, että kun tietomallin (xml-siirtoprofiili) vie xml/xsd muodossa, niin attribuuteissa käytetyt koodistot exporttatutuvat xs:simpleType -tyyppisinä enumeroituina arvoina. Kun tämä puuttuu, asiakkaita ei voi ohjata katsomaan tietomallia alustalta, vaan xsd -formaatti pitää itse kursia käsin kasaan, ja toimittaa asiakkaille.
• +Kommentti 9.12.2020 VM:n seminaarista: Olisi hyvä, jos Yhteentoimivuusalustalla (tietomalleissa) pystyisi kertomaan metatietojen lisäksi, mikä on tiedon master data -lähde/tietovaranto, jos sellainen on olemassa. Esim. henkilötunnuksien master data on VTJ:ssä. Näin tiedon hyödyntäjä ohjattaisiin suoraan tiedon lähteelle APIen avulla eikä tietoa kerättäisi uudelleen itse.

Kommentit-työkalu

• kysymykseen (Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille): Kommenttipyyntöjen julkisuus saattaa vaihdella joko täysin julkinen, osittain julkinen tai täysin rajattu välillä. Kommentointipyynnön lähettäjällä pitäisi olla mahdollisuus tämän määrittämiseen.
• Kommentoinnin avaamattomuus on aiheuttanut ihmettelyä, kun tavoitteena on yhteentoimivuus, yleiskäyttöisyys ja avoin alusta. Miten valmisteluvaiheessa voidaan luottaa asiantuntijoiden pienen piirin kykenevän tuottamaan kaikille sopivaa? Kommentointi ja koko työ tulisi altistaa paljon nykyistä laajemmalle avoimelle tarkastelulle.
• kysymykseen (kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille): Olisi hyvä, että kommentit näkyisivät vähintään kierroksen käynnistäjälle ilman, että käy itse kommentoimassa ja että voisi valita, näkyvätkö kommentit kaikille, jotta asiasta voitaisiin päättää projektikohtaisesti.
• Oletettavasti kommenttien tekemiseen voi vaikuttaa kommentin antajan identiteetin näkyminen. Ominaisuus kommentointipyynnön lähettäjän määriteltäväksi. Ratkaisumalli voisi mennä: kirjautuneille käyttäjille näkyy identiteetti; anonyymeille kommentoijille ei näy identiteettiä
• Kommentointikynnys voi nousta, jos on otettava huomioon, että kommentit ovat julkisia. Toisaalta ihmiset ovat jo erilaisissa some-yhteyksissä tottuneet siihen, että lukijoita voi potentiaalisesti olla paljonkin.
• kysymykseen (avataan kommentointikierrokset avoimiksi kaikille): Pitäisi pystyä valitsemaan, onko kierros avoin kaikille, koska eri projekteilla on erilaisia tarpeita.
• Anonyymi kontribuutio erilaisissa keskusteluissa tulisi olla poikkeus, jolla olisi oltava hyvät perusteet – vähän niin kuin Hesarin mielipidekirjoituksissa. Miten tässä kontekstissa tuollainen voisi realisoitua? Onko riski, jos halutaan esittää jatkokysymyksiä palautteen antajalle - se ei ole mahdollista? Lisääkö työtä?

Toimintatavat

• Tarvitaan asiantuntijatyöryhmä määrittelemään sisällöt otsikoille/koodeille. Lisäksi pitää säätää siitä, millä menettelyllä näitä voidaan muuttaa – asetuksella?
• Voisi laatia vuosikellon, jonka mukaan kehittämistä tehdään. Erityisen toivottavaa olisi järjestää palautteen ja kehittämisideoiden työstämistä vaikkapa työpajamaisesti, esim, kerran pari vuodessa siten, että ideoita voisi sparrata myös muiden hyödyntäjien kanssa.
• Y-alustan kehittäminen keskittyy liikaa pieniin toiminnallisuusmuutoksiin. Pitää tiedostaa, mitä haluttiin tavoitella eikä keskittyä sovelluksen toiminnallisuuksiin. Sanastotyön tärkeys on hukutettu sovelluksen jippoihin. Tietomallien kohdalla taas epämääräinen mallinnus ja käsitteiden kytkentä tiedonsiirron ja sitä myötä ”koodauksen" rakenteisiin heikentää entisestään tietomallinnuksen tärkeyttä.
• Yhteentoimivuusalustan visio ja mikä on sen rooli esim. 5 vuoden päästä julkishallinnossa? Suhde muihin työkaluihin ja käyttö eri sektoreilla?
• Kansainväliset standardit ja skeemat hyötykäyttöön
• Tietokomponenttikirjastojen kehittämiseen panoksia ja menettelytapoja. Ne vaativat paljon työtä, jotta voisivat olla "suosituksia" ja niitä kannattaisi hyödyntää. Onko niihin panostettu riittävästi?
• Suositellut tietosisällöt (kysymys 5): Suositus-merkinnän toimivuus olisi epävarmaa. Kuka saa päättää merkinnän käytöstä ja onko käyttäjille hankalaa tulkita useampaa luokitusta rinnakkain? Tärkeämpää olisi saada nykyinen luokitus aktiiviseen käyttöön.
• Luultavasti jokin tällainen menetelmä olisi hyödyllinen – vähän niin kuin vertaisarvioinnin kaltainen malli voisi toimia. Miten raadit valitaan ja kuka vastaa niiden toiminnasta? Suosittelu ajatuksena sinänsä hyvä.
• Y-aineistojen yleinen hallintamalli tulee sitoa tietoalueiden vastuuelinten toiminnan liikkeelle lähtöön. Tässä vaiheessa voi odottaa, koska ei ole vielä järjestäydytty. Kriteerit ”suositus” -leiman saavalle aineistolle täytyy määritellä. Ehdotus on kuitenkin erittäin perusteltu ja tarkoituksenmukainen.
• Osa ehdotuksista tuntuu triviaaleilta, mutta ehkä ne ovat joillekin välttämättömiä. Laajempaa käyttöönottoa silmällä pitäen tärkeämpää olisi tässä vaiheessa kehittää toiminnallisia prosesseja kuin työvälineiden yksityiskohtia. Esimerkiksi kun jonkin sisällön tila on "lausunnolla", mitä tämä oikeastaan tarkoittaa? Tai mikä tekee jostain koodistosta tai termistä "suosituksen"? Pelkät työvälineet eivät edistä yhteentoimivuutta, vaan niiden ympärillä on oltava muita rakenteita (prosessit, toimintatavat).
• Asiantuntijaraati jäi mietityttämään; miten se kootaan ja millä taataan raadin asiantuntijuustaso? Miten kytkeytyy yhteentoimivuustyöhön ja muuhun ylipäätään?
• Hyödyllistä olisi, jos kerättäisiin vuosittain koko Y-alustan/palvelunosien palautetta (normaali palvelu/tuotepalaute ml. ruusut ja risut -osasto sekä vapaa sana). Tämän voisi myös järjestää fasilitoidun infotilaisuuden tms. mekanismin avulla.
• Yhteentoimivuusalustan yhteistä käyttöä tulisi koordinoida kaikkien kesken niin, että jokaisesta käyttäjäorganisaatiosta on nimetty edustaja, joka arvioi käytettävyyttä ja yhteentoimivuutta suhteessa oman organisaation käyttöön suunniteltuihin koodistoihin. En ole huomannut mitään asiantuntijaryhmää, joten emme ole tuoneet yhtään koodistoa alustalle, koska sen hallinnoinnista ei ole sovittu alustan ylläpitäjien kanssa.

Täydennys: VM:n seminaarissa 9.12.2020 esitettyjä kommentteja

Valtiovarainministeriön TiHA-hankkeen järjestämässä Avoindata.fi- ja Yhteentoimivuusalusta-seminaarissa esitettiin myös tähän aihepiiriin liittyviä kommentteja. Näkökulmat ja kommenttien esittäjät ovat hiukan eri kuin marraskuun kyselyssämme.

• Koodistojen yhteistyöryhmä olisi erittäin tarpeellinen. Koodistoja alkaa olla Y-alustalla jo sen verran paljon, että koordinointia tarvitaan.
• Onko tietoa, milloin YSR- ja KMR-työ jossain jatkuu?
• Toivottavasti yhteentoimivuusalustaa ei nähdä liian fyysisenä ilmentymänä, jonne tallennetaan tietomalleja, koodistoja, jne. vaan malli rakentuisi verkostomaiseksi. Kohta meillä on tiedonhallintasukupolven "mainframe"-kone. Ei siis tietoja yhteen paikkaan vaan tehoja löydettävyyteen ja hakuun. Vrt. Google.
• Ainoa keino pysyvyyden ja ajantasaisuuden varmistamiseksi on se, että tiedon tuottajalla on joku intressi tietojen päivittämiseen. Tiedon keskittäminen ja kopiointi jollekin "alustalle" ei ole kestävä ratkaisu.
• Ainakin paikkatietojen osalta aineistometatietoista voi linkittää suoraan tietoa aineistoihin tai aineistoja tarjoaviin palveluihin. Tätä mahdollisuutta tiedontuottajat eivät valitettavasti ole riittävässä määrin hyödyntäneet. Sitä suuremmat höydyt ovat mitä paremmin metatietoja pidetään ajan tasalla, mitä enemmän käytetään yhteisiä koodistoja, määrityksiä yms. ja mitä paremmin huolehditaan hyödyntäjien tietotarpeista (mm. linkitys itse aineistoihin ja rajapintapalveluihin).
• Yhteentoimivuus voi tarkoittaa myös palveluiden yhteentoimivuutta. Eli palvelut voisivat keskustella keskenään, jolloin syntyy ihmiselle/kuluttajalle mielekkäitä palvelupolkuja. Toki tämäkin tarvitsee taustalle teknologioita ja niiden yhteistä kieltä.
• Tiedotusvälineiden (ja kansalaisyhteiskunnan!) kannalta tärkeää on sekä rajapinnat että niiden helppo selailu. Siksi rajapintojen yhteydessä olisi oltava myös helppo tapa selailla tietoja ilman suurta tietoteknistä osaamista.
• Koska toimija tarvitsee kuvauksia omissa palveluissaan, on ajantasainen tieto ao. palveluissa ja ao. toimijalla omassa työvälineessään myös kehittämisen vuoksi. Y-välineessä oleva tieto on ”kopio”. Tällaista kopiotoiminnallisuutta ei nimenomaan haluta tukea (tiedonhallintalaki) viranomaisten muussa toiminnassa, mm. ajantasallapidon ongelmien vuoksi. Metadataakin tulisi tarjota rajapintapalvelujen kautta, ei kopioimalla (taikka uudelleen editoimalla kuten y-alustassa suurimmalta osin joutuu tekemään).
• Yhteentoimivuutta edistävien sanastojen ja ontologioiden osalta kannattaa pitää mielessä myös Finto: https://finto.fi/fi/
• Onko yhteentoimivuusalustan hyödystä konkreettisia esimerkkejä? Miten se on parantanut yhteentoimivuutta? Tiedon laadun osalta yhteentoimivuusalustasta puuttuu laatusäännöt, joiden avulla organisaatio, joka aikoo hyödyntää dataa voi varmistua siitä, onko tiedon kerännyt organisaatio tarkastanut automaattisesti esimerkiksi yhteentoimivuusalustassa määriteltyjen tietomäärittelyjen noudattamisen.