7.4.2011 Samppa Saarela
Mysema
Tiedon avaaminen käytännössä
Taustaani
● Semanttisen laskennan tutkimusryhmässä (SeCo) tutkijana 2002 – 2005
– Promoottori ● Ontologiapohjainen kioskisovellus HY:n
promootiokuvista – MuseoSuomi
● Ontogator –näkymäpohjainen RDF hakukone ● Profium 2005 – 2006 ● Mysema toimitusjohtaja, arkkitehti 2006 –
– Balancion.com – semantic.hri.fi
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
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
Aluesarjat - vaiheet
● PCAxis/Java –parserin tekeminen ● RDF –muunnos
– URI-skeema – Ontologian eli skeeman valinta – SCOVO
● Yksinkertainen ● Riittävän ilmaisuvoimainen suunniteltuihin
käyttötapauksiin
SCOVO Tietomalli
Item value: int
Dataset name: String
Dimension name: String
1
0..n
1..n
1..n datasetDimension
dataset
dimension
Vuosi Alue
SCOVO Esimerkki
Naiset item
scv:Item
Kallion peruspiiri
2009
Sukupuoli
Vuosi
Alue
scv:Dimension
4
rdf:type
scv:dimension rdf:type
rdf:type
rdf:type
scv:dimension
scv:dimension rdf:value
rdfs:subClassOf
rdfs:subClassOf
rdfs:subClassOf
Helsingin 15 vuotta täyttäneet sukupuolen, iän ja koulutusasteen (ennakkotieto) mukaan 1. tammikuuta
scv:Dataset
scv:dataset
rdf:type
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
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
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.
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
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
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
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?
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
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
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?
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
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
● 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)
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!
Kiitos!