Een van de hoofdtaken van de UB Leiden is volgens mij het communiceren met klanten om informatie(bronnen) aan te bieden. Heel vaak willen we daarbij gebruik maken van een URL, de informatie zelf of de beschrijving van de informatiebron is online beschikbaar. Een paar vormen van communicatie (in brede zin) waarbij dat het geval kan zijn:

• Rechtstreekse actieve communicatie (mail, chat, telefoon, in persoon)
• Passief aanbod (website, tutorial, handleiding)
• Tussen systemen (vanuit een bibliografisch bestand naar fulltext artikel, vanuit de catalogus naar een externe website, etc.)
• Vanuit systemen aangeboden (een herbruikbare permanente link naar een catalogusrecord, een scan van een handschrift, een artikel, etc.)

 Daarbij lopen we nogal eens tegen lastige problemen aan:

• De URL moet naar het juiste niveau verwijzen, een link waarvan men mag verwachten bij een artikel uit te komen, moet niet blijven steken op een algemene pagina van een tijschrift
• De URL moet naar de juiste plek verwijzen, een artikel is vaak op meerdere plaatsen fulltext beschikbaar, maar voor onze klanten niet altijd overal toegankelijk.
• De URL moet betekenisvol zijn, de inhoud van de URL moet dus iets zeggen over de verwijzing
• De URL moet (bij externe bronnen) zorgen voor de juiste toegangsrechten. Bij gelicenseerde informatie moet een student er van thuis uit wel bij kunnen maar een niet geautoriseerde gast juist niet
• De URL moet persistent zijn, ook na langere tijd moet de URL nog steeds werken en naar de juiste plek verwijzen
• En als het even kan moeten gebruikscijfers bijgehouden kunnen worden

Voor veel situaties leek het lange tijd een goede oplossing om een OpenURL te gebruiken. Zelfs de thuistoegang valt dan te regelen met behulp van EZproxy. Het werkt goed om bovenstaande problemen op te lossen, maar roept wel weer tenminste één nieuw probleem op:

• De URL moet niet te lang zijn. Als voorbeeld een "heel gewone" Open URL uit Web of Science:
  http://sfx.leidenuniv.nl:9003/sfx_local?&url_ver=Z39.88-2004&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.atitle=Pharmacological%20investigations%20on%20lipopolysaccharide-induced%20permeability%20changes%20in%20the%20blood-brain%20barrier%20in%20vitro&rft.auinit=P&rft.aulast=Gaillard&rft.date=2003&rft.epage=31&rft.genre=article&rft.issn=0026-2862&rft.issue=1&rft.place=SAN%20DIEGO&rft.pub=ACADEMIC%20PRESS%20INC%20ELSEVIER%20SCIENCE&rft.spage=24&rft.stitle=MICROVASC%20RES&rft.title=MICROVASCULAR%20RESEARCH&rft.volume=65&rfr_id=info:sid/www.isinet.com:WoK:WOS&rft.au=de%20Boer%2C%20A&rft.au=Breimer%2C%20D

 OpenURL kan ook lang niet altijd gebruikt worden: een link naar een pagina op de website of een catalogusrecord is niet zo makkelijk in een OpenURL te vangen. In een telefoongesprek kan je geen OpenURL gebruiken, in een mail gaat het vaak mis met de lengte. En met die persistentie kan het wellicht ook tegenvallen.  Dat laatste zou wel eens een flink probleem kunnen gaan worden nu wij overwegen om onze OpenURL resolver SFX elders onder te brengen: gehost bij leverancier Ex Libris in plaats van op onze eigen server. De kans is groot dat daarbij de base-url (het eerste deel van de URL) zal wijzigen. Weg persistentie voor alle links die nu ergens genoemd staan, tenzij we nog iets slims verzinnen. Voor dynamisch gegenereerde links valt het hopelijk nog wel mee, door de base-url te vervangen werkt het wel weer, maar voor alle statische URL's is het een flinke kluif om alles te vervangen denk daarbij aan de 250.000 URL's die we hard in de catalogus hebben staan. Of die URL's in Blackboard cursussen, op websites, in mailtjes, etc. 

Maar hoe moet het dan wel? Eerst gaan we proberen te zorgen dat de huidige gebruikte OpenURL's blijven werken. Maar daarmee is het probleem van de lengte en toepasbaarheid niet opgelost. Daarom zijn we aan het onderzoeken welke andere tools er zijn. We hebben gekeken of het zelf bouwen van een voorziening haalbaar zou zijn, een URL verkorter met een database (en daarmee hulpmiddelen voor persistentie), koppeling aan EZproxy, vergaring van gebruikscijfers en met herkenbare en leesbare URL's. Helaas ontbreekt het ons aan tijd en middelen om dat op te bouwen en vooral ook te beheren.  

Een alomvattende oplossing lijkt er niet te zijn. Voor gebruik tussen systemen blijven we natuurlijk OpenURL gebruiken, voor directe communicatie kijken we naar URL verkorters in de buitenwereld. Er blijken heel veel van dit soort diensten te zijn. Op dit moment onderzoeken we de mogelijkheden van goo.gl en bit.ly (ly staat voor Libië, maakt dat nog wat uit? En goo.gl is van Google, willen we dat wel?) Beide hebben als voordeel dat ze open en tamelijk betrouwbaar lijken te zijn. Ook bieden ze een API en gebruikscijfers, met als bonus zelfs de mogelijkheid om direct een QR code te gebruiken. Maar dus ook geen totaaloplossing.

Afgelopen week was ik een aantal dagen te gast bij de UvA om daar uitleg van OCLC te krijgen over catalogiseren in WorldCat. Het was zeer nuttig, ik heb een hoop geleerd over de mogelijkheden en de beperkingen.

De UBL catalogiseert in het GGC, records komen automatisch door naar ons bibliotheeksysteem Aleph. We zijn vooralsnog niet van plan dat anders te gaan doen. Gelukkig is het GGC ook van OCLC net als WorldCat, een koppeling tussen die systemen bestaat al, zij het nog niet volledig. GGC records worden wel in WorldCat opgenomen, maar andersom gaat het nog moeizaam.

OCLC heeft al jaren een aantal nuttige initiatieven die voor ons van belang kunnen zijn. We zouden in een aantal gevallen waarschijnlijk efficiënter kunnen werken dan nu het geval is, als we gebruik maken van metadata zoals die door leveranciers aangeboden worden. Dat wordt in de WorldCat omgeving redelijk ondersteund (zij het met techniek van jaren terug: uitwisseling van files via een FTP server).

Men heeft in Dublin Ohio al iets bedacht voor:

• approval plans, metadata en administratieve gegevens via WorldCat Cataloging Partners
• slip plans, metadata en administratieve gegevens via WorldCat Selections
• pakket verwerking, metadata via WorldCat
• catalogiseren in niet Westers schrift, met automatische transliteratie, via WorldCat Connexion client

Wij zouden mogelijk van deze tools gebruik willen maken, maar dan wel via het GGC. Dat vergt wel wat extra aanpassingen: OCLC Nederland zou dan gegevens uit de verschillende WorldCat varianten automatisch voor ons moeten inlezen in het GGC, waarna de records via (L)OUF naar Aleph moeten overkomen. Dit is denkbaar en lijkt haalbaar. Of het echt winst op gaat leveren valt lastig in te schatten.

Voor de andere aanwezige bibliotheken (UvA en Utrecht) gelden andere werkwijzen, zij werken rechtstreeks in Aleph, maar moeten dan wel zorgen voor een upload naar het GGC.

WorldCat als catalogiseeromgeving blijkt ook nogal wat beperkingen te kennen. Zo kan geen goed gebruik gemaakt worden van andere authority files dan die van de Library of Congres. Een Nederlandse set auteursnamen gebruiken wordt dan wel erg lastig, zeker als we ons niet aansluiten bij internationale initiatieven als VIAF. Ook de manier waarop met dubbele records en taalvarianten van records wordt omgegaan baart mij wat zorgen. Er zitten wel erg veel verschillende records in WorldCat die allemaal het hetzelfde object beschrijven. Welke moet je dan gebruiken? Ook mogelijkheden om updates van records automatisch door te laten komen (zoals bij het GGC) zijn er nog niet.

Wij hebben het voornemen om in een project na te gaan hoe we de WorldCat instrumenten kunnen inzetten en wat ons dat kan opleveren. Aan mij de eer om dit project voor te bereiden. De UvA is zeer geïnteresseerd in rechtsreeks catalogiseren in WorldCat. Utrecht (via Z39.50 al benutter van WorldCat gegevens) gaat eerst aan de slag met het in gebruik nemen van Marc21 als intern formaat, maar blijft geïnteresseerd.

Met de ontwikkelingen in de opzet van biblitoheeksystemen en de workflow die de komende jaren te verwachten zijn, is het zeker nuttig om al vast ervaring op te doen met andere manieren van werken. Eerst maar eens kijken hoe het allemaal echt werkt en goed blijven overleggen met de collega's. We kunnen zeker van elkaar leren.  

 Er is heel veel informatie te vinden op de website van OCLC: http://www.oclc.org/us/en/connexion/default.htm

 

 

 

 

 

Wat levert dat nou op zo'n dagje Ticer? Niet veel nieuwe informatie, maar wel nieuwe inzichten. En waarschijnlijk ook wel plannen (nu nog even tijd er voor vinden).

Ik mocht naar de Ticer dag over Mobile Technologies, met vier boeiende lezingen. Dankzij de opzet van Ticer gaan de lezingen goed de diepte in, er is voldoende tijd om de materie goed te bespreken en ook voor vragen en discussie zijn er genoeg mogelijkheden. Het programma en veel materiaal is natuurlijk terug te vinden op de Ticer website: http://www.tilburguniversity.nl/services/lis/ticer/2010/program.html

Wat mij betreft de meest opvallende zaken:

• Veel iPad's in de zaal, geen representatieve bibliotheekpersoneel steekproef dus. 
• Bij Pew wordt erg veel tijd door personeel besteed aan presentie op internet en bij conferenties, tot 50% van de werktijd
• Twitter wordt daarbij momenteel veel gebruikt
• Bibliotheken moeten (als organisatie) aanwezig zijn in sociale netwerken, omdat de (toekomstige) klanten zich daar bevinden
• De waan van de dag bepaalt welk netwerk daarbij van belang is, van SecondLife naar Facebook, blogs en Twitter naar ...
• Dat vraagt dan wel om beleid vanuit de organisatie, positiebepaling, uitgangspunten en gedragsregels moeten worden bepaald en onderhouden
• De instelling moet zich actief opstellen en daar tijd voor vrijmaken, alle medewerkers doen mee (?)
• Medewerkers hebben continue begeleiding nodig, om nieuwe vaardigheden te leren (hoe kan ik Twitter goed gebruiken?) en kwalitatief goed te blijven werken, namens de organisatie.
• Wees voorzichtig met vermenging van privé en werk, zeker bij Twitter.
• Mobiele toepassingen kunnen goed werken en zijn relatief eenvoudig te realiseren, mits gebruik gemaakt wordt van een mobiele internet laag over bestaande voorzieningen (zoals bijvoorbeeld bij de UBA gedaan is)
• Maar bedenk wel goed van tevoren wat je wilt en wat de klant er echt aan heeft, denk vooral mobiel
• En verwacht niet al te veel van het resultaat. De populairste mobiele site bij NCSU: een webcam van de rij bij de koffieautomaat
• Mobiele websites zijn redelijk eenvoudig te maken en dan direct op verschillende platforms te gebruiken, maar de klant wil en verwacht en zoekt naar apps. Die zijn dan weer veel lastiger te maken.
• Ik wil een smartphone (maar de baas gaat dat niet voor me regelen)
• De toekomst van e-book readers is en blijft onzeker, e-readers zijn nu vooral voor de "reading-glass generation", lezen vanaf een iPad is wel flitsend maar ook vermoeiend. Mogelijk meerdere apparaten afhankelijk van de leesomstandigheden.

Hoe nu verder? Ik verwacht dat vanuit het management van de UBL binnenkort initiatieven komen. Of is dat toch te veel gevraagd?

Al jaren stuit samenwerking tussen universiteitsbibliotheken op het gebeid van inrichting van systemen op allerlei praktische bezwaren. We het er wel vaak over. Waarom hebben we allemaal onze eigen SFX server in gebruik, dat kan toch veel handiger, door een server te delen.

De systemen laten het toe, leverancier Ex Libris zorgt steeds beter voor consoritum ondersteuning en bijv. in Finland gaat het al jaren goed, met één landelijke infrastructuur voor Metalib.

Naast lastige problemen rond zeggenschap over de eigen installatie speelde tot nu teo altijd de plek een belangrijke rol. Wie zou dan zo'n centrale isntallatie meoten beheren en hosten?

In het Surf meerjarenplan http://www.surf.nl/nl/OverSURF/Pages/SURFmeerjarenplan.aspx lijkt voor dat probleem een oplossing in zicht. Surf is van plan om een nieuwe dochter op te richten:  SURFsps, met in tweede instantie de bedoeling om daar gezamenlijke ICT-diensten van het hoger onderwijs onder te kunnen brengen.

Tot nu toe werd dit node gemist, hoeplijk gaan de ambities van Surf ver genoeg en wordt dit snel gerealiseerd. als we dan ook nog geode samenwerking op dit gebied tussen KNWA, KB en Surf rond kunnen krijgen, kan er een landelijk dekkende infrastructuur ontstaan. Geen zorgen meer over hosting!

Sinds 2003 wordt bij de Universiteit Leiden SFX gebruikt als OpenURL resolver. Een prachtige uitvinding, met een knopje in bibliografische bestanden kan iemand via onze eigen SFX server naar bijvoorbeeld de fulltext van een artikel worden geleid, en dan ook nog precies naar die fulltext versie waar wij toegang voor hebben.

Maar.... dan moet die SFX server wel over de juiste informatie beschikken, de gegevens van tijdschriften en leveranciers moeten wel kloppend in de "Knowledge Base" zitten. Leverancier Ex Libris doet zijn stinkende best, maar toch lukt het niet altijd. Ook uitgevers doen vaak (maar soms ook niet) hun best om zowel aan de bibliotheken als aan bemiddelende partijen zoals Ex Libris, de juiste informatie te geven.

Waar gaat het dan fout? Het blijkt erg lastig om alle verschillende partijen op de zelfde manier met elkaar te laten communiceren. Iedereen hanteert zijn eigen afspraken, eigen sets aan gegevens en eigen manieren om gegevens te verspreiden.

De UKSG probeert daar nu samen met de NISO iets aan te doen en heeft richtlijnen opgesteld voor de uitwisseling van gegevens. Zie http://www.uksg.org/kbart voor meer informatie. In een ideale wereld zouden alle leveranciers zich hier aan houden en wordt het een stuk makkelijker om over de juiste gegevens te beschikken. 

"The KBART Working Group’s charge is to improve the supply of data to link resolvers
and knowledge bases, in order to improve the efficiency and effectiveness of OpenURL
linking. This is to be achieved by providing best practice guidelines, educational
materials and events, and a web hub to act as a central resource for knowledge base
information."

Iets om mee te nemen in licentieonderhandelingen: leverancier hou je aan de KBART richtlijnen!

Een ander probleem is in theorie al lang opgelost, maar de oplossing wordt helaas niet (voldoende) gebruikt. Het is vaak lastig om van een tijdschrift alle verschijningsvormen op een rijtje te houden en met elkaar te verbinden. Een tijdschrift kan, met verschillende ISSN's, zowel een gedrukte als een online als een CD versie hebben. In de Knowledge Base van SFX wordt dit vaak aan elkaar gekoppeld, maar niet altijd even goed.

Nu blijkt er al enige tijd een linkende ISSN te bestaan: ISSN-L, met al sinds 2007 een eigen plekje in de Marc21 specificaties: 022 $l. ISSN.org beheert lijstjes met als doel: "The linking ISSN or ISSN-L enables collocation or linking among different media versions of a continuing resource". Zie: http://www.issn.org/2-22637-What-is-an-ISSN-L.php

Waarom wist ik dit niet en wat doen onze leveranciers (Ex Libris, OCLC, uitgevers) hier mee?