How I Learned to Stop Worrying and Not Love LIBRIS
I dessa dagar av LIBRIS som lokal OPAC sker det en mängd intressanta saker. Utvecklingen av verktyg som eXtensible catalog, WorldCat Local och ”discovery tools” som Primo kommer att ställa krav på LIBRIS att bli något annat än ett gränssnitt för svenska biblioteks tryckta böcker och tidskrifter. Mitt biblioteks tryckta bestånd i relation till det elektroniska (fria och licensierade) blir allt mer oproportionerligt.
Vad våra användare behöver är ett gränssnitt mot bibliotekets samlade resurser integrerat i en lokal kontext. Svergies samlade tryckta bestånd är inte en lokal kontext. För att LIBRIS skall fortsätta vara attraktivt måste det kunna hantera enskilda biblioteks licensierade och urval av fritt tillgängliga tjänster.
Sett till det som händer utanför enskilda biblioteks försök att använda LIBRIS som en gemensam OPAC känns det onekligen som om tiden sprungit ifrån LIBRIS. Det behöver dock inte betyda att LIBRIS inte är rätt verktyg för Sveriges samlade bibliotek. Men om LIBRIS skall vara attraktivt för ett enskild högskolebibliotek så måste det förutom att erbjuda en samkatalog, erbjuda lånetransaktioner, licensierade resuser (antingen via centrala index eller samsökning) och urvalda fria resurser (t ex OAI-PMH höstade arkiv). Jag skulle även vilja påstå att det bör stödja integration med publiceringssystem (CMS) och lärplattformar. Om LIBRIS hade kört ett projekt som eXtensible catalog hade jag hoppat av lycka. Nu hoppas jag att man lyfter den strategiska diskussionen om vad vi vill ha för system och vad vi skall ha dem till. Jag tror att LIBRIS skulle kunna vara så mycket mer än vad jag upplever det som att våra chefer planerar för idag och det är synd.
Märkligt nog så finner jag att det i dagsläget verkar vettigare att satsa på Primo (och få integration mellan mitt biblioteks samlade resurser) än att satsa på LIBRIS (och få integration mellan svenska biblioteks bok-kataloger).
Detta skrämmer mig något.
hmm, det slår mig även att lika gärna som att vi skaffar Primo lokalt så skulle ju LIBRIS kunna uppgradera sitt MetaLib till Primo. På så vis skulle man få ett gränssnitt mot de lokala bibliotekskatalogerna och verktyg för att kunna hantera licensierade bestånd. Lägg till det API:erna för Primo och vi har ett intressant alternativ till att vidareutveckla LIBRIS webbsök som lokal OPAC. Kanske är det MetaLib/Primo som borde utvecklas i den riktningen… de tankarna hör man inte mycket om i strategidiskussionerna.
Handlar det inte till syvende og sidst om att de verktyg vi använder behöver stödja öppna API:er? På det planet skiljer väl egentligen inte en lokal ILS sig från Libris – i båda fallen behöver vi kunna prata med systemet från det gränssnitt där vi vill samla ingången till resurserna, och då gärna på ett sätt som kräver så lite specialanpassningar som möjligt.
Det som främst skiljer Libris från t.ex. ert lokala Aleph är väl att du kan använda Aleph som detta gränssnitt – men är det självklart att man utgår från bibliotekskatalogen? Kanske kan ett ”outsourcande” av OPAC:en snarare få oss att ännu tydligare inse att katalogen bara är en av många resurser som måste kunna integreras och/eller samsökas i andra verktyg?
(Sedan finns det naturligtvis en annan problematik med att inte ha direkt tillgång till systemet, som svårigheter med batchimporter och liknande.)
Allt det här tänkte jag skriva, sedan gick jag tillbaka och läste min senaste (tror jag) kommentar på betabib, och insåg att jag skrev ungefär samma sak då …
Vet du förresten var SRU-stödet för Libris finns? Jag hittar bara dokumentation om XSearch.
Stöd för öppna API:er är bra. Men det handlar egentligen inte om det till syvende og sidst upplever jag det som att det handlar om behovet av att kunna samordna och presentera ett biblioteks urval av tjänster. Såväl fria som licensierade.
Det som främst skiljer LIBRIS från mitt lokala Aleph är att jag lokalt via API:er kan integrera mitt biblioteks licensierade bestånd och presentera det i en lokal kontext.
Jag tror starkt på att datat i vår katalog skall nå ut i så många sammanhang som möjligt. Men det intressanta i det här sammanhanget är inte katalogdatat. Det utgör en så liten del av vårt bestånd att det blir mer och mer marginaliserat. Det som istället är viktigt är kombinationen av de tryckta och elektroniska resurser som vi väljer att förvärva. I framtiden tror jag även att beståndsbyggandet för biblioteken kommer att handla om att välja ut OA arkiv och andra fria resurser för höstning eller inarbetning i våra samlingar.
Ett biblioteks bestånd speglar den omgivande forskningen och utbildningen. Katalogen är en väldigt liten del av det beståndet och jag tror det som utgör beståndet (urvalet av databser, tryckta och elektroniska böcker/artiklar, OA-arkiv osv) kan vara relevant att presentera som just ett sammanhållet bestånd.
Så länge LIBRIS inte kan hantera mitt biblioteks licenseriade material kan den inte ersätta det som vi strävar mot, inte ens vår aktuella OPAC.
Ah, just det. Jag tror inte det finns någon SRU för LIBRIS. Men om du nöjer dig med URL-syntax och svar i XML så borde XSearch fungera lika bra. Eller?
Nej, du har rätt. Till syvende og sidst var fel ordval. Det jag avsåg var inte slutresultatet, där är vi nog ganska men inte riktigt ense, utan bedömningen av huruvida en viss tjänst fungerar om man vill uppnå slutresultatet.
Jag är lite osäker på vad du menar med att du ”lokalt via API:er kan integrera” – är det trafiken över nätet som gör Libris till ett sämre val? För annars ser jag inte skillnaden så tydligt som du.
Möjligen pratar vi förbi varandra. Jag är med på din idé med en samlad ingång till bibliotekets bestånd (licensierat, fysiskt eller bara utvalt). Det som inte är självklart för mig är att OPAC:en är den ram vi ska bygga in detta i. Vi kan lika gärna bygga vår samlade ingång i Primo, Joomla eller egenkomponerad php. Libris webbsök blir i det scenariot mer likvärdigt med t.ex. EBSCOhost:s gränssnitt – det finns kvar och kan vara användbart att gå vidare med.
Angående SRU så står det under ”Teknik och format” att Libris har stöd för det, därav min fråga. Och fördelen med att använda en mer spridd standard är väl att man enklare kan använda programbibliotek för att arbeta mot den och behöver göra mindre anpassningar för olika tjänster.
Jodå, det finns en SRU-server. Den bor på http://one.libris.kb.se/sru/libris, här är en exempelurl: http://one.libris.kb.se/sru/libris?query=%22mary%20shelley%22&recordSchema=marcxml&operation=searchRetrieve&maximumRecords=3
Vart dokumentationen tagit vägen kan jag inte svara på. Jag rekommenderar ett mail till libris@kb.se.
I övrigt konstaterar jag att det här är en intressant diskussion, ur väldigt många aspekter. Värd att ta över en öl någon gång kanske…
Det jag är ute efter är att man strategiskt måste lyfta frågan om hur andra resurser än bibliotekens tryckta böcker och tidskrifter skall bli tillgängliga i LIBRIS. Om man är helt ärlig så görs det faktiskt en hel del t ex via SFX->LIBRIS projektet. Men det räcker inte, eftersom vi saknar möjlighet att göra batch-uppdateringar i LIBRIS kan vi inte ladda LIBRIS med bestånd för våra e-böcker. Ett bestånd som växer dramatiskt och som vi idag bara har tillgängligt i vår lokala katalog (tack vare MARC poster från leverantören).
Men jag hade gärna sett att man fört diskussioner kring hur OA arkiv, e-böcker från Hathi trust, institutionella arkiv, digitaliserade arkiv skall göras tillgängliga i LIBRIS. Där pratar vi i första hand om sådant som är fritt tillgängligt.
Behovet av identifiering av användare från ett bibliotek är ytterligare en sak som måste till om LIBRIS skall hantera licensierat material som t ex ovan nämnda e-böcker.
Vad jag menar med lokalt integrera är att vi idag har kontroll över gränssnittet och utvecklingen vilket gör att vi kan blanda en lokal söktjänst med en licensierad i vår OPAC för t ex samsökning. Vi kan styra över autentisering och hur våra resurser presenteras på ett sätt som vi idag inte kan göra i LIBRIS. Ett LIBRIS med stöd för grafiska anpassningar, personalisering, autentisering mot lokala system och integration med fria och ett biblioteks licenseriserade bestånd. Det vore något det. Och det är något som ser ut att vara möjligt i Primo. Så en rimlig tanke vore ju att MetaLib uppgraderas till Primo. Så att vi kan testa och se hur det fungerar (antagligen inte alls…
)
Jag förstår poängen med att efterstäva samma teknik för flera källor. Speciellt om man vill slå ihop resultat. Så slipper man konvertera xml-format. Än så länge har jag inte gjort något sådant och med de funktioner jag använder så handlar det ju bara om att xml-taggarna heter olika saker i övrigt blir ju resultet detsamma. Urlsyntax med xml svar. Men det verkar ju onödigt att använda olika utsökningsmetoder om man kan använda samma. Jag har bara använt SRU servern för uppsök och då Xsearch för LIBRIS.
Tack Anders för att du reder ut att det finns en SRU och var den bor. Jag tror säkert att vi kommer prata en hel del om LIBRIS på BibCamp, där finns det säkert några öl med