Hvordan lage nye brukeropplevelser basert på bibliotekdata
Fra Biblab
Tradisjonelt har biblioteksystemene vært tett integrerte monolitter, der funksjonaliteten i ulike deler har vært tett sammenkoblet. Dette har også omfattet sluttbrukernes grensesnitt, OPACen. De siste årene har det vært en økende misnøye med denne organiseringen, spesielt at OPACen er så tett knyttet til bibliotekenes husholdningssystemer. Dels skyldes dette at man ønsker å tilby sluttbrukerne én løsning for søk i alle bibliotekets ressurser, det være seg katalogen, elektroniske bøker og tidsskrift, institusjonelle arkiver, lenkesamlinger osv; dels skyldes det at man har sett at de tradisjonelle systemleverandørene ikke har klart å lever grensesnitt som har holdt tritt med utviklingen ellers på Nettet.
Hva må til for at man skulle kunne lage tjenester som søker i alle ønskelige kilder, og som tilbyr det man ønsker av funksjonalitet?
Innhold |
Datakilder
Det man ønsker å oppnå er bedre tilgang til metadata og elektroniske ressurser for bibliotekets brukere. Dette kan omfatte:
Ressurser som bibliotekene eier
- Bibliotekkataloger
- Institusjonelle arkiver
- Bildesamlinger
- Lenkesamlinger
Ressurser som bibliotekene betaler for tilgang til
- Samlinger av elektroniske bøker
- Samlinger av elektroniske tidsskrift
Åpent tilgjengelige ressurser
- Samlinger av åpen fulltekst
- Åpne arkiver
APIer og protokoller
For å lage tjenester av den typen det er snakk om her er man nødt til å kunne hente data fra ulike kilder på standardiserte måter. Det finnes åpne, standardiserte APIer og protokoller som kan benyttes for de fleste relevante formål. Eksempler på dette kan være Z39.50 for bibliotekkataloger, og OAI-PMH for åpne arkiver. Av og til vil man være tvunget til å forholde seg til en leverandør-spesifikk protokoll, dersom dette er det eneste som er tilgjengelig for en gitt datakilde.
Hvilke protokoller som er tilgjengelig vil legge føringer på hvordan man kan implementere en tjeneste, jamfør "Just in time eller just in case" nedenfor.
Se: Kategori:APIer og protokoller
(Meta)-dataformater
Et stort spørsmål er hvilke formater dataene man kan få tak i har. Dels er dette spørsmål om utformingen, for eksempel om de er pakket inn i XML eller ikke (ren MARC eller MARCXML), dels er det et spørsmål om hvor detaljerte dataene er (fullt MARC-format eller Dublin Core).
Alternative grensesnitt
Skal man gi brukerne nye opplevelser, som ikke er knyttet til OPACen, må man ha et "sted" å presentere dem. Det finnes i dag mange prosjekter som jobber med å implementere slike tjenester, dels er dette proprietære løsninger utviklet av kommersielle leverandører, dels er det prosjekter som gjøres tilgjengelig som åpen kildekode.
Se: Kategori:Alternative grensesnitt
"Just in time" eller "just in case"
En avveining man må gjøre er om man skal høste inn dataene man baserer tjenesten på, eller om man skal utføre eksterne søk i sanntid (samsøk).
Just in time
Her utføres søk i flere kilder mens brukeren som initierte søket sitter og venter. Data fra de ulike kildene samles inn og presenteres for brukeren på en samlet måte. Alle eventuelle koblinger mellom data må utføres mens brukeren venter.
Eksempler på protokoller som kan benyttes er Z39.50 og SRU.
Just in case
Her samles data inn fra ulike kilder etter hvert som de blir tilgjengelige, og når brukeren initierer et søk, utføres søket i den lokale samlingen av metadata. Eventuelle koblinger mellom data fra ulike kilder kan utføres etter hvert som data blir tilgjengelig.
Et eksempel på en protokoll som kan benyttes er OAI-PMH.
Opphavsrett
For data som bibliotekene selv eier bør det ikke være noe problem hva man gjør med dem, men andre kilder kan legge begrensninger på bruken. Amazon har for eksempel regler for hvilke data som kan lagres og hvilke som ikke kan lagres, eventuelt hvor lenge de kan lagres.
