3. Aluesarjat -projektista
● LOD-pilotti
– Helsingin kaupungin tietokeskus ja ForumVirium
– Kuinka hyvin RDF sopii tilastotietojen käsittelyyn?
– Mikä mahdollista, mikä ei?
– Mitä konkreettista hyötyä?
● 1) Pilotti (n. 50 htp)
– 4 sprinttiä
– Sprintin pituus n. 2 vk á 12+ htp
– 2 osa-aikaista kehittäjää
● 2) Tuotantoprojekti 12+ htp
– http://semantic.hri.fi/
– Viimeistely yhä kesken
4. Aluesarjat -projektista
● Fokus konepellin alla, LOD-rajapinnoissa, ei
käyttöliittymässä
– Havainnollistaminen vaatii käyttöliittymää
– SPARQL –hakusivu
● SPARQL protokollan mukainen palvelu
– Demo: Fasettihaku
● REST/JSON –palvelu
– Demo: Tilastot kartalla
● Lähtökohta
– PCAxis muotoisia tilastoja 9 ... 86 kpl
● Windows -ohjelma
● ASCII formaatti – ei valmista parseria Javalle
5. Aluesarjat - vaiheet
● PCAxis/Java –parserin tekeminen
● RDF –muunnos
– URI-skeema
– Ontologian eli skeeman valinta
– SCOVO
● Yksinkertainen
● Riittävän ilmaisuvoimainen suunniteltuihin
käyttötapauksiin
6. SCOVO Tietomalli
Dataset
name: String
1
dataset
0..n
Item
value: int
datasetDimension
1..n
dimension
1..n
Dimension
name: String
Vuosi Alue
7. SCOVO Esimerkki
Helsingin 15 vuotta täyttäneet
sukupuolen, iän ja rdf:type scv:Dataset
koulutusasteen (ennakkotieto)
mukaan 1. tammikuuta
scv:Dimension
scv:dataset scv:Item
rdf:type rdfs:subClassOf
rdfs:subClassOf
scv:dimension rdf:type
item Naiset Sukupuoli rdfs:subClassOf
scv:dimension
rdf:value rdf:type
scv:dimension 2009 Vuosi
4
Kallion rdf:type
peruspiiri Alue
8. Alun haasteita
● Kielioppipohjainen parseri (antlr) ei skaalautunut
– 2GB muistia ei riittänyt ison tilaston käsittelyyn
● Käsinkirjoitettu “streaming” PCAxis –parseri
– 20M muistia riittää parserille reilusti
– OpenSource
– http://source.mysema.com/display/stat/Mysema+Stat
9. Hyötyjä RDF:stä
● Erilaista tietoa voi yhdistää useasta eri
lähteestä
– Alueiden kuvaukset
– Koordinaatit
– DBpedia
– 86 erillistä tilastoa (yhdistyvät ristiin)
– Monikielisyys
● Ei onnistu perinteisillä formaateilla (Esim. PCAxis,
Excel, CSV) – helppoa RDF:llä!
● ...kunhan niissä käytetään samoja URI-
tunnisteita
10. URL Skeema
● RDF:ssä kaikella on URI
– W3C: Cool URIs don't change
– URI on abstrakti tunniste (ISBN, sähköposti
UID jne.)
– URL: “Lisätietoja Webistä”
● Tilastot
– http://semantic.hri.fi/data/datasets
● Dimensiot
– http://semantic.hri.fi/data/dimensions
● Dimensioiden arvot
– http://semantic.hri.fi/data/dimensions/Alue
– http://semantic.hri.fi/data/dimensions/Vuosi jne.
11. Fasettihaku
● REST/JSON –pohjainen palvelu
– Rajoitteet URL-parametreina
– Käyttö helppoa millä tahansa ohjelmointikielellä
– JavaScript/AJAX pohjainen demo
● Toteutettu SPARQL kyselyillä
– Sisäisesti useita kyselyjä ja optimointeja
● Skaalautuminen
– Haasteita jo hyvin varhaisessa vaihessa:
yhdessäkin tilastossa paljon dataa!
– Evaluitu: Sesame Native Store, Bigdata, Virtuoso
12. Skaalautuminen
● Turhat tiedot pois
● Pakotettu sivutus – max 1000 riviä
– Kaikissa hakurajapinnoissa
● Tilastotiedot eivät suoraan ladattavissa
● Fasettihaku vaatii vähintään kolme rajoitetta
– 0-2 rajoitteella filtteröidään Datasettien
metatietojen perusteella
● OpenLink Virtuoso tietokanta skaalautuu
– Lisäindeksi
● Fasettihakupalvelun sisäisiä kyselyitä
optimoitu paljon
13. Avaamisen tarkoitus?
● Tiedon uudelleenkäyttö
● Uuden liiketoiminnan mahdollistaminen
– Innovaatiot
● Modernia “Web 3.0” arkkitehtuuria
hyödyntävät sovellukset
● Helpottaa sovellusten yhteistoimintaa
– Ontologiat – yhteinen laajennettavissa oleva
rakenne tiedolle
– Esim. BestBuy RDFa +30%
● Good Relations / Google
14. Käyttötapaukset
● Mihin tietoa tarvitaan?
● Mihin ja miten tietoa käytetään?
– Voisi käyttää?
● Käyttötapauksien miettiminen on tärkeää!
– Löytyykö konkreettista, suoraa tarvetta?
– Mitä muuta datalla voisi tehdä?
● Korkealentoista vs konkreettista?
15. Ketterästi
● Ensisijaisesti yksinkertaisin mahdollinen
toteutus konkreettisten tavoitteiden
saavuttamiseksi
● Korkealentoiset visiot hyvä huomioida, mutta
käytännössä toissijaisia
● Työn vaiheistaminen pieniin konkreettisiin
askeleisiin valittujen käyttötapausten
mukaisesti
● Tärkeintä on saada aikaiseksi
– “Release early, release often”
– Ei kuitenkaan laadun kustannuksella
16. Minkälaisia rajapintoja?
● Datan ehdoilla
● Ladattavia tiedostoja vai palveluja?
● Helppokäyttöisyys ja pieni käyttöönottokynnys
● Käytännönläheisesti käyttöä protoillen – ei
paperilla/PowerPointissa
17. Rajapintavaihtoehtoja
● RDF ja SPARQL
– Hyvä vaihtoehto erityisesti ennalta
määrittelemättömille käyttötapauksille
(serendipiteetti)
– Paljon mahdollisuuksia
– Toistaiseksi vähän osaajia
● Siirtotiedostot
– Yksinkertaisinta
– Soveltuvuus suuriin tietomääriin?
18. Rajapintavaihtoehtoja
● REST (JSON tai XML)
– Rajatummille käyttötapauksille kuin SPARQL
– Pieni kynnys ja käyttö helppoa
● SOAP/RPC
– Huomattavasti raskaampi arkkitehtuuri
– Palvelimelta toiselle palvelimelle
19. Siirtotiedostot ja formaatit
● Excel
– Ensisijaisesti ihmisille
– Luettavissa koneellisesti, mutta vaatii
erikoistyökaluja
– Kirjastoja ei välttämättä löydy kaikille
ohjelmointikielille
● CSV
– Ei standardoitu – sekavia käytäntöjä
– Ongelmia esim. erotinmerkkien, monirivisen
tiedon sekä lokalisointien kanssa
20. ● XML
– Hyvä, jos löytyy standardiskeema
● JSON
– Yksinkertainen ja kevyt, mutta toimiva
● RDF
– Turtle tai RDF/XML tai RDFa
– Linkit datasta ulos ja datasta sisään
– Tiedon rikastaminen – itse ja muut
● Dataa voi tarjota usealla eri formaatilla!
– XML, RDF, JSON...
– Samasta osoitteestakin (Accept/format)
21. Arkkitehtuuri
● Arkkitehtuuri valittava käyttötapausten ja
vaatimusten perusteella
● Olemassa olevan päälle
– Tuotantojärjestelmä – tietoa
● Datan luonne
– Kuinka usein muuttuu?
● Kuinka ajantasalla tiedon tulee olla?
– Datan määrä
● Hakupalvelu vai siirtotiedosto?
● Skaalautuminen, kehittäjien tietotaito jne.
● Tapauskohtaista!