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!

Samppa.Saarela@mysema.com