Krav til biblioteksystemer Foreleser: Runar Eggen, epost: runar.eggen@jbi.hio.no Trenger vi spesifisere krav? Litt om kravspesifikasjoner Bibliotekstandarder IT-standarder Funksjonalitet i biblioteksystemer Denne første forelesningen vil ta for seg situasjonen slik den er i dag, sett "ovenfra". Neste gang vil vi se på detaljene i hva selve systemet må/bør inneholde.

Trenger bibl. stille krav? Er ikke de systemene bibliotek trenger ferdige? Hvorfor skal vi lære om kravspesifikasjoner? Enkelte av dagens systemer over 20 år gamle Utvikling går fort

Hvorfor stille krav? Viktig å vite hva man betaler for Viktig å vite om man kan få mer for pengene et annet sted Plikt til å utnytte ressursene til beste for bibliotekeier/brukere Bibliotekarens viktigste verktøy Må ikke bare kunne bruke systemet, men også velge det system som er best

Konservativisme 1 Har man arbeidet 20 år i et system, er det kanskje det eneste man kan. Da forsvarer man status quo, selv om det er faglig galt. Leverandører kan også ha interesse av å forsvare status quo. Kompetanse på ett enkelt system er nokså verdiløs dersom kunnskapen ikke kan generaliseres.

Konservatisme 2 PC-brukere, Mac-brukere og Unix-tilhengere er ofte nærmest fundamentalister. Det samme gjelder biblioteksystembrukere. De fleste biblioteksystem kjører i dag på Windows eller Linux/Unix, men dette er ingen naturlov. Enkle brukergrensesnitt senker endringsterskelen, fordi bruker må investere mindre tid i systemet.

Et lite regnestykke Et bibliotek skal katalogisere 100.000 bøker. I ett system bruker man ett minutt lenger på hver katalogisering. En billig arbeidstime koster 200 kr. I løpet av katalogiseringsprosessen bruker man 1667 timer eller 333.333 kr ekstra på et ineffektivt system. For 300.000 kr får man kjøpt mye biblioteksystem.

Spesifikasjonen vanskeligst Ikke noe annet kan i samme grad forkrøple sluttresultatet som kravspesifikasjonen. Jo seinere en feil i programvaren oppdages, jo dyrere er de å rette opp. Mange feil er latente og oppdages først i en annen fase enn de oppstod i. Det gjøres mange feil i krav. Typisk er uriktige fakta, utelatelser, inkonsistenser og tvetydigheter. Feil i krav kan oppdages. Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Kravspesifikasjoner som gikk galt TRESS-90. Trygdeetatens nye system ble skrinlagt etter at flere hundre mill. kr. var brukt. Ariane 501-raketten, ESAs prestisjeprosjekt. Raketten eksploderte 30 sek. etter oppskytning pga. spesifikasjonsfeil i programvaren til styresystemet. Ariane It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.

Viktige suksessfaktorer Brukermedvirkning Støtte fra toppledelsen Klart definerte krav Andre faktorer: skikkelig planlegging, realistiske forventninger, kortere milepæler, kompetent personale, eierskap, klar visjon og mål, hardt arbeidende og fokusert stab. Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc Verken utviklere eller brukere alene skriver gode kravspesifikasjoner. Utviklerne mangler kunnskap om kundenes behov, og kundene mangler kunnskap om utviklingsprosessen.

Spesifikasjonens faser Finne behov. Problemanalyse Fastsette krav Spesifikasjon av krav Kontroll av endringer i krav Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Vanligste feil i kravspek Manglende info Funksjon, egenskap Grensesnittdefinisjoner Ytelseskrav (svartid, databasebelastning) Kvalitetskrav (menneskelige faktorer, pålitelighet, sikkerhet) Gal info Konstruksjon istedenfor krav Ikke hva kunden ønsker Tvetydige krav Inkonsekvente krav Ikke testbare krav Unødvendig info Kjekt å ha Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Kravspek for utvikling/kjøp Biblioteksystemer er til en viss grad hyllevare, og de fleste bibliotekarer vil derfor i liten grad ta del i systemutvikling. Men for mange bibliotek vil valg og innføring av et nytt system være et stort prosjekt som krever en spesifikasjon. Det kan ofte bli snakk om tilpasninger av hyllevare. Kravspesifikasjonen skal leve lenge etter at det første utviklingsprosjektet ble gjennomført. Kravene må formuleres uavhengig av når og hvordan man vil gjennomføre utviklingsprosjektet. Derfor skal ikke prosjektplaner med.

Krav skal leve lenge Kravspesifikasjonen skal leve lenge, ofte lenger enn de første programmene den spesifiserte. Det er derfor viktig at den er modifiserbar. Da må den være konsistent, og ikke redundant. Dvs. at et man bruker ord konsekvent og at et tema/objekt behandles ett sted.

Databasen viktig(st) Databasen er minst like viktig som programmene. Dataene skal leve lenger. Databasestruktur må kunne endres. Data må kunne masse-endres og hentes ut uten programmering. Viktig å følge standarder, som f.eks. SQL. Ikke alle biblioteksystem gjør dette.

Brukervennlighet og fleksibilitet Det er av og til en konflikt mellom brukervennlighet og fleksibilitet. En programleverandør som får motstridende krav fra forskjellige kunder, må velge mellom å vedlikeholde forskjellige kodeversjoner eller å legge inn parameterstyring av programmene. Stor grad av parameterstyring kan gjøre systemet komplisert å sette opp og bruke. Løsning: Gode installasjonsprogrammer og dokumentasjon. Evt. sentral drift.

Brukervennlighet 2 Brukergrensesnitt i et biblioteksystem bør likne andre programmer slik at kunnskap får overføringsverdi.

Bibliotekstandarder 1 MARC-formatet - hvilket MARC-format? MARC-formatet langt fra perfekt Unødvendig komplisert (00-feltene, indikatorer, delfelter) Lite egnet for programmering Lite konsekvent (bl.a. bruk av indikatorer) Selvmotsigende (for eksempel aldersgrupper i 008-feltet) Snevert (kun brukt av bibliotek) Foreldet MEN bedre med en standard enn ingen! Hvorfor har så få Bibliofil-bibliotek tatt i bruk Bibliofils Z39.50-baserte samsøk? Fordi det koster en del penger, og Bibliofil tilbyr en ikke-standard samsøk-løsning betydelig billigere. Frittstående z-klient, z-klient integrert i OPAC. Bygge egen z-portal osv.

Bibliotekstandarder 2 MARC-formatet er så utbredt at det blir krevende å skifte det ut. Tendens til å gå tilbake til ett MARC-format (UKMARC er lagt ned, svenskene går over til MARC21.) XML kan bli viktig framover. Generelt format med generelle verktøy XML-innpakket MARC Hva betyr det at man er XML-kompatibel? Dublin Core kan redusere behovet for MARC-katalogisering.

Bibliotekstandarder 3 Dublin Core The Elements (ikke bare bibliotek) Title Creator Subject Description Publisher Contributor Date Type Format Identifier Resource Identifier Source Language Relation Coverage Rights

Bibliotekstandarder 4 AACR 2 Ble til i en annen tid (hva trenger du ordningsord til i dag for eksempel?) Hva er ordningsord? (tenk biografier) Svært detaljert Systemene tar hånd om mye av reglene (. - trenger du ikke tenke på lenger) ISBD-visning en fordel, men ikke absolutt nødvendig. Men KOMPAKT og lett å lese! Bedre med en standard enn ingen!

Bibliotekstandarder 5 CCL – Common Command Language Mange sier de følger det. Men ofte har de bare noe som likner. Hvem vet hva det er? Spiller det noen rolle? [Tretegns søkekode]=[søketerm]

Bibliotekstandarder 6 Z39.50 er en protokoll for samtidig søking og oppdatering i flere databaser. Fra 1990-årene. Programvare tilgjengelig lenge, men begrenset utbredelse. NILL – Norsk fjernlånstandard (Norwegian InterLibrary Lending). Ganske ny, de første applikasjonene ute nå.

IT-standarder – operativsystem 1 Tre hovedtyper: Windows, MacIntosh og Unix (Linux er en Unix-variant) Windows og Unix mest aktuelle for biblioteksystemer Alle operativsystemene gir mulighet for grafisk grensesnitt Eldre biblioteksystemer har tegnbasert grensesnitt (BIBSYS, eldre Bibliofil-versjoner, Mikromarc 1)

IT-standarder - operativsystem 2 Windows - hvilken Windows? 32 og 16 bits Windows 32 bits programmer går ikke på Windows 3.x 32 bits Windows er fra og med Win95 Hvis en leverandør sier at systemet går på 16 bits Windows, skal du ikke kjøpe det. Det betyr at det ikke utnytter mer moderne Windows-versjoner.

IT-standarder - operativsystem 3 Operativsystemuavhengig? Web-baserte biblioteksystemer sies å være operativsystemuavhengig. Stemmer det? På serversiden: Serveren må kjøre ett eller annet operativsystem. På klientsiden: Ja, men ikke alle systemer støtter alle HTML-versjoner, og er heller ikke like gode i alle nettlesere. Et system bør la seg kjøre i de vanligste nettleserne. I Norge i dag (oktober 2004) er dette Opera, Mozilla og Internet Explorer.

IT-standarder – grensesnitt 1 Grafisk grensesnitt et absolutt krav i dag Det er bare en viktig systemleverandør i Norge som ikke oppfyller dette. Unicode gjør det mulig å representere alle alfabet i ett tegnsett. 16 bits tegn istedenfor 8, hvilket gir 65536 forskjellige tegn istedenfor 255. De færreste biblioteksystem tilbyr unicode i dag.

IT-standarder – grensesnitt 2 Web-grensesnitt begynner å bli vanlig, ikke bare for søk, men også for utlån og katalogisering Web-grensesnitt har mange fordeler og minst en ulempe Fordeler: operativsystemuavhengig på klientsiden, små krav til linje, stedsuavhengig Ulemper: vanskeligere, men ikke umulig, å få inn funksjonalitet

Klient-tjener (client-server) Teknologien populær i Windows-miljø Tynne eller tykke klienter (tynne krever mindre av linjer og maskiner) Windows krever ”mellomklient” hvis man må via internett for å nå serveren. Citrix ICA-klient brukes bl.a. av MM2. Flerlagsarkitektur (multi-tier) gjør klientprogrammene og serverprogrammene mer uavhengige av hverandre.

IT-standarder – dokumenter Dokumenter bør være i standard-formater. Dokumenter bør ikke være i proprietære formater som Microsoft Word osv. Dokumenter skal kunne leses om flere hundre år. Derfor er XML viktig for bibliotek.

Funksjonalitet i biblioteksystemet Her skal vi se på: Hva ”alle” systemer har/bør ha Hva noen systemer har Nye tjenester Bibliotekmarkedet Biblioteksystem-markedet

Hva ”alle” systemer har/bør ha Innkjøpssystem Katalogsystem m/autoritetsregister Utlånssystem Publikumssøk m/bestilling, melding på web Tidsskriftsystem Statistikk og rapportfunksjon enkel å bruke! Sanntids oppdatering, én database Filialhåndtering, konsortiehåndtering Istedenfor å forelese opplisting av funksjonene i disse systemene vil jeg heller demonstrere dem i ett system.

Skille klinten fra hveten Siden "alle" systemer har de fleste basisfunksjonene, blir det viktig å vite hvor forskjellene ligger. Ikke alle forskjellene like nødvendige, men de kan fortelle om utviklingstakt.

Hva noen systemer har 1 Publikumstjenester: Mappa mi/Lånerprofil Selvbetjening og utlånsautomat Epost- og SMS-varsling (forfalte lån, ank. reserveringer) Søk fra mobiltelefon Katalogkrydder/Innsyn Visning av fulltekstdokumenter Z39.50-basert samsøk Z39.50 server og Z39.50 klient Hvorfor har så få Bibliofil-bibliotek tatt i bruk Bibliofils Z39.50-baserte samsøk? Fordi det koster en del penger, og Bibliofil tilbyr en ikke-standard samsøk-løsning betydelig billigere. Frittstående z-klient, z-klient integrert i OPAC. Bygge egen z-portal osv.

Hva noen systemer har 2 Utlån System nede-funksjon Fjernlånssystem Direct mail til lånergrupper Forhåndsreservering til en best tid (booking) Boken kommer Bilde av lånerne Forskjellige lydsignaler i utlånsskranke Import av lånerdata fra skoleadm. systemer

Hva noen systemer har 3 Katalog/Innkjøp: Enkel kopiering av katalogposter fra andre Filtre ved import av data for å luke ut uønsket informasjon Integrert innkjøp av bøker (Ved bestilling i nettbokhandel overføres katalogdata og innkjøpsdata til ditt biblioteksystem) Det finnes naturligvis mange flere funksjoner som er forskjellige, dette er bare et lite utvalg.

Hva noen systemer har 4 Generelt: Grafisk grensesnitt Brukertilpasning (skjermbilder, søkbarhet, rettigheter, rutiner etc.) Replikering (kopiering av db med toveis oppdatering) Sentral drifting

Hva noen systemer har 5 Generelt: Databasen bør være SQL-kompatibel, eventuelt kompatibel med etterfølgende standarder Alle klientfunksjoner bør kunne kjøres i en nettleser (se f.eks. reindex.net) Viktig å kunne ta ut data fra basen, kunne endre på data globalt uten å spesialskrive store programmer. Ikke alle systemer er SQL-basert. Det skyldes oftest at databasen deres er for gammel.

Bokomslag, omtale, innh.fort. ISBN brukes til å koble den lokale bibliotekkatalogen til en sentral base der omslagsbilde, forlagets bokomtale, baksidetekst og, i noen tilfeller, innholdsfortegnelse ligger. Flere norske biblioteksystemer har tatt i bruk slike løsninger. Dette er et eksempel på en ny funksjon som kanskje ikke er helt nødvendig, men som gjør katalogen betydelig mer levende. Den gjør det også lettere for låneren å se om han har funnet den rette boka.

Bokomslag, bokomtale, innh.fort.

Også BIBSYS har dette

Og Bibliofil har det

Mulige nye tjenester 1 Samtidig oppdatering av flere systemer (Z39.50 gjør det mulig å katalogisere i flere baser samtidig) Forbedret samtidig søk i flere baser (Se UB Karlsruhe, BIMIN, NORZIG) http://www.ubka.uni-karlsruhe.de/hylib/en/kvk.html http://min.bibl.no/ Det er en glidende overgang mellom hva noen systemer har og hva vi kan kalle mulige nye tjenester. I enkelte tilfeller finnes programvaren allerede, i andre tilfeller finnes nødvendig teknologi (verktøy) og i atter andre tilfeller finnes erklært vilje til å utvikle, enten hos myndigheter eller hos programvarehus. Tenk hva samtidig oppdatering av FS, BS og NBs baser ville bety av rasjonalisering!

Mulige nye tjenester 2 Automatisert fjernlån (NILL) Integrering av digitale ressurser innebærer at systemet kan se hvilke tidsskrifter institusjonen abonnerer på, og brukerne kan dermed lese disse på sin PC NILL-standarden er en norsk standard som er enklere enn Z. Den er basert på XML. Forklar hva som ligger i NILL, dvs. automatisk svar fra långivende bibliotek som kommer inn i låntakende biblioteks database.

Mulige nye tjenester 3 Open Archive Initiative Open URL (standard) Automatisk høsting av data til samkataloger Automatisk høsting av data til tverrfaglige databaser (f.eks. Oljedirektoratet) Open URL (standard) Norsk digitalt bibliotek (ABM) Søk i heterogene ressurser, f.eks. bibliotek/bokhandel/web som hos UB Karlsruhe, SFX/Metalib, Z portal, Endeavor) Paradigmeprosjektet (arkivering av Internett). Kun for forskere! Automatisk høsting (i prinsippet som spidere samler inn data) til samkataloger kan erstatte mye manuelt arbeid som gjøres i dag.

Mulige nye tjenester 4 Felles lånerkort for alle norske bibliotek (prosjekt igangsatt) Håndtering av alle tegnsett (arabisk, hindi etc. krever Unicode, få systemer har det i dag) Sentralt vedlikeholdte databaser over databaser (SFX/Metalib) Emneportaler (Bibsys m.fl.)

Mulige nye tjenester 5 Vekting av treff. Dette gjøres i søkemotorer på web, hvorfor ikke i biblioteksystemer? Komponentbaserte systemer Biblioteksystemet kan settes sammen av standardkomponenter fra forskjellige leverandører Korter utviklingstid og øker omstillingsevne

Initiativ savnet! Z-portaler ikke på langt nær så utbredt som man skulle tro Regionale portaler f.eks. folkebibl. Faglige portaler Markedet har ikke fungert her Naturlig oppgave for Norsk Digitalt Bibliotek og ABM!

Bibliotekenes framtid Lex armlengde – man er interessert i de bøker man har innen armlengdes avstand. Lex tastetrykk – man er interessert i den informasjon man har tilgjengelig ved hjelp av et par tastetrykk. Informasjon her og nå – ikke om ei uke jfr SFX/Metalib Ingen bruker fornøyd med en referanse! Lånere skal ikke behøve gå til biblioteket! Sluttbrukerstyrt fjernlån

Hvordan det kan gjøres The Cochrane Library er frikjøpt av SHDIR for alle norske brukere – en av verdens aller beste medisinske databaser. Sjekker om du kommer fra en norsk IP-adresse. http://www.cochrane.no/files/Library.cfm

Systemgenerasjoner 1. generasjon: Tegnbaserte stor/minimaskinsystemer. Proprietær db. Katalog og utlån ofte de første modulene. 2. generasjon: Tegnbaserte PC-systemer. 3. generasjon: Grafisk grensesnitt. "Komplette systemer". Web-basert publikumssøk. Lenking til fulltekstdokumenter. SQL database. 4. generasjon: Komponentbasert. Gjennomført web-grensesnitt i hele systemet. Fulltekst integrert, som f.eks. søking i fulltekstdokumenter, samtidig søk i heterogene ressurser, kobling til elektroniske tidsskrifter, systemet vet om du har abbonnement. Z-portaler. Mobiltelefoner/mobile terminaler. Har forsøkt å kategorisere systemer i "generasjoner". Ikke helt problemfritt, for det er glidende overganger. BIBSYS sine bibliotekarprogrammer er f.eks. 1.generasjon, men websøket ligger mellom 2. og 3. generasjon.

Bibliotekmarkedet Hovedgrupper Allmenne (folkebibliotek, videregående skoler, grunnskoler) Fagbibliotek Høyskoler (små og mellomstore) Universitet (store) Spesialbibliotek (sykehus, musikkbibliotek, departementer, oftest små) Firmaers informasjonssentre (ikke opphengt i marcformat eller tradisjonelle bibliotekdyder)

Biblioteksystem-markedet Forskjellige systemer dominerer de forskjellige markedsnisjene. Ofte historiske årsaker til hvilke systemer som dominerer hvilke nisjer, ikke nødvendigvis systemenes egenskaper avgjørende. Folkebibliotek: Bibliofil, Mikromarc og Aleph Skolebibliotek: Mikromarc, Bibliofil og Tidemann Universitet og høgskoler: Bibsys, Aleph og Mikromarc Spesialbibliotek: Mikromarc, Tidemann, Bibsys og Bibliofil Mange systemer i Norge, de fleste er norsk-utviklet.

Faktorer å vurdere ved kjøp 1 Funksjonalitet, brukervennlighet Videreutvikling Lett å skifte ut (dataene viktigere enn system). Må med i kontrakt! Operativsystem, maskinplattform, minnekrav Norsk leverandør og brukerstøtte Pris (anskaffelse, årlig avgift, hjelp) Samarbeid med andre bibliotek Cost of ownership. Hva betyr det å være eneste norske bruker? Kostnader ved systemskifte. Hva vil det f.eks. koste for Bibsys-bibliotek å skifte system? Eksempel: Avviklingen av Media-systemet og kostnadene for å få dataene ut.

Faktorer å vurdere ved kjøp 2 Er systemet moderne i dag? Hvis ikke, er det sannsynligvis at det vil være det om et år? Om fem år? Systemene i norske bibliotek er 1.- 3. generasjon, men 4. generasjon er tilgjengelig. Vi kan derfor komme til å se en omfattende utskifting i de neste årene. Cost of ownership. Hva betyr det å være eneste norske bruker? Kostnader ved systemskifte. Hva vil det f.eks. koste for Bibsys-bibliotek å skifte system? Eksempel: Avviklingen av Media-systemet og kostnadene for å få dataene ut.

Sentral drifting Fordeler: Ulemper: IT-avdelinger glade for å slippe ansvar for biblioteket (marginalt) Biblioteket glade for å slippe ansvar for IT (kompetanse) Sikrere backup Alltid siste versjon installert Ulemper: Ikke alltid gratis Båndbredde kan være problem MM2 og Aleph krever minst 64 mbit/s. Man bør imidlertid ha mer.

Leverandører av katalogdata Biblioteksentralen – slik bibliotek vil ha dem Forlagsentralen – ofte raskest Nasjonalbiblioteket – "gratis" poster Bibsys – "gratis" poster for outsidere Samme arbeidet gjøres minst 3-4 ganger i Norge Dere bør ikke gjøre det enda en gang Internett – "gratis" poster Hvem har copyright til katalogposter? Er en katalogpost et åndsverk? Har et bibliotek copyright på data som er skrevet av ei bok? Er det forlagets data?

Tenk økonomi og trivsel! BS og FS tilbyr integrert bokkjøp og overføring av katalogpost og eksemplaropplysninger. Mer enn halvparten av arbeidet spart ved å bruke ferdige katalogposter. Brukerne betaler for arbeidstiden din!

Forslag til videre lesning http://www.biblio-tech.com/ (teknisk web-mag., månedlig) http://www.ariadne.ac.uk/ (teknisk web-mag., kvartalsvis) http://www.libraryjournal.com (generelt, 20 nr årlig) http://www.nb.no/html/postlister.html (postlister) http://www.nb.no/ (Nasjonalbiblioteket) Norsk digitalt bibliotek http://www.nb.no/paradigma/ (Paradigme-prosjektet) http://www.mgmt.dal.ca/slis/etig/itcolumn/ITZ39.htm (Z39.50 in your library)

Leverandørene Biblioteksystemer Katalogdata http://www.bibits.no http://www.bibliotekservice.no http://www.bibsys.no http://www.bibsyst.no http://www.reindex.net Katalogdata http://www.bibsent.no/bibbi/side1.shtml Alle bibliotekkataloger i landet http://www.nb.no/baser/bibliotek/

Standarder http://dublincore.org http://www.loc.gov/marc/marc.html http://www.loc.gov/marc/marcxml.html http://www.w3.org/ http://www.nb.no/katkom/NORMARC/normarc.html

Forelesning 2: Hva alle bør ha Innkjøpssystem Katalogsystem m/autoritetsregister Utlånssystem Publikumssøk m/bestilling, melding på web Tidsskriftsystem Statistikk og rapportfunksjon enkel å bruke! Sanntids oppdatering Filialhåndtering, konsortiehåndtering Dette er kun en rask innføring i hva et biblioteksystem bør inneholde og ingen fullstendig kravspesifikasjon.

Innkjøpssystem (Akkvisisjon) Innkjøpssystemet skal holde orden på anskaffelsesønsker bokvalg ordre oppfølging (purring etc) mottak mediebudsjett Det bør ha mulighet for direkte kommunikasjon med leverandører Velger termen Innkjøp, da de fleste anskaffelser er kjøp.

Innkjøp Valutahåndtering Leverandøropplysninger Bestille for andre bibliotek/filialer Håndtere flere konti Vise forbruk/tilgjengelige midler grafisk Overføre penger mellom år Fordeling av budsjett over måneder Forskellig mønster bøker/tidsskrifter Bruke EAN for å søke EAN = European Article Number

Innkjøp Bøker som skal bestilles, må kunne reserveres Endring av eksemplarstatus Setting av innstillinger for hvordan mottatte bøker skal behandles (innbinding, utlån etc).

Innkjøp Et innkjøpssystem er ikke et regnskapssystem, men kan likevel gi god økonomisk oversikt. Egne regler for regnskapssystem

Katalogisering Det må kunne styres hva som skal autoriseres Katalogprogram må ha tilgang til Bibliografiske data Eksemplaropplysninger Autoritetsfiler Emneord Klassifikasjonssystem

Katalogisering Autoritetsregistre må kunne oppdateres direkte fra katalogprogrammet Endring av autoritetsregistre bør ha en kontrollmekanisme som "Ønsker du virkelig å gjøre dette?". Globalt å bytte ut en term med en annen kan være risikabelt

Katalogisering Sømløs kopiering av eksterne poster Sømløs kommunikasjon m/Innkjøp Sømløs kommunikasjon m/Utlån og fjernlånsfunksjon Forhåndsvisning i ISBD/MARC, evt. andre standardformater Bør kunne velge hvilket format data skal lagres i og vises i

Katalogisering – søk Søking må kunne høyre-, venstre- og midttrunkeres Trunkeringstegn bør være valgfritt "Alt" bør være søkbart, også eksemplaropplysninger Kommandosøk Indeksblaing Grafisk søk

Katalogisering Henvisninger må kunne håndteres direkte i katalogisering (autoritet) Søk på en form må gi treff på de andre formene Eks.: Mumle Gåsegg må også gi treff på Johan Borgen

Katalogisering Katalogisering av flerbindsverk må være mulig og enkel å utføre Lenking mellom versjoner av et dokument bør være mulig Lenking av bind i flerbindsverk nødvendig FRBR Functional Requirements for Bibliographic Records Hvis du er interessert i FRBR, se: http://folk.uio.no/knuthe/dok/frbr/datamining.pdf

Katalogstatistikk Årlig tilvekst Total samling Samlingens fordeling på fag, medietype, lånergrupper og filialer Tilvekstens fordeling på fag, medietype, lånergrupper og filialer Budsjettets fordeling på fag, medietype, lånergrupper og filialer Bibliotekmyndigheters krav

Søking Søking i samlingen bør være tilgjengelig fra alle større moduler Grensesnitt bør helst være nokså likt fra modul til modul Det bør være mulig å lagre søk Det bør være mulig å få personifiserte meldinger om nyheter

Utlån Registrere utlån og tilbakelevering Reservere dokumenter Varsel til skrankepersonale Reservere dokumenter Forhåndsreservere (booke) Fornye lån Purre/Rykke Reserveringsbrev/epost

Utlån Fleksibelt oppsett av utlånsbetingelser og overdagspenger Enkelt oppsett for når bibliotekets filialer er åpne Justere forfallsdato tilsvarende, slik at ikke bøker forfaller på dager biblioteket er stengt.

Utlån Utlån av elektroniske dokumenter er spesielt Bør elektroniske dokumenter tilbakeleveres? Hvis ikke, må dokumentet bli ubrukelig når lånetid er utløpt Hvis ja, hva skiller det fra et vanlig lån?

Rapporter Det bør være enkelt å ta ut rapporter på Ankomne reserveringer Uavhentede reserveringer Bøker som er/har vært reservert Lånere som skylder penger Lånere som er sperret Bøker som skal flyttes Eksemplarer med en bestemt status Det bør være enkelt å modifisere rapporter og skape sine egne

Utlånsstatistikk 1 Totalt antall lån i en gitt periode Lån fordelt på filial, lånergruppe, faggruppe, materialtype De mest utlånte titler (innkjøp) De minst utlånte titler (kassering) De mest aktive lånergrupper (ta hensyn til i mediebudsjett?) De minst aktive lånergrupper (markedsføring) Historie fra virkeligheten: Et bibliotek fikk beskjed av kommunestyret om å legge ned en filial. Da biblioteket brukte utlånsstatistikken som viste hvor mye lånere med postnr som grenset til filialen hadde lånt, ble nedleggingen stanset.

Utlånsstatistikk 2 Statistikk bør lett la seg kopiere til andre programmer (tekstbehandling, regneark) Grafer bør produseres Bør kunne definere nye statistikker, for eksempel ved hjelp av SQL Bør tilfredsstille myndigheters krav Historie fra virkeligheten: Et bibliotek fikk beskjed av kommunestyret om å legge ned en filial. Da biblioteket brukte utlånsstatistikken som viste hvor mye lånere med postnr som grenset til filialen hadde lånt, ble nedleggingen stanset.

Utlån - Fjernlån Systemet bør håndtere både innlån fra andre bibliotek og utlån til andre bibliotek. Bør håndtere kopier og elektroniske lån Bør gjøre bruk av nasjonale og internasjonale standarder I Norge: NILL og Base Bibliotek

Publikumssøk Skal være selv-instruerende Skal likevel ha kraftige søkemuligheter Velge mellom ett eller flere-felt-skjerm, indeksblaing, grafisk søk Bør ha valgfritt språk Bør vise lenkede dokumenter (flerb.) Bør ha kart over biblioteket Et eksempel: Informatikkbiblioteket: http://www.ub.uio.no/umn/inf/kart/ifib.html

Publikumssøk Bør kunne reservere Bør kunne se nyheter i biblioteket også be om fjernlån Bør kunne se nyheter i biblioteket Bør kunne se de mest populære titler Bør kunne se egne lån Bør kunne avbestille reserveringer Bør kunne se tilknyttede dokumenter (både fulltekst og evt. lenkede referanser)

Publikumssøk og andre bibl. Andre bibliotek vil ønske å se MARC-poster slik at de kan kopiere eller sjekke egen katalogisering Andre bibliotek vil ønske å be om fjernlån

Tidsskriftkontroll Heftekontroll Sirkulasjonskontroll Utsending av innholdsfortegnelse Tilgang til elektronisk tidsskrifthefte (kan også plasseres andre steder i systemet) Varsling om nye hefter for tidsskrifter innen låners interessefelt

Tidsskriftkontroll Utgivelsesmønstre varierer System må være fleksibelt System kan bli svært komplisert Avhengig av god datamodell og planlegging

Oppetid Systemets oppetid Må være oppe så lenge biblioteket er åpent Bør være oppe 24t x 7 Brukerstøtte bør være tilgjengelig i bibliotekets åpningstid

Sikkerhet 1 Databasen må ikke være fysisk tilgjengelig for alle brukere ODBC er en måte å oppnå dette på (Open Database Connection) Databasen må ha muligheter for selv-reparasjon ved f.eks. strømbrudd. Checkpoints , rollback Loggfiler Speiling

Sikkerhet 2 Forskjellige brukergrupper må kunne settes opp med forskjellige adgangsnivåer Bibliotek i konsortier bør ikke se hverandres utlånsdata

Dette er ingen spesifikasjon Forelesningsnotatene fra denne og forrige forelesning er kun en generell innføring, de er ingen kravspesifikasjon Mange institusjoner har laget svært detaljerte krav, mange av dem kan gjenbrukes! Ikke sikkert at du finner et system som tilfredsstiller ALLE kravene – må veie krav mot hverandre Forskjell på kravspesifikasjon for utviklingen av et nytt system og på de kravene man stiller når man skal kjøpe et system.