Edellisessä postauksessa jäin pähkäilemään, miten Twitter-listan kaikkien jäsenten nimet saa poimittua. Keino löytyi, kun vaan malttoi lukea GET lists/members -API-määrittelyä. Avainsana on next_cursor. Koodissa on esimerkkinä ylen-suomitop100-lista, jossa on jo 102 jäsentä.
Tekstinlouhintaa SuomiTop100-listalla
Yle uutisoi juhannuksen alla: Tutustu heihin – 100 kiinnostavaa suomalaista Twitterissä. Amatöörilouhijalle tällainen kotimainen Twitter-ryhmä tarjoaa mukavan tutkimuskohteen. Mitä sanoja top-tweettajat käyttävät? Minkähän takia? Missä yhteydessä?
Blogista Heuristic Andrew löytyi selkeä ohje juuri tähän, tekstin louhintaan Twitteristä R:n avulla.
Hankalinta on saada tarpeeksi louhittavaa. Kohtuullisella hikoilulla sain koottua listalta reilut 500 tweettiä. En juuri tunne Twitterin API:a, joten saatoin hyvinkin olla väärän lähteen äärellä. Olisiko statuspäivitykset pitänyt sittenkin kerätä listan sijaan jäsenten omalta aikajanalta? Harkitsin tätä. Idea kuivahti alkuunsa siihen, että en pystynyt poimimaan rajapinnan kautta listan kaikkia jäseniä vaan vain 20. Joistakin foorumikirjoituksista jäi itämään epäilys, että tämä olisi API:n rajoitus. Luultavammin rajat ovat kuitenkin näiden korvien välissä. No, hyvä että materiaalia on edes jonkin verran.
R-koodin seasta löytyy kommentteja työn etenemisestä ja havaintoja tuloksista. Silmiinpistävää on sanaston heterogeenisuus. Esiin nousevat oikeastaan vain Twitter-kommunikoinnin säätimet, sanat joilla osoitetaan mistä oma teksti on peräisin. Aineisto on lisäksi monikielistä, joka vähentää sanojen toistumistiheyttä näin pienessä otoksessa.
Kuten Heuristic Andrew, minäkin tein ryhmittelyanalyysin (cluster). Sen kuvaus on puumainen dendrogrammi. Mitä ylempänä oksa on, sitä enemmän on sen lehvästössä olevien sanojen esiintymisiä. Lähekkäin ja saman punaisen kehyksen sisällä olevat oksat kertovat siitä, että niiden sanoilla on tiettyä yhteyttä toisiinsa. Kehyksiä on tässä seitsemän, kokeilin pienempääkin. Oikeaan laitaan syntyi nyt hieman turhankin iso kaatoluokka.
Dendrogrammin lukeminen on työlästä, koska niskaa pitää kääntää 90 astetta vasempaan. Epäilemättä löytyy tapa, jolla kääntyy graafi, ei pää.
Tämän harjoituksen pohjalta ei pysty sanomaan juuri mitään siitä, mitä, miten ja miksi Suomi twiittaa. Joitakin arvailuja voi esittää. Saattaa olla, että sanonnat (quote) ja lainaukset (via) ovat melko yleisiä. Mahdollisesti jotkut listan jäsenet ovat suositumpia viittauksen kohteita kuin muut. Jälkimmäinen päätelmä on itse asiassa tavallaan louhinnan sivutuote; samalla kun kaikki välimerkit siivottiin pois, lähti myös käyttäjänimen edestä @-merkki, jolloin henkilöä kuvaavasta nimestä tuli ns. tavallinen sana.
Excelistä R:n kautta Google Motion Chart -palloiksi
Yleisten kirjastojen monipuolisia tilastolukuja vuodesta 1999 lähtien löytyy avoimena datana mm. Helsinki Region Infoshare -sivuston kautta. Tilastoja julkaistaan sekä Excel-tiedostoina että XML-muodossa. Miten sujuu R:ltä Excel? Sitä piti testata.
Kirjoitin auki huomioita kommenteiksi itse R-koodiin.
Datan lukeminen Excel-muodosta oli yllättävän vaivatonta, kiitos R:n kehittyneiden kirjastojen. Kirjastotilastotkin ovat sisällöltään melko hitaasti muuttuvaa, mikä helpotti. Ainoa varsinainen isompi pulma tuli eteen Excel-funktioiden muodossa. Jokaisen taulukon lopussa on summafunktio. Sekään ei olisi ongelma, ellei viimeisen rivin numero vaihtelisi taulukosta toiseen. Kuntia yhdistetään, taulukot elävät. Eikä tämäkään olisi kompastuskivi, elleivät taitoni XLConnect-kirjaston käyttäjänä olisi niin heppoiset. En nähtävästi sittenkään osannut kertoa sille:”Jos kohtaat funktion, kulje ohi ja sano, ettet nähnyt mitään.”
Kehittämisehdotus tilastojen koostajalle: voisiko summarivi olla taulukon alussa? Esimerkiksi aina rivillä 1. Se ei ehkä näyttäisi yhtä hyvältä tai loogiselta kuin taulukon lopussa, mutta selkeyttäisi datan jatkokäsittelyä. Itse data otsikkoineen voisi alkaa aina samalta riviltä, vaikka viidenneltä. Lisäksi: vuosiluku omassa sarakkeessaan olisi mukava bonus! Tosin, ymmärrän hyvin, että jos sarakkeita aletaan lisäämään, se saattaa muuttaa tilastojen keräysprosessia. Vuosiluku kun nyt kuitenkin käy ilmi sekä tiedoston nimestä että taulukon alusta.
Google Motion Chart kirjastotilastoista olisi vieläkin mielenkiintoisempi, jos siinä olisi mukana kirjaston lisäksi muitakin elämänmuotoja. Hieno esimerkki löytyy Tiedonlouhintaa-blogista: viimeisimpien vaalien tuloksia voi tarkastella vaikkapa siltä kantilta, mikä on kunnan työttömyysaste.
Turku vs Helsinki – Vaski vs Helmet
Pääkaupunkiseudun Helmet-kirjastoissa kaunokirjallisuus on irroitettu muusta luokituksesta. Siksi tällä shakkilaudalla sarake 8x on valkoinen aina luokkaan 86 asti. Siitä alkaa kirjallisuustiede.
Helsingin ja Turun ympäristöjen välillä on havaitsevinaan pientä eroa; mm. etiikkaa ja estetiikkaa (17-17.5), uskontoa (2x), yleistä yhteiskuntatiedettä (30) ja tilastotiedettä (31) on enemmän Helsingissä kuin Turussa. Erot voivat tosin syntyä aineistomäärien absoluuttisista määristä. Suhteellisia osuuksia kuvio ei kerro.
Helmet-kirjastojen kaunokirjallisuuden kielikohtaiset pääluokat eivät kerro kaikkea. Esimerkiksi espanjan alta löytyy myös portugalinkielinen kirjallisuus (7.8). Mikähän on syynä siihen, että kokoelmissa on italiaksi ja espanjaksi vähemmän näytelmiä (x.3) kuin muissa ns. isoissa kielissä?
Vaski-datan two-by-two -dentograafista erottaa jo jotenkuten, miten tietokirjallisuus on jakautunut.
Vaski-kirjastojen luokat shakkilaudalla
Uusimmassa The Code4Lib Journal -lehdessä oli artikkeli dentograafeista, ja se innosti testaamaan samaa johonkin kotimaiseen aineistoon. Varsinkin, kun R-opiskelu on sopivassa (alku)vaiheessa, jolloin kaikki naulat näyttävät siltä, että niitä pitää kumauttaa nimenomaan R-merkkisellä vasaralla.
Turun seudun Vaski-kirjastojen bibliografinen data on ollut avoimesti saatavilla viime vuoden syyskuusta lähtien. Samasta aineistosta on jo ehditty tehdä mielenkiintoisia verkostograafeja.
Lähdin liikkeelle Vasken MARCXML-muotoisista tiedostoista, ja hyvin suoraviivaisesti. Poimin niistä kaikista samat kentät XSLT-muunnoksella (välittämättä siitä oliko niitä kyseisessä tietueessa tai ei), ja muunsin näin saadun XML:n edelleen yhdeksi isoksi CSV-tiedostoksi. Kirjastoluokaksi valitsin useasta vaihtoehdosta sen, mitä Turku käyttää.
Lopputuloksessa on paljon NA-arvoisia tyhjiä kenttiä ja kokonaisia rivejä. Ne olisi luultavasti järkevä siivota pois jo ennen seuraavaa vaihetta, mutta koska otin opiskelun kannalta, poistin ne vasta R-ohjelmassa.
Tämä sakkilauta-dentograafi näyttää vain luokituksen kaksi ylintä tasoa. X-akselilla on kymmenluku, y-akselilla ykkösluku. Risteyskohdan ruudun väri kertoo, paljonko tätä aineistoa on. Mitä tummempi, sitä enemmän. Kirkkaimpana tähtenä taivaalla loistaa kertomakirjallisuus, mutta paljon himmeämpi ei ole musiikki (ks. verkko-YKL -pääluokat).
Tietokirjallisuuden luokitus on hienosyisempää eivätkä erot siksi juuri näy näin yleisellä tasolla. Siihen tarvitaan William “dentograafi” Dentonin esimerkin mukaisesti two-by-two -shakkilauta. Jotakin voi silti päätellä jo tästäkin; taustasta erottuvat mm. oikeustiede (33), lääketiede (59) ja liiketaloustiede (69). Liekö seudun yliopistojen vaikutusta?
Tweettien uusiokäyttöä
Twitter on uutisvälineeni nro 1, lähes. Niinpä suosikkejakin tulee tallennettua usein. Säilön linkkejä kiinnostaviin juttuihin. Ne tuppaavat kuitenkin unohtumaan, koska eivät ole mukana uutissyötteissä, joita taas käyn läpi GReaderilla. Yhteys puuttuu. Twitterin OAuth-autentikointi on pelottanut sen verran, etten ole tarttunut toimeen.
Tällä viikolla satuin katsomaan tallenteen YUIConf 2011 -konferenssista. Siinä YQL engineer Paul Donnelly demoaa, miten YQL-konsolinäkymässä saa rakennettua oikeanlaisen REST-kyselyn Twitteriin siten, että ohjelmointirajapintaan pääsee käsiksi. Pelkällä Yahoo Pipesilla tämä ei onnistu, koska se ei tue OAuthia.
YQL-konsolilla homma on helppo, kunhan vaan on ensin hankkinut tarvittavat avaimet ja tokenit. Ne saa Twitteriltä, rekisteröit vain jonkin sovelluksen.
Videolla YQL-osuus alkaa n. 20 minuutin paikkeilla.
Hae esiin Data tables -osiosta twitter.favorites, klikkaa konsolin response-laatikon oikeaan ylänurkkaan ilmestyvää painiketta – ja saat eteesi lomakkeen, johon avaimet ja tokenit kopioidaan. Itselläni meni tuon painikkeen äkkäämiseen tovi; videosta ei saa ihan selvää, mihin kohtaan Paul sormellaan osoittaa.
Kun testi menee läpi, konsolin alalaidasta voi kopsata valmiin kyselyn. Se Yahoo Pipesin Fetch data -moduuliin, ja siitä sitten RSS-syötteen peruskentät kuntoon ja siirto GReaderiin.
HelMet API ja sivutus
Harjoittelu jatkuu. Tämä versio näyttää, miten useampisivuisen hakutuloksen saa listattua yhteen ja samaan tauluun. Mitään kovin massiivisia hakuja ei näin kannata tehdä. Varmempi ja miksei käyttäjäystävällisempikin tapa toteuttaa sama asia on antaa sivukohtaiset tabit, jota klikkaamalla kyseinen sivu haetaan. Samaan tapaan siis kuin mitä API:n oma Search-sivu tarjoaa.
Demohaku on tarkoituksella niin nirso, että se olettaa kirjailijan nimen esiintyvän sellaisenaan author-kentässä. Jos näin ei ole, listalta tipahtaa. Näin kävi esimerkiksi teokselle Carnets : mai 1935 – février 1942, jonka author-kentän lopussa on tyhjä merkki. Tosielämässä ylimääräiset blankot otetaan tietysti huomioon.
Helatorstain HelMet-API
Tulipa mukavaan saumaan tuo HelMet API -julkaisu. Sain uraauurtavaa, kotimaista materiaalia jQueryn ja JSON(P):n alkeiden opiskelulle. Joten, pientä juhlameininkiä, onhan helatorstai ja kaikki: omistan tämän ensimmäisen tekijähakuyritelmäni pitkän linjan internet-aktiiville, Kari A. Hintikalle! Toivottavasti kirjoituskäsi on pian taas kunnossa, ja tekeillä oleva Vertaisaika etenee mallikkaasti. Terveisiä myös muille kirjoittajille: Tuija-kaimalle ja Annelle. Pääsette demohenkilöiksi sitten kun nimekkeitä on enemmän 😉
Kuratointia
HS Open #2
HS Open kakkonen on huomenna, ja sinne olen minäkin menossa. Mielenkiintoinen päivä tulossa! Luupin alla ovat mm. eduskuntavaalit 2011. Rahoittajia löytyi, ehdokkaita oli, vaalit käytiin. Mitä muuta tästä spektaakkelista voi päätellä numeroiden valossa?
Lähdetään liikkeelle datasta.
Keskeistä aineistoa HS Open kakkosen Politiikka-ryhmälle ovat ehdokkaiden ilmoitukset kampanjoiden menoista ja ilmoitukset tukijoista. Arvokasta taustainformaatiota tuovat mm. YLE:n vaalikonetiedot.
Kaksi taulukkoa, kaksi omistajatahoa. Voiko taulukot yhdistää jonkin yhteisen, uniikin sarakkeen avulla? Ei voi, näillä tiedoilla. Mitään Vaaliehdokas-ID -avainta ei ole olemassa. Henkilötunnus tietysti kaikilla ehdokkailla on, mutta sitä ei saa julkaista eikä hyödyntää. YLE:n taulukkorivit (ehdokkaat) on yksilöity ID-numerolla, mutta se on taulukon tuottamisen sivutuote. Ehdokasnumero taas on vaalipiirikohtainen. Puoluerahoitusvalvonnan aineistossa ei ole mitään avainsaraketta. Tarvitaan siis yhteinen nimittäjä.
YLE:n aineistossa on mainittu ehdokkaista sukunimi ja kutsumaetunimi. Puoluerahoitusvalvonnan datassa taas sukunimi ja kaikki nimet, joista jokin on todennäköisesti kutsumanimi. Riittäisikö etu- ja sukunimen yhdistäminen avaimeksi? Ehkä ei, sillä kaimoja saattaa olla. Puolueen lyhenteen lisääminen perään olisi kai jo aika varmaa? Harmi, että lyhenne löytyy vain rahoitusdatasta, ei YLE:ltä.
Ajatus: lähes jokaisella ehdokkaalla vaikutti tällä kerralla olevan oma vaali-web-domain. Olisiko jonkun jossakin kannattanut tallentaa se?
Käytin yhteisen avaimen muodostamisen yrittämiseen useita tunteja. Lopputulos: ei tullut avainta, mutta tulipa kokemusta datan siivoamis- ja esitystyökaluista Google Refine ja Google Fusion Tables. Ynnä hämmennystä ja lievää manailua Google Docs -hipsuista ja muista yllätyksistä.
Google Refine
Google Refine (entinen Freebase Gridworks) on näpsäkkä työkalu. Esimerkiksi data.gov.uk on käyttänyt sitä omissa yhdistetyn avoimen datan hankkeissaan. Jeni Tennisonilta löytyy selkeäsanainen esitys aiheesta. Googlen pari omaa esittelyvideota kannattaa katsoa. Niillä pääsee hyvin alkuun.
Rahasummia tullaan laskeskelemaan ja vertailemaan. Niiden on siis syytä olla tietotyypiltään samanlaisia. Annoin Refinen lukufasetin (numeric facet) käydä läpi kaikki ne Puoluerahoitusvalvonnan taulukon sarakkeet, joissa oli rahasummia. Suurin osa oli tekstityyppiä, mutta joukossa oli myös numeerista dataa.
Valtavirrasta poikkeavat taulukon solut editoidaan. Kaikille tekstityypi, klik, done. Tällainen “masterdatan” muokkaaminen ei tietysti ole riskitöntä.
Taulukkolaskentaohjelmistot tarjoavat monenlaista vipstaakia datan sisäänlukuvaiheessa. Kokeilin, miten vahingossa mukaan livahtaneet hipsut ja ylimääräiset tyhjät merkit pystyy poistamaan. Pystyy, helposti.
Google Refine Expression Language (GREL) ymmärtää säännöllsiä lausekkeita. Alla poistetaan Etunimet-sarakkeen soluista lopun tyhjät merkit ja sulkeva hipsu.
Google Fusion Tables
Pinserissä oli muutama viikko sitten mainio salapoliisitarina iPhone-paikkadatasta. Siitä luin ensimmäistä kertaa näistä fuusiotauluista. Kätevä apu datan kääntelyyn ja katseluun eri kanteilta. Ja jos mukana on paikkatietoa – kuten Pinserin tapauksessa – ne esitetään automaattisesti karttanäkymässä. Taulukkoon voi tallentaa näkymiä, ja näkymiin edelleen suodatuksen ja ryhmityksiä.
Tein YLE:n vaalikonedatalle näkymän, jossa ovat ehdokkaista vain perustiedot kuten nimi, ikä, sukupuoli, puolue jne. Suodatin jäljelle vain ne rivit, jotka liittyvät valittuihin ehdokkaisiin. Ryhmitys keskimääräisen iän ja puolueen mukaan.
Erilaisten näkymien ja ryhmittelyjen määrittely data-aineistolle lähestyy pivot-taulujen filosofiaa. Excel ja OpenOffice Calc ovat tunteneet ne jo pitkään, ja aivan hiljattain niille tuli aito tuki myös Google Docsiin. Olen yksi heistä, joille pivotointi on vielä varsin vierasta. Tony Hirstin maanläheinen blogaus on auttaa alkuun.
Paikkatiedosta puheenollen, leikittelin jonkin aikaa ajatuksella, että saisin ennen HS Openia käsiini jonkin eduskuntavaaliehdokkaan, jolla olisi ollut iPhone mukana vaalityössä. Grand Plan: oletetaan, että hän olisi halukas antamaan Tieteen käyttöön viimeisen vaalityöviikkonsa paikkadatan. Oletetaan edelleen, että hän olisi liikkunut nimenomaan omassa vaalipiirissään iPhonensa kanssa. Miltä näyttäisi visualisointi, jossa olisivat mukana hänen liikkeensä ja hänen kyseisessä vaalipiirissä saamansa äänet? Voisiko tästä vetää minkäänsortin johtopäätöksiä vaalityön vaikutuksista äänestyskäyttäytymiseen? No, vastaus on tietysti että ei voi 🙂 mutta sormiharjoitteluna se olisi ollut mukava. Terveiset ja kiitokst Jyrki Kasville, joka tuli ensimmäisenä mieleen, kun mietin keneen ottaa yhteyttä. Hän oli tehnyt vaalityötä Eduskunnan Nokia E90:n kanssa, koska siinä oli työpaikan kalenteri. Muita en tähän hätään ehtinyt saada kiinni.
Google Docs
Suurin osa tästä aurinkoisesta viikonlopusta meni Google Docsin kanssa mähkiessä. Kuvittelin näet voivani rakentaa sen avulla puuttuvan lenkin rahoitusdatan ja YLE:n vaalikonedatan välillä.
Olin muodostanut Google Refine’n transform-vivulla molempiin taulukoihin ylimääräisen apusarakkeen HloID, ehdokkaan sukunimi ja ensimmäinen etunimi. Tavoite: kopioida sen avulla YLE-taulun ID myös toiseen tauluun. Silloin minulla olisi kunnon avain.
Lopulta onnistui, edes osittain (mutta ei oikealla aineistolla, josta kohta lisää), kiitos ahkeran googlaamisen ja ystävällisten Google Docs -foorumin vakioauttajien.
=QUERY('Sheet2'!A:C,"SELECT C WHERE A CONTAINS """&A361&""" ")
Tässä ollaan työkirjan lakanalla Sheet1, B-sarakkeen (tuleva ID) solussa B361. Samalla rivillä, A-sarakkeessa, on HloID. Saman työkirjan lakanasta Sheet2, sarakkeesta A, etsitään vastaavaa merkkijonoa. Jos löytyy, saman rivin sarakkeesta C haetaan arvo soluun B361.
QUERY-lauseke on tallennettu ensimmäiselle datariville. Solun oikeasta alanurkasta kiinni, ja lausekkeen kopiointi taulukon kaikille riveille. Suhteellinen viittaus A-sarakkeen soluun kasvaa samalla automaagisesti.
So far so good. Mutta. Varsinainen taulukko on niin iso, että Google Docs ei suostukaan lukemaan sitä samaan työkirjaan. No, tämän ei pitäisi olla ongelma, sillä myös kokonaan toisesta työkirjasta voi hakea, ainakin teoriassa.
=QUERY(IMPORTRANGE("0AvfW9KgU1XzhdHJSRFFwSGR3YWR6MVl3X0ZVWkhibUE","Sheet1!A:C"),"SELECT C WHERE A CONTAINS """&A361&""" ")
Pitkä älämölö on työkirjan yksilöivä avain. Sen näkee URL:sta.
Ei onnistunut. Google Docs oli joko sitä mieltä, että C-saraketta ei ole tai että hittiä ei löydy. Joissakin ohjeissa lakana ympäröitiin yksinkertaisilla hipsuilla, toisissa ei. Joissakin käytettiin puolipistettä välimerkkinä, toisissa pilkkua.
Nyt te varmaan sanotte, että “miksi ihmeessä mokoma vaiva, tauluthan voi yhdistää simppelisti tällä tavalla…” ja näytätte. Jään odottamaan.
EDIT 23.5: Järjestäjät olivat tehneet paljon duunia datan eteen. Aineisto oli siististi kantatauluissa, kanta LAMP-palvelimella ja palvelin Amazonilla. Kiitos tämän, päivän annista tuli hyvä. Porukassa oli osaajia monelta alalta, ja nopea protoilu sujui. Lahjakasta väkeä!
Metadatasta matikka
Viime viikkojen virkistäviä uutisia oli HelMet-kirjastojen bibliografisen datan julkaiseminen MARCXML-muodossa.
Luettelointityön yksityiskohtaisuus ja huolellisuus on hämmästyttävää. Miten dataa sitten voisi hyödyntää? Kirjastot.fi-keskustelussa Mace Ojala visioi:
Tällaista datadumppia voisi käyttää esim. kirjoitusvirheiden etsimiseen HelMet -tietokannasta. Tai vaikkapa kaivellakseen kirjoittajien ja asiasanojen välisiä yhteyksiä; miten HelMet-kirjastojen luettelointidata kuvailee vaikkapa Aleksis kiven tuotantoa kokonaisuutena? Tätä voisi vertailla vaikkapa siihen miten muut kirjastot saman aineiston sisältöä kuvailevat. Tai voi kaivaa vaikkapa eri kirjastoluokkiin luokittelemiemme teosten jakauman eri vuosille. Tai vertailla vaikkapa miten kirjastoluokat ovat sidoksissa toisiinsa lisäluokkien kautta. Tätä dataläjää voi käyttää myös vaikkapa etsiäkseen muita tapoja kuvailla tällaista aineistoa kuin kirjastojen käyttämä MARC21, pyrkien vaikkapa Open Linked Dataan.
Ensi alkuun pitää saada jokin tolkku MARC-kentistä.
Sormiharjoituksena tein muutaman tiedoston sisällöstä XSLT2-muunnoksen CSV– ja HTML-formaattiin. Valitsin englanninkielistä kaunokirjallisuutta tältä vuosikymmeneltä. Poimin mukaan kirjailijan, kirjan nimen, julkaisuvuoden ja ISBN-numeron sekä muodostin suoran linkin HelMet-tietokantaan, ohjeen mukaan. Lopputulos tässä.