fi fi de en fi fi en eo pt fi it fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi gom ru en ru fi fi fi fi nb fi fi fi fi fi fi fi fi fi fi fi fi fi it fi fi fi fi fi fi fi fi fi fi fi en fi fi fi fi fi fi fi fi fi et fi fi fi fi fi fi lt fi fi fi fi fi fi fi fi fi fi fi fi tr fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi fi lt fi fi fi fi fi fi th en fi fi fi zh it fi fi fi fi fi fi fi fi it fi zh it fi fi ceb fi fi fi fi fi lt fi fi fi it th fi fi fi zh it en it th fi zh it en it th fi zh it en it th fi zh it fi it et zh it fi fi fi it
= Koha-kirjastojärjestelmän testaus Jyväskylän yliopiston kirjastossa
Matti Lassila  ; Hannu Markkanen; Veli-Matti Häkkinen
:last-update-label: Lisenssi: Creative Commons Nimeä-JaaSamoin 4.0 Kansainvälinen. Päivitetty:
Suomalaisten korkeakoulukirjastojen käyttämä Voyager-kirjastojärjestelmä alkaa olla elinkaarensa päässä. Teknisiltä ratkaisuiltaan monin paikoin vanhentunut järjestelmä on toistaiseksi toiminut luotettavasti siitä huolimatta, että yhä useampi korkeakoulukirjasto on siirtynyt käyttämään asiakaskäyttöliittymänään Finnaa, joka kuormittaa kirjastojärjestelmää merkittävästi enemmän kuin aiemmin käytössä ollut WebVoyage-käyttöliittymä.
Keväällä 2015 Jyväskylän yliopiston kirjastossa päätettiin käynnistää Koha-kirjastojärjestelmän testausprojekti, jonka tarkoituksena oli selvittää kirjaston valmiutta siirtyä uuteen kirjastojärjestelmään asiakkaille tällä hetkellä tarjotut palvelut säilyttäen.
Projektin alussa tutustuimme Kohaan Vaara-kirjastojen käyttämän ohjelmistoversion avulla, mutta kirjaston oma testausprojekti toteutettiin Kohan virallisella kehitysversiolla footnote:[Testauksessa käytettiin Kohan versiota 3.19.00.026] huomioimatta Vaara-kirjastoissa tehtyjä muutoksia.
1. Miltä osin kirjasto kykenee itse suoriutumaan järjestelmävaihdoksesta ilman järjestelmätoimittajan tai muun ulkopuolisen tahon apua?
2. Miltä osin Koha täyttää asiakkaille tällä hetkellä tarjottujen palvelujen asettamat vaatimukset?
3. Mitä nykyisten Voyager-järjestelmäintegrointeja vastaavien integrointien toteuttaminen Kohaan vaatii; huomioiden erityisesti Finna ja Melinda?
Sen lisäksi, että tässä raportissa kuvataan testausprojektin aikana tehtyjä ratkaisuja, raporttiin on sisällytetty myös toteuttamatta jääneiden ratkaisuvaihtoehtojen hahmotelmia ja yleisiä Kohaan liittyviä huomioita.
Jyväskylän yliopiston kirjasto tulee siirtymään seuraavaan Voyager-kirjastojärjestelmän versioon yhdessä muiden suomalaisten korkeakoulukirjastojen kanssa vuoden 2016 aikana. Testausprojektin myötä kirjastolla on kuitenkin valmius siirtyä Kohaan vaihtoehtoisena järjestelmänä, mikäli Voyager-kirjastojärjestelmän tuki lakkaa tai eteen tulee teknisiä ongelmia tai palvelutarpeita, joita Voyagerin puitteissa ei voida ratkaista. Työnkulkuja kehittämällä ja joitain lisätoiminnallisuuksia hankkimalla Koha voi korvata Voyager-kirjastojärjestelmän.
Migraatiossa siirrettiin bibliografiset tietueet, nidetiedot, varaukset, lainaustilanne sekä anonymisoidut asiakastiedot. Sarjajulkaisujen tiedot siirrettiin vain osittain.
Vufind-integrointia varten olisi hyödyllistä, jos sarjajulkaisu-tietokantataulujen lisäksi varastotiedot löytyisivät myös MARC-tietueista standardinmukaisessa muodossa. Tästä syystä, sen lisäksi että, kattavuuskenttien perusteella muodostetaan Kohaan niteitä joiden fyysinen varastoyksikkö -- vuosikerta, vuosikerran osa, yksittäinen numero jne. -- vaihtelee julkaisusta riippuen, sarjajulkaisujen tietojen osalta voisi olla järkevää tutkia mahdollisuutta sisällyttää Voyagerin hankintamoduulin tuottamat MARC-kentät Kohaan tuotaviin tietueisiin sellaisenaan.
Testausprojektin aikana tutkittiin, miten nykyiset Voyager-integroinnit muihin järjestelmiin voidaan toteuttaa Koha-ympäristössä. Integrointeja ei toteutettu käytännössä, vaan ratkaisuvaihtoehtojen toimivuutta punnittiin järjestelmien dokumentaation ja lähdekoodiin tutustumisen perusteella.
Melindassa luetteloidut tietueet siirtyvät kirjastojen paikallisiin tietokantoihin Kansalliskirjastossa kehitettyjen replikointiskriptien avulla. Skriptit eivät ole järjestelmäriippumattomia, vaan ne on suunniteltu toimimaan nykyisessä Alehp (Melinda) - Voyager (paikallistietokanta) -ympäristössä. Kohaa varten replikointiskripteihin tulee tehdä muutoksia, jotka alustavan selvitystyön perusteella vaikuttaisivat olevan verrattain helppoja toteuttaa.
Paikalliskannan osalta replikointi perustuu nykyisellään Voyager-tietokannassa ajettaviin SQL-kyselyihin. Kohan tapauksessa SQL-kyselyt on kansallisbibliografiatunnuksella tapahtuvien hakujen osalta -- eli hakujen, jotka kohdistuvat paikallisen kannan `035`-kenttään -- välttämätöntä korvata Kohan hakurajapintoihin perustuvalla toteutuksella. Kohassa MARC-kenttien arvoja ei tallenneta haettavassa muodossa SQL-tietokantaan vaan erilliseen hakuindeksiin, joka nykyisessä julkaisuversiossa on http://www.indexdata.com/zebra[Zebra] ja lähitulevaisuudessa https://www.elastic.co/products/elasticsearch[Elastic Search].
Kohassa `035` kenttä ei ole Zebrassa, eikä tulevassa ElasticSearch-haussa oletusarvoisesti haettavissa, mutta on helposti määriteltävissä haettavaksi järjestelmäasetuksista. ElasticSearchin haettavissa olevat kentät tulevat olemaan määriteltävissä selainkäyttöliittymän kautta.
Mikäli Kohan käytössä on Zebra-hakumoottori, tietueen tarkistus voidaan toteuttaa Z39.50- tai SRU-haulla, kunhan kenttä on määritetty haettavaksi Zebran asetustiedostossa. Käytettäessä ElasticSearchia Z39.50 voidaan tarvittaessa ohittaa kokonaan. Paikallisen tietueen olemassaolon tarkistukseen liittyvät SQL-kyselyt voidaan korvata HTTP-pyynnöillä ElasticSeacrhin hakurajapintaan. HTTP-pyynnöt voivat olla esimerkiksi muotoa:
haettaessa Melindan tunnisteella `648704` olevaa tietuetta Kohasta silloin kun MARC-kenttä `035` on määritelty haettavaksi nimellä `other-control-number` hakuasetuksissa.
Paikallisen MARC-tietueen nouto voidaan toteuttaa joko Z39.50:n, SRU-haun tai OAI-PMH-rajapinnan kautta. Suunnitteilla on myös sisältöneuvotteluun (https://en.wikipedia.org/wiki/Content_negotiation[content negotiation]) perustuva mahdollisuus pyytää tietue aina kulloiseenkin käyttötarkoitukseen sopivassa muodossa kunkin tietueen yksilöivän URL-osoitteen kautta.
Paikallisen tietueen päivittäminen tehdään replikointiskriptin nykytoteutuksessa `Pbulkimport` -skriptillä, joka on Voyagerin komentorivityökalu tietueiden tuontia tai massamuutoksia varten. Kohassa ei ole vastaavaa, kaikki replikoinnissa tarvittavat toiminnot tarjoavaa työkalua, mutta toiminnot voidaan kuitenkin toteuttaa Kohan nykyisten komentorivityökalujen yhdistelmällä. Kohan https://github.com/Koha-Community/Koha/blob/3007208c70274a2bab326bc3ccf31bced32dab2b/misc/migration_tools/bulkmarcimport.pl#L615[`bulkmarcimport.pl`] -skriptiä voidaan hyödyntää replikoinnin lisäys- ja muutostoiminnoissa, kun taas tietueen poisto saadaan hoidettua https://github.com/Koha-Community/Koha/blob/3007208c70274a2bab326bc3ccf31bced32dab2b/misc/batchdeletebiblios.pl#L45[`batchdeletebiblio.pl`] -skriptillä. Pbulkimportin käyttämät Voyagerin
__Bulk Import Rules__ -muunnossäännöt saadaan Kohassa toteutettua joko `bulkmarcimportin` parametreillä tai laajentamalla `bulkmarcimportin` toiminnallisuutta Perl-alirutiineilla, joita kutsutaan kunkin tuotavan tiedoston kohdalla. Mahdollisuus laajentaa `bulkmarcimportin` toiminnallisuutta on sisäänrakennettu skriptiin, joten tarvittavat laajennokset saadaan toteutettua hallitusti.
Kohaa varten on saatavissa ajantasainen https://github.com/vufind-org/vufind/pull/486[Vufind-ajuri], joka on tarkoitettu Vufind 2.4 -versiolle. Ajuri on todennäköisesti muokattavissa yhteensopivaksi Finnan lähtökohtana olleen varhaisemman Vufind 2-version kanssa, mutta testausprojektin yhteydessä muutostyöhön ei kuitenkaan ryhdytty.
Ajurin toteutus perustuu Kohan https://renki.vaarakirjastot.fi/cgi-bin/koha/opac/ilsdi.pl[ILS-DI]-rajapintaan sekä nykyisen Voyager-ajurin tapaan suoriin SQL-kyselyihin Kohan tietokantaan. ILS-DI:n kautta toteutettavissa olevia toimintoja ovat muun muassa aineiston varaaminen, varauksen peruminen ja lainojen uusiminen.
ILS-DI on toteutukseltaan vanhanaikainen rajapinta -- sen http://code4lib.org/files/ils-di.pdf[pohjatyö] on tehty 2007 ja standardimäärittelyn http://old.diglib.org/architectures/ilsdi/DLF_ILS_Discovery_1.1.pdf[viimeisin versio] (1.1) on julkaistu vuonna 2008.
Kohaan ollaan toteuttamassa teknisesti ajanmukainen http://wiki.koha-community.org/wiki/New_REST_API_RFC[REST-tyyppinen rajapinta], joka tulee tarjoamaan nykyisen ILS-DI-rajapinnan tarjoamat toiminnot sekä muun muassa sarjajulkaisujen tietojen käsittelyyn liittyviä toiminnallisuuksia.
Aineistotietojen siirto Finnaan voidaan toteuttaa nykyiseen tapaan OAI-PMH-rajapinnan yli.
Kohan testaus jaettiin osiin kirjaston eri toiminnoista -- lainaus, hankinta, kokoelmat -- vastaavien toimistojen kesken. Näin pyrimme selvittämään miten Koha nykymuodossaan soveltuu toimistojen tämänhetkisiin toimintatapoihin ja mitä kehittämistarpeita nousee esiin, mikäli toimintatavat ja asiakkaille tarjotut palvelut halutaan säilyttää nykyisenlaisena myös järjestelmävaihdoksen jälkeen.
* Kausijulkaisujen ilmestymiskaavojen laatiminen saapumisvalvontaa varten on monimutkaista
* tilikarttaa yksinkertaistetaan uuteen kirjastojärjestelmään siirryttäessä
* tietojen tulisi siirtyä saumattomasti Kohan, LibNet-tilaushallintapalvelun ja tulevan ERM-järjestelmän välillä
* Kohan raportointityökaluun on luotavissa hankinnassa tarvittavia raportteja lomakekäyttöliittymän tai http://wiki.koha-community.org/wiki/SQL_Reports_Library[SQL-kyselyiden] avulla
* Nykyiselle Voyagerin hankintamoduulin laajuiselle hankintatoiminnallisuudelle ei ole Kohassa tarvetta, sillä rahankäytön yms. seurantaraportit saadaan yliopiston taloushallinnosta
* Kirjatilaukset tultaisiin viemään Kohaan minimitiedoilla jotta hankinnan tila saadaan näkyviin asiakkaille, muut tiedot ERMiin
Kirjastossa on asiakkailta suljettu varasto, jossa oleviin teoksiin kohdistuvat aineistopyynnöt käsitellään tällä hetkellä Voyagerin __Call Slip__ -toiminnon kautta. Nykyisessä Kohan julkaisuversiossa ei ole olemassa vastaavaa toimintoa, joten testauksessa selvitettiin voisiko varastotilauksissa tarvittavat toiminnallisuudet toteuttaa määrittelemällä käyttöön sopivat asetukset. Asetuskombinaatioiden osalta testauksessa kokeiltiin seuraavaa:
* Luotiin lainaussääntö, jonka mukaan hyllyvarausten teko varastokokoelmaan on sallittu
* Pakotettiin varastokokoelmaan nidekohtainen varaus, eli varaus on pakko tehdä aina tiettyyn niteeseen
* Otettiin varastokokokoelmassa käyttöön StaticHoldsQueueWeight -asetus
* Määritettiin Transfer-asetuksissa, ettei aineistoja siirretä pääkirjaston sekä pääkirjaston varaston välillä. Tarkoitus oli kokeilla, estääkö tämä myös varausten siirtymisen em. kirjastojen kokoelmien välillä.
Näillä asetuksilla asiakas saa tehtyä varauksen varastokokoelman niteeseen. Ongelmaksi tulee kuitenkin se, että nimekevarausten tarttumista ei voi rajoittaa aineistotyyppikohtaisesti siten, että asiakkaan itsensä tekemät nidevaraukset olisivat kuitenkin mahdollisia.
Nidevaraustoimintoa voisi käyttää kuitenkin siihen, että kirjastojärjestelmän ulkoista järjestelmää -- esimerkiksi tikettijärjestelmää -- käyttäen tehdyt varaukset saadaan näkyviin asiakaskäyttöliittymän puolella. Nimekevarausten tarttumisen saa estymään määrittelemällä varastolle omat lainaussäännöt ja estämällä varaukset (__Hold Policy__ __Holds not Allowed__). Silloin kun lisäksi on sallittu henkilökunnan ohittaa asetettu Hold Policy (__AllowHoldPolicyOverride__), henkilökunta voi tehdä noudon jälkeen ko. niteeseen varauksen, mutta asiakkaiden nimekevaraukset eivät kuitenkaan tartu näihin varastokappaleisiin. Näin ulkoista järjestelmää voitaisiin käyttää tilausten tekoon sekä käsittelyyn ja samalla asiakaskäyttöliittymään saataisiin näkyville varastotilauksen tilanne. Mahdollisia ulkoisia järjestelmiä voisivat olla esimerkiksi:
- Tukholman yliopiston kirjastossa kehitetty http://libereurope.eu/blog/2014/12/02/navigating-the-librarys-closed-stacks-with-a-smartphone/[varastopyyntöjen käsittelyjärjestelmä]
- on Tukholmassa tuotantokäytössä, tulossa avoimella lisenssillä julkiseen jakoon
- käyttää Microsoftin palvelinteknologioita, joita yliopistolla ei muuten ole käytössä. Tukea voi olla vaikea saada
- käytetään varastopyyntöjen käsittelyyn tikettijärjestelmää (kuten http://www.otrs.com/otrs-business-solution-for-better-customer-service/otrs-as-document-workflow-management-software/[OTRS])
- pyynnöt tehdään https://metacpan.org/pod/App::OTRS::CreateTicket[rajapinnan kautta] järjestelmään, varaus luodaan asiakkaalle noudon jälkeen, joten näkyy Kohassa
- muokattavissa oleva työnkulku
- tikettijärjestelmälle voi olla tarvetta muissakin http://www.library.illinois.edu/it/helpdesk/service/OTRS[kirjaston työnkuluissa]
Katso kohta Kohan  >.
Tällä hetkellä hyllyvarauksen teko tulee mahdolliseksi heti kun ensimmäinen lainakappale kyseiseen aineistotyyppiin kuuluvasta teoksesta on lainattu. Tarjolla on ollut korjaus, joka muuttaa toiminnan siten, että vasta kun kaikki lainakappaleet ovat lainattu, varauksen tekeminen tulee mahdolliseksi. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11481[Tätä korjausta] ei kuitenkaan ole vielä otettu osaksi Kohan julkaisuversion koodia
==== Pääkirjaston varasto omana kirjastona
Testausasennuksessa pääkirjaston varasto on omana kirjastonaan. Tarkoituksena on testata, voiko varastotilaukset hoitaa tämän avulla.
Palautuksen kannalta on helpompi, jos varasto on samaa kirjastoa pääkirjaston kanssa. Jos varasto olisi erillinen kirjasto:
* varastokirja jouduttaisiin palauttamaan kahteen kertaan. Ensimmäisen palautuksen (yleiskokoelma automaatilla, Fennicat käsin) jälkeen kirja jäisi Kuljetuksessa-tilaan. Toisessa palautuksessa kirjastoksi vaihdettaisiin Pääkirjaston varasto, jolloin kirja muuttuisi Saatavana-tilaan.
* joku palautuspisteen kone tai selainikkuna pidettäisiin auki niin, että kirjastona on Pääkirjaston varasto. Kaikki varastokirjat palautettaisiin sen kautta (myös automaatilla palautettu varaston yleiskokoelma).
Nykyisessä Kohan julkaisuversiossa ei ole recall-mahdollisuutta. Jyväskylän yliopiston kirjastossa recall-toimintoa käytetään pääasiassa laitoslainassa oleviin Fennica-kokoelman teoksiin. Recallia käytetään myös esim. Kanavuoren etävaraston lainassa olevien gradujen varaamiseen.
Prosessi, jos recallia ei olisi ja asiakas kysyy laitoslainassa olevaa Fennicaa:
* ostetaan teos meille lainakappaleeksi
* jos teos on loppuunmyyty (tai lehti), tilataan Varastokirjastosta. Teettää työtä ja aiheuttaa kuluja (tilauksen teko ja käsittely, postitukset), mutta yleensä toimii nopeasti.
* jos teos ei löydy Varastokirjastosta, tilataan muualta kaukolainana. Voiko asiakas joutua odottamaan pitkään? Entä maksut? Asiakasta tuskin ilahduttaa maksaa kirjasta, joka kuitenkin olisi meidän omissa kokoelmissa.
* entä jos meillä on ainoa kappale, jota ei löydy mistään muualta. Harvinainen tilanne, mutta mahdollinen. Pyydetäänkö asiakasta odottamaan vai otetaanko lainaajaan yhteyttä esim. sähköpostitse tai puhelimitse ja pyydetään palauttamaan kirja? Hidas ja työläs tapa. Kirjan lainaaja voi vitkastella palautuksen kanssa. Laina-ajan lyhentäminen ja mahdollinen sanktio voivat jouduttaa palauttamista, mutta niiden asettaminen käsipelissä hidasta.
Recall-tyyppisten varausten määrä on n. 200 kpl vuodessa, eli toiminnolle olisi käyttöä, mutta toisaalta määrä on sen verran pieni, että on syytä miettiä, pärjätäänkö ilmankin? Lyhennetäänkö henkilökunnalla lainassa olevien Fennicoiden laina-aikaa esim. 28 vrk ja laitetaan ne normaalisti varattaviksi?
Pitäisikö Chydeniuksen/Kokkolan kirjoilla olla oma nidetyyppi? Jos Kokkolan kirjoilla oma nidetyyppi, voisi asetuksilla estää meidän asiakkaiden sinne tekemät varaukset ja päinvastoin. Tällä hetkellä varaukset tarttuvat myös Kokkolan aineistoihin riippumatta asiakkaan kotikirjastosta.
Mikäli varausten tarttuminen estettäisiin omalla nidetyypillä, opiskelija tai henkilökunnan jäsen, jonka kotikirjasto on Jyväskylässä mutta asioi myös Kokkolassa, ei voisi varata aineistoa omatoimisesti. Henkilökunta voisi kuitenkin ohittaa varauseston.
Eräpäivien laskentaan vaikuttavaan http://manual.koha-community.org/3.18/en/calholidays.html[kalenteriin] ei saa laitettua kirjaston aukiolopäivien kellonaikoja, jolloin eräpäivätiedoissa tai lainauskuiteissa ei näy kirjaston sulkemisaikaa. (=palautusaika) Olisi tarpeen erityisesti lyhytlainoissa.
Kalenteriin liittyviä parannuksia on esillä Kohan kehitystikettijärjestelmässä (tiketit http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8133[#8133] ja http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11211[#11211], mutta niiden toteutusaikataulusta ei ole tietoa.
Voi olla tarpeen miettiä, halutaanko henkilökunnalla pitää erilaiset maksu- ja lainakieltokäytännöt vai yhtenäistää opiskelijoiden ja muiden asiakkaiden kanssa?
Testauksen aikana ei päätetty, tulisiko Koha olemaan myös luetteloinnin työväline vai tapahtuisiko luettelointi ensisijaisesti Melindassa, jolloin tietueisiin liitetään vain nidetiedot.
==== Sijainti / Niteen luokan pituus
Kohan nidentietojen hyllysijainti (`952$o`) -kenttä voidaan haluttaessa muodostaa http://manual.koha-community.org/3.22/en/administration.html#itemcallnumber[automaattisesti] bibliografisen tietueen kentän, kuten esimerkiksi `082` tai `092` -kentän tietojen pohjalta. Hyllysijainnin pituudella ei ole rajoitusta.
Koha http://bywatersolutions.com/2013/04/02/koha-is-ready-for-rda/[tukee RDA:ta] mutta RDA-luettelointia ei testattu lukuun ottamatta http://wiki.koha-community.org/wiki/MARC_frameworks[RDA-luettelointipohjan] asennusta, joka onnistui ongelmitta.
==== Tietojen poiminta muista järjestelmistä
Mikäli Kohaa tullaan käyttämään luettelointityökaluna, tietueiden poiminta muista järjestelmistä voidaan tehdä Z39.50-rajapinnan kautta. Myös tietueiden siirto eräajona http://manual.koha-community.org/3.18/en/catalogtools.html[selainkäyttöliittymästä] on mahdollista. USEMARCON-tyyppiset muutokset ovat osin mahdollisia suoraan Kohan eräajotyökalussa.
Tällä hetkellä musiikin osakohteet luetteloidaan Alephilla Melindaan ja monografiaosakohteet Voyagerilla JYKDOKiin. Kohassa on osakohdeluettelointimahdollisuus
* Onnistuuko eräajo ARTOon?
* Jos luettelointi tehdään vain Alephilla, pitää varmistaa monografiaosakohteiden luettelointimahdollisuus. Vai siirrytäänkö luetteloimaan ARTOon? Rajapinta TUTKAan?
Koha-kehitystyössä keskeisessä asemassa oleva http://bywatersolutions.com[ByWater Solutions] ylläpitää http://devs.bywatersolutions.com/[palvelua], jolla kerätään joukkorahoitusperiaatteella resursseja Kohan ominaisuuksien kehittämistä varten. Palveluun voi jättää kehitysehdotuksia, joita Bywater harkintansa mukaan julkaisee sivustolla. Palvelun hyödyntäminen voisi olla harkitsemisen arvoinen vaihtoehto myös suomalaisten Koha-kirjastojen tapauksessa, jos havaitaan, että Kohasta puuttuu ominaisuus, joka voisi olla hyödyllinen laajalti, eikä ominaisuuden kehittämiseen pelkästään kotimaisin resurssin ole mahdollista. Esimerkiksi varastopyyntöjen käsittely voisi olla tällainen yhdessä rahoitettava, laajasti hyödyllinen kehityskohde.
Kohan kehitystyön suuntaa ja uusien ominaisuuksien ideointia on mahdollista seurata kehittäjäyhteisön ylläpitämältä http://wiki.koha-community.org/wiki/Category:RFCs[Request for Comments]-wikisivulta. RFC-dokumenttien tarkoituksena on koota yhteen erilaisia näkemyksiä Kohaan halutuista ominaisuuksista, hakea konsensusta ja mahdollistaa kehitystyöhön osallistuminen mahdollisimman varhaisessa vaiheessa.
RFC-dokumenttien lisäksi kehitystyön kokonaiskuvan muodostamisessa ovat avuksi kehittäjäyhteisön http://meetings.koha-community.org/[verkkokokousmuistiinpanot] ja Kohan http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&product=Koha&query_format=advanced[tikettijärjestelmä].
Keväällä 2015 EBSCO https://www.ebsco.com/news-center/press-releases/koha-receives-massive-support-from-ebsco-for-enhancements[ilmoitti] tukevansa merkittävällä summalla Kohan kehitystyötä. Tuki kanavoidaan http://www.kohagruppoitaliano.moonfruit.com/[Koha Gruppo Italianon] kautta Kohan kehittämisessä mukana oleville ohjelmistoyhtiöille. Tukea on käytetty muun muassa Kohan http://wiki.koha-community.org/wiki/Elasticsearch[sisäisesti käyttämän hakuindeksin uudistustyöhön] -- uudistetulla haulla varustettu Koha on tulossa julki jo syksyllä 2015 -- ja muita EBSCOn tuella tehtävä parannuksia ovat muun muassa:
* Linkitetyn datan tuki
* Laajennettu metadataskeemojen tuki; mahdollisuus sisällyttää hakuun myös muuta kuin MARC21-dataa
* Laajennettu https://github.com/ebsco/edsapi-koha-plugin[Ebscon EDS-palvelun tuki]
Näiden kehityskohteiden lisäksi käynnissä tai suunnitteilla on myös muita Jyväskylän yliopiston kirjaston kannalta kiinnostavia kehityskohteita, kuten varastotilausten tuki.
Tällä hetkellä Kohasta puuttuu mahdollisuus tehdä ja käsitellä yleisöltä suljettuihin kokoelmiin kohdistuvia aineistopyyntöjä. Vuonna 2010 julkaistuun Kohan 3.2-versioon on kuitenkin ollut saatavilla ranskalaiselle http://www.bulac.fr/[BULAC-kirjastolle] kehitetty https://github.com/BULAC/koha/blob/bulac-dead_end-3.02.04/C4/Stack/Desk.pm[aineistopyyntö-laajennos], joka BULAC-kirjaston on ollut tarkoitus muokata yhteensopivaksi Kohan uudempien versioiden kanssa. Varastotilaustoimintoon ja recall-tyyppisiin varauksiin tarvittavien muutosten kehittäminen tai rahoittaminen voisi olla myös suomalaisille korkeakoulukirjastoille hyödyllinen yhteistyön muoto, mikäli Kohaan siirtyminen tulee ajankohtaiseksi tulevina vuosina.
Seuraavat taulukot sisältävät testiasennuksessamme käytössä olleet asetukset.
|EIKAYTTOA |Aineisto ei käytössä
|LAINA14 |Laina-aika 14 vrk
|LAINA28 |Laina-aika 28 vrk
|VARASTO180 |Varastolaina 180 vrk
|VARASTO28 |Varastolaina 28 vrk
Voyagerin kokoelmatunnukset mapattiin Kohan CCODE-sallittuihin arvoihin.
Yhteensä kokoelmakoodeja oli 259.