Loma-ajan rauhan ollessa syvimmillään reippaat skriptilapsoset jostain päin maailmaa tekivät minulle palveluksen ja saivat blogiani pyörittäneen Wordpress-julkaisutyökalun pahasti solmuun. Päivittämättä jäänyt lisäosa teki asennuksesta haavoittuvan, vaikka Wordpress itsessään olikin kaikin tavoin kunnossa ja päivitetty. Jälkiä siivotessani tulin tulokseen, että nyt voisin vastaisen varalta palata ajassa taaksepäin, hylätä julkaisujärjestelmät ja pystyttää sivustoni toimimaan ilman palvelinpuolella ajettavaa koodia.

Muistin lukeneeni pari vuotta sitten Hiking in Finland -blogista Octopress-julkaisujärjestelmästä, haeskelin postauksen esille ja ryhdyin perehtymään aiheeseen. Muutaman mutkan kautta päädyin lueskelemaan Octopressin kaltaisten julkaisutyökalujen vertailua. Toisin kuin julkaisujärjestelmät yleensä, nämä työkalut eivät vaadi palvelimelta tietokantaa, PHP:n tai minkään muunkaan ohjelmointikielen tukea ja niiden laitteistovaatimukset ovat minimaaliset. Julkaisutyökalua käytetään omalta koneelta ja tuloksena syntyvät staattiset HTML-sivut siirretään palvelimelle julkaistavaksi.

Vertailtuani eri vaihtoehtoja suhteessa Octopressiin päädyin valitsemaan Docpad-julkaisutyökalun. Rubyn ja Railsin tuntevalle Octopress olisi ollut oiva valinta mutta nollapisteestä lähtiessäni Docpadin Javascriptiin (NodeJS) perustuva toteutus tuntui kiinnostavammalta perehtyä -- Javascriptiä kun ei nykyään juuri voi välttää, teki mitä tahansa kehitystyötä.

Sivuston uudelleenpystyttämisessä suurin vaiva oli vanhojen sisältöjen siirtämisessä. Onneksi skriptilapsoset eivät olleet tyhjentäneet tietokantaa, joten sain ladattua menneiden vuosien kirjoitukset talteen wp2octopress-skriptillä. Skriptin tuottamaa tulosta joutui paikoitellen muokkaamaan aika lailla, mutta suurin osa kirjoituksista oli suoraan siirrettävissä. Hyökkäyksen seurauksena Wordpressin tiedostonsiirtotoiminnallisuuden avulla siirretyt kuvat olivat tipotiessään, mutta ne sai onneksi ongittua talteen Internet Archiven Wayback Machinen avulla. Kommentit saivat uuden kodin Disqus-kommentointipalvelusta ja siirto sujui täysin Disqusin omien ohjeiden mukaisesti.

Alkuunpääsyä helpottaakseni en ryhtynyt pystyttämään Docpadia alusta alkaen itse, vaan käytin pohjana Erv Walterin Githubissa julkaisemaa blogikäyttöön viritettyä kokoonpanoa. Jahka kesä kääntyy syksyä kohti, lie systemaattisemman NodeJS-tutkiskelun aika.

Valtion taidemuseo, vuoden 2014 alusta alkaen Kansallisgalleria, julkaisi lokakuun alussa kokoelmiensa metatiedot avoimena datana. Sen lisäksi, että CC0-lisensoitua kokoelmadataa voi käsitellä erittäin hyvin dokumentoidun rajapinnan kautta, metatiedot voi ladata pakettina datan paikallista käsittelyä varten. Nyt joulun jouteliaina välipäivinä latailin datapaketin koneelleni ja päätin katsoa, miltä data näyttää BaseX XML-tietokantaohjelman kautta tarkasteltuna.

Kuten kirjastoaineistoja, myös taideteoksia kuvaillaan kontrolloitujen asianasastojen avulla -- onpa tämä oma tutkimusalansakin, ikonografia. Pintapuolisen datasetin läpikäynnin perusteella näytti, ettei lähellekkään kaikkia kokoelmien teoksia ole kuvailtu asiasanoin. Kuvailtuja teoksia on datasetissä kuitenkin niin paljon, että kokoelmista voisi saada luotua suht. paikkansapitävän yleiskuvan visualisoimalla käytetyt asiasanat verkostona, kuten olen tehnyt aikaisemmin kirjastoaineistojen tapauksessa.

Mielenkiintoisen eron kirjastoaineistojen kuvailutietoihin tekee taideteosten kuvailussa käytetty Iconclass-luokitusjärjestelmä. Iconclassin asiananat muodostuvat kirjain- ja numerosarjoista sekä selväkielisestä määritteestä, joka täsmentää numero-kirjainsarjan koodaamaa kuvailutermiä. Koska teokset kuvaillaan kieliriippumattomilla koodeilla, kuvailut ovat ymmärrettävissä vaikka kuvailutyötä tehnyt henkilö ja taideteosten metatietojen selailija eivät jakaisikaan yhteistä kieltä. Käytännössä siis, sen sijaan että jouluista aihetta kuvaava teos kuvailtaisiin suomalaisessa taidemuseossa asiasanalla 'joulu', kuvailuterminä voidaan käyttää Iconclass-koodia 11Q7612. Voidaan siis ajatella, että Iconclass-koodit ovat eräänlaisia linkkejä taideteoksista luokitusjärjestelmään -- ihanteellinen linkitetyn datan sovelluskohde siis.

Tähän ilmiselvään sovelluskohteeseen on myös tartuttu ja Iconclass on julkaistu koneluettavassa muodossa. Edellinen 11Q7612-kuvailutermi voidaan ilmaista linkkinä http://iconclass.org/11Q7612.json, jonka kautta selviää Iconclass-koodin selväkielinen merkitys useilla eri kielillä -- suomi mukaanlukien --sekä koodin sijainti kuvailutermien hierarkiassa. Koska koodien selväkielisiin ilmauksiin pääsee käsiksi helposti muodostettavien URL-osoitteiden kautta, on suhteellisen helppoa kirjoittaa XQuery-skripti, joka käy läpi kunkin taideteoksen kuvailutiedot, lataa verkosta kuvailukoodien selväkieliset ilmaukset ja muotoilee tiedot siten, että ne voidaan esittää verkostona Gephi-visualisointiohjelman avulla.

Iconclass-kuvaillut teokset Kiasman kokoelmissa.

(Lataa tarkkaresoluutioinen kuva.)

Pääasiassa Kiasman kokoelmiin kuuluvien Iconclass-kuvailtujen teosten lisäksi päätin ottaa käsittelyyn selväkielisillä asiasanoilla kuvailtujen teosten metatiedot. Suurin osa näistä teoksista kuuluu Ateneumin kokoelmiin.

(Lataa tarkkaresoluutioinen kuva.)

YLE Kirjasto -tietopalvelu on kaikessa hiljaisuudessa julkaissut artikkeliviitetietokantansa sisällön avoimena datana. Tietokanta sisältää yli 65500 viitettä pääasiassa kotimaisista aikakauslehdistä. Latasin Excel-muodossa olevan datasetin ja uteliaisuuttani vilkaisin, mitä tietoja artikkeleista on tallennettu tietokantaan. Huomasin, että viitetietokannan Asiasanat-kenttään on tallennettu runsaasti henkilöiden nimiä; oletettavasti niiden henkilöiden, joita artikkeli on käsitellyt. Tästä sain ajatuksen tutkailla tietokannan avulla, miltä suomalainen mediatodellisuus näyttää aikakauslehtiartikkeileiden viitteiden valossa. Keistä koostuu se henkilökaarti, joka nauttii toimittajien suosiosta vuodesta toiseen?

Ensitöikseni muunsin aineiston Excel-muodosta standardiin CSV-taulukkomuotoon ja latasin tiedon BaseX XML-tietokantaan. BaseX osaa ladata suoraan CSV-muotoisia tiedostoja.

Artikkiliviitteiden asiasanat on tallennettu puolipistein erotettuna yhteen kenttään suuraakkosin kirjoitettuna. Saadakseni poimittua muiden metatietojen joukosta henkilönimet, minun tuli kirjoitella XQuery-skripti joka erottaa henkilönimet ja muuntaa nimet noudattamaan normaaleja oikeinkirjoitussääntöjä. Alla oleva skripti on toteutukseltaan karkea, sillä se tunnistaa henkilönimet asiasanan sisältämän välilyönnin perusteella. Tämän seurauksena mukaan tulee myös muita kaksiosaisia asiasanoja. Tämä ei kuitenkaan haittaa tietokannan sisällön käsittelyä, sillä virheelliset tiedot voi seuloa pois myöhemmässä vaiheessa.

import module namespace functx = "http://www.functx.com"; 
for $record in //record
let $subjects:= tokenize(fn:normalize-space($record/Asiasanat), '; ')
for $subject in $subjects
    let $fullname_reversed:=$subject[contains(., ' ')]
    let $fullname_tokenized:=tokenize(lower-case($fullname_reversed), ' ')
    let $name:= <name>{string-join((functx:capitalize-first($fullname_tokenized[2]),functx:capitalize-first($fullname_tokenized[1])), ' ')}</name>
    let $to_print:= 
    if(string-length($name)>3)
    then <name>{data($name)}</name>
    else ()
return if (not(empty($to_print))) then
insert node $to_print into $record/persons
else()

Skripti täydentää artikkeliviitetietokannan sisältöä persons-kenttään tallennettavilla henkilötiedoilla. Seuraavaksi nämä tiedot tulee ryhmitellä henkilöiden mukaisesti, siten että kunkin henkilön alle kootaan tiedot vuosista, joina kyseinen henkilö on mainittu artikkeliviitessä.

<mentions_in_press>{
for $record in //record
for $person in $record/persons/name

group by $person
return <press_mention><fullname>{$person}</fullname><year>{$record/Vuosi}</year></press_mention>
}</mentions_in_press>

Tämän työvaiheen jälkeen tiedot tulee koostaa vielä kerran, siten että toistuvat vuosiluvut poistetaan ja korvataan kunkin vuosiluvun kohtaan tallennettavalla toistuvuustiedolla.

<press_mentions_in_year>{
for $press_mention in //press_mention
let $years:=distinct-values($press_mention/year/Vuosi)
let $counts:= for $year in $years
              let $count:=count($press_mention/year/Vuosi[.=data($year)])
              order by $year
              return <year count='{$count}'>{$year}</year>
return <press_mention_per_year>
          <name>{$press_mention/fullname}</name>{
          for $count in $counts
            return $count
      }</press_mention_per_year>
    }</press_mentions_in_year>

Viimein kasassa on XML-tietokanta, josta voidaan tehdä suhteellisen helposti erilaisia henkilöihin liittyviä kyselyitä. Tietokannan sisältö siivottuna noin 5000 rivin tienoille muista kuin henkilötiedoista löytyy Githubista. Ajattelin, että tämä saattaisi olla jollekulle mielenkiintoinen XQuery-harjoitteluaineisto :) Myös skriptit löytyvät samasta paikasta.

On oletettavaa, että henkilömainintojen useus riippuu siitä, minkä tyyppisistä lehdistä lehtitietokannan viitteet ovat peräisin. Seuraavista lehdistä tietokanta sisältää yli tuhat viitettä:

Mutta nyt asiaan, henkilömainintoihin.

Eniten mainintoja vuodessa on prinsessa Dianalla, 47 kappaletta vuonna 1997.

Eniten vuosittaisia mainintoja lehtien palstalla on Katri Helenalla. Hänet on mainittu kaikkiaan 37 vuoden aikana. Katri Helenalla mainintoja on eniten vuonna 1993, 13 kappaletta.

Kahdeksan henkilöä ovat paistatelleet vähintään 30 vuotena lehtien palstoilla:

Kun tarkastellaan vähintään 25 eri vuotena mainittuja henkilöitä -- poislukien edellä mainitut kahdeksan henkilöä -- joukko on jo selvästi suurempi. Ensimmäisen maininnan mukaisessa järjestyksessä:

Otetaan lopuksi vielä tarkasteluun ikuisen mäkikotkan, kaimani Matin seikkailut julkisuudessa. Lehtiartikkelimainintojen mukaan järjestestettynä Matin vilkkaimmat vuodet ovat olleet:

Nyt kun artikkeliviitetietokanta on XML-muodossa, täytynee ottaa se myös uudemman kerran tarkasteluun. Tämän kokemuksen perusteella tietokannasta saa yllättävän vähällä vaivalla irti yksityiskohtia, jotka ovat tavallisesti kätkeytyneetä tietokannan kokonaisuuteen.

Otin asiakseni tutkia, mitä kirjastoissa vuosikymmeniä eri muodoissa käytetyn MARC-metadataformaatin kenttiä hyödynnetään pääkaupunkiseudun Helmet-tietokannassa. Alkujaan tarkoituksenani oli seuloa MarcXimiL-työkalun avulla tietokannasta esiin siitä todennäköisesti löytyvät duplikaattitietueet. Ohjelman osoittauduttua tuskaisen hitaaksi ja hieman bugiseksi, päätin jättää asian sikseen ja julkaista duplikaattivertailua varten laatimani kenttäyhteenvedon nyt, ja toteuttaa duplikaattivertailun XQueryn avulla joskus myöhemmin, jollei joku muu ratkaise pulmaa minua ennen.

Kenttäyhteenvedon pohjana käytin MarcXimil-työkalun mukana tulleen colldescr -skriptin tulostetta. Oletusarvoisesti colldescr tulostaa kenttien käytöstä prosenttijakaumat sekä kenttien pituuksien keskiarvot. Muokkasin skriptiä niin, että se tulosteeseen saadaan kenttien absoluuttiset määrät sekä pituuksien mediaanit. Muunnetun skriptin voi ladata käyttöön Gist-palvelusta. Ajoin colldescr-skriptin jokaisen Helmet-datadumpin 68 MARCXML-tiedoston kohdalla, joista kukin sisälsi keskimäärin 10000 MARC-tietuetta. Helmet-tietokannan nykyisessä datadumpissa on kaikkiaan 672206 tietuetta (versio 1.1 / 20.5.2011).

Luonnollisestikaan skriptiä ei kannattanut ajaa käsipelillä, vaan kutsuin sitä BASH-komentotulkkiskriptin kautta. Oheisessa komentotulkkiskriptissä viitattu files_to_process.tmp sisältää listan kaikista 68 MARCXML-tiedostosta:

#!/bin/bash

while read line; do
echo $line
python misc/colldescr.py $line > $line.csv
done < files_to_process.tmp%

Skriptin suoritettuani minulla oli 68 kappaletta CSV-muotoisia tiedostoja, joista kukin sisälsi ennen taulukkosarakkeita muutaman rivin skriptin ajonaikaisia viestejä. Nämä täytyi saada poistettua tiedostoista ennen tiedostojen jatkokäsittelyä. Maltoin kuitenkin mieleni ryhtyä poistamaan rivejä käsin ja tutkin hieman R-tilasto-ohjelman dokumentaatiota - olin joka tapauksessa päättänyt laskea yhteenvedon R:ssä, joten jos mahdollista, myös taulukot kannattaisi siivota samaa työkalua käyttäen. Kuinka ollakaan, R:n taulukkolukija osaa jättää pois tiedostojen alusta halutun määrän rivejä ja onnekseni ajonaikaisten viestien määrä tiedostoissa oli vakio. Seuraava R-skripti lataa CSV-muotoiset tiedostot sekä yhdistää taulukkojen arvot yhteisten avainten (l. kenttätunnisteiden) perusteella.

require(plyr)
require(reshape)
csv_files = list.files(
  path="/Users/matti/Documents/2012/HelmetMARCUsage/csv",
  pattern = '*.csv',
  all.files = TRUE, 
  full.names = TRUE)

csv_file_list = lapply(
  csv_files, 
  function(x){
    read.csv(
      file = x,
      skip = 13,
      sep = '\t',
      col.names = c('field', 'count', 'length')
      )})

merged_csv <- merge_all(csv_file_list)

marc_field_usage<-ddply(
  merged_csv,
  c("field"),
  summarise, 
  count = sum(count),
  length = median(length)
  )

Luotu marc_field_usage -muuttuja sisältää kaikkien Helmet-tietokannassa käytettyjen MARC-kenttien ja osakenttien lukumäärät sekä näiden pituuksien mediaanit. Alla olevaan taulukkoon olen ottanut 96 useimmin käytettyä kenttää, sekä liittänyt näiden yhteyteen kenttäkuvaukset Helmet-luettelointiohjeesta.

Vaski-kirjastot julkaisivat luettelotietokantansa avoimena datana menneen viikon perjantaina - oiva tilaisuus testata, selviääkö vastikään lisämuistilla terästetty (2GB->8GB) työjuhtani koko ~1.7 miljoonan tietueen datasetin pyörittelystä kerrallaan.

Kohteekseni otin FINMARC-luettelointioppaasta bongaamani 600 Kohdehenkilö-kentän, jonka määritys kuuluu: "Kenttään tallennettavat tiedot kohdehenkilöstä liittyvät teoksen sisältöön. Henkilön nimi on asiasanana.". Oppaasta mainittiin myös, että kenttään saatetaan tallentaa myös teoksen kohteena olevan suvun tjms. tietoja -- mielenkiintoista! Päätin katsoa, millaisia verkostoja tähän kenttään tallennettujen henkilöiden ja henkilöjoukkojen välille muodostuu. Nyt alkuvaiheessa tarkoituksenani ei ollut tehdä näistä verkostoista sen kummempia analyysejä, kunhan saisin datan sopivaan muotoon myöhempiä analyysejä varten ja pari nättiä kuvaa tänne verkkoon näytille :)

Harjoituksen vuoksi noudatin tavanomaisesta poikkeavaa työkulkua. Tällä kertaa pidin käsittelemäni tiedot alusta loppuun XML-muodossa. Lähtöpäässä oleva tieto näytti tältä:

<record xmlns="info:lc/xmlns/marcxchange-v1">
  <datafield tag="600" ind1="1" ind2=" ">
    <subfield code="a">Lehtonen</subfield>
    <subfield code="h">J. V.</subfield>
    <subfield code="x">juhlajulkaisu</subfield>
  </datafield>
  <datafield tag="600" ind1="1" ind2=" ">
    <subfield code="a">Sillanpää</subfield>
    <subfield code="h">F. E.</subfield>
    <subfield code="t">Nuorena nukkunut</subfield>
  </datafield>
  <datafield tag="600" ind1="1" ind2=" ">
    <subfield code="a">Lassila</subfield>
    <subfield code="h">Maiju</subfield>
    <subfield code="x">kirjallinen jäämistö</subfield>
  </datafield>
  <datafield tag="600" ind1="1" ind2=" ">
    <subfield code="a">Kivi</subfield>
    <subfield code="h">Aleksis</subfield>
    <subfield code="t">Canzio</subfield>
  </datafield>
  <datafield tag="600" ind1="1" ind2=" ">
    <subfield code="a">Richelieu</subfield>
    <subfield code="h">Armand Jean du Plessis de</subfield>
  </datafield>
</record>

..ja putken päästä, XQueryn avulla tehdyn mankeloinnin jälkeen ulos tuli tällaista, Gephi-visualisointityökalun ymmärtämää GEXF-muotoista XML:ää .

<?xml version="1.0" encoding="UTF-8"?>
<gexf xmlns="http://www.gexf.net/1.1draft" version="1.1" xmlns:viz="http://www.gexf.net/1.1draft/viz" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.gexf.net/1.1draft http://www.gexf.net/1.1draft/gexf.xsd">
  <meta lastmodifieddate="2011-10-02">
    <creator>Matti Lassila</creator>
    <description>Co-occurencies of names in Vaski-database</description>
  </meta>
  <graph defaultedgetype="mixed" mode="static">
  <attributes class="node">
      <attribute id="role" title="role" type="string"/>
  </attributes>
        <nodes>
            <node id="aleksis_kivi" label="Aleksis Kivi">
                <attvalues>
                    <attvalue for="role" value="person"/>
                </attvalues>
                <viz:size xmlns:viz="http://www.gexf.net/1.1draft/viz" value="232"/>
            </node>
            <node id="maria_jotuni" label="Maria Jotuni">
                <attvalues>
                    <attvalue for="role" value="person"/>
                </attvalues>
                <viz:size xmlns:viz="http://www.gexf.net/1.1draft/viz" value="44"/>
            </node>
            <node id="anakreon" label="Anakreon">
                <attvalues>
                    <attvalue for="role" value="person"/>
                </attvalues>
                <viz:size xmlns:viz="http://www.gexf.net/1.1draft/viz" value="3"/>
            </node>
        </nodes>
        <edges>
            <edge source="minna_canth" target="aleksis_kivi"/>
            <edge source="minna_canth" target="juhani_aho"/>
            <edge source="minna_canth" target="teuvo_pakkala"/>
            <edge source="minna_canth" target="ilmari_kianto"/>
        </edges>
  </graph>
</gexf>

En vielä nykyisillä XQuery-taidoillani saanut tehtyä muunnosta yhdellä loitsulla, vaan suodattelin ja yhdistelin datasettiä aina pienempiin ja pienempiin osiin. Loppuvaiheen koostamisen ennen Gephiin siirtymistä tein editorissa, eli laitoin yhteen tiedostoon mukaan erikseen luomani henkilö-solmut ja toisessa tiedostossa olevat henkilö-solmujen väliset yhteydet.

Nyt kun datasetti on oikeassa muodossa ja siistitty, työläin työvaihe on takanapäin. Jahka aikaa on, tutkiskelen mitä datasetistä saa irti. Samalla koitan kirjoittaa lyhyesti auki, mitä työvaiheita MARCXML-muotoisten FINMARC-tietueiden mankelointi Gephin ymmärtämään muotoon vaati.