Palautekooste: JHS XXX Paikkatiedon yksilöivät tunnisteet

Transkriptio

1 Palautekooste: JHS XXX Paikkatiedon yksilöivät tunnisteet 1. Organisaatio 2 - Nurmeksen kaupunki - Yksityishenkilö - Finnvera Oyj - Turvallisuus- ja kemikaalivirasto - Elinkeino-, liikenne- ja ympäristökeskuksien ja TE-toimistojen kehittämis- ja halllintokeskus (KEHA-keskus), Tieto- ja viestintäyksikkö - Espoon kaupunki, tekninen ja ympäristötoimi - Maanmittauslaitos - SYKE/Tietokeskus - Geologian tutkimuskeskus GTK - STM - Tilastokeskus - Kansalliskirjasto 2. Yhteyshenkilön tiedot 2 3. Yleiskommentit Vastaajien määrä: 7 - Suositukset ova tarpeellisa. - Finnveralla ei ole lausuttavaa JHS XXX Paikkatiedon yksilöivät tunnisteet -suositusluonnokseen. - Kysymyksiä: Miten yksilöivät tunnisteet käsittelevät multipolygoneja? Saako jokainen osa oman yksilöllisen tunnisteen vai käsitelläänkö ne yhden tunnisteen alla? Mikäli alue jakautuu useampaan osaan saavatko kaikki alueet uuden tunnuksen vai jääkö jollekin alkuperäinen tunnus ja muille uudet? - Motivaatio yksilöiville tunnisteille on tietojen yhdisteltävyys. Suositusluonnos tulee varsinaisen asiansa ohessa kuvanneeksi viittauksineen muihin JHS:iin hyvin paikkatietojen yhteiskäytön kokonaisuutta tällä hetkellä. Yksilöivien tunnusten teoria esitetään luonnoksessa. Käytäntö jää odottamaan järjestelmätoimittajien toteutuksia. Suositus on siinä määrin tekninen, että se onkin enemmän järjestelmätoimittajien ja tietotekniikan ammattilaisten kuin aineiston tuottajien luettavaksi sellaisenaan sopiva. Luonnos aukeaa liitteidensä kautta, tunnisteen rakenne tulee varsinaisessa suositustekstissä varsin myöhään kohdissa ja Inspire-tietokohde tarvitsee pysyvän tunnuksen, mutta lisäksi sitä vastaava reaalimaailman kohde omansa, joten tuleekin kaksi pysyvää tunnusta. Joillekin Inspire-tietotuotteille on toistaiseksi määritelty useita vastuutahoja. Kun yksilöivän id:n voi varata yksi taho ja ko. tahon tiedosta tulee primäärinen tietolähde, tarvitaan tässä tarkennusta joidenkin aineistojen kohdalla, mikä organisaatio lopulta hallinnoi Inspire-aineistoa. Suositus on tekninen ja edellyttää muutoksia käytetyissä tietojärjestelmissä. Muutokset liittyvät yksilöiviin tunnuksiin ja kohteiden elinkaaritiedon hallintaan. Toteutus aiheuttaa kustannuksia kaupungille. Kustannuksia ei vielä tiedetä. Loppukäyttäjälle muutos voi olla lähes näkymätön ja sen toimivuus riippuu ohjelmistotoimittajan toteutuksesta edellytetään yksilöiviä tunnisteita Liitteen I tietotuotteille. Se on aika pian, kun ajatellaan, että tiedon tuottajien ohjelmistoihin tarvitaan uutta toiminnallisuutta. - Suositus ei ole helposti hyödynnettävissä, vaatii pysyvän infrastruktuurin tuekseen ja sekä loppukäyttäjille annettavan tuen. Suosituksen mukaisten käytäntöjen toteutuessa paikkatietojen ja niihin liittyvien käsitteiden automaattinen hallinta ja helpottuu ja osin vasta mahdollistuu. Suosituksen soveltamisessa tulisi pyrkiä harkitsemaan ja priorisoimaan kohteita eikä välttämättä soveltamaan kaikkiin INSPIRE-kohteisiin ilman harkintaa tai näkemystä prosessin hyödyllisyydestä. - JHS täydentää hyvin yksilöivien tunnisteiden osalta kansallista paikkatiedon viitearkkitehtuuria, jonka päivityksessä tulisi huomioda yhteys tähän JHS:ään. - Yleisvaikutelma on, että suositusluonnos on varsin selkeä ja esimerkit parantavat sen luettavuutta. Suositukset

2 perustuvat kansainvälisesti tunnettuun järjestelmään mikä on tietysti hyvä asia. Tilastokeskuksella ei kuitenkaan ole tällä hetkellä meneillään tunnisteisiin liittyvää yleistä laajempaa hanketta, johon ko. JHS:ää voisi peilata. Joihinkin yksityiskohtiin haluamme kuitenkin kommenteissamme kiinnittää huomiota; Kommentit :22, 41, 56, Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: Yhteensä Keskiarvo Suositus on tarpeellinen ,56 Suositus on otettavissa käyttöön ilman tukea ja koulutusta Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla , ,44 Yhteensä ,41 5. Suositusluonnoksen hyväksyminen 2 6. Vastustusperusteet 7. Yleiset muutosehdotukset Vastaajien määrä: 4 - Pintapuolisen silmäilyn perusteella pari huomiota: Mielestäni tämän tyylisissä teksteissä kanttaisi käytää RFC-formaattia. Luonnoksessa menee mielestäni sekaisin yleinen pohdinta ja varsinainen määrittely. Tekstistä ei selvästi erotu mitä nyt ehdotetaan. Pieni osa RFC-formaattia on sitovuussanaston määritteleminen RFC 2119:ssä: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" Mutta ehdotan siis laajemminkin RFC-konventioiden noudattamista. Olisi esimerkiksi hyvä eksplikoida mistä "related work:istä" kirjoittajat ovat tietoisia ja miten omaansa asemoivat siihen jne.

3 Datan käytettävyysnäkökulmasta (ihmisluettavuus, developer experience) ei aina ole toivottavaa, että dataan kirjataan täysipitkiä ureja. Mielestäni olisi hyvä suosittaa soveltuvin osin JSON-LD käyttöä Sitä on pohdittu GeoJsoniinkin liittyen Kolmantena huomiona. Toivoisin selkeämpää kansainvälisen yhteentoimivuuden esiinnostamista käyttötapauksissa ja muutenkin tekstissä ehdotetun asemoimista kansainvälisesti käytettyihin yksilöiviin tunnisteisiin, kuten OpenStreetMap ja GeoNames Tässä esimerkiksi Helsingin linkitykset kyseisiin palveluihin WikiDatassa - Luettavuuteen ja asiakokonaisuuden ymmärrettävyyteen kiinnitettävä huomiota. Lauserakenteet ovat usein liian monimutkaisia ja niiden selkeyttäminen on tarpeellista. INSPIRE direktiivin mukaisten pakollisten asioiden selkeä erottaminen suosituksista olisi tarpeen. Viitattaessa direktiiviin tarkka kohta mainittava. - Voisiko kieliasua vielä selkeyttää, teksti on ajoittain vaikeaselkoista ollakseen suositus, jota pitäisi pystyä laajalti hyödyntämään. Suositustekstiin voisi lisätä esimerkkejä. Aihe on varsin vaikea ja esimerkit voisivat helpottaa ymmärtämistä. - Suositustekstin ja liitteen 1 välillä on paljon päällekkäisyyttä, jopa samaa tekstiä ja kuvia (tai niiden osia) käytetty molemmissa. Pitäisikö pyrkiä eliminoimaan? Suosituksessa ja liitteissä on monessa kohtaa (ainakin neljässä) mainittu sähköpostiosoite, joko "metatieto@nls.fi" tai "metatieto(at)maanmittauslaitos.fi". Ilmeisesti kysymyksessä on pohjimmiltaan sama osoite/postilaatikko, kannattaako se mainita niin monessa paikassa? Jos mainitaan, niin tulisi käyttää johdonmukaisesti samaa osoitetta ja muotoa. 8. Muutosehdotukset kappaleeseen 1. Johdanto - Ei muutosehdotuksia 9. Muutosehdotukset kappaleeseen 1.1 Suosituksen rakenne - Liite 4 voisi olla viimeinen liite - Koodilistat ja niiden URI-tunnisteet, näiden käsittely puuttuu JHS:stä vielä kokonaan. Olisiko omana liitteenä vai pitäisikö lisätä itse suosituksen tekstiin? Suositukset vastaavuuksista INSPIRE-koodilistojen ja kansallisten koodilistojen välillä tarvitaan. 10. Muutosehdotukset kappaleeseen 2. Soveltamisala - Kohderyhmälistaan pitäisi myös lisätä: - Paikkatietoaineistojen kehittäjät ja ylläpitäjät Ensi vaiheessa pitäisi varmistua siitä, että näitä tunnisteita otetaan käyttöön eri paikkatiedoille ja siihen liittyville tiedoille aineistojen tuottajaorganisaatioissa. Lisätkää tietoja Yhteentoimivuusohjelmaan, mikäli ohjelma on tässä yhteydessä relevantti. Lisätkää myös linkki Yhteentoimivuusohjelmaan. Tekstiä voisi osittain lyhentää ja selkeyttää. 11. Muutosehdotukset kappaleeseen 3. Viittaukset - Miksi osa viittauksista on kohdassa 3 ja osa kohdassa Voisiko kaikki viittaukset olla kohdassa 12.1? 12. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet - Ei muutosehdotuksia - Finto: itse käytämme nimitystä "Suomalainen asiasanasto- ja ontologiapalvelu" URI vs URI-tunniste: nyt on määritelty eri merkitys näille termeille suomeksi, vaikka kysymys on alkujaan samasta englanninkielisestä lyhenteestä (I tulee sanasta Identifier, joten "URI-tunniste" sisältää

4 tunniste-merkityksen kahteen kertaan). Ehdotan näiden yhdistämistä. Englanninkielisiä termivastineita puuttuu paljon, vaikka ne useimmissa tapauksissa ovat ilmeisiä. Esim. aineistotunniste = dataset identifier nimiavaruusrekisteri = namespace registry ontologia = ontology ontologiapalvelu = ontology service paikallinen tunniste = local identifier polkukomponentti = path component reaalimaailman kohde = real world object uudelleenohjaus = redirect(ion) uudelleenohjauspalvelu = redirection service UUID-määritelmä puuttuu (mainittu kohdassa 5.2) paikkatietokohdetyyppi puuttuu (mainittu kohdassa 6.1) 13. Muutosehdotukset kappaleeseen 5.1 Tietomallinnukseen perustuva yksilöinti Vastaajien määrä: 3 - Lauseessa Samaa reaalimaailman kohdetta kuvaavien tietokohteiden yksilöivät tunnisteet voidaan myös liittää viittaus tähän reaalimaailman kohteeseen... Pitäisi olla ilmeisesti Samaa reaalimaailman kohdetta kuvaavien tietokohteiden yksilöiviin tunnisteisiin voidaan myös liittää viittaus tähän reaalimaailman kohteeseen... - Lauseessa "Samaa reaalimaailman kohdetta..." sijamuotovirhe? - Tässä virkkeessä on jotain vikaa: "Samaa reaalimaailman kohdetta kuvaavien tietokohteiden yksilöivät tunnisteet voidaan myös liittää viittaus tähän reaalimaailman kohteeseen, jolloin eri tietomallien mukaisia kohteiden ominaisuustietoja voidaan yhdistää." Paitsi että kielioppi on väärin, en ole ihan varma ymmärränkö miten reaalimaailman kohteeseen viitataan. Koordinaatit? Nimi? 14. Muutosehdotukset kappaleeseen 5.2 Muut tunniste- ja yksilöintijärjestelmät - Ei muutosehdotuksia - Miksi UUID esitellään vasta tässä? Miksei Termit ja lyhenteet-kohdassa? 15. Muutosehdotukset kappaleeseen 5.3 INSPIRE-direktiivin edellyttämät tunnisteet - Olisi hyvä jos lukijalle kävisi helposti ilmi mitä aineistoja ko. vaatimukset koskevat. Viittaus PATINEn ylläpitämään listaan Suomen Inspire-aineistoista? 16. Muutosehdotukset kappaleeseen 5.4 Muut kuin INSPIRE-direktiivin mukaiset tunnisteet - Virke " Paikkatietoinfrastruktuurin kattamien paikkatietoaineistojen laajuuden takia samoja tietoja hyödynnetään useilla julkishallinnon ja yhteiskunnan toimialoilla, ja myös keskeiset perustietovarannot kattaen" ei ole ymmärrettävä. - Ei muutosehdotuksia 17. Muutosehdotukset kappaleeseen 6.1 Yleiset vaatimukset - "Yksikäsitteisyys [...] edellyttää [...] että kohteen eri versioiden on oltava saman paikkatietokohdetyypin ilmentymiä" Onko tosiaan näin? Tämähän tarkoittaa, että jos jokin kohde on esim. virheellisesti luokiteltu väärään paikkatietokohdetyyppiin, virhettä ei voi korjata antamatta kohteelle uutta tunnistetta. Se myös tarkoittaa, että

5 paikkatietokohdetyyppien on pysyttävä ikuisesti samoina. 18. Muutosehdotukset kappaleeseen 6.2 Tietojärjestelmäriippumattomat tunnisteet - Tämä jää irralliseksi. Ilmeisesti tämä on vaatimus yleisten vaatimusten lisäksi. Onko tarpeen erotella? 19. Muutosehdotukset kappaleeseen 7.1 Tunnisteen muodostuminen - Missään ei määritellä, mikä on 'kohde'. Onko aina reaalimaailman kohde? Voiko olla esim. ns. multipart -polygon? Ilmeisesti on tiedontuottajan asia määritellä aineistokohtaisesti? Voiko aiheuttaa kuitenkin harmonisointi-ongelmia? Tästä voisi olla viittaus tässä JHS:ssa, jos kohteen määrittämisen ohjeet ei kuulu tähän suositukseen. 20. Muutosehdotukset kappaleeseen Paikallinen tunniste - Paikallisen tunnisteen antaminen tiedontuottajan vastuulla, tiedontuottajia voi olla useita, esim. luonnonsuojelualue-aineisto: Metsähallitus vastaa aineistosta, mutta SYKE vastaa INSPIRE-aineiston tuottamisesta ja -palveluista. Onko mahdollista antaa edes suosituksia siitä, miten tietolähdekohtainen tunnusvarausjärjestelmä tai muu yksikäsitteisyyden varmistava mekanismi toteutettaisiin? 21. Muutosehdotukset kappaleeseen Nimiavaruus - Kuka muodostaa nimiavaruudet kansainvälisille organisaatioille kuten Helcomille? FI:n sijaan HELCOM? Ns. johdettu aineisto ja sen metatiedot: useasti INSPIRE-aineistosta tarvitaan myös kansallinen tietotuote. Useasti metatieto on suurelta osin sama kuin INSPIRE-tietotuotteella, ja kohteet ovat samat. Tuleeko näille kaikille eri versioille oma metatieto ja siten oma aineisto-id? Lisää tiedontuottajan päällekkäistä työtä, eikä välttämättä ole selkeä käyttäjänkään kannalta? esim. On yksi pohjavesi-aineisto, joka on kuvattu metatietoihin. Aineistosta muodostetaan INSPIRE-tietotuotten mukaiset wms- ja wfs palvelut, joiden metatiedot kuvataan. Aineistosta muodostetaan myös kansalliset palvelut, joiden metatiedot kuvataan. - "joka varataan osoitteesta metatieto@nls.fi". Onko ikuisesti (JHS-suosituksen voimassaoloajan) näin, kannattaako tässä olla näin tarkka yhteystieto? 22. Muutosehdotukset kappaleeseen Versiotunniste - Toivotaan täsmällistä viittausta kohtaan (ohjeistuksen tekstinpätkään), jossa todetaan, että myös aikaisempien versioiden tulee olla saatavilla (ts. pakollista). Versiotunnistehan ei ole pakollinen tieto, joten tämä vaikuttaa ristiriitaiselta. - Kappaleessa määritellään merkit, joita saa käyttää. Versiotunnisteessa sallitaan kuitenkin aikaleimassa esim. + ja :, jotka eivät kuulu sallittuihin merkkeihin!? 23. Muutosehdotukset kappaleeseen 7.2 URI-tunnistetyypit - Ei muutosehdotuksia 24. Muutosehdotukset kappaleeseen Reaalimaailman kohteen tunniste - / id - Lisätkää viittaus kansallisen INSPIRE toimeenpanon tietomäärittelyihin, jossa jokaiselle tietokohdetyypille on määritelty sitä vastaava viranomainen. Vaihtoehtoisesti viranomaiset voisi lisätä Liite 6 taulukoihin omaan sarakkeeseen. Voisiko suositukseen lisätä selkokielellä sen, mikä tuli keskukstelutilaisuudessa esille, eli että jos

6 reaalimaailman kohdetta vastaa (esim.) sekä pistemäinen että aluemainen paikkatietokohde, nämä molemmat saavat saman tunnisteen. Esim. samaan Natura-alueesen voi kuulua sekä aluemaisia ja viivamaisia kohteita. 25. Muutosehdotukset kappaleeseen Paikkatietokohteen tunniste - / so - Ehkä voisi lisätä joku tuttu ja turvallinen esitysmuoto kuten ESRI shapefile tai file geodatabase. 26. Muutosehdotukset kappaleeseen Paikkatietokäsitteen tunniste - / def - Lisätkää esimerkki koodiluettelosta, joka osalta myös käytetään def-tunnistetta vai pitäisikö tämän olla kappaleessa 11? Lisätkää tekstiä (tai esimerkki liitteeksi) siitä kuinka INSPIREn koodiluetteloihin viitataan ja kuinka INSPIREn ja kansallisten koodiluetteloiden vastaavuudet osoitetaan. Esitysmuodot; pakolliset listattava selkeästi esim kappaleessa Muutosehdotukset kappaleeseen Paikkatietokohteiden ja -käsitteiden esitysmuodot sekä muiden dokumenttien linkittäminen - / doc - Esitysmuodot; pakolliset listattava selkeästi esim kappaleessa Muutosehdotukset kappaleeseen 8. Tunnisteen elinkaaren hallinta - Ei periaatteessa vaatimuksena INSPIREssä, mutta jos halutaan yksilöivistä tunnisteista täysmääräisen hyödyn, nämä ovat käytännössä tarpeen. 29. Muutosehdotukset kappaleeseen 8.1 Muutostyypit - Selkeästi esille, mikä on pakollista ja mikä suositeltavaa. 30. Muutosehdotukset kappaleeseen 8.2 Elinkaarisäännöt ja versionhallinta - Eri versioiden ja poistuneiden kohteiden säilytysvelvollisuus lisää aineistonylläpitojärjestelmien tiedon määrää sekä hallinnointia. Tarvitaan uutta ohjelmatoiminnallisuutta. Kannattaa olla tarkkana, mitä oikeasti kannattaa yksilöidä ja versioida. Kokemuksena asiakastarpeesta kuntatietojärjestelmässä voi todeta, että purettujen rakennusten ja maastosta kadonneiden rajapyykkien tiedot on säilytetty ja kysyntää on ollut myös rantaviivan aikaisemmalle sijainnille. - "INSPIRE-toimeenpanosäännöt edellyttävät, että kohteen aikaisemmat version tulee säilyttää". Missä toimeenpanosäänössä, viittaus? (Historiantiedon hallintamekanismit ovat tosi alkutekijöissä Suomessa ja muuallakin...) 31. Muutosehdotukset kappaleeseen 9.1 Paikkatietokohteen tunnisteen valinta - On epäselvää mitä tarkoitetaan 3. kappaleen parilla viimeisillä lauseilla. Halutaanko tällä kertoa, että tämä on tiedontuottajan päätettävissä? Voiko tiedontuottaja siis päättää antaako samalle kohteelle (esim pohjavesialue) saman tai eri yksilöivän tunnisteen? Pitäisikö ainakin suositella, että tunnuksen tulee olla sama mikäli kyseessä on sama paikkatietokohde? 32. Muutosehdotukset kappaleeseen 9.2 Verkkotunnus - Tässä kohdassa oletetaan, että aineisto on tiedon tuottajan palvelussa saatavissa online koko ajan. Sen voisi

7 sanoa selkeämmin ja viitata ao. suositukseen. - Ei muutosehdotuksia 33. Muutosehdotukset kappaleeseen 9.3 Yksikäsitteisyyden varmistava mekanismi - Ei muutosehdotuksia 34. Muutosehdotukset kappaleeseen 10.1 Nimiavaruusrekisteri - Aineistotunnisteet olisi kuitenkin hyvä saada helposti esiin. Kts. kommentti liittyen kansainvälisiin organisaatioihin. Mitkä niiden nimiavaruudet ja niiden aineistojen nimiavaruudet ovat? 35. Muutosehdotukset kappaleeseen 10.2 Uuudelleenohjauspalvelu 36. Muutosehdotukset kappaleeseen Paikkatietokohde - /so/ - Kuntien kokoavan paikkatietopalvelun olisi tarkoitus huolehtia kuntien aineistojen muuntamisesta Inspire-skeemojen mukaiseksi, jolloin Kuntien paikkatietopalvelu olisi tavallaan primääri lähde, vaikka kuntien omissa palveluissa aineisto olisikin KRYSP-tietomallin mukaisesti saatavilla. Tämä lienee sinänsä mahdollista ja järjestystä hieman muokaten muistuttaa liitteen 5 Digiroad2- esimerkkiä. Tästä seuraa kuitenkin mahdollinen ongelma, kun kunta kuvaa aineistonsa Paikkatietohakemistoon. Ilmeisesti kuvattaisiin Inspire-aineistona Tietopalvelun aineisto ja muuna aineistona kunnan oma KRYSP-aineisto. Samantapainen tilanne syntyy kaupallisten toimijoiden kokoomapalveluiden tapauksissa. Tällä hetkelläkin on olemassa kuntien aineistoja välittäviä kaupallisia palveluita. - "Tiedon tuottajalla on näiden muuttuessa vastuu palvelunsa toimivuudesta". Mihin viitataan "näiden"-sanalla? 37. Muutosehdotukset kappaleeseen Reaalimaailman kohde - /id/ - Mistä tietoa siitä onko joku jo tehnyt id-tunnisteen? (viimeinen kappale) 38. Muutosehdotukset kappaleeseen Paikkatietokohdetta kuvaava käsite - /def/ - Lisättävä URI-polun rakenne koodilistoille - "Käsitelähteenä olevalle sanastolle aineistotunnisteen saa osoitteesta metatieto(at)maanmittauslaitos.fi." Sama kommentti kuin kohtaan 7.1.2, onko järkevää antaa näin yksityiskohtainen yhteystieto suosituksessa? Miksi osoite on eri kuin kohdassa 7.1.2? 39. Muutosehdotukset kappaleeseen Esitysmuodot ja dokumentit - /doc/ - RDF/XML-esimerkki näyttää sekavalta. Vähintään suosittelen sen käsittelyä jollakin syntax highlight -työkalulla. JHS 183:ssa käytettiin tohtml.com-palvelua (copy-paste selaimesta Wordiin säilyttää värit). Sisennys ei ole aivan johdonmukainen - <dc:subject> on sisennetty liikaa. Turtle-syntaksi voisi olla luettavampi kuin RDF/XML. RDF-esimerkissä on pientä sekaannusta Dublin Core nimiavruuden kanssa. Esimerkissä käytetään dc:hasformat-suhdetta, joka löytyy uudemmasta Dublin Core Terms -nimiavaruudesta

8 ( mutta esimerkissä on käytetty vanhempaa DC Elements 1.1 nimiavaruutta. Toisaalta esimerkissä käytetään myös dc:format-suhdetta merkkijonoarvoilla (esim. "application/json") mikä ei ole sallittu DC Termsissä, jossa format-arvojen tulisi olla resursseja. Helpointa olisi lisätä nimiavaruusmäärittely DC Termsille, näin: xmlns:dct=" ja sitten korjata dc:hasformat-suhteet muotoon dct:hasformat. Samoin dc:subject-suhteet voi muuttaa uudempaan nimiavaruuteen ts. muotoon dct:subject. 40. Muutosehdotukset kappaleeseen 11.2 Uudelleenohjauksen ja tietojen linkittämisen käytänteet Vastaajien määrä: 3 - Kuvan mukaan Lappeenrannan kaupungin Saimaalta voi päästä Syken Saimaan tietoihin, mutta ei toisin päin. Ilmeisesti kuitenkin on tarkoitus, että mahdollisuuksien mukaan fyysisen ympäristön id:n kautta, jos se on tallennettu, pääsee kaikkien aineiston toimittajien vastaaviin kohteisiin. Tässäkin tapauksessa näkyy myös se, että jos tiedon tuottajia on monta, pitää viimeistään toteutusvaiheessa yksilöidä Inspire-aineistosta vastaava taho. - Esimerkkikaaviot, suositusluonnos sivu 18 ja liite I sivu 6: Suosittelen vaihtamaan esimerkki-kohteen (nyt Saimaa) toiseksi. Esimerkin tulisi kuvata yksinkertaista perustapausta, josta voi johtaa menettelytapoja ja -ohjeita muita tapauksia varten. Saimaa on paikkatietokohteena hankalimpia mallinnettavia. Esimerkiksi MML:n paikkaluokituksen mukaan "Järvi tai lampi" on "Vedenkorkeudeltaan yhtenäinen makean veden luonnonallas", jolloin Saimaa ulottuu Imatralta aina Mikkeliin, Varkauteen ja Joensuuhun. Esimerkin Lappeenrannan kaupungin "Saimaa" saattaa merkitä kunnan alueella olevaa muutaman kilo-metrin järvikaistaletta. Yksittäinen järvi ei myöskään ole käsite, kuten kaavio esittää, vaikka retorisesti joku voisikin sanoa että "Saimaa on käsite sinänsä". Kaaviossa URIin on sisällytetty sana "saimaa" (pieni s?). Paikannimiä ei tule sisällyttää URIin. Nimi on järven ominaisuus, joka voi myös muuttua. Nimi voi myös sisältää kirjaimia ä, ö, å ja saamen erikoismerkkejä. Jos ko. kaaviossa halutaan käyttää järveä esimerkkinä, suosittelen esimerkiksi Pyhäjärveä (jokin Suomen noin 50 Pyhäjärvestä). - Kaavio: voisiko lisätä esimerkkiin "alkuperäisen aineiston" ei siis pelkästään INSPIRE-aineiston paikkatietokohde? Teksti:...edellisessä kappaleessa 11.3, pitäisi olla Muutosehdotukset kappaleeseen 11.3 Vastauskäytänteet - Jos URI annetaan ilman paikallista tunnistetta, vastauksena annetaan ATOM-syöte? Tätä tuskin toteutuu kaikissa tapauksissa?! 42. Muutosehdotukset kappaleeseen 12.1 Yhdistetty tieto (Linked data) - tämä kohta ei nyt täsmää dokumentin kanssa - Suosituksessa ei ko. kappaletta? 43. Muutosehdotukset kappaleeseen 12.2 Ontologiapalvelu - tämä kohta ei nyt täsmää dokumentin kanssa - Suosituksessa ei ko. kappaletta? 44. Muutosehdotukset kappaleeseen 12.3 Luettelopalvelu - tämä kohta ei nyt täsmää dokumentin kanssa - Suosituksessa ei ko. kappaletta? 45. Muutosehdotukset kappaleeseen 13. Opastavat tiedot - tämä kohta ei nyt täsmää dokumentin kanssa

9 46. Muutosehdotukset kappaleeseen 13.1 Kirjallisuusviitteet ja muut viittaukset - Tarkoitettaneen kohtaa Muutosehdotukset kappaleeseen 14. Liitteet - Tarkoitettaneen kohtaa 13. Liite 4 viimeiseksi 48. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 1. Johdanto 49. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 2. Paikallisen tunnisteen luominen tietokantaan - Missä vaiheessa kohteelle haetaan tunniste? Käytännössä työskentelytapa ja siitä seuraava ohjelmistologiikka esimerkiksi tapauksessa, jossa alue uudiskartoitetaan, vaatii jatkokehittelyä. Ilmeisesti ohjelmistokehittäjien ratkaistava ja ratkaistavissa. Suosituksen toteutusten aikataulu tietojärjestelmissä ja niiden oheisissa palvelurajapinnoissa on vielä auki. 50. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 3. Yksilöivän HTTP URI -tunnisteen luominen. - Kuvaan voisi lisätä esimerkin "alkuperäisen aineiston" kohteen so-tunnisteen 51. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 3.1 Aineistotunnisteen varaaminen. - Tässäkin esiintyy sähköpostiosoite, joka on sama kuin itse suosituksen kohdassa mutta eri kuin suosituksen kohdassa Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 3.2 Yksilöitävän kohteen tyyppi. 53. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen Paikkatietokohteet (so). - Kohta "Muille kuin INSPIRE-aineistoille paikkatietokohteen HTTP URI -tunnisteen..." : suositus käyttää gml:identifier -elementtiä. Muut kuin INSPIRE-aineistot eivät välttämättä ole gml-muodossa, koska sitä ei missään vaadita. Kohta "Paikallista tunnistetta suositellaan käytettäväksi gml:id-attribuutin..." Koskeeko tämä INSPIRE-aineistoja? 54. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 3.2.2

10 Reaalimaailman kohteet (id). 55. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen Paikkatietokäsitteet (def). 56. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 4. Uudelleenohjausten asettaminen. Vastaajien määrä: 3 - Esimerkkikaaviot, suositusluonnos sivu 18 ja liite I sivu 6: Suosittelen vaihtamaan esimerkki-kohteen (nyt Saimaa) toiseksi. Esimerkin tulisi kuvata yksinkertaista perustapausta, josta voi johtaa menettelytapoja ja -ohjeita muita tapauksia varten. Saimaa on paikkatietokohteena hankalimpia mallinnettavia. Esimerkiksi MML:n paikkaluokituksen mukaan "Järvi tai lampi" on "Vedenkorkeudeltaan yhtenäinen makean veden luonnonallas", jolloin Saimaa ulottuu Imatralta aina Mikkeliin, Varkauteen ja Joensuuhun. Esimerkin Lappeenrannan kaupungin "Saimaa" saattaa merkitä kunnan alueella olevaa muutaman kilo-metrin järvikaistaletta. Yksittäinen järvi ei myöskään ole käsite, kuten kaavio esittää, vaikka retorisesti joku voisikin sanoa että "Saimaa on käsite sinänsä". Kaaviossa URIin on sisällytetty sana "saimaa" (pieni s?). Paikannimiä ei tule sisällyttää URIin. Nimi on järven ominaisuus, joka voi myös muuttua. Nimi voi myös sisältää kirjaimia ä, ö, å ja saamen erikoismerkkejä. Jos ko. kaaviossa halutaan käyttää järveä esimerkkinä, suosittelen esimerkiksi Pyhäjärveä (jokin Suomen noin 50 Pyhäjärvestä). - Toinen kappale: Tunnisteen antajan tehtävänä on määritellä... po. Tiedontuottajan tehtävänä on määritellä... - Tässä esiintyy sähköpostiosoite, joka on sama kuin kohdassa mutta eri kuin muissa kohdissa Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 1. Johdanto. - Johdanto olisi hyvä alkaa kolmannella kappaleella "Tässä liitteessä..." 58. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 2. Tiedontuottajan URI-palvelun toimintaperiaate ja vastauskäytänteet. - Kuvasta ja tekstistä saa käsityksen että WFS-palvelu on pakollinen ATOM-syötteen lisäksi. Näinhän ei asia ole, vaan jompi kumpi on toteutettava. 59. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 3. Tekniset vaatimukset. - Tässä voisi mainita, että Fuseki noudattaa SPARQL 1.1 standardia ja mikä tahansa muukin SPARQL 1.1 yhteensopiva RDF-tietokanta pitäisi toimia sen tilalla. En ainakaan näe ympäröivässä tekstissä mitään Fusekiin tiukasti sidoksissa olevaa. Ainoastaan.htaccess-esimerkeissä näkyi URL-polkuja jotka viittaavat Fusekiin, mutta ne pitäisi joka tapauksessa tarkistaa vastaamaan omaa Fuseki-asennusta ja tilalla voi tällöin yhtä hyvin olla jokin muu SPARQL-toteutus. 60. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 4. Tiedontuottajan URI-palvelun toteutusvaiheet. - Näyttäisi siltä, että paikkatiedontuottajaorganisaatio tarvitsee erillisen url-palvelun? 61. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 5. Tiedontuottajan URI-palvelun palauttaman RDF-tiedon rakennekuvaus.

11 - Luokkanimet jhs:doc ja jhs:data eivät noudata yleisiä käytäntöjä, joissa luokkanimet pyritään kirjoittamaan isolla alkukirjaimella (ja CamelCasella). Olisiko parempi käyttää luokkaniminä esim. jhs:document ja jhs:data? Taulukossa ei ole määritelty ovatko arvot resursseja vai literaaleja. Toki se jossain määrin selviää myöhemmistä esimerkeistä. DC-nimiavaruuden käyttö on tässäkin hiukan ongelmallista (vrt. kommentti suosituksen lukuun ); luultavasti kannattaisi erotella nimiavaruudet dc ja dct ja käyttää näissä määriteltyjä suhteita seuraavasti: dct:hasformat, dct:subject, dc:format. 62. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 6.1 XSLT-muunnostiedosto. - Tässä on muunnettu GML:ää suoraan SPARQL UPDATE -lauseeksi. Voihan sen näinkin tehdä, mutta lopputulos on kyllä aika sekava kun täytyy huomioida sekä XML:n/XSLT:n että SPARQL-kielen syntaksi ja mm. erikoismerkkien käsittely. Minusta järkevämpää olisi tehdä XSLT-muunnos GML:stä RDF/XML:ksi ja sen jälkeen ohjeistaa lataamaan syntynyt RDF/XML-dokumentti esim. yhden rivin SPARQL LOAD -kyselyllä. 63. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 6.2 SPARQL-kysely. - Tämä on ehkä hiukan turhan monimutkainen kysely sinänsä yksinkertaiseen asiaan, eli pyydetään periaatteessa kaikki (suosituksen mukaiset) tiedot tietystä paikkatietoresurssista. Jos ei haittaa, että mukana on myös mahdollisia muita elementtejä (kuvittelisin että näin juuri halutaan), päästään paljon helpommalla: CONSTRUCT { < jhs:so?so.?so?prop?val. } WHERE { < jhs:so?so.?so?prop?val. } Tai jos tiedetään jo valmiiksi paikkatieto-objektin tunniste (yllä muuttuja?so), niin voidaan jopa käyttää yhden rivin DESCRIBE-kyselyä. Toisaalta datan julkaisuun tämän tyyppisten kyselyjen avulla on myös monia aputyökaluja (esim. Pubby, Loddy, Elda) joten en ole ihan varma kannattaako tällaisia välttämättä edes itse kirjoittaa. 64. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 6.3 RDF-esimerkki. - Sama kommentti Dublin Core nimiavaruuksista kuin itse suosituksen lukuun Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 6.4 Apache.htaccess -tiedosto. - Tämä on kyllä lähtökohtaisesti niin vaikea/sekava, että minun on hiukan hankala uskoa että siitä on kenellekään hyötyä. Mutta en osaa ehdottaa parempaakaan. CONSTRUCT-kyselyt voisi joka tapauksessa yksinkertaistaa kohdan 6.2 kommenttien mukaisesti. 66. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 1. Johdanto. - Johdantoon alkuun kappale jossa kerrotaan "Tässä dokumentissa kuvataan..."

12 67. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 2. Yleistä. 68. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 3. Tapahtumatyypit ja niiden alaluokat. 69. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 4. Elinkaarisäännöt paikkatietojen mallintamisessa. - Paikkatietokannossa tehdään erilaisia topologisia eheysajoa ja alueen muodostusta, jotka eivät varsinaisesti muuta kohteita. Toteutuksessa pidettävä nämä muutokset erillään versioinnista. 70. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 5. Elinkaarisääntöjen käyttäminen. 71. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 6. Elinkaarisääntöjen tuottaminen. 72. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 7.1 Esimerkki kiinteistömuodostusprosessin elinkaarisäännöistä. 73. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 7.2 Esimerkki rakennuksen elinkaarisäännöistä. - Jos rakennukset yhdistetään hallinnollisesti, ei ole oikein sanoa, että toinen niistä purettiin. Asialle pitää olla jokin osuvampi ilmaus, kuten lakkasi yhdistämisen takia. Esimerkistä selviää, että rakennuksen tunnus pysyy, vaikka sen käyttötarkoitus muuttuisi. Liitteen ja suosituksen tekstistä saa kahdesta kohtaa päin vastaisen kuvan asiasta kun puhutaan rakennuksen identiteetin muuttumisesta käyttötarkoituksen muuttuessa. Kaavayksikön tapauksessa alueella olevan kiinteistörekisteriyksikön olemassa olo jatkuu, vaikka sen alueelle muodostettaisiinkin uudella kaavalla tai tonttijaolla uusia kaavayksiköitä. Rekisteriyksikkö muuttuu vasta toimituksessa. Maarekisteritilat ja asemakaavan mukaiset tontit ovat samassa kiinteistörekisterissä. Rekisterikiinteistö ei ole mikään toimituslaji 74. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen 1. Johdanto. 75. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen 2.1 Metatiedot.

13 76. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen Tietotuotemäärittely. 77. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen Elinkaarisäännöt. 78. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen Tunnisteen muodostaminen. 79. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen 2.3 Sähköiset rajapintapalvelut. 80. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIRE-aineistoille kappaleeseen 3. Ohjeistus käyttöönotosta. - erittäin hyvä kokonaiskuvaus aineiston julkaisemisesta yhteiskäyttöön. Jotta aineiston tuottajat toimisivat sen mukaan, tarvitaan tukea ohjelmistotoimittajilta ja asiantuntijoilta, mikä tietysti maksaa. - Sekä WFS-plavelun että ATOM-syötteen rakentaminen ei ole edes INSPIRE-vaatimuksena pakollista (jompi kumpi), ei voida vaatia ei-inpire aineistoillekaan 81. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 1.1 Käyttötapaus avoimien paikkatietotuotteiden löytämisestä ja käyttöönottamisesta. - Liitteen alkuun Johdanto! Voisi karsia nykytilan ja menneisyyden kriittisen tarkastelun ja keskittyä onnistumisiin. Pysyvä tunnus ei mitenkään voi olla käsin ylläpidettävä. 82. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen Avoimien paikkatietotuotteiden hakeminen Paikkatietohakemiston kautta. 83. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen Avoimien paikkatietotuotteiden hakeminen Tampereen avoimen datan datakatalogista. 84. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 1.2 Avoimen datan

14 kehittäjän tietoarkkitehtuurinäkökulma. 85. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 1.3 Vaiheet. 86. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 2.1 Dokumenttien linkittäminen - Esimerkki mineraalivaroihin liittyvästä palvelusta. 87. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen Vaiheet. 88. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 2.2 Ylläpidon synkronointi URI:ien avulla - Pysäkkitiedon ylläpito Digiroad2-järjestelmässä. 89. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen Vaiheet. 90. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 3. Yhteiskäyttö URI:en avulla - Hydrografia teema. 91. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 3.1 Myrkkypäästön hallinta. 92. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 3.2 Vaiheet. 93. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 4. Ontologiat ja yhdistetty tieto (Linked data). 94. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 4.1 Metatietotasolla olevien linkitysten hyödyntäminen.

15 95. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 4.2 Skeematasolla olevien linkitysten hyödyntäminen. 96. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 4.3 Metatieto- ja skeematasoilla olevien linkitysten hyödyntäminen. 97. Muutosehdotukset liitteen 5. Käyttötapausesimerkkejä kappaleeseen 4.4 Kohdetasolla olevien linkitysten hyödyntäminen. 98. Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 1. Johdanto. - Onkohan järkevää listata aineistoja ja kohdetyyppejä, koska kokemus on jo osoittanut että päivityksiä tulee? 99. Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 2. Yksilöivät tunnisteet INSPIRE-aineistoissa Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 2.1 Yhteiset tyypit Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 2.2 Liite I aineistot. - Hydrografia, VPD Vesimuodostuma, WFDWaterBody on siirretty osaksi liite III aineistoja. Nÿkyään osana AM-teemaa Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 2.3 Liite II aineistot Muutosehdotukset liitteen 6. Yksilöivät tunnisteet INSPIRE-aineistoissa kappaleeseen 2.4 Liite III aineistot. - TILASTOINTIYKSIKÖT - Tilastointialueet - Statistical Tessellation TILASTOINTIYKSIKÖT - Tilastoruudukko - StatisticalGrid eli yllä Inspire-aineistoista käyttämämme suomenkieliset nimet