Tulevaa DSpace-rintamalta (OR2009 9/10)

Open Repositories -konferenssissa kuultiin uutisia mm. uusista, tulossa olevista DSpace-versioista, joista etenkin alkuvuodesta 2010 lupailtu DSpace 2.0 tuo mukanaan perustavanlaatuisia  muutoksia koko ohjelmiston rakenteeseen ja toimintaan.

DSpace-koodin versionhallinta on hiljattain siirretty Sourceforgesta Oregonin yliopiston Open Source Labiin (OSL). OSL tarjoaa mm. hienorakenteisemman pääsynhallinnan koodiin, mikä helpottaa tiimityöskentelyä. Priorisointi- ja tracker-työkalu Jiraa ollaan ottamassa käyttöön. Sen avulla on jatkossa tarkoitus hallinnoida bugi-raportointia, priorisointia ja uusien ominaisuuksien toivelistaa. Toivelistan prioriteeteistä voidaan järjestää äänestyksiä. Näin käyttäjät saavat enemmän mahdollisuuksia osallistua ja vaikuttaa kehityksen suuntaan.

DSpace 1.6

1.6-versiossa tietokantamalli ja ohjelmistoarkkitehtuuri pysyvät entisellään. Syksyllä ilmestyvässä versiossa on bugi-korjauksien lisäksi paremmat statistiikat, joiden yksityiskohtia ei oltu vielä täysin lyöty lukkoon konferenssin aikoihin. Embargo-ominaisuus ja batch edit ovat muut merkittävimmät uutuudet. Batch edit mahdollistaa usean tietueen kuvailutietojen muokkaamisen yhdellä kertaa. 1.6:ta pidetään astinlautana 2.0 versioon. Google Summer of Coden diplomiharjoittelijat saattavat myös tuoda 1.6:een muutakin mielenkiintoista, esim. paremman kokoelmanhallinnoinnin.

DSpace 2.0

DSpace-kehittäjät ovat hyvin tietoisia nykyisen alustan rajoituksista. DSpace ei ole ollut niin modulaarinen kuin esimerkiksi Fedora. Tämä johtuu mm. siitä että ohjelmaa ei alun perin suunniteltu näin laajaan käyttöön vaan pikemminkin MIT:n omaan käyttöön. Toisaalta DSpace on profiloitunut out-of-the-box-tuotteeksi, joka tekee siitä helposti monoliittisemman kokonaisuuden. Lisäksi vapaaehtoisten koodarien patchit ovat vaikeuttaneet ajan myötä kokonaisuuden hallintaa. Tästä huolimatta DSpacessa on jo ollut paljon modulaarisuutta tukevia tekniikoita, kuten plugin manager, Maven ja Manakin. Ei kuitenkaan riittävästi, ja versio 2.0:ssa arkkitehtuuri ja tietokantamalli onkin suunniteltu alusta alkaen uusiksi.

Tietomalli

Eräs DSpacen heikkous on ollut sisällön organisoinnin kankeus: tieto on järjestetty yhteisöihin, niiden alla oleviin kokoelmiin ja lopulta kokoelmissa oleviin tietueisiin. Uudessa tietomallissa tällainen hierarkia ei ole rajoitteena. Kaikki julkaisuarkiston tieto mallinnetaan entiteetteinä ja niiden välisinä relaatioina, kuten ispartof, haspart, hasfile, isformat yms. Entiteetit voivat esittää mm. julkaisusarjoja, vuosikertoja, vuosikertojen osia, kirjoja, tekijöitä, tiedostoja, metadataskeemoja yms. Näin todellista tarvetta tiedon järjestämiseen voidaan tukea paremmin: Artikkelien, kirjojen museo-objektien yms. tarvitsemat tietorakenteet voidaan mallintaa niitä varten tehdyillä entiteeteillä.

Tekijät esitetään vanhassa DSpacessa vain tietueen, esim. artikkelin kentässä esiintyvänä tekstinä. Saman henkilön nimi kirjoitetaan kenttään helposti monella eri tavalla ja tämä näkyy sitten tekijälistauksessa erillisinä niminä/tekijöinä. Tekijöiden ollessa entiteettejä uniikkius on turvattu kun henkilöä kuvaava entiteetti liitetään työhön. Myös henkilön nimen tai muiden tietojen päivitys helpottuu, kun riittää, että se tehdään vain yhteen paikkaan. Vanhassa tietomallissa nimen päivitys piti tehdä jokaiseen tietueeseen, jossa ko. henkilö mainittiin.

Myös tiedostojen järjestämisessä hyödynnetään uutta tietomallia, filedescriptor-entiteetti kertoo tietoja tiedostosta ja sen suhteista. Näin ollen tiedosto voidaan kuvata huomattavasti aikaisempaa tarkemmin: Esimerkiksi kuvatiedoston filedescriptoriin voidaan lisätä relaatiot esikatselukuvaan, tiedoston käyttötilastoihin, tekijäoikeudet omistavaan henkilöön X, sekä sen digitaaliseksi skannanneeseen organisaatioon Y.

Arkkitehtuuri

Uuden arkkitehtuurin tarkoituksena on tarjota kehittäjille helppo tapa liittää omia moduuleja DSpacen yhteyteen ja helpottaa kustomointia ja konfigurointia. Arkkitehtuuri pohjautuu palvelumanagerin käyttöön, jonka vastuulla on palveluiden hallinta ja jakelu. Yksi palvelu hoitaa tietyn kokonaisuuden ohjelman toiminnasta, kuten autentikoinnin, tallentamisen, välimuistin hallinnan tai vaikkapa jonkin näiden toimintojen alitoiminnon. Esimerkiksi tallennuspalvelu voidaan toteuttaa palvelulla, joka tallentaa julkaisuarkiston tiedot paikalliselle levylle tai vaihtoehtoisesti DuraCloudiin. Locator-palvelu puolestaan hallitsee yksilöivät tunnisteet ja tämäkin palvelu voidaan toteuttaa eri tavalla riippuen siitä, mitä tunnistejärjestelmää käytetään.

Kehittäjät voivat lisätä omia palveluitaan palvelumanagerin avulla, esimerkiksi korvaamalla vanhan autentikointipalvelun uudella tai lisäämällä kokonaan uusi toiminnallisuuden. Palvelu rekisteröidään palvelupooliin (tämä voi tapahtua lennossa, käynnistämättä arkistosovellusta uudelleen). Jos joku moduuli sitten tarvitsee tiettyä palvelua, palvelumanageri tarjoaa oikean ja ajantasaisen palvelun oikeaan osoitteeseen. Uuden palvelun toteuttajalla ei tarvitse välttämättä olla tietoa DSpacen toiminnan yksityiskohdista, riittää että palvelun sisäinen toiminta on kunnossa ja tekee sen mitä lupaa. Arkkitehtuurin joustavuuden maksimoimiseksi palvelumanageri on abstraktoitu, eli se voidaan toteuttaa monella tavalla.

Uusien palveluiden toteuttamista helpottaa myös tapahtumamekanismi, jonka avulla voidaan laukaista tietty toiminto, kun DSpacessa tietyt ehdot täyttyvät. Tästä esimerkkinä vaikkapa varmistuspalvelun käynnistys aina silloin, kun uusi työ on syötetty arkistoon.

Muuta

Mavenia käytetään jatkossakin DSpacen asennuksen ja koodikirjastojen hallintatyökaluna. Mavenin avulla voi pitää myös hallinnassa paremmin omia DSpace-koodiin tehtyjä muutoksia siten, että päivittäminen onnistuu jatkossakin ja oma koodi pysyy selkeästi erillään peruskoodista.

Manakin ja JSP-käyttöliittymä jatkavat rinnakkaiseloa, molemmilla käyttöliittymillä on vakaa käyttäjäkuntansa. Olisi toisaalta ollut hyvä saada vain yksi käyttöliittymä asioiden yksinkertaistamiseksi. DSpacen eräs varjopuoli on ollut se, että jotkin patchit ovat olleet vain toiselle käyttöliittymälle sopivia. Toivoa sopii, että kahden käyttöliittymän rinnakkaiselon jatkumisesta ei aiheudu turhaa haarautumista kahden käyttäjäkunnan välillä.

DSpace 2.0:aa luvataan varovasti alkuvuodesta 2010. Kehitysversiosta pitäisi tulla julkaisu jo kesän aikana. Useaan otteeseen eri esityksissä painotettiin kuitenkin, että tarkemmat ominaisuudet ovat liikkuva kohde ja monia valintoja vielä harkitaan. Varmaa on kuitenkin se, että DSpace tulee muuttumaan huomattavasti seuraavan vuoden aikana. Toivon mukaan uusi uljas DSpace ei hajoa nokkeluuteensa ja teknisiin hienouksiinsa, vaan pystyisi selviytymään mahdollisimman vähillä kasvukivuilla. Yhteisössä on paljon odotuksia ja vaatimuksia uudelle järjestelmälle, tulevaisuus näyttää miten käy. Ainakin kehittäjät ovat pätevää ja innokasta väkeä. DSpace 2.0:sta on saatavilla demo osoitteessa http://atmire.com/dspace2.