Keskiraskas louhinta

Eiliseen verrattuna levyn nurkalla on nyt melkein 50 kertaa isompi otos, reilut 20000 tweettiä. Jokaiselta listan jäseneltä 200, hänen omalta aikajanaltaan. GET statuses/user_timeline -API-määrittely lupaa maksimiksi 3200 per nenä, mutta silloin mukana voivat olla (paluuformaatista riippuen) myös ns. natiivit retweettaukset. Annoin ne tulla mukaan.

En viitsinyt koputella tweetkattoa, vielä. Pöytäkoneella oli jo tekemistä tämänkin tekstikorpuksen käsittelyn kanssa. Erityisen hidas oli stopwordien poisto-operaatio.

Käyttäjänimistä on jäljellä enää listan perustaja Niku Hooli, mikä ei yllätä; lista on uusi juttu, ja siitä ja sen perustajasta on tietysti (re)tweetattu paljon. Sitä en sen sijaan ymmärrä, miksi the keikkuu edelleen mukana ja huipulla, vaikka lisäsin sen stopword-listaan. Täytyy joskus kaivella lisää.

Tuloksesta voi varovaisesti piirtää kuvaa yhteisöstä, jonka aktiivisimmat sanankäyttäjät ovat kohteliaita, kilttejä ja ajan hermolla. Sosiaalisen median käytäntöjen ammattilaisia.

Koodinpätkästä puuttuu louhintaosuus. Se on sama kuin ennenkin.

Twitter-listan jäsenet

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. Käsiteltävät tiedostot on listattu kokoomatiedostossa libdata.xml. Lopputulokset tässä ja tässä.

Väitöskirjat

Suomalaisista yliopistoista valmistui vuonna 2009 reilut 1600 uutta tohtoria. Olen siitä omituinen, että tykkään vilkuilla minkälaisia väitöskirjoja on ilmestynyt. Suurin osa kovasta tieteestä menee yli hilseen (onko kukaan väitellyt hilseestä?), mutta mukaan mahtuu silti sadoittain potentiaalisesti mielenkiintoisia, tuoreita tutkimuksia.

Väitöstilaisuuksista ja uusista väitöskirjoista tiedotetaan yliopistojen verkkosivuilla. Lehdistötiedotteissa, osana yleis-, ajankohtais- tai tiedeuutisia, tapahtumakalenterissa, uusissa julkaisuissa. Tiedottaja on yleensä joko yliopiston viestintä, julkaisuyksikkö tai kirjasto. Väitösuutisista kiinnostuneen kansalaisen on oltava kärppänä, mistä mitäkin löytyy ja milloin.

Reilu vuosi sitten tein tukun RSS-syötteitä Yahoo!Pipesilla niiden yliopistojen väitöksistä, jotka eivät sitä itse tarjoneet. Melko työlästä. Yliopiston julkaisujärjestelmästä (tai sen puutteesta) riippuen tiedote putkahtaa ilmoille eri tekniikoilla tuotettuna ja vaihtelevan muotoisena. Olennaisten tietojen poimiminen HTML-sivulta on pikkutarkkaa puuhaa, eikä mikään takaa että logiikka toimii enää ensi viikolla.

Kävin nyt uudestaan läpi kaikki putket. Muutoksia tuli pal-jon. Ei mikään ihme. Yliopistoja on tällä välin yhdistelty, järjestelmiä uusittu, sivuja siirrelty, leiskoja muutettu.

Kaikkien syötteiden liittäminen yhteen ja samaan tekee lopputuloksesta raskaan, joten jaoin ne viiteen pakettiin. Maantiedettä mukaillen etelästä pohjoiseen: pääkaupunkiseudun, Turun, Tampereen yliopistot sekä Lappeenrannan, Jyväskylän, Vaasan ja Itä-Suomen, Oulun ja Lapin yliopisto.

Helsingin yliopiston E-thesis -palvelun mittavasta syötetarjonnasta ovat mukana vain keskustakampus ja Kumpula. Yksi on joukosta poissa: entinen TKK eli nykyinen Aalto-ylipiston Teknillinen korkeakoulu. Syötteet ovat HTTPS-protokollan takana, ja Yahoo!Pipesilta ei löydy tukea sille. Varsinaisesti. YQL-kyselykielen ja Fetch Data -modulin avulla protokollarajoitetta voi tosin yrittää kiertää. En saanut temppua onnistumaan TKK:lla, Jyväskylässä (RSS) sen sijaan kyllä. Tiedä sitten, mikä ero tuossa on...

Jo hyvissä ajoin ennen väitöstilaisuutta väitöskirjan metatiedot on tallennettu digitaaliseen, määrämuotoiseen formaattiin. Työn on tehnyt yliopiston kirjasto. Metatieto on saman tien päivitetty paitsi paikalliseen tietokantaan myös Kansalliskirjaston Linda-yhteistietokantaan. Harmi vain, että tähän metatietoon ei ole toistaiseksi tarjolla avointa ohjelmointirajapintaa. Jos osaa ja viitsii, Lindan hakuliittymästä voi tietysti riipiä haluamansa tiedon screen scraping -tekniikoilla. Kotitarpeita ajatellen koodaus menee kuitenkin överiksi.

Kuinka ollakaan, tiedot väitöskirjoista leviävät myös Suomen rajojen ulkopuolelle. Isoimpia toimijoita ovat WorldCat ja Google Scholar. Molemmat tarjoavat API:n. Molemmat rajoittavat API:n käytön to qualifying institutions, mitä se sitten käytännössä tarkoittaakaan. Tiedän, että Google Scholarilla on paljon ystäviä, koska se on ajan tasalla. Vaikka sieltä ei välttämättä löydykään muuta kuin englanninkielistä aineistoa - kuten Jyrki Ilva E-thesis -palvelusta huomautti jo vuonna 2006 - suomenkieliset väitöskirjat alkavat olla harvinaisuus.

Leena Saarinen kirjoitti maaliskuussa Kansalliskirjaston Digitaalinen kirjasto -blogissa myönteiseen sävyyn Julkinen data -julkaisusta otsikolla Askel kohti avointa julkisdataa. Tämä lupaa hyvää. Nyt ei kun yhdessä toivomaan, ettei tarvitse odottaa liian kauan.

Taulukko tietokantana

Ulkomaan luontoretkillä on tullut tavaksi pitää listaa nähdyistä eläinlajeista. Taulukkoon nimi englanniksi ja latinaksi (jos tiedossa), paikka ja mahdollinen kommentti. En ole mikään listafriikki, mutta kirjaaminen helpottaa lajien ja tapahtumien muistamista.

Listoihin saattaa olla mielenkiintoa muillakin, joten olen muokannut niistä HTML-version verkkoon (sivun lopussa). Työnantaja on ollut joustava ja sallinut kohtuullisen määrän privaattia aineistoa webbipalvelimellaan. Se päivä on kuitenkin lähellä, että materiaali on syytä siirtää muualle. Webhotelli on mietinnässä muistakin syistä, mutta väliaikaisratkaisuna Google Docs on houkutteleva vaihtoehto.

Tony Hirst kertoo mainion havainnollisessa blogissaan, miten julkiseen Google-taulukkoon voi tehdä kyselyjä Google Visualisation API -kyselykielellä aivan kuin taulukko olisi verkossa oleva tietokanta. Kieli muistuttaa SQL-kyselykieltä. Tulosjoukon saa JSON-, CSV- tai HTML-muodossa.

Alkuperäiset taulukot ovat läppärillä Excel-tiedostoina. Toin Perun matkan lakanan Import-toiminnolla Googlelle, ja aloin leikkiä hakukielellä:

- kaikki lajit, jotka näin Manu Wildlife Centerissä (MWC)
. Ei aakkostusta, ja taulukon sarakkeille A-D ymmärrettävämpi label

- kultapyrstöt (oropendola) aakkosjärjestyksessä

- kaikki rivit ensimmäistä lukuunottamatta, koska sen ensimmäisessä solussa ovat yhtenä pötkönä paikkalyhenteiden selitykset

So far so good, mutta vielä riittää duunia. Ensimmäisellä rivillä oleva tieto pitää saada käyttöön, samoin linkit latinalaisesta nimestä Wikipediaan.

Tvleffat-putki päivittyi

Muutama vuosi sitten tein tulevien TV-elokuvien syötteen telkku.com -palvelun perusteella. Kun äsken tweettasin illan Beat the Devil -leffasta, kävin pitkästä aikaa katsomassa, miltä putken alkupää näyttää. Ja kas, sieltähän löytyy nyt myös joistakin elokuvista linkki www.imdb.com-sivuille. Kopautin putkea, ja nyt linkki valuu mukana. Jos sinulla on sattumalta jatkotilaus putkesta, päivitä se syötelukijassasi.

Vuokratontti

Hankin viime vuonna tontin Second Life -virtuaalimaailmasta, EduFinland-saaristosta. Samaan tapaan kuin moni muutkin vuokralainen, minäkin testaan siellä yhtä sun toista ja mietin siinä sivussa, mihin oikeaan käyttöön tontista olisi. Tähän liittyen kirjoitin jopa riskianalyysin. Vaikka hassuahan se tavallaan on, tuo oikean etsiminen. Tonttihan ei ole todellinen vaan virtuaalinen.

Riskianalyysi pitää joka tapauksessa päivittää. Linden Lab näet julkaisi helmikuun lopulla uuden (beta) asiakasohjelman, Second Life Viewer 2, ja se onkin toista maata. Paitsi että käyttöliittymä muistuttaa entistä enemmän selainta, niin nyt myös mille tahansa objektille voi tuoda dynaamista web-sisältöä. Asiakasohjelmassa raksuttaa WebKit-moottori.

Osallistuin viikolla erääseen testiin, jossa ryhmä avattaria mm. muokkasi yhdessä Etherpad-dokumenttia. Todellisen ja virtuaalisen sekoittuminen reaaliajassa oli hämmentävä kokemus. No, Etherpadia ei kohta enää ole - joten nyt on parasta kerätä tavarat - mutta tämä oli vasta alkua.

Vielä kerran Radioputkesta: VTIMEZONE kunnolla mukaan

Yahoon putkesta tuleva vajavainen iCal alkoi nyppiä. Haen tämän outputin nyt Linux-ympäristöön, rakennan siellä standardinmukaisen tiedoston, siirrän sen webbipalvelimelle, ja tilaan sen sieltä Google-kalenterilla.

Skriptiä varten tein kaksi samana pysyvää aputiedostoa alku ja vtimezone, jotka yhdistetään muuttuvaan tietoon jokaisella ajokerralla.

alku:


BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ts.fi/iCal/EN


vtimezone:


BEGIN:VTIMEZONE
TZID:Europe/Helsinki
BEGIN:STANDARD
DTSTART:19811001T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:Europe/Helsinki
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810301T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:Europe/Helsinki
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE


Tämä shell-skripti on ajastettuna kerran vuorokaudessa.


#!/bin/bash

# Yahoo!Pipesin tuottaman iCal-muotoisen tiedoston URL
url='http://pipes.yahoo.com/pipes/pipe.run?_id=6602675e62d5d95c7333285517e6a471&_render=ical&urlinput1=http%3A%2F%2Fspreadsheets.google.com%2Fpub%3Fkey%3Dtd1iey6KTeeTgGlE6U3_PPg%26output%3Dcsv'

# Haetaan data, ja tallennetaan se tiedostoksi
curl $url -o tolisten.ics

# Otetaan alussa olevat metatiedot talteen
grep X-WR tolisten.ics >XWR

# Yhdistetään alku, metatiedot ja aikavyöhyketiedot
cat alku XWR vtimezone >beforeevents

# Otetaan tapahtumatiedot erilleen
sed -n '/BEGIN:VEVENT/,$p' tolisten.ics >events

# Tyhjät rivit pois, ja korvataan DTSTART- ja DTEND-rivit
perl -pe 's/^\n//;s/DTSTART:/DTSTART;TZID=Europe\/Helsinki:/g;s/DTEND:/DTEND;TZID=Europe\/Helsinki:/g' events >tzidevents

# Yhdistetään alkuosa tapahtumatietoihin
cat beforeevents tzidevents >all.ics

# Siirretään valmis tiedosto webbipalvelimelle
mv all.ics ~/public_html/yle.ics

# Lopuksi vielä tiedoston lukuoikeudet kuntoon
chmod go+rx ~/public_html/yle.ics


iCal-standardi edellyttäisi lisäksi jokaiselle tapahtumalle uniikin ID:n. Google-kalenteri ei sitä välttämättä tarvitse, mutta ehkä sen voisi vielä tuohon viritellä.

Radioputkia, laajan matematiikan kurssi

Edellisessä postauksessa jäin tilanteeseen, jossa ohjelman viimeinen kuuntelupäivä sijoittuu edessä häämöttävään talvikauteen, ja se pitäisi hanskata jotenkin. Helppo korjaus on se, että putki haaroitetaan: toisessa vähennetään kolme, toisessa kaksi tuntia. Yhdistämisen jälkeen tehdään yhteinen loppusiivous. 

Radioputkia

Kuuntelen säännöllisesti muutamaa Yleisradion ohjelmaa YLE Areenasta. Lue: yritän muistaa kuunnella. Aina ei onnistu.


Ohjelmien RSS-syötteessä on tieto siitä, milloin kukin ohjelmajakso poistuu palvelusta. Tämä tieto Google-kalenteriin, muistutus sähköpostissa vaikka kuusi tuntia ennen ohjelman häipymistä - kelpaisi minulle. Pilvipalveluna? Mikäs siinä. Kyse ei ole kriittisestä jutusta.

Yahoo!Pipes tarjoaa iCal-ulostuloputken, jonka voi tilata Google-kalenteriin. Ei hassumpaa. Entä missä pitää listaa seurattavista ohjelmista? Itse putkeen sitä ei kannata pultata, koska silloin ylläpito menee hankalaksi. Onneksi Yahoo!Pipes-putkeen voi tuupata dataa ulkopuolelta CSV-muodossa. Google Docsin taulukkolaskentaohjelma taas osaa julkaista lakanan CSV:nä. Prosessi alkaa hahmottua. Töihin!


Osoite-sarakkeessa on Areenan A-Ö -listauksesta löytyvä ohjelman kuuntelusivun URL. B-sarake on vain sitä varten, että muistaa mistä ohjelmasta on kyse; URL kun ei sitä kerro.

Lakana pitää julkaista: Share > Publish as web page > Get a link to the published data (CSV). Täppä sille, että julkaistaan aina kun dokumenttia on muutettu. URLista kopio, putkelle syötteeksi, ja ajo. More options -valikosta löytyy Get as iCal. Tästä linkistä kopio.

Googlen kalenteri ei suostu nielaisemaan linkkiä tällaisenaan. Avuksi tulee jokin verkosta löytyvä URL-lyhennepalvelu kuten bit.ly, tiny.url tai vastaava. Lyhyt-URL talteen, ja Google Calendar auki. Other calendars > Add > Add by URL. Kopio sinne.

Nyt on jo lähes valmista. Google ilmoittaa, että se aikoo indeksoida kalenterin, mitä se sitten ikinä tarkoittaakaan tässä yhteydessä. Voi kestää tovin, ennen kuin ohjelmatiedot tulevat näkyviin. Jos tuntuu kestävän, kokeile virkistystä Refresh-linkistä.

Uuden kalenterin Notifications -kohtaan vielä Event reminder: By default, remind me via email 6 hours before each event. Ja sitten ei kun odottamaan, että automaatio hoitaa loput. Yahoo! kysyy Googlelta, mitä seurataan. YLE päivittää ohjelmasyötteen. Yahoo! käy hakemassa sen. Google lisää uudet tiedot kalenteriin - noin kerran vuorokaudessa - ja pistää postia, kun aika ok.

Päältä katsoen homma näyttää toimivan kuin rasvattu. Ylimääräistä rasvaa siellä onkin.


Isoin ongelma on aika. Toinen, pienempi, on merkistö.

Putkessa on rumaa liimaa: kellonajoista vähennetään kolme tuntia, jotta ajat menevät oikein silloin kun kalenteri on Suomen aikavyöhykkeellä ja on kesä. Vain näin olemme Googlen kanssa päässeet yhteisymmärrykseen siitä, mitä kello oikein on.

Montakohan tuntia pähkäilin tämän kanssa? Monta. Kuinka ollakaan, kävi ilmi, että tämä on tuttu juttu. Syy on ainakin osaksi Yahoo!n, sillä iCal-tiedosto on Googlen mielestä vajaa. Siitä puuttuu VTIMEZONE-komponentti, joka kertoo faktat minun aikavyöhykkeeni kesä- ja talviajasta: milloin muutos tapahtuu, ja mihin suuntaan kelloja silloin siirretään suhteessa Greenwichin aikaan (GMT). Jokaisessa kalenteritapahtumassa voisi silloin viitata tähän aikavyöhykemäärittelyyn TZID-avaimella, automaatio raksuttaisi ja kaikki olisivat tyytyväisiä.

Allaoleva iCal-tiedosto on Google Calendarin mielestä ok. Testasin sen tallentamalla tiedoston webbipalvelimelle ja tilaamalla sen sieltä. Tapahtuma-ajat menivät nätisti paikoilleen, vaikka välissä vaihtuu kesä talveksi. Great! Valitettavasti vaan Yahoo!Pipesilla ei pysty tuota VTIMEZONE-komponenttia lisäämään, koska se ei liity tapahtumaan eli putkiterminologian mukaan RSS-syötteen yksittäiseen alkioon.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ts.fi/iCal/EN
BEGIN:VTIMEZONE
TZID:Europe/Helsinki
BEGIN:STANDARD
DTSTART:19811001T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:Europe/Helsinki
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810301T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:Europe/Helsinki
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:ts.fi-1
DTSTART;TZID=Europe/Helsinki:20100411T081500
DTEND;TZID=Europe/Helsinki:20100411T081500
SUMMARY:Tapahtuma1
END:VEVENT
BEGIN:VEVENT
UID:ts.fi-2
DTSTART;TZID=Europe/Helsinki:20101103T074500
DTEND;TZID=Europe/Helsinki:20101103T074500
SUMMARY:Tapahtuma2
END:VEVENT
END:VCALENDAR

Oli miten oli. Jos yrittää sinnitellä Google-kalenteriputken kanssa, niin ennen kuin normaaliaika taas lähestyy, putkeen on vähintään saatava valid-elementin haistelu. Siellä sanotaan selkeästi, onko aikaero kaksi vai kolme tuntia GMT:hen.

iCalin oletusmerkistö on UTF-8. Yahoo!Pipesin tuotos on sitä, mutta ainakin Windows XP+Firefox 3.6.3 -näkökulmasta jotain on pielessä lähetyspäässä (?), sillä skandinaaviset kirjaimet eivät näy oikein. En ole tutkinut asiaa sen syvällisemmin. Poistin suosiolla pisteet ja aksentit jo putkessa.

Paikalliselta koneelta löytyy Windows Outlook 2003 ja sen kalenteri. Tässä versiossa ei ole dynaamista kalenterin tilausmahdollisuutta (uudemmissa Windowseissa on), mutta perus-import syö siististi tästä toisesta putkesta tulevan iCal-tiedoston. Edes kellonaikoja ei tarvinnut sitä varten ruveta säätämään. Riittää, että valid-elementistä poimi end-arvon jatkoa varten.


Skandiongelma on kyllä täälläkin, joten nöyrästi vain pilkut piiloon!