Luetteloijan vuodenkierto

Vuoden kierto näkyy kirjastoissa. Kesä tyhjentää dekkarihyllyt ja synkimmän talven aikaan matkakirjat löytävät lukijansa. Mutta näkyykö vuoden kierto kirjastotiedossa, luettelotietokannan tietuessa?

Viime kesänä aiempia kirjastoluettelografiikoita tehdessäni olin kiinnittänyt huomiota MARC -kontrollikentässä 008 olevaan päivämäärään. Tuohon kenttään tallennetaan tieto siitä, milloin kyseinen MARC-tietue on alunperin luotu. Sopivasti kentän tietoja käsittelemällä olisi siis mahdollista summailla yhteen tiettyinä kuukausina ja vuosina (ja miksei myös päivinä) luetteloitujen teosten määriä. Tuolloin asian kehittely jäi, koska tiedossani ei ollut kohtuullisella vaivalla opeteltavia työkaluja melkoisen suuren datamäärän läpikäyntiä varten. Tämä pulma ratkesi, kun olen nyt graduuni ja työhöni liittyen koittanut perehtyä XQuery-ohjelmointikieleen ja XML-tietokantoihin. Yhteenvetolukujen laskeminen alkoi näyttää mahdolliselta -- tarvitsisi vain tallentaa Helmet-tietokannan sisältö XML-tietokantaan ja harrastaa hieman XQuery-magiaa.

Ja katso, lopulta Ärrä pyöräytti ulos käppyrän. Otin käsittelyyn mukaan aineiston vuodesta 1980 eteenpäin, sillä tätä vanhempaa aineistoa ovat poistot karsineet siksi paljon että kuvion skaalaero olisi tullut turhan suureksi. Lisäksi poistin vuoden 1992 lokakuulta 130961 (!!) tietokantaan viedyn teoksen piikin. Mitäköhän kummaa kirjastossa on tuolloin tapahtunut -- vai liekö datassa virhe?

Helsingin kaupunginkirjaston kokoelman kartunta suhteessa aikaan

Kirjastotyössä olevat osannevat sanoa, muistuttaako kuvio todellisuutta. Kesän hiljaisuus erottuu, mutta näkyykö kuvasta jotain muutakin? Esimerkiksi, mikähän lie syy yksittäisten luettelointiaktiivisuuspiikkien taustalla?PDF-versiosta erottunee yksityiskohdat paremmin.

Työvaiheet olivat kutakuinkin samat, kuin aiemmissa Helmet-aineistoa käyttäneissä kokeiluissani. Aluksi muunsin Helmet-datadumpin XSLT-muunnostiedoston avulla MODS-muotoon (kiitokset muuten Labs-väelle datadumpin päivittämisestä!). MODS-muodosta ajoin tietokannan vielä pienempään ja näppärämpään muotoon, jossa oli vain tarvitsemani tiedot. Vaivainen koneeni ei jaksa pyörittää kovin suuria datamääriä, joten minun tuli karsia aineistosta kaikki ylimääräinen tieto pois. Järeillä laitteilla aineistoa voisi käsitellä suoraan, ilman alkuvaiheen muunnoksia. Lopulta latasin epäolennaisista tiedoista karsitut XML-tiedostot tietokantaan. Karsimisesta huolimatta koneeni alkoi yskähdellä, joten päätin ottaa tarkasteltavakseni vain Helsigin kaupunginkirjaston kokoelmasta löytyvien teosten luettelointitiedot.

Nyt kun tarvitsemani tiedot olivat XML-tietokannassa, saatoin aloittaa niiden käsittelyn XQuery-kielen avulla. Aluksi siistin eksoottisessa MARC-muodossa olevan päivämäärätiedon hieman rakenteisempaan muotoon


import module namespace functx="http://www.functx.com";

<catalogingdates>{
for $record in /records/record
let $date:=string($record/created)
let $year:=substring($date,1,2)
let $month:=substring($date,3,2)
let $day:=substring($date,5,2)
return( <item>
                    <year>{$year}</year>
                    <month>{$month}</month>
                    <day>{$day}</day>
                </item>)
</catalogingdates>

Varsinainen yhteenvetolukujen laskeminen tapahtui XQueryn count()-funktiolla. Huomasin, että olin onnistunut ylikirjoittamaan toisella skriptillä tämän laskennan tehneen XQuery-loitsun, mutta kyseessä oli kutakuinkin samanmittainen pätkä kuin ylempi.

Viimeisenä askeleena ennen Ärrään siirtymistä otin tiedot ulos CSV-muodossa:

for $year in distinct-values(//year)
for $done_in_month in //done[year=$year]
let $month:=data($done_in_month/month/@id)
return ({$year}-{$month}-1,{data($done_in_month/month)})

Tälläkin kertaa päätin luoda grafiikan R:n ggplot2-kirjaston tarjoamilla työkaluilla. Kuvio syntyi R-komennoilla:

    t<-qplot(date, count, data=lastyears, geom="path", group=1, ymax=2000,ylab="",xlab="")
    t + scale_x_date(format='%Y',major="years") + theme_bw()

Sanojen rihmat

Viikonlopun alla julkaistiin Gephi-visualisointityökalun uusi kokeiluversio, ja päätin ottaa asiakseni tutkailla ohjelmaa hieman. Gephi oli minulle nimeltä tuttu, mutten aiemmin ole viitsinyt asentaa sitä koneelleni kun olen arvellut Javalla toteutetun ohjelman olevan kovin resurssisyöppö. No, arveluni osui oikeaan, mutta sopivan pienellä aineistolla viiveet pysyivät siedettävinä.

Tällä kertaa päätin katsoa, millaisia verkostoja Helmet-dumpin tekstimuotoiselle aineistolle annetut asiasanat muodostavat. Kokonaisuudessaan tekstiaineistoa on dumpissa noin 50000 tietuetta. Pilkoin tästä satunnaisotannalla käsiteltäväksi muutamia erikokoisia datasettejä. Tällä kertaa en tarvinnut Python-skriptejä, vaan sain luotua tarvitsemani tiedostot yksinkertaisen XSLT-muunnostiedoston ja UNIX-komentorivityökalujen avulla. Ajoin aluksi koko dumpin tekstiaineiston asiasanat muotoon, jossa kunkin teoksen asiasanat on listattu yhdellä rivillä. Gephiin ladattavat tiedostot syntyivät tästä suuresta tiedostosta rl-työkalun avulla, joka poimii sille annetusta tiedostosta halutun kokoisen satunnaisotannan.

Ohessa kuva kuudensadan tietueen otannasta (korkearesoluutioinen kuva PDF-tiedostona). Kuvassa sinisellä sävyllä korostettu asiasanaryhmä liittyy suomenkieliseen kaunokirjallisuuteen ja keltainen ruotsinkieliseen kaunokirjallisuuteen. Oranssilla on merkitty ruotsinkieliseen tietokirjallisuuteen liittyvät asiasanat ja vihertävällä suomenkielisen tietokirjallisuuden asiasanat. Viivojen paksuus kuvaa sitä, kuinka usein jotkin asiasanat esiintyvät yhdessä. Tähän kuvaan en ole laittanut näkyville, mitkä sanat ovat kyseessä. Täytyy mietiskellä, minkälaiseen kuvaan sanat saisi otettua mukaan, ilman että kuva menee täysin tukkoon. Gephi on melkoisen monipuolinen ohjelma, joten eiköhän sieltä löydy ongelmaan ratkaisu.

Runolliset tietueet

Muokattu 4.4: Nyt julkaistuja teoksia kuvaavien ympyröiden koko määräytyy teosten lukumäärän logaritmina. Pakkautumisongelma tuntuu helpottavan ja yksityiskohdat säilyvät paremmin. Päivitin esikatselukuvan ja ladattavan PDF-tiedoston.

Jatkoin Helmet-datadumpin pyörittelyä. Istuskelin perjantai-iltapäivän työ/opiskelupaikkani järjestämässä verkostoanalyysi-metodipajassa, josta sain ajatuksen kokeilla SNA-menetelmiä Helmet-aineistoon.

Koska aineisto on melkoisen suuri -- satojatuhansia tietueita -- mopokonetta ja hermoja säästääkseni päätin ottaa aineistosta jonkin kiinnostavan osajoukon käsiteltäväkseni. Päädyin Suomessa suomeksi tai ruotsiksi julkaistuihin runoihin ja runojen kustantajiin: näin näppitultumalta runoja ei julkaista vuositasolla kovin hurjia määriä ja on mielenkiintoista tietää, mitkä tahot hoitavat tätä julkaisutoimintaa.

Aloitin tarvitsemani aineiston koostamisen ajamalla aiemmin MODS-muotoon saattamastani Helmet-datadumpista XSLT-muunnoksen CSV-taulukkomuotoon, johon tallensin kunkin runoteoksen tekijän, kustantajan ja julkaisuvuoden. XSLT-muunnoksen synnyttämät taulukot eivät olleet suoralta käsin käyttövalmiita, vaan aineistoa joutui siivoilemaan jonkin verran käsin.

Tämän jälkeen järjestelin ja suodatin UNIX-komentorivityökalujen (sort ja unique) avulla tiedoston sellaiseen muotoon, jossa riveillä on kirjailijan nimi, kustantaja ja kyseisen kustantajan kautta julkaistujen teosten lukumäärä. Nyt data oli sellaisessa muodossa, että käytettävissäni oli kaikki ne tiedot, jotka oletin tarvitsevani mielessäni olevan grafiikan toteuttamiseksi koneen avulla.

Datasta syntyi kaavio Python-ohjelmointikielen NetworkX verkostoanalyysipaketin sekä Graphviz -visualisointityökalun suosiollisella avustuksella.

Python-skriptin nielemä tieto näytti tältä: 4 WSOY Töyrylä, Timo 19 WSOY Vaara, Elina 4 WSOY Vala, Katri 5 WSOY Venho, Johanna ...ja skriptin tuottama, DOT-muotoinen tieto kutakuinkin tältä:

"Vaara, Elina" [style=filled, fixedsize=true, height="0.25", width="0.25", shape=circle, role=author, fontsize=1, label="", color=lightgray]; WSOY [width="2.5", style=filled, fontsize=12, fixedsize=true, role=publisher, color=red, height="2.5"]; "Vaara, Elina" -> WSOY [color=gray37, penwidth=4];

Loppu olikin silkkaa automagiaa suurimmaksi osaksi. Latasin DOT-tiedoston Graphviz-ohjelmaan, joka pienen asetustensäätelyn jälkeen lykkäsi ulos haluamani grafiikan. Jahka saan opeteltua Graphviziä lisää, koitan josko saisin mankeloitua esityksen hieman havainnollisempaan muotoon.

Runokustantajat

Kuvassa punaiset ympyrät ovat kustantajia ja harmaat kirjailijoita. Ympyrän koko heijastelee julkaistujen teosten määriä.

Esikatselukuva sisältää vain pienen osan koko grafiikasta -- ohessa kuva kokonaisuudessaan PDF-muodossa.

Harmonikassa Kimmo Pohjonen - Axiell Arena ja musiikin tiedonhaku

Muokkaus: Päivitetty 18.3. Lisätty titleoriginal ja titlemain -hakukentät.

Viime vuoden alkusyksystä kirjoittelin ylös havaintojani siitä, kuinka tuolloin Tampereella pilottivaiheessa olleen Arena-verkkokirjaston haun saisi tuottamaan epämääräistä tarkempia hakutuloksia. Ennen myöhemmin syksyllä tapahtunutta julkaisua verkkokirjastoon tuli 'tarkennettu haku', joka ei kyllä aivan vastaa sitä mitä Axiellilta odotin, mutta onhan tuo kyllä askel parempaan suuntaan. Hausssa(kin) on siis parantamisen varaa vielä.

Kuten edellisessä Arena-kirjoituksessani totesin, haun ongelmat johtuvat tällä hetkellä lähinnä hakukäyttöliittymän keskeneräisyydestä, eikä niinkään taustajärjestelmän kyvyttömyydestä. Arenan hakujärjestelmänä toimii avointa koodia oleva Solr-hakumoottori, jonka tarvittaessa taipuu jos jonkinlaisiin hakuihin. Tästä osoituksena listasin hyvän joukon Solr-hakuavaimia, joilla Arena-haun saa tarvittaessa kohdistettua esim. kustantajaan ja julkaisuvuoteen (esim. oma suosikkihakuni on publisher:"Terra Cognita" AND publicationyear:[2009 TO NOW]).

Nyt jatkoin hieman Arenan tutkailua, jälleen Heikki Poroilan innoittamana. Kuinka ollakaan, arvailun kautta löysin kolme viisi hakukenttää lisää.

Edition-kenttä sisältää tiedon painoksesta. Tässä tiedonhakija törmää luettelointikäytäntöjen kirjavuuteen, sillä kenttään tallennttua tietoa ei parhaalla tahdollakaan voi kutsua kovin määrämuotoiseksi. Ovelasti hakuavaimen katkaisemalla ja sumealla haulla nämä epäsäännöllisyydet voinee kuitenkin kiertää. Haetaanpa kokeilut vuoksi kaikki Deluxe Edition CD-levyt:

edition:"deluxe edition" AND mediaclass:cd

Number-kenttä sisältää ISBN-numeron. Tästä ei liene kovin kummoista iloa kirjastonkäyttäjälle. Toisaalta ISBN:n avulla saisi rakennetuta työkalun, joka osaisi esim verkkokirjakaupan sivulta löytyvän ISBN:n perusteella tarkastaa kirjastosta, löytyykö ko. teosta lainattavaksi. Esimerkkihaku:

number:9789525635072

Note-kenttään tallennettu tieto pelastaa musiikkitiedonhakijan! Aikojen saatossa musiikinluetteloinnissa pakollisten teostietojen oheen on tallennettu tietoja äänityspaikasta, esiintyjistä ja muista äänitteen yksityiskohdista. Tämä tieto on haettavissa note-kentän kautta. Kokeillaanpa hakea äänitteet, jotka on tallennettu vuonna 1970:

note:"äänitetty 1970"~2

Aaltomerkillä ja numerolla hakulauseen lopussa kerron järjestelmälle, että äänitetty ja 1970 -merkkijonot tulee esiintyä kahden sanan päästä toisistaan, jotta esiintymä lasketaan haussa osumaksi. Entä löytyykö kirjastosta sellaisia CD-levyjä, joissa olisi kansilehdykässä mukana sointumerkit? Katsotaan:

note:"sointumerkit"~0.3 AND mediaclass:cd

Entäpä löytyykö kirjastosta levyjä, joista harmonikkataiteilija Pohjonen olisi taustabändin jäsenenä -- näin postauksen otsikon mukaisesti:

note:"Kimmo Pohjonen acc"~3

Huomautuksia-kentän sisältö on sen verran pitkälle määrämittaista, että sen rakenteistaminen kohdennetusti haettavaan muotoon ei olisi kovin kummoinen juttu. Tästä olisi erityisesti musiikkitiedonhaussa hyötyä, kun haku voitaisiin kohdistaa esim. artistin rooliin kyseisellä tallenteella.

Titleoriginal-kenttä sisältää teoksen alkuperäisnimen. Katsotaanpa, kuinka monelle kielelle käännettynä Waltarin Sinuhe löytyy PIKI-kirjastoista:

titleoriginal:"sinuhe egyptiläinen"

Näemmä kotikirjastostani löytyy ainakin seitsemän Sinuhen kieliversiota

Titlemain-kentän sisällöstä en ole päässyt vielä aivan varmuuteen. Alkujaan ajattelin, että kyseessä olisi jonkun sortin yhtenäistetty nimeke (l. yhteisesti sovittu nimi sellaiselle teokselle, jonka nimestä esiintyy useita erilaisia kirjoitusasuja) mutta tulosten perusteella kenttä tuntuu liittyvän myös muihin käyttötilanteisiin.

Kartta kirjastosta

Macen tammikuisen postauksen innoittamana sain viimeinkin piirreltyä ensimmäiset Helmet-kirjastojen kokoelmaa kuvaavat tilastografiikat. Aloitin grafiikkojen takana olevan aineiston pyörittelyn jo kesäkuun helteiden aikaan, Helmet-kirjastojen julkaistua kokoelmatietokantansa avoimena datana. Proggis kuitenkin jäi telakalle, josta sen nyt viikonloppuna herätin henkiin virkistääkseni R-taitoja gradutaistoa varten.

Grafiikat ovat syntyneet Helmet MARCXML-aineistodumpista, joka on ajettu aluksi MODS-muotoon XSLT-muunnostiedostolla. Sen jälkeen tiedot muutettiin CSV-taulukkomuotoon toisella XSLT-muunnoksella. Ensimmäisen muunnosvaiheen olisi voinut hyvin jättää väliin, ja ajaa tiedot taulukoksi suoraan MARCXML-muodossa. Koin kuitenkin selväkielisen MODS-tiedostomuodon käsittelyn helpommaksi, siihen nähden että olisin MARCXML:ää pyöritellessäni joutunut miettimään, mikä kenttäkoodi vastaa mitäkin metatietoa.

Siivoilin muunnostiedostojen avulla syntynyttä CSV-taulukkotiedostoa pienillä Python-koodinpätkillä ja latasin tämän jälkeen tiedoston R-tilasto-ohjelmaan. Ärrässä mankeloin tiedot tarvitsemaani muotoon ja lopulta tuotin grafiikat R:n treemap-kirjaston avulla. Kaikki edellä mainitut ohjelmat ja työkalut ovat vapaata koodia.

Pidemmittä puheitta -- kokoelmagrafiikoita, olkaa hyvä. Pikkukuvaa klikkaamalla grafiiikan saa suurennettua. Mikäli grafiikkojen muoto on outo, Wikipedia-selvittää mistä on kyse (Treemapping-artikkeli).