Palautekooste ja työryhmän vastine: JHS XXX Paikkatiedon yksilöivät tunnisteet

Transkriptio

1 Palautekooste ja työryhmän vastine: JHS XXX Paikkatiedon yksilöivät tunnisteet 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ä: Suositukset ova tarpeellisa. Ei toimenpiteitä 3.2 Finnveralla ei ole lausuttavaa JHS XXX Paikkatiedon yksilöivät tunnisteet -suositusluonnokseen. 3.3 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? 3.4 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 Ei toimenpiteitä Huomioitu: yksilöivien tunnisteiden liittäminen riippuu käytettävästä tietomallista ja elinkaarisäännöistä. Työryhmä täsmentää suosituksen ja sen liitteiden tekstejä. Ei toimenpiteitä Huomioitu: suositusluonnoksen käyttöönottosuunnitelmassa otetaan huomioon. Huomioitu: työryhmä tiivistää ja täsmentää suositusta siten, että johdanto sekä varsinainen suositusteksti erottuvat selkeämmin. Hylätään: Inspire-tietotuotteiden vastuutahojen

2 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 Inspireaineistoa. 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. 3.5 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ä. 3.6 JHS täydentää hyvin yksilöivien tunnisteiden osalta kansallista paikkatiedon viitearkkitehtuuria, jonka päivityksessä tulisi huomioda yhteys tähän JHS:ään. 3.7 Yleisvaikutelma on, että suositusluonnos on varsin selkeä ja esimerkit parantavat sen luettavuutta. Suositukset 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, 103 määrittely kuuluu Inspire:n toimeenpanoon, ei JHSsuositukseen. Ei toimenpiteitä. Ei toimenpiteitä. Ei toimenpiteitä Ei toimenpiteitä Hylätty: Inspire:n sääntöjen mukaan kaikille Inspirekohteille ei edellytetä yksilöiviä tunnisteita. Tarkemmin Inspire:n säännöistä ja toimeenpanosta päätetään muualla kuin JHS-suosituksessa. Huomioitu: Työryhmä lisää viittaukset paikkatiedon viitearkkitehtuuriin käyttöönottosuunnitelmaan sekä viestittämällä asian viitearkkitehtuurin käynnistymässä olevaan konsulttityöhön.. Ei toimenpiteitä 4. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: 9

3 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ä: 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" txt Mutta ehdotan siis laajemminkin RFCkonventioiden noudattamista. Olisi esimerkiksi hyvä eksplikoida mistä "related work:istä" kirjoittajat ovat tietoisia ja miten omaansa asemoivat siihen jne. 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 tyylistä Huomioitu: JHS suosituksissa noudatetaan JHS 136:sta, joka viittaa myös RFC 2119:n. Työryhmä tarkentaa tekstiä paremmin vastaamaan JHS 136:n luvun 5.3 mukaista teknistä eritelmää. Huomioitu: työryhmä täsmentää suositusehdotuksen tekstiä Huomioitu työryhmä täsmentää tekstiä JHS136:n ohjeiden puitteissa. Huomioitu: täydennetään lähteitä Huomioitu: työryhmä keskustelee mielellään palautteenantajan kanssa tarkemmasta kuvauksesta. Työryhmä harkitsee JSON-LD:n sekä RDF/Turtlen lisäämistä vaihtoehtoiseksi toteutustavaksi.

4 @context:in 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. 7.3 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ä. 7.4 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. Huomioitu: työryhmä tarkentaa käyttötapausten kuvauksia siten, että viittaukset muihin tietoaineistoihin tulevat mukaan. Huomioitu: työryhmä on parantaa suositusehdotuksen tekstiä. Huomioitu: työryhmä tarkentaa suositusehdotusta ja mahdollisesti tekee erikseen osion, jossa on eritelty Inspire-direktiin liittyvät asiat. Huomioitu: työryhmä tarkentaa tekstiä. Esimerkkien osalta toivomme palautteen antajalta konkreettisia ehdotuksia. Hylätty: työryhmä on laatinut liitteet siten, että lukija saa riittävän tiedot pelkästään liitteen lukemisella. Huomioitu: sähköpostiosoitteet korjataan yhdenmukaiseen muotoon. 8. Muutosehdotukset kappaleeseen 1. Johdanto 8.1 Ei muutosehdotuksia Ei toimenpiteitä 9. Muutosehdotukset kappaleeseen 1.1 Suosituksen rakenne 9.1 Liite 4 voisi olla viimeinen liite Hylätty: liitteiden järjestys on muodostunut asioiden esitysjärjestyksestä suositustekstissä. Mahdollisesti

5 järjestys muuttuu seuraavassa versiossa. 9.2 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. Huomioitu: lisättäneen /def/ kohtaan. Huomioitu/Hylätty: asia käsitellään Inspire-direktiivin toimeenpanon yhteydessä ja se tullaan ohjeistamaan erikseen myöhemmin. Koodilistojen vastaavuuksista on tarkoitus antaa menettelytapaohjeistus Inspiren toimeenpanon yhteydessä. 10. Muutosehdotukset kappaleeseen 2. Soveltamisala 10.1 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ää. Hyväksytään Huomioitu: tarkennetaan käyttöönottosuunnitelmassa. Huomioitu: Jos palautteella tarkoitetaan linkitystä Yhteentoimivuudeen tietopankkiin ( / avoindata.fi), niin linkitys lisätään suositukseen. Muussa tapauksessa toivomme palautteen antajalta tarkennusta asiaan. Huomioitu 11. Muutosehdotukset kappaleeseen 3. Viittaukset 11.1 Miksi osa viittauksista on kohdassa 3 ja osa kohdassa Voisiko kaikki viittaukset olla kohdassa 12.1? Ei toimenpiteitä: kohdassa 3 on mainittu JHSohjeistuksen mukaisesti säädöksiin liittyvät viittaukset. Kohdassa 12.1 on taasen lähdeviitteet. JHS-suositusten ylläpidossa on havaittu, että säädösten muutokset on tehokkaampaa ottaa huomioon kun kuhunkin JHS:n liittyvät säädökset on helposti luettavissa kappaleesta 3. Inspire-direktiivin ja siihen liittyvän suomalaisen lainsäädännön viittaukset tulevat siis kappaleeseen 3. Sen lisäksi Inspire-direktiiviin ja sen toimeenpanosääntöihin tulee myös lähdeviittauksia kappaleeseen Kohdan 3 tarkoituksena on JHS-prosessissa, että siihen kirjataan säädökset, joiden muutoksista voi aiheutua seurauksia tai ylläpitoa po JHS:en. 12. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet

6 12.1 Ei muutosehdotuksia Ei toimenpiteitä 12.2 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ää 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 Hyväksytään Huomioitu: työryhmässä on käyty keskustelua aiheesta jo aikaisemmin. Selvyyden ja luettavuuden takia on päädytty siihen, että URI-tunniste olisi ymmärrettävämpi termi. Erityisesti niiden lukijoiden keskuudessa, joille URI on ennestään täysin tuntematon asia. Asiaa käsitellään vielä työryhmässä. Tunniste-termin sijasta käytetään URI-yhteydessä konkreettisempaa termiä tunnus, joka on kansallisesti yleisesti käytössä tietoresurssien yhteydessä (vrt. rakennustunnus, henkilötunnus, kiinteistötunnus). Huomioitu: työryhmä täydentää termien määrittelyjä. UUID-määritelmä puuttuu (mainittu kohdassa 5.2) paikkatietokohdetyyppi puuttuu (mainittu kohdassa 6.1) Hyväksytään Huomioitu: työryhmä ei ollut tunnistanut tätä erityiseksi termiksi, kopioidaan määrittely Geoinformatiikan sanastosta. 13. Muutosehdotukset kappaleeseen 5.1 Tietomallinnukseen perustuva yksilöinti Vastaajien määrä: Lauseessa Samaa reaalimaailman kohdetta kuvaavien tietokohteiden yksilöivät tunnisteet voidaan myös liittää viittaus tähän reaalimaailman kohteeseen... Hyväksytään 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? 13.3 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? Hyväksytään: katso palaute 13.1 Hyväksytään: katso palaute 13.1 Huomioitu: Reaalimaailman kohteisiin viitataan URItunnisteilla. Lisätään esimerkki suositusehdotukseen. Reaalimaailman kohteen tunnisteelle käytetään ns.

7 placeholder-menettelyä siten, että sitä mallintavan paikkakohteen URI-tunnuspolun /so/-komponentin sijaan vaihdetaan /id/-komponentti. 14. Muutosehdotukset kappaleeseen 5.2 Muut tunniste- ja yksilöintijärjestelmät 14.1 Ei muutosehdotuksia Ei toimenpiteitä 14.2 Miksi UUID esitellään vasta tässä? Miksei Termit ja lyhenteet-kohdassa? Huomioitu: lisätään termeihin. 15. Muutosehdotukset kappaleeseen 5.3 INSPIRE-direktiivin edellyttämät tunnisteet 15.1 Olisi hyvä jos lukijalle kävisi helposti ilmi mitä aineistoja ko. vaatimukset koskevat. Viittaus PATINEn ylläpitämään listaan Suomen Inspire-aineistoista? Huomioitu: lisätään viittaus 16. Muutosehdotukset kappaleeseen 5.4 Muut kuin INSPIRE-direktiivin mukaiset tunnisteet 16.1 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ä. Huomioitu: Kappale kirjoitetaan paremmin Ei muutosehdotuksia Ei toimenpiteitä 17. Muutosehdotukset kappaleeseen 6.1 Yleiset vaatimukset 17.1 "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ä paikkatietokohdetyyppien on pysyttävä ikuisesti samoina. Ei toimenpiteitä: asianmukaisesti laadittujen elinkaarisääntöjen mukaan paikkatietokohde on luokiteltu väärin ja virhe voidaan korjata. Jos kuitenkin paikkatietoaineistossa paikkatietojen kohdetyyppi muuttuu (esimerkiksi pisteestä alueeksi), lienee muutos lähtökohtaisesti niin suuri, että käytännössä muodostuu uusi paikkatietoaineisto. Tällöin paikkatietoaineistoille tulee uusi tietoaineistotunnus ja sitä kautta uusille kohdeille uudet yksilöivät tunnukset. (Yksittäisen paikkatietokohdetyypin geometriatyypin muuttuessa säännön soveltamista voi harkita tarkoituksenmukaisuusperustein esimerkiksi sen suhteen, onko mallinnustavalla vaikutusta ulkopuolisiin tahoihin.)

8 18. Muutosehdotukset kappaleeseen 6.2 Tietojärjestelmäriippumattomat tunnisteet 18.1 Tämä jää irralliseksi. Ilmeisesti tämä on vaatimus yleisten vaatimusten lisäksi. Onko tarpeen erotella? Huomioitu: lukua 6 tarkennetaan 19. Muutosehdotukset kappaleeseen 7.1 Tunnisteen muodostuminen 19.1 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. Huomioitu: muutetaan kohdetunniste => tunniste Kaikilla paikkatietokohteilla ei ole reaalimaailman kohdetta. Esimerkiksi korkeuskäyrällä ei ole reaalimaailmassa, mutta silti sillä voi olla yksilöivä tunniste. Paikkatietokohteen geometrian tyyppi voi olla multipolygon. Suositusluonnoksessa esitetty URIkäytänne on tietomallipohjainen. Siksi paikkatietokohteen mallin-nusmetodi määrittelee yksikäsitteisesti URI-tunnuksen muodostumisen. Mallinnukseen vaikuttavien tai ohjaavien standardien kehittyminen säätelee ja harmonisoi mallinnuskäytäntöä. Esimerkiksi tuore ISO Linear Referencing-standardi mahdollistaa viivamaisten kohteiden relatiivisen referoinnin ts. standardi mahdollistaa viivamaisten kohteiden käsittelyn osissa pilkkomatta itse kohdetta osiin (tiestön kohdalla vaikkapa päällysteen, tielajin ja nopeusrajoitusten suhteen). Tämä standardi antaa viitteitä monitasoisten tai -osaisten geometrioiden mallintamiseen yhtenäisellä tavalla. Kyllä Voi. Kansainvälinen standardointi ohjaa ja harmonisoi mallinnuskäytänteitä. Työryhmän tiedossa ei ole yhtä yleisohjetta johon voisi viitata. Liittyy kohdealueen paikkatietojen tietomallintamiseen ja paikkatietojen hyödyntämiseen. Esimerkiksi tuore ISO Linear Referencingstandardi mahdollistaa viivamaisten kohteiden relatiivisen referoinnin ts. standardi mahdollistaa viivamaisten kohteiden käsittelyn osissa (tiestön kohdalla vaikkapa päällysteen, tielajin ja nopeusrajoitusten suhteen) pilkkomatta itse kohdetta osiin. Tämä standardi antaa viitteitä monitasoisten tai -osaisten geometrioiden mallintamiseen yhtenäisellä tavalla. 20. Muutosehdotukset kappaleeseen Paikallinen tunniste

9 20.1 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? Huomioitu: työryhmä harkitsee tarkempien esimerkkien ja käyttötapausten tuottamista. Esitetyssä tilanteessa voisi olla mahdollista hyödyntää globaalia tunnusvarausjärjestelmää (UUID). Työryhmän käsityksen mukaan annetussa esimerkissä Metsähallituksen tulee huolehtia yksilöivistä paikallisista tunnuksista. Lisäksi Metsähallituksen ja SYKEn tulee sopia asiasta kuinka yksilöivät tunnukset hallitaan sekä alkuperäisessä tietoaineistossa että Inspire-tietotuotteeessa. 21. Muutosehdotukset kappaleeseen Nimiavaruus 21.1 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 INSPIREtietotuotten mukaiset wms- ja wfs palvelut, joiden metatiedot kuvataan. Aineistosta muodostetaan myös kansalliset palvelut, joiden metatiedot kuvataan "joka varataan osoitteesta Onko ikuisesti (JHS-suosituksen voimassaoloajan) näin, kannattaako tässä olla näin tarkka yhteystieto? Huomioidaan: työryhmä selvittää asiaa ja tarkentaa suositusehdotusta. Helcom-aineistolla on aineistotunniste Paikkatietohakemistossa. Ei toimenpiteitä: toistaiseksi ei ole harkittu tarkempien soveltamissääntöjen sisällyttämiseksi osaksi JHSsuositusta. Jos eri tietotuotteet eroavat oleellisesti toisistaan, niin silloin lienee tarkoituksenmukaista, että tietotuotteille annetaan omat yksilöivät aineistotunnisteet sekä metatiedot. Jos johdettua aineistoa käytetään useilla tahoilla, niin on perusteltua että sillä on omat yksilöivät tunnisteet. Hylätään: Maanmittauslaitos hoitaa Inspire-direktiivin mukaista kansallista metatietohakemistoa. Jos tämä velvoite muuttuu, voidaan kyseinen sähköposti uudelleen ohjata uudelle vastuutaholle. 22. Muutosehdotukset kappaleeseen Versiotunniste 22.1 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!? Huomioitu: työryhmä etsii halutut viittaukset ja liittää ne suositustekstiin. Huomioitu: työryhmä tarkistaa asian Inspire:n dokumenteista. 23. Muutosehdotukset kappaleeseen 7.2 URI-tunnistetyypit

10 23.1 Ei muutosehdotuksia Ei toimenpiteitä 24. Muutosehdotukset kappaleeseen Reaalimaailman kohteen tunniste - / id 24.1 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 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. Huomioitu: viittaus lisätään. Huomioitu: työryhmä tarkentaa suositustekstiä. Suositusluonnoksessa ei ole otettu kantaa paikkatietokohteen ja sen geometrisen esityksen suhdetta tai keskinäistä riippuvuutta. Yleisesti paikkatietokohteet mallinnetaan niin, että niillä on yksi geometrinen esitys, ja esimerkiksi aluemaisilla kohteilla voi sen lisäksi olla referenssipiste attribuuttina, jolloin kuitenkin on kyse yhdestä ja samasta paikkatiekohteesta. Jos samassa aineistossa on erikseen mallinnettu pistemäinen paikkatietokohde ja aluemainen paikkatietokohde kuvaamaan samaa reaalimaailman ilmiötä, ne ovat eri paikkatietokohteita ja saavat kumpikin oman URI-tunnuksen, jossa niillä on sama aineistotunniste-osa. Molempien URI-tunnuksissa viitataan samaan reaalimaailman kohteeseen (/id/- URI:in), jonka URI-tunnisteen kautta kohteet linkittyvät JHS-suositusluonnoksen mukaan. Periaatteessa mahdollinen tapaus voisi olla paikkatietokohde, jolla on monitasoinen geometrinen esitys. Tässä tapauksessa on siis kyse yhdestä ja samasta paikkatietokohteesta, jolla on oma yksikäsitteinen URI-tunnuksensa. Kohteen URIviittaus palauttaa WFS-/GeoJson- tms. rajapinnan, joka sisältäisi useita geometriaesityksiä. (Rajapinnat esitetään kohteen /doc/-uri:ssa.) Suositusluonnoksessa esitetty URI-käytänne on tietomallipohjainen. Siksi paikkatietokohteen mallinnusmetodi määrittelee yksikäsitteisesti URI-tunnuksen muodostumisen. Mallinnukseen vaikuttavien tai ohjaavien standardien kehittyminen säätelee ja harmonisoi mallinnuskäytäntöä. Esimerkiksi tuore ISO Linear Referencing-standardi mahdollistaa kohteen käsittelyn osissa (tiestön kohdalla vaikkapa päällysteen, tielajin ja nopeusrajoituksen muuttuessa) pilkkomatta itse kohdetta osiin. Tämä standardi antaa viitteitä monitasoisten tai -osaisten geometrioiden mallintamiseen yhtenäisellä tavalla. Pysyvien tunnusten antaminen kiinnittää paikkatiedon jakautumisen yksittäisiin kohteisiin pitkälle tulevaisuuteen. Siksi on tärkeää, että paikkatietokohteet muodostavat loogisia

11 kokonaisuuksia, jotka vastaavat mahdollisimman hyvin yleistä käsitystä vastaavasta reaalimaailman kohteesta. 25. Muutosehdotukset kappaleeseen Paikkatietokohteen tunniste - / so 25.1 Ehkä voisi lisätä joku tuttu ja turvallinen esitysmuoto kuten ESRI shapefile tai file geodatabase. Hylätty: suosituksessa halutaan nykyaikaisia standardoituja tai avoimia tiedostomuotoja. Työryhmä harkitsee OGC:n Geopackages tiedostomuodon lisäämistä. 26. Muutosehdotukset kappaleeseen Paikkatietokäsitteen tunniste - / def 26.1 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 11. Huomioitu: työryhmä tarkentaa suositustekstiä ja viittauksia koodiluetteloista Huomioitu/Hylätty: asia käsitellään Inspire-direktiivin toimeenpanon yhteydessä ja se tullaan ohjeistamaan erikseen myöhemmin. Huomioitu: työryhmä tarkentaa pakollisia esitysmuotoja sekä lisää suositeltavat esitysmuodot. 27. Muutosehdotukset kappaleeseen Paikkatietokohteiden ja -käsitteiden esitysmuodot sekä muiden dokumenttien linkittäminen - / doc 27.1 Esitysmuodot; pakolliset listattava selkeästi esim kappaleessa 11. Huomioitu: työryhmä tarkentaa pakollisia esitysmuotoja sekä lisää suositeltavat esitysmuodot 28. Muutosehdotukset kappaleeseen 8. Tunnisteen elinkaaren hallinta 28.1 Ei periaatteessa vaatimuksena INSPIREssä, mutta jos halutaan yksilöivistä tunnisteista täysmääräisen hyödyn, nämä ovat käytännössä tarpeen. Huomioitu: lisätään maininta Inspire:n vaatimuksista koskien tunnisteen elinkaaren hallinnasta. 29. Muutosehdotukset kappaleeseen 8.1 Muutostyypit

12 29.1 Selkeästi esille, mikä on pakollista ja mikä suositeltavaa. Huomioitu: työryhmä tarkentaa suositusehdotusta. 30. Muutosehdotukset kappaleeseen 8.2 Elinkaarisäännöt ja versionhallinta 30.1 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? Ei toimenpiteitä Ei toimenpiteitä Huomioitu: työryhmä etsii halutut viittaukset ja liittää ne suositustekstiin. (Historiantiedon hallintamekanismit ovat tosi alkutekijöissä Suomessa ja muuallakin...) 31. Muutosehdotukset kappaleeseen 9.1 Paikkatietokohteen tunnisteen valinta 31.1 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? Huomioitu: tarkennetaan ja selvennetään tekstiä. 32. Muutosehdotukset kappaleeseen 9.2 Verkkotunnus 32.1 Tässä kohdassa oletetaan, että aineisto on tiedon tuottajan palvelussa saatavissa online koko ajan. Sen voisi sanoa selkeämmin ja viitata ao. suositukseen. Huomioitu: tarkennetaan tekstiä 32.2 Ei muutosehdotuksia Ei toimenpiteitä 33. Muutosehdotukset kappaleeseen 9.3 Yksikäsitteisyyden varmistava mekanismi 33.1 Ei muutosehdotuksia Ei toimenpiteitä

13 34. Muutosehdotukset kappaleeseen 10.1 Nimiavaruusrekisteri 34.1 Aineistotunnisteet olisi kuitenkin hyvä saada helposti esiin. Kts. kommentti liittyen kansainvälisiin organisaatioihin. Mitkä niiden nimiavaruudet ja niiden aineistojen nimiavaruudet ovat? Huomioitu: työryhmä selventää suositusehdotusta ja käyttöönottosuunnitelmaa. Huomioitu: jos kansainvälisestä paikkatietoaineistosta on kansallinen versio, se voidaan kuvailla Suomen kansalliseen paikkatietohakemistoon. Tällöin paikkatietoaineisto saa oman aineistotunnisteen. Uudelleenohjauspalvelun avulla voidaan URI-kyselyt ohjata kansainväliseen paikkatietoaineistoon. 35. Muutosehdotukset kappaleeseen 10.2 Uuudelleenohjauspalvelu 36. Muutosehdotukset kappaleeseen Paikkatietokohde - /so/ 36.1 Kuntien kokoavan paikkatietopalvelun olisi tarkoitus huolehtia kuntien aineistojen muuntamisesta Inspireskeemojen 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? Huomioitu: työryhmä harkitsee tarkempien käyttökuvauksien ja esimerkkien tuottamista. Jos kuntien keräämistä paikkatietoaineistoista muodostetaan KRYSP-aineisto, niin se tulisi kuvata paikkatietohakemistoon. Täten KRYSP-aineisto saisi oman yksilöivän aineistotunnisteen. KRYSPaineiston muodostamisessa tulee ottaa huomioon, että kohteiden yksilöivät tunnisteet säilyvät. Tämä voidaan toteuttaa esimerkiksi lisäämällä alkuperäisten tietoaineistojen yksilöviin tunnisteisiin kuntatunnus. Kunnat voivat kuvata omat paikkatietoaineistonsa paikkatietohakemistoon. Tähän pätee myös edellä mainittu. Huomioitava: näiden viittaa polkukomponentteihin ({namespace}, {theme}, {class}, }, {localid}) 37. Muutosehdotukset kappaleeseen Reaalimaailman kohde - /id/ 37.1 Mistä tietoa siitä onko joku jo tehnyt id-tunnisteen? (viimeinen kappale) Huomioitu: työryhmän tarkoituksena on sisällyttää käyttöönottosuunnitelmaan järjestelyt joiden avulla voidaan toteuttaa keskitetty palvelu reaalimaailman kohteiden selailua varten. 38. Muutosehdotukset kappaleeseen Paikkatietokohdetta kuvaava käsite - /def/

14 38.1 Lisättävä URI-polun rakenne koodilistoille Huomioitu: työryhmä tarkentaa suositustekstiä ja viittauksia koodiluetteloista 38.2 "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? Hylätään: Maanmittauslaitos hoitaa Inspire-direktiivin mukaista kansallista metatietohakemistoa. Jos tämä velvoite muuttuu, voidaan kyseinen sähköposti uudelleen ohjata uudelle vastuutaholle. Huomioitu: sähköpostiosoitteet korjataan yhdenmukaiseen muotoon. 39. Muutosehdotukset kappaleeseen Esitysmuodot ja dokumentit - /doc/ 39.1 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 ( mutta esimerkissä on käytetty vanhempaa DC Elements 1.1 nimiavaruutta. Toisaalta esimerkissä käytetään myös dc:formatsuhdetta 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. Huomioitu: työryhmä tutustuu työkaluun Huomioitu: RDF/XML on suosituksen ensisijainen formaatti. Harkitaan vaihtoehtoisia muotoja (Turtle, JSON, JSON-LD) Hyväksytään 40. Muutosehdotukset kappaleeseen 11.2 Uudelleenohjauksen ja tietojen linkittämisen käytänteet Vastaajien määrä: 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 Huomioitu: kuva on tavallaan puutteellinen. Jos esimerkissä Syke:n tietoihin olisi tallennettu Lappeenrannan kaupungin URI, niin olisi mahdollista seurata linkkiä toiseenkin suuntaan. Ei toimenpiteitä: Inspire-tietotuotteiden vastuutahojen määrittely kuuluu Inspire:n toimeenpanoon, ei JHSsuositukseen.

15 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? Huomioitu: Tarkennetaan kaaviota. Huomioitu: Tarkennetaan kaaviota. Teksti:...edellisessä kappaleessa 11.3, pitäisi olla Muutosehdotukset kappaleeseen 11.3 Vastauskäytänteet 41.1 Jos URI annetaan ilman paikallista tunnistetta, vastauksena annetaan ATOM-syöte? Tätä tuskin toteutuu kaikissa tapauksissa?! Huomioitu: muutetaan vastauskäytänne niin, että ilman paikallista tunnistetta vastauksena annetaan aineiston metatiedot (XML). - Pyritään kuitenkin ratkaisuun, joka mahdollistaa ATOM-syötteen silloin kun se on saatavilla oleva palvelu 42. Muutosehdotukset kappaleeseen 12.1 Yhdistetty tieto (Linked data) 42.1 tämä kohta ei nyt täsmää dokumentin kanssa Ei toimenpiteitä 42.2 Suosituksessa ei ko. kappaletta? Ei toimenpiteitä 43. Muutosehdotukset kappaleeseen 12.2 Ontologiapalvelu 43.1 tämä kohta ei nyt täsmää dokumentin kanssa Ei toimenpiteitä

16 43.2 Suosituksessa ei ko. kappaletta? Ei toimenpiteitä 44. Muutosehdotukset kappaleeseen 12.3 Luettelopalvelu 44.1 tämä kohta ei nyt täsmää dokumentin kanssa Ei toimenpiteitä 44.2 Suosituksessa ei ko. kappaletta? Ei toimenpiteitä 45. Muutosehdotukset kappaleeseen 13. Opastavat tiedot 45.1 tämä kohta ei nyt täsmää dokumentin kanssa Ei toimenpiteitä 46. Muutosehdotukset kappaleeseen 13.1 Kirjallisuusviitteet ja muut viittaukset 46.1 Tarkoitettaneen kohtaa 12.1 Ei toimenpiteitä 47. Muutosehdotukset kappaleeseen 14. Liitteet 47.1 Tarkoitettaneen kohtaa 13. Ei toimenpiteitä 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 49.1 Missä vaiheessa kohteelle haetaan tunniste? Huomioitu: Tarkennetaan tekstiin, että elinkaarisäännöt määrittävät, milloin kohteelle tulee luoda uusi tunniste. Käytännössä työskentelytapa ja siitä seuraava ohjelmistologiikka esimerkiksi tapauksessa, jossa alue uudiskartoitetaan, vaatii jatkokehittelyä. Ilmeisesti ohjelmistokehittäjien ratkaistava ja ratkaistavissa. Huomioitu: Jatkokehittelyä ja toteutusten aikataulua käsitellään käyttöönottosuunnitelmassa Suosituksen toteutusten aikataulu tietojärjestelmissä ja niiden oheisissa palvelurajapinnoissa on vielä auki.

17 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 Huomioitu: Tarkennetaan kaaviota. 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 Huomioitu: sähköpostiosoitteet korjataan yhdenmukaiseen muotoon. 52. 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 INSPIREaineistot 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? Huomioitu: Tarkennetaan tekstiä Huomioitu: Tarkennetaan tekstiä 54. Muutosehdotukset liitteen 1. URI:n muodostamisen prosessi kappaleeseen 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ä: Esimerkkikaaviot, suositusluonnos sivu 18 ja liite I sivu Huomioitu: Tarkennetaan kaaviota.

18 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.. Hyväksytään Huomioitu: sähköpostiosoitteet korjataan yhdenmukaiseen muotoon. 57. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 1. Johdanto Johdanto olisi hyvä alkaa kolmannella kappaleella "Tässä liitteessä..." Hyväksytään 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. Huomioitu: muutetaan vastauskäytänne niin, että ilman paikallista tunnistetta vastauksena annetaan aineiston metatiedot (XML). - Pyritään kuitenkin ratkaisuun, joka mahdollistaa ATOM-syötteen silloin kun se on saatavilla oleva palvelu 59. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 3. Tekniset vaatimukset.

19 59.1 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. Hyväksytään 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? Ei toimenpiteitä. 61. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 5. Tiedontuottajan URI-palvelun palauttaman RDF-tiedon rakennekuvaus 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. Huomioitu: Korjataan luokkanimet alkamaan isolla alkukirjaimella Huomioitu: Korjataan luokkanimet alkamaan isolla alkukirjaimella Hyväksytään 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. Huomioitu: Työryhmä tutustuu esitettyyn toimintatapaan ja harkitsee esimerkin muuttamista 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

20 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: Huomioitu: Työryhmä harkitsee esimerkin muuttamista 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. Huomioitu: Työryhmä tutustuu työkaluihin 64. Muutosehdotukset liitteen 2. Esimerkki tiedontuottajan URI-palvelun teknisestä toteutuksesta kappaleeseen 6.3 RDF-esimerkki Sama kommentti Dublin Core nimiavaruuksista kuin itse suosituksen lukuun Hyväksytään 65. 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. Huomioitu: Työryhmä harkitsee esimerkin muuttamista. (Esimerkki-case on JHS-työssä pilotoitu menettely, johon on ns. proof-of-concept; parempia käytäntöjä otetaan mielellään vastaan ja lisätään toimeenpanon ohjeistukseen sekä käyttöönottosuunnitelmaankin mahdollisuuksien mukaan.) 66. Muutosehdotukset liitteen 3. Elinkaarisääntöjen muodostaminen kappaleeseen 1. Johdanto.

21 66.1 Johdantoon alkuun kappale jossa kerrotaan "Tässä dokumentissa kuvataan..." Hyväksytty 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. Huomioitu: Tarkennetaan tekstiä 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. Huomioitu: Täsmennetään esimerkkiä

22 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 INSPIREaineistoille kappaleeseen 1. Johdanto. 75. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille kappaleeseen 2.1 Metatiedot. 76. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille kappaleeseen Tietotuotemäärittely. 77. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille kappaleeseen Elinkaarisäännöt. 78. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille kappaleeseen Tunnisteen muodostaminen. 79. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille kappaleeseen 2.3 Sähköiset rajapintapalvelut. 80. Muutosehdotukset liitteen 4. Yksilöivien tunnisteiden julkaiseminen muille kuin INSPIREaineistoille 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 Ei toimenpiteitä (Käyttöönottosuunnitelmaan on tarkoitus ottaa mukaan ohjelmistotoimittajien perehdyttäminen) Huomioitu: Täsmennetään tekstiä (liittyy kohtaan 41.1; Vastauskäytänteet 11.3, jota täsmennetään) 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! Huomioitu: Täsmennetään tekstiä

23 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 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