Menneet viimat, tulevaisuuden tuulet

Ajattelin koota hieman mennyttä vuotta yhteen ja katsoa tulevaisuuteen, sillä on tullut aika juhlistaa tämän datajournalismi-blogin syntymäpäivää.

Julkaisin nimittäin ensimmäisen viestin keskiviikkona, 21. joulukuuta 2011. Kirjoituksen aiheena oli tuolloin Ei-versionhallintadatan visualisointi Gource:lla ja käsittelin datan siivoamista ja visualisointia verkostojen avulla. Olin vast'ikään siirtynyt Tampereen teknillisestä yliopistosta ja tutkijan vakanssista Svenska Yle:en Web-suunnittelijaksi (käytännössä Drupal-koodariksi) ja ajattelin, että blogi olisi myös hyvä tapa ylläpitää kontaktia aikaisempaan uraani.

Valitsin nimen lähinnä hetken mielijohteesta mutta myös, koska termi "datajournalismi" ilmensi mielestäni hyvin sellaisia käsitteitä kuten visuaalinen tarinan kerronta sekä käyttäjäinteraktio, joista olin tuolloin hyvin kiinnostunut. Tuossa vaiheessa en kuitenkaan osannut juurikaan ajatella mitä "journalismi"-osuus edes sanassa datajournalismi voisi tarkoittaa. Minulle datajournalismi merkitsi terminä lähinnä sellaisten visualisointien toteuttamista, jotka kertovat datan tarinan lukijalle ymmärrettävässä muodossa. Blogia perustaessani olin siis täysin untuvikko datajournalismin saralla ja olin kuullut koko termistä ensimmäistä kertaa muutamaa kuukautta aikaisemmin osallistuessani Antti Poikolan masinoimaan datajournalismin päivään.

Kuitenkin heti ensimmäinen kirjoitus yllätti minut suosiollaan (tähän päivään mennessä 372 lukukertaa) ja sain sen johdosta paljon positiivista palautetta eri tahoilta. Palautteen kannustamana koin, että blogille on tarvetta ja olenkin kirjoittanut tähän päivään mennessä tämä viesti mukaan lukien 48 kirjoitusta erilaisista datajournalismiin liittyvistä asioista.

Suosituin viesteistäni on ollut kirjoitus Hyvinkään ampumistapauksesta epäillyn sosiaalisesta verkostosta, johon Yle Uutiset linkkasi minusta tehdyssä haastattelussa (2111 lukukertaa). Kokonaisuudessa lukukertojen perusteella kirjoitusten Top5 näyttää seuraavalta:

• Hyvinkään ampumistapaus, 27.5.2012, 2111 lukukertaa
• "Osaaja haussa, tiedätkö ketään?", 7.8.2012, 1300 lukukertaa
• Kuka minä olen? @TuomasEnbuske, 22.2.2012, 1082 lukukertaa
• Twitter-verkostoanalyysia Gephi:llä, 17.2.2012, 932 lukukertaa
• Bensan hinta, no sehän kiinnostaa meitä ~kaikkia!, 22.9.2012, 925 lukukertaa

Keskimäärin yksittäinen kirjoitus blogissa kerää muutama sata lukukertaa. Tavanomaisena päivänä, jolloin en julkaise mitään vierailee blogissa tilastojen mukaan muutamia kymmeniä henkilöitä. Yhteensä blogi on kerännyt runsaat 16 000 lukukertaa, joka tekee runsaat 40 lukukertaa yksittäistä päivää kohden.

Näin tilastojen valossa. En kuitenkaan missään vaiheessa arvannut, että harrastuksesi kirjoittamallani blogilla olisi osaltaan niin merkittävä vaikutus tulevaisuuteeni. Vuoden aikana olen nimittäin Drupal-työni ohessa vapaa-ajallani osallistunut Yle:ssä ja muissa mediaorganisaatioissa yheensä n. 20:een datajournalistiseen projektiin, enkä voi olla uskomatta, etteikö esimerkiksi tämän blogin saamalla huomiolla olisi ollut tiettyä vaikutusta siihen, että olen noihin projekteihin ajautunut. Toki olen ollut myös suotu erittäin hienoilla ystävillä ja työkavereilla, jotka ovat edesauttaneet asioita ja suositelleet minua mukaan hankkeisiin.

Tämä menneistä. Katsottaessa tulevaisuuteen niin on tästä harrastuksesta nyt tulossa minulle oikea työ. Aloitan vuoden vaihteen jälkeen työt Yle:een perustettavassa PlusDesk-toimituksessa Uuden ajan toimittajana eli datajournalistina. Toimitus tulee alkuvaiheessa olemaan viiden hengen suuruinen ja pitää sisällään itseni lisäksi tuottajan (Juho Salminen) ja kolme graafista osaajaa. Tehtävämme on käytännössä tuottaa dataan perustuvaa journalismia uutis- ja ajankohtaistoimituksille. Uudenlaista ja julkiselle palvelulle ominaista sisältöä.

Minulla on paljon suunnitelmia ja odotuksia tulevaa työtäni varten ja niistä toivottavasti kaikki datajournalismista kiinnostuneet saavat tietää tuonnempana.

Kiitos kaikille blogia lukeneille ja hyvää joulua sekä railakasta tulevaa vuotta.

MediaWiki tietosisällön visualisointi, Osa 1: Gephi

Tämä viesti ei sinällään käsittele sosiaalisen verkostojen analyysiä tai datajournalismia, jotka pyrin pitämään tämän blogin pääaiheina. Kuitenkin tekniikat ja välineet, joita hyödynnetään ovat samoja ja tässä esimerkissä datan rakenne on vastaavanlainen kuin usein SNA:n tapauksessa.
</spoiler>

Wiki on käsite tietosisällölle, joka on kaikkien lukijoittensa muokattavissa. Wikille on myös tunnusomaista, että kaikki tallennetut versiot tiedosta säilytetään. Tunnetuin yksittäinen wiki on varmasti Wikipedia, mutta erilaisia wikejä ja wiki-alustoja löytyy useita. Useilla yrityksillä on sisäisiä Wikejä kuten myös monilla yhdistyksillä ja muilla organisaatioilla. Tunnettuja Wiki-alustoja ovat mm. Confluence, MediaWiki ja esimerkiksi FosWiki.

Wikien suurin rikkaus on, että tieto on yhteisön hallittavissa. Tämä hajauttaa tiedon ylläpitämisen vastuun ylläpito-organisaatiolta, mutta ominaisuus tuo myös haasteita. Tieto rämettyy helposti ja tiedon löytäminen on laajoissa wiki-ympäristöissä vaikeaa kun tietoa ei hallinnoida keskitetysti. Usein on myös vaikeaa hahmottaa mitä tietoa esimerkiksi yrityksen sisäisestä wikistä löytyy. Tiedon löytymistä tukisi jos Wikien luokittelu- ja hierarkia-toimintoja käytettäisiin tehokkaasti ja ne tuotaisiin selkeästi käyttjien esille. Usein kuitenkin tiedon rakenteen tuottaminen on tavalliselle käyttäjälle liian haastavaa.

Tämä hyvin laveana ja yleisenä kuvauksena wikeistä. Tarkoitukseni oli antaa oikeutus seuraavalle esimerkilleni siitä miksi wikien rämettyneisyyttä kannattaa kuvata ja miten siitä voitaisiin mahdollisesti päästä eroon.

---

Olen ylläpitänyt itselläni henkilökohtaista, mutta avointa MediaWiki-alustaa muutaman vuoden ajan. Sivuja ympäristössä on vain alle 30. Kuitenkin huomaan, että osa tiedosta hukkuu Wikin uumeniin mm. koska tietoa ei ole linkitetty mihinkään muuhun olemassa olevaan tietoon. Henkilökohtaisen MediaWiki-asennukseni lisäksi minulla oli mahdollisuus kokeilla samoja periaatteita erään organisaation laajemmassa ympäristössä.

MediaWiki:ssä tiedon ryhmittely tehdään pääasiassa luokkien avulla. Yksittäiselle MediaWiki-sivulle on mahdollista määritellä rajoittamaton määrä luokkia, joihin sivu kuuluu. Yksittäisen luokan sivulta on nähtävissä mitkä sivut kuuluvat tähän luokkaan. Hierarkiasta on mahdollista tehdä myös syvempi liittämällä luokkia toisiin luokkiin.

Toteutin MediaWikin tietosisällöistä verkostovisualisoinnin käyttäen aiemmasta blogimerkinnästä tuttua Gource:a sekä Gephi:ä. Esittelen tässä kirjoituksessa Gephi:llä tekemäni tuotokset, koska Gource:a käsittelin jo aiemmin ja molempien läpikäynti olisi turhan raskasta. Käyn Gource:lla toteutetut versiot läpi myöhemmin.

Gephi on verkostoanalyysiin erikoistunut avoimeen lähdekoodiin perustuva työkalu, jolla on mahdollista visualisoida dataa, jolla on verkostorakenne. Gephi sisältää monipuoliset ladonta-algoritmit ja sen avulla on mahdollista laskea mm. laskea tunnuslukuja ja tehdä datan refaktorointia. Gephi lukee useita tiedostoformaatteja ja tuettuihin formaatteihin kuuluu mm. XML-pohjainen GEXF-tiedostoformaatti.

GEXF:llä on mahdollista kuvata monipuolisesti erilaisia verkostoja ja dataan on mahdollista vapaasti liittää haluamiaan attribuutteja. Yksinkertaisimmillaan GEXF käsittää <nodes>-elementin, joka kuvaa datassa olevat solmut sekä <edges>-elementin, joka kuvaa solmujen väliset yhteydet. Solmut ja yhteydet yksilöidään ID-arvojen avulla, jotka useimmitten omissa esimerkeissäni ovat olleet koneellisesti tuotettuja surrogaatti-avaimia.

Datan keräsin räätälöidyn SQL-kyselyn avulla suoraan MediaWikin MySQL-tietokannasta, jonka jälkeen tulostin datan PHP-scriptillä GEXF-muotoon, joka on siis suoraan mahdollista avata Gephi:llä. Vaihtoehtoisesti data oltaisiin voitu ryömiä asiakaspäässä, mutta koska tässä tapauksessa minulla oli suora pääsy tietokantaan tähän ei ollut tarvetta ryhtyä. Asiakaspään ryömintä olisi kuitenkin pakollista mikäli haluttaisiin tutkia sellaisia wiki-palveluja, joiden backendiin ei olisi pääsyä (tämä tilanne on varmasti normi kun puhutaan datajournalismista).

Mikäli haluat tutustua Gephi:n käyttöön laajemmin suosittelen katsomaan läpi esimerkiksi Olli Parviaisen tekemät kalvot aiheesta. SlideShare-palvelusta löytyy myös monia muita hyviä presentaatioita asiaan liittyen. En myöskään halua mennä liikaa yksityiskohtiin PHP:n tai SQL:n osalta, koska näen ne epäolennaisena, mutta jos haluat tietää näistä enemmän kerron kyllä mielelläni.

Kuvassa 1 nähdään MediaWiki-alustani nykytilanne visualisoituna Gephi:llä. Kuten sanottua wiki ei ole sivujen määrässä mitattuna suuri, mutta data soveltuu hyvin yksinkertaisuutensa vuoksi hyvin esimerkikiksi. Visualisoinnissa suurempi solmun koko kuvaa solmun astesummaa eli solmusta lähtevien yhteyksien määrää. Siniset solmut ovat wiki-sivuja ja punaiset solmut esittävät luokkia. Yhteydet luodaan sivujen ja luokkien välillä sillä perusteella, että sivu on merkitty kuuluvaksi luokkaan.

Esimerkkivisualisointi Gephi:llä MediaWiki:ni sivuista ja luokista. Tässä MediaWiki-ympäristössä ei ole hyödynnetty luokkien luokittelua, mutta suurin osa sivuista on liitetty vähintään yhteen luokkaan. Luokkien ja sivujen nimet on riisuttu yksityisyys syistä. (Kuva 1)

Visualisoinnista (Kuva 1) nähdään miten wikissä on selkeitä toisistaan riippumattomia aihealuekokonaisuuksia ja että suurin osa sivuista kuuluu (nykyään) ainakin yhteen luokkaan. Valitettavasti lähtötilanteesta, jossa suurempi osa sivuista oli "orpoja" minulle ei ole tallessa kuvankaappausta. Aikaisemmin kuitenkaan suuri osa sivuista ei kuulunut mihinkään luokkaan, jolloin (kuten edellä mainitsin) data katosi wikin uumeniin.

Verkostovisualisoinnin avulla pystyin osoittamaan helposti mitkä sivut olivat "luokattomia" ja käymään ne läpi lisäten niille, jonkin olemassa olevan luokan. Visualisoinnin avulla pystyin myös näkemään mahdollisia uusia luokkia. Lisäksi kun on mahdollista nähdä sivujen väliset yhteydet luokkien kautta voidaan havaita esimerkiksi, että miten tietyistä sivuista selkeästi puuttuu sille kuuluva luokka.

Minulla oli myös mahdollisuus käyttää erään laajemman wiki-ympäristön dataa suoraan tietokannasta. Tässä järjestelmässä wiki-sivuja ja luokkia oli huomattavasti enemmän kuin omassa ympäristössäni. Käytin datan keräämiseen ja käsittelyyn samoja menetelmiä kuin aiemmin, mutta Gephi:ssä käytin hieman eri piirtokäytäntöjä (Kuva 2).

Laajemmat Wiki-ympäristöt tuottavat haasteita visualisoinnin luettavuudelle ja hahmotettavuudelle. Tässä väreillä ja solmun koolla on molemmilla kuvattu solmun astesummaa. Yksittäiset sivut on piirretty siten keltaisella ja tumman sininen kuvaa suosituimpia luokkia. Solmut ovat painovoimaohjattuja. Sivujen ja luokkien nimet on poistettu yksityisyys syistä. (Kuva 2)

Kuvasta 2 nähdään miten laajemman wiki-ympäristön visualisoinnin havainnointi ja käsittely on huomattavasti vaikeampaa kuin aikaisemman suppeamman ympäristön (Kuva 1). Mielenkiintoista on kuitenkin huomata miten tässäkin ympäristössä havaitaan selkeitä aihekokonaisuuksia, jotka eivät linkity luokkien kautta muuhun sisältöön vaan ovat "eristäytyneitä" kokonaisuuksia.

Kiinnostava jatkotukimuksen aihe olisi katsoa linkittyykö tieto paremmin muissa wiki-alustoissa, joissa tiedon luokitteluun käytetään muita mahdollisesti monipuolisempia tapoja, mutta tämä tästä tällä kertaa. Jatkoa seuraa asian tiimoilta myöhemmin Gource-visualisointien osalta.

Gource:n asentaminen: OS X Lion

Hyödynsin edellisessä viestissäni visualisointikomponenttia nimeltä Gource. Olen aikaisemmin käyttänyt Gource:a Windows-ympäristössä, jossa sen käyttöönottaminen on triviaalia, koska Gource tarjotaan .exe-tiedostona, jota voidaan käyttää ajamalla sille parametreja komentoriviltä.

OS X:llä Gource:n käyttöönottaminen ei ollut näin suoraviivaista, joten ajattelin, että voisi olla hyödyllistä kirjoittaa auki mitä kommervenkkeja kävin läpi saadakseni Gource:n toimimaan OS X Lionilla. Tämä ohje mukailee Matthew Hutchinson:n kirjoittamaa blogiviestiä.

1) Asenna MacPorts. .dmg-paketti on hyvä valinta jos et tiedä paremmasta. Tarvitset myös Xcode:n kuten asennusohjeissa mainitaan, joten asenna se ensin jos sinulla ei vielä ole sitä.

http://www.macports.org/install.php

2) Käytä MacPortsia asentaaksesi paketit, jotka Gource vaatii.

sudo port install pcre libsdl libsdl_image ftgl

Matthew:n blogissa mainittujen pakettien lisäksi tarvitset boost:n.

sudo port install boost

3) Asenna Git-versionhallintaohjelmisto mikäli sinulla ei sitä vielä ole asennettuna.

http://help.github.com/mac-set-up-git/

4) Kloonaa Gource:n viimeisin versio Git:stä.

git clone git://github.com/acaudwell/Gource.git Gource

5) Git:stä kloonatussa Gource:n versiossa ei ole mukana src/core-kansion tiedostoja, joten lataa Git:n .zip-paketti ja siirrä paketin src/core-kansion tiedostot Git:stä kloonattuun src/core-kansioon. Muussa tapauksessa kääntäminen hajoaa puuttuviin tiedostoriippuvuuksiin.

http://code.google.com/p/gource/downloads/list

6) Käännä Gource.

cd Gource
autoreconf -f -i
./configure && make && sudo make install

7) Aja Gource komentoriviltä. Ruudulle pitäisi ilmestyä esimerkki Gource-visualisointi.

8) Jos haluat tehdä Gource-visualisoinneista .avi-tiedostoja (esimerkiksi jotta voit ladata ne Youtubeen) asenna FFmpeg

sudo port install ffmpeg

---

Toivottavasti muistin oleelliset kohdat. Kaikki kommentit ja parannusehdotukset ovat tervetulleita.

Ei-versionhallintadatan visualisointi Gource:lla

Gource on monipuolinen, lähinnä versionhallintatiedon, visualisointiväline. Gource:lle on mahdollista syöttää suoraan esimerkiksi Git- tai SubVersion-järjestelmien lokitietoa. Gource rakentaa versionhallinnan käyttäjistä ja tiedostoista hakemistorakenteisiin perustuvan (puu)rakenteen. Youtube:sta on löydettävissä useita Gourcella toteutettuja versionhallinan visualisointeja. Tässä esimerkiksi (Video 1) toteuttamani Statster-verkkopalvelun SubVersion-versionhallintadata visualisointuna Gourcella. Annotointi on tehty Youtube:ssa.

Gource on versionhallintatiedon visualisointiväline. (Video 1)

Gource:lla on kuitenkin mahdollista visualisoida myös muuta kuin versionhallintaohjelmiston tuottamaa dataa. Custom log format mahdollistaa minkä tahansa puurakenteen visualisoimisen Gource:lla. Datan ei tarvitse edes olla millään tavalla tiedostorakenteisiin liittyvää (vaikka Gource dataa sillä periaatteella käsitteleekin) vaan data voi semanttisesti pitää sisällään mitä tahansa tietoa. Ainoa rajoitus on, että datan täytyy olla verkostomaiselta rakenteeltaan puu. Gource:lla ei ainakaan tällä hetkellä (v.0.37) ole mahdollista visualisoida verkostoja, joissa solmujen väliset yhteydet eivät ole yksikäsitteisiä.

Esimerkkini koostuu eräästä sosiaalisen median verkkopalvelusta kerätystä tietosisällöstä. Data pitää sisällään blogikirjoituksia, tapahtumia, keskusteluita ja uutisia sekä näihin sisältöihin jätetyistä kommenteista. Eli rakenteeltaan kaikki tietosisällöt (blogikirjoitukset, tapahtumat, keskustelut ja uutiset) liittyvät suoraan juuri-solmuun. Kommenttien hierarkia rakentuu edellämainittujen sisältötyyppien alle. Rakenne on siis speudokoodina seuraavanlainen:

1. {root} -> {content_1} -> {comment_1} -> {comment_2}
2. {root} -> {content_1} -> {comment_1} -> {comment_3}
3. {root} -> {content_2} -> {comment_4}

Esimerkissä on kaksi sisältöä (content_1 ja content_2) ja niihin on molempiin jätetty kommentteja. Nähdään, että ensimmäiseen sisältöön jätettyä kommenttia on edelleenkommentoitu kahdesti. Kommentit rakentuvat siis sisältöjen alle tai muiden kommenttien alle. Data on selkeästi rakenteeltaan puumainen. Ensimmäinen versio (Kuva 1), jonka toteutin tuotti seuraavanlaisen loppunäkymän:

Visualisoinnin ensimmäinen versio, jossa nähdään vain puurakenteen viimeisimmät lehdet. (Kuva 1)

Tässä (Kuva 1) todellinen datan rakenne ei tule selkeästi esiin, koska Gource:n kannalta syötetyn lokidatan formaatti ei ollut optimaalinen. Data syötettiin Gource:lle seuraavanlaisessa muodossa:

1. /root/
2. /root/content_1/
3. /root/content_1/comment_1

Visualisoinnista ei näe selkeästi mikä kommentti kuuluu mihinkin sisältöön ja mikä on juurisolmu. Tämä johtuu siitä, että Gource piirtää kansiorakenteet oksina (edge) ja tiedostot lehtinä (node), joten Gource:lle ylläkuvatulla tavalla syötetty data ei piirrä sisältötyypeille lehteä. Gource:n näkökulmasta "content_1" on tyhjä kansio ja se piirretään pelkästään oksana. Gource siis käsittelee pitkät hakemistorakenteet, jotka eivät sisällä tiedostoja pitkinä oksina. Puurakenteen viimeinen lehti käsitellään Gource:ssa kuitenkin aina solmuna ja nämä ovat niitä, jotka visualisoinnissa (Kuva 1) nähdään.

Esimerkissä siis ainoastaan "comment_1" piirretään lehtenä kun tarkoituksenmukaista olisi hahmottamisen kannalta piirtää juurisolmu "root", sisältötyyppi "content_1" ja kommentti "comment_1" jokainen omana lehtenään. Yritin selvittää ongelmaa kysemällä ratkaisua Gource:n yhteisöltä ja sainkin tyydyttävän vastauksen. Tästä pisteet aktiiviselle yhteisölle.

Ratkaisu oli luoda hakemistorakenteen rinnalle, jokaiseen hakemistoon sitä kuvaava tiedosto. Gource mieltää, että tiedostoja ovat rakenteessa nimet, joilla on (pisteellä erotettu) tiedostopääte. Asetin tiedostopäätteet loogisesti niin, että eri sisältötyypit saivat oman tiedostopäätteen. Näin eri sisältötyyppeihin jätettyjen kommenttien lukumäärät oli mahdollista esittää selkeästi Gource:n "show legend" -toiminnolla. Selite on nähtävissä Kuvan 2 vasemmassa yläreunassa. Data muodostettiin siis ohjeiden mukaisesti seuraavalla tavalla:

1. /root/
2. /root/content_1/
3. /root/content_1/content_1.forum
4. /root/content_1/comment_1
5. /root/content_1/comment_1/comment_1.forum

Datan rivien määrä siis ~kansinkertaistuu, mutta lopputuloksena saadaan todellista dataa paljon paremmin mukaileva ja helpommin luettava lopputulos. Esimerkiksi vasemmalla alhaalla nähtävissä oleva, kommenttien perusteella suosituimman, sisältötyypin avausviesti löytyy punaisen rykelmän keskeltä ja avausviestiin tulleet vastaukset ovat rakentuneet avausviestin ympärille hyvin selkeästi havaittavalla tavalla.

Visualisoinnin 2. versio, jossa kaikkiin hakemistoihin lisätty yksi tiedosto. (Kuva 2)

On hyvä huomioida, että todellisuudessahan Gource tuottaa datasta videomuotoisen visualisoinnin, josta on nähtävissä miten data rakentuu ja ketkä käyttäjän datan luomiseen osallistuvat, joten nämä aspektit jäävät näkemättä näistä staattisista esimerkeistä (Kuva 1 ja Kuva 2).

Gource on siis tehokas työkalu myös muiden datajoukkojen kuin versionhallintatietojen visualisointiin. Olen käyttänyt Gource:a mm. MediaWiki-alustan tietosisältöjen sekä muiden verkkopalvelujen tietosisältöjen visualisointiin, joiden toteuksia esittelen myöhemmin tässä blogissa.