Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016

Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: ddb@kulturstyrelsen.dk med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl 12.00. 1. Bibliotek og kontaktoplysninger: Biblioteket Frederiksberg Michael Thomsen, Sektionschef, stab & administration +45 38 21 18 19 mith04@frederiksberg.dk 2. Generelle bemærkninger: 1. Det ser ud til at mange af forslagene vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? 2. Søgning efter biblitoeksmaterialer er måske den vigtigste funktionalitet vi stiller til rådighed. Umiddelbart tager ingen af de foreslåede projekter hånd om det væsentlige problem, at default sorteringen af søgeresultater i DDB CMS er Bedste match, som ikke virker særlig godt, og ofte rankeres det mest relevante materiale ikke øverst. I stedet for at at boost/rankering skal administreres af de enkelte biblioteker, bør der centralt udvikles en rankerings algoritme der virker bedre out of the box. Der spildes mange ressourcer både fra biblitoekspersonale (administration af boost/rankering) og brugere (forgæves søgninger der ikke giver relevant materiale). 3. Prioritering og kommentering af udviklingsprojekter Hver projektkandidat gives en prioritet fra 0 til 3, alt efter hvor relevant udviklingsprojektet anses for at være: 0 = Bør ikke gennemføres 1 = Lav relevans 1

2 = Medium relevans 3 = Høj relevans Projekt R16.01 - Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: 2 Projekt R16.02 - Børneforslagsstiller: Underholdning og læring Angiv prioritering: 1 Projekt R16.03 - Forslagsstiller og rankering - oplevelsesindhold Angiv prioritering: 2 Projekt R16.04 - Det dynamiske vidensystem alle grænseflader Angiv prioritering: 2 Med Personalisering (release i DDB CMS ultimo 2015) opsamles der også data om brugeren (lånehistorik, interesser mm.) som også kan bidrage hertil. Projekt R16.05 - Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering: 1 2

Projekt R16.06 - Adgangsplatformen (analyse) Angiv prioritering: 3 Projekt R16.07 - BOB-basen: Vis infomedia-links i artikelbestillinger Angiv prioritering: 2 Projekt R16.08 - Bibliotek.dk: Vis nærmeste bibliotek der har åbent Angiv prioritering: 1 Projekt R16.09 - Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: 3 Projekt R16.10 - Bibliotek.dk: Bestil flere materialer i et hug Angiv prioritering: 1 Projekt R16.11 - Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt Angiv prioritering: 3 3

Projekt R16.12 - Søgning i eksterne dataset gennem OpenSearch Angiv prioritering: 2 Projekt R16.13 - Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: 2 Projekt R16.14 - KontekstSØG for forskere og studerende Angiv prioritering: 1 Projekt R16.15 - Brugsscenarier for geodata i brønden Angiv prioritering: 1 Projekt R16.16 - Service til konvertering og udlevering af geodata Angiv prioritering: 1 Projekt R16.17 - Konsolidering Fase 2 - Konsolidering af de fælles mobile løsninger til den nye arkitektur 4

Angiv prioritering: 1 Projekt R16.18 - Konsolidering Fase 2 - Konsolidering af de sidste nationale funktioner og idriftsættelse af bibliotek.dk Angiv prioritering: 3 Projekt R16.19 - Konsolidering Fase 2 - Nationale funktioner fra bibliotek.dk til DDB CMS Angiv prioritering: 2 Projekt R16.20 - Netpunkt.dk: fase 2 af ny grænseflade til netpunkt.dk Angiv prioritering: 3 Projekt R16.21 - Bibliotek.dk: Integration med andre systemer Angiv prioritering: 3 Der bør kunne søges i bibliotek.dk fra lokale bibliotekers egen webside, således at hvis et materiale ikke er tilgængeligt lokalt, vises det i samme søgning, at materialet i stedet kan anskaffes fra andet bibliotek. Nu hvor både DDB CMS og bibliotek.dk er baseret på Brønden, burde det være muligt, og det vil skabe en bedre sømløs brugeroplevelse, at brugeren ikke skal bevæge sig imellem to forskellige grænseflader/indgange. 5

Projekt R16.22 - BOB: Låse en bestilling i BOB- implementeringsprojekt Angiv prioritering: 2 Projekt R16.23 - Automatisk fjernlån som service: Hvem kan levere først? Angiv prioritering: 3 Projekt R16.24 - Skalering af databrøndens repositoriestruktur Angiv prioritering: 2 Projekt R16.25 - Udbygning af OAI-PMH høst fra Danbib Angiv prioritering:? Projekt R16.26 - Dataflow til Danbibs nye Data I/O System Angiv prioritering:? Projekt R16.27 - Repository til autoritetsdata Angiv prioritering: 3 6

Projekt R16.28 - Servicelag til autoritetsdata repository Angiv prioritering:? Projekt R16.29 - Implementering af RDA i den nationale infrastruktur Angiv prioritering:? Projekt R16.30 - Data: Analyseprojekt vedrørende BIBFRAME Angiv prioritering:? Projekt R16.31 - Linked data i den nationale infrastruktur Angiv prioritering:? Projekt R16.32 - Automatisk fjernlån af eget materiale Angiv prioritering:? Projekt R16.33 - Yderligere udvikling og effektivisering af fjernlån 7

Angiv prioritering:? Projekt R16.34 - OpenOrder: Migrere php-openorder til JavaEE Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? Projekt R16.35 - OpenHoldingStatus: Optimering af holdingsopslag mod FBSbiblioteker Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? Projekt R16.36 - OpenHoldingStatus: Migrere php-openholdingstatus til JavaEE Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? Projekt R16.37 - OpenRS: Migrere C++-delen til JavaEE Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? 8

Projekt R16.38 - OpenRS: Skifte DBMS fra Oracle til Postgres Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? Projekt R16.39 - OpenRS: Flytte z3950-holdingsopslag til migreret (JEE)- OpenHoldingstatus-webservice Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? Projekt R16.40 - VIP-basen (OpenAgency) migreres til Postgres Enig med FGI s vurdering Det ser ud til at det vil give besparelser for bibliotekerne. Vil besparelsen betyde fx lavere bidrag? 9

Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: ddb@kulturstyrelsen.dk med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl 12.00. 1. Bibliotek og kontaktoplysninger: Aarhus Kommunes Biblioteker Møllegade 1 8000 Aarhus C. Kontaktperson: Per Kjær 2. Generelle bemærkninger: Personaliseringsprojektet bør inddrages i flere af projekterne: R16.02 ; R16.06 3. Prioritering og kommentering af udviklingsprojekter Hver projektkandidat gives en prioritet fra 0 til 3, alt efter hvor relevant udviklingsprojektet anses for at være: 0 = Bør ikke gennemføres 1 = Lav relevans 2 = Medium relevans 3 = Høj relevans Projekt R16.01 - Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: 3 Ser det som en fordel for bibliotek.dk 10

Desuden ses det som en del af processen for at få DDB CMS til ligeledes at understøtte ADHL i forhold til digitale ressourcer. Endelig kunne ADHL på digitale ressourcer indgå i rankering. Projekt R16.02 - Børneforslagsstiller: Underholdning og læring Angiv prioritering: 3 i forhold til analysedelen Usikkert, hvilken værdi dette projekt giver for slutbrugerne. Vi vil derfor anbefale en foranalyse, inden man eventuelt beslutter sig for at gå videre med udviklingen. I analysen er det vigtigt, at der fremkommer use cases, som fortæller hvordan forretningen (bibliotekerne) bliver inddraget i den videre proces. Projekt R16.03 - Forslagsstiller og rankering - oplevelsesindhold Angiv prioritering: 3 i forhold til analysedelen incl. pilot Høj relevans af analysefasen. Mener dog, at man allerede i pilot skal indtænke DDB CMS. Projekt R16.04 - Det dynamiske vidensystem alle grænseflader Angiv prioritering: 3 Høj relevans og fundament for det videre arbejde med forslagsstillere, rankering og et utal af nye anvendelsesmuligheder. Samtidig sikrer dette et demokratisk ejerskab til dataene, hvorfor det er vigtigt, at biblioteker, projekter og leverandører kan anvende disse data. Projekt R16.05 - Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering: 1-2 11

Biblioteket er ikke en øde ø, hvorfor det vil være rigtig godt, hvis man kan inddrage data fra den kontekst, som vores brugere er en del af på nettet, herunder sociale medier m.v. Projekt R16.06 - Adgangsplatformen (analyse) Angiv prioritering: 0 Vi mener, at CULR og SAOU bør være implementeret i forhold til vores egen sektor, inden man begynder at tænke på nye muligheder. F.eks. de forskellige nettjenester under DDB som ereolen, App en til DDB CMS. CULR og SAOU projekterne har været kendetegnet ved at være teknisk komplekse og dermed måske vanskelige at forholde sig til ude i bibliotekerne. Derfor mener vi, at fokus i 2016 må være at få de to services implementeret og taget i anvendelse. Projekt R16.07 - BOB-basen: Vis infomedia-links i artikelbestillinger Angiv prioritering: 0 Vi mener der er et licensproblem i dette, da vi bibliotekerne kun har købt adgang til brug på stedet. Projekt R16.08 - Bibliotek.dk: Vis nærmeste bibliotek der har åbent Angiv prioritering: 1 Mener at forslaget skal vende os, således at åbningstids-data skabes i DDB CMS, og herfra skubbes over i VIP-basen. Samtidig kunne det være et problem med Åbne Biblioteker, hvor man ikke nødvendigvis giver alle landets borgere adgang til nærmeste bibliotek. Projekt R16.09 - Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: 1 12

Projekt R16.10 - Bibliotek.dk: Bestil flere materialer i et hug Angiv prioritering: 1 Vi har et forbehold i forhold til den øgede arbejdsmængde forslaget sandsynligvis vil medføre ude i bibliotekerne. Blandt andet fratagning af materialerne, da dette fortsat er en manuel proces i de fysiske biblioteker; af den grund sætter vi prioriteten lav. Mængden af uafhentede reserveringer vil øges endnu værre, hvis der er tale om fjernlånt materiale. Projekt R16.11 - Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt Angiv prioritering: 1 Projekt R16.12 - Søgning i eksterne dataset gennem OpenSearch Angiv prioritering: 3 Vi mener det er vigtigt at få etableret et projekt omkring dette; det kunne give nye muligheder på en række områder (f.eks. musik) Projekt R16.13 - Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: 2 Enig i FGI s vurdering. Projekt R16.14 - KontekstSØG for forskere og studerende Angiv prioritering: 0 13

Projekt R16.15 - Brugsscenarier for geodata i brønden Angiv prioritering: 1 Projekt R16.16 - Service til konvertering og udlevering af geodata Angiv prioritering: 1 Projekt R16.17 - Konsolidering Fase 2 - Konsolidering af de fælles mobile løsninger til den nye arkitektur Angiv prioritering: 1 Enig med FGI s i, at der stilles en ramme. Projekt R16.18 - Konsolidering Fase 2 - Konsolidering af de sidste nationale funktioner og idriftsættelse af bibliotek.dk Angiv prioritering: 1 Enig med FGI s i, at der stilles en ramme, men ikke i deres prioritering. Projekt R16.19 - Konsolidering Fase 2 - Nationale funktioner fra bibliotek.dk til DDB CMS Angiv prioritering: 1 Enig med FGI s i, at der stilles en ramme. 14

Projekt R16.20 - Netpunkt.dk: fase 2 af ny grænseflade til netpunkt.dk Angiv prioritering: 0 Vi har svært ved at forstå, hvorfor denne udvikling er nødvendig for netpunkt.dk. Vi kunne godt tænke os at se en business case, der viser, at dette giver merværdi for bibliotekerne. Et ressourceforbrug på 3000 timer er meget. Projekt R16.21 - Bibliotek.dk: Integration med andre systemer Angiv prioritering: 1 Savner en beskrivelse af hvilke andre systemer bibliotek.dk skal integrere med. Projekt R16.22 - BOB: Låse en bestilling i BOB- implementeringsprojekt Angiv prioritering: 0 Har aldrig haft dette problem, selv om vi er et stort bibliotek. Projekt R16.23 - Automatisk fjernlån som service: Hvem kan levere først? Angiv prioritering: 1 Er bekymret for, at dette går uden om besluttede låneveje. Bekymret for, at dette vil give en belastning af nogle få/enkelte biblioteker. Positivt, at funktionen udstilles som webservice. Projekt R16.24 - Skalering af databrøndens repositoriestruktur Angiv prioritering: 2 Enig i at Brønden bør kunne scaleres. Man bør dog forholde sig til om de nævnte kilder skal være repræsenteret i BRØNDen set i forhold til OpenSearch (R16.12). En konsekvens af at lægge så store 15

kilder i Brønden kan desuden være, at DDB CMS grænsefladen skal gentænkes, således at søgeresultaterne ikke bliver skævvredet. Projekt R16.25 - Udbygning af OAI-PMH høst fra Danbib Angiv prioritering: 1 Kan ikke vurdere relevans før vi ikke kender omfanget og hvilken business case det adresserer. Projekt R16.26 - Dataflow til Danbibs nye Data I/O System Angiv prioritering: 3 Projekt R16.27 - Repository til autoritetsdata Angiv prioritering: 2 Projekt R16.28 - Servicelag til autoritetsdata repository Angiv prioritering: 2 Projekt R16.29 - Implementering af RDA i den nationale infrastruktur Angiv prioritering: 2 Indførsel af RDA i Danmark er endnu ikke besluttet, men vil være en sandsynlig og nødvendig - udvikling. Men vi vil gerne gøre opmærksom på, at vi er bekymrede for på nuværende tidspunkt at 16

fastlægge en ramme på 2.000-6.000 timer for Brønd og servicelag, samtidig med, at vi pålægger grænsefladeleverandørerne tilpasning i ukendt omfang. Hvis beslutning/implementering ikke kommer i 2016, vil ressourcerne så blive fritsat til anden udvikling? Projekt R16.30 - Data: Analyseprojekt vedrørende BIBFRAME Angiv prioritering: 3 Projekt R16.31 - Linked data i den nationale infrastruktur Angiv prioritering: 0 Enig med FGI s vurdering. Projekt R16.32 - Automatisk fjernlån af eget materiale Angiv prioritering: 0 Savner en nærmere beskrivelse af dette projekt før vi kan forholdes os til projektet. Projekt R16.33 - Yderligere udvikling og effektivisering af fjernlån Angiv prioritering: 0 Projekt R16.34 - OpenOrder: Migrere php-openorder til JavaEE Angiv prioritering: 3 Enig med FGI s vurdering. 17

Projekt R16.35 - OpenHoldingStatus: Optimering af holdingsopslag mod FBSbiblioteker Angiv prioritering: 3 Enig med FGI s vurdering. Projekt R16.36 - OpenHoldingStatus: Migrere php-openholdingstatus til JavaEE Angiv prioritering: 3 Enig med FGI s vurdering. Projekt R16.37 - OpenRS: Migrere C++-delen til JavaEE Angiv prioritering: 3 Enig med FGI s vurdering. Projekt R16.38 - OpenRS: Skifte DBMS fra Oracle til Postgres Angiv prioritering: 3 Enig med FGI s vurdering. Projekt R16.39 - OpenRS: Flytte z3950-holdingsopslag til migreret (JEE)- OpenHoldingstatus-webservice 18

Angiv prioritering: 3 Enig med FGI s vurdering. Projekt R16.40 - VIP-basen (OpenAgency) migreres til Postgres Angiv prioritering: 3 Enig med FGI s vurdering. 19

Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: ddb@kulturstyrelsen.dk med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl 12.00. 1. Bibliotek og kontaktoplysninger: Københavns Biblioteker Krystalgade 15 1172 Københavns K Email: reneho@kff.kk.dk tlf. 24 77 01 42 2. Generelle bemærkninger: Fremstillingsformen i udviklingsplanen er til tider meget indforstået i sin sprogbrug. Og da udviklingsplanen i høj grad også bliver vurderet af ikke-teknisk kyndige, altså af formidlere og bibliotekernes forretningskyndige, bør udviklingsplanen fremadrettet forsøge at være mere pædagogisk i sin fremstilling og se sin målgruppe bredere. Fx kunne man overveje at inkluderer et brugsscenarie ved emnerne, så potentialet bliver beskrevet mere illustrativt. Dette ville formentlig også give forøget interesse for at kvalificere udviklingsplanen. Fremstillingensformen kunne desuden også præsenterer sammenhængene mellem de forskellige emner tydeligere. Det er ikke altid lige klart, hvorfor emner er adskilt fra hinanden og relationsformuleringer som Forudsætter et grundsystem udviklet via 2015-projekterne og mindst et af 2016-projekterne skaber ikke forståelse eller overblik. Mange gode ambitioner risikerer at blive vurderet mindre relevant, end en givent emne reelt er, når relationerne/sammenhængende med andre projekter ikke er tydeligt og læseren således ikke helt ser, hvad potentialet er. Generelt vurderer København Biblioteker, at FGI s mange opfordringer til (for)analysefaser er den hensigtsmæssige fremgangsmåde, når emnerne er af en betydelig størrelse. Desuden vurderer Københavns Biblioteker, at hvis større projekters foranalyser kvalificerer et emne til videreudvikling, så bør bibliotekerne orienteres om såvel analysernes konklusioner som DDBs anbefalinger til den videre proces, inden projektet videreføres, hvis emnernes ressourcebehov er af et vist omfang (fx over 200 timer og derover). 20

I forlængelse af ovenstående anbefales det desuden, at man trykprøver use cases i en bredere, låner-/borgernære sammenhænge. Gerne inddrager relevante biblioteker i udformningen, så use casene kommer så tæt på den borgernære erfaring som muligt. Generelt anbefales det, at alt der udvikles til Bibliotek.dk og Danbib udvikles til at kunne fungerer i DDB-cms og vice versa. Hvorvidt dette reelt er den allerede eksisterende ambition er ikke helt tydelig i fremstillingen. Som afsluttende bemærkning, så er mange af emnerne vurderet ressourcemæssigt som lille, mellem etc. Ressourcebehovet bør præciseres, før emner kan reelt kan vurderes og det bør således genudsendes til høring 3. Prioritering og kommentering af udviklingsprojekter Hver projektkandidat gives en prioritet fra 0 til 3, alt efter hvor relevant udviklingsprojektet anses for at være: 0 = Bør ikke gennemføres 1 = Lav relevans 2 = Medium relevans 3 = Høj relevans Projekt R16.01 - Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: _som FGI Enig FGI s indstilling. Godt sammenhæng til digitale materialer. 21

Projekt R16.02 - Børneforslagsstiller: Underholdning og læring Angiv prioritering: _som FGI Enig i FGI s bemærkning. Det anbefales desuden, at analysen fokuserer på, at der laves en parallel-pilotimplementering ved en række DDB-biblioteker ved en evt. implementeringspilot i Palles Next, således potentialet afprøves en bredere formidlingskontekst. Kommentar- overveje efter implementerering Projekt R16.03 - Forslagsstiller og rankering - oplevelsesindhold Angiv prioritering: _som FGI Enig FGI s instilling. Det anbefales pilotimplementering foretages i DDB-cms eller lignende - i samarbejde med en række mindre biblioteker, frem for en pilot i bibliotek.dk-skala. Anskues desuden som mindre væsentlig end Projekt R16.04 Målgruppen bør desuden præciseres hvem er bibliotek.dk-brugeren? Det anbefales desuden, at analysen inddrager erfaring og løsninger fra DDB s/tings personaliseringsprojekt 1 og 2 Projekt R16.04 - Det dynamiske vidensystem alle grænseflader Angiv prioritering: _2 Projekt R16.05 - Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering: _som FGI Enig med FGI s indstilling Københavns vurderer, at det er vigtigt, at analysen eksplicit specificerer sin relevansforståelse - og evt. indtænker flere relevansoptikker for at understøtte flere forskellige former for relevansparametre ved ranking. Det anbefales desuden, at der ikke kun skeles til datasæt trukket ud fra brugernes digitale adfærd, men at der også medtænkes en bedre dataoptik, hvor situationsspecifikke data fra fysiske og kulturelle omstændigheder inddrages som relevant data(tænk: Smartcity) 22

Projekt R16.06 - Adgangsplatformen (analyse) Enig i FGI s relevansvurdering. Måske skulle det bare kaldes Single sign on Projekt R16.07 - BOB-basen: Vis infomedia-links i artikelbestillinger Angiv prioritering: _1 Lav relevans. Funktionaliteten er udmærket, men er af begrænset relevans, hvis links til Infomedia integreres i respektive OPAC. Projekt R16.08 - Bibliotek.dk: Vis nærmeste bibliotek der har åbent Perspektivet er forkert. Det er ganske enkelt for besværligt at vedligeholde oplysninger om åbningstider via VIP. Det anbefales i stedet, at der laves en integration fra åbningstider indskrevet i lokale web-grænseflade til VIP som det første skridt, inden R16.08 gennemføres. Projekt R16.09 - Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: _som FGI Genbrug af Personaliseringsprojektet er fint. Enig med FGI Projekt R16.10 - Bibliotek.dk: Bestil flere materialer i et hug Oplagt. Men hvorfor kun på bibliotek.dk? Projekt R16.11 - Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt Angiv prioritering: _som FGI Enig med FGI. Det anbefales desuden, at analyseprojektet overvejer, om funktionalitet kan integreres i lokale grænseflader, så status på fjernlån kan ses der. Det er MINDST ligeså relevant 23

Projekt R16.12 - Søgning i eksterne dataset gennem OpenSearch Angiv prioritering: _som FGI Enig med FGI. Projekt R16.13 - Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: _1 Som præsenteret 1=relevans. Spørgsmålet er, om det er de relevante kriterier. København ser gerne en større præcisering af, hvorfor disse kriterier er valgt, da mange andre kriterier kunne være relevant fx geografi. De valgte filtre virker tilfældige. Projekt R16.14 - KontekstSØG for forskere og studerende Angiv prioritering: _som FGI Enig med FGI og BIL. Spørgsmålet er, at om forskere og studerende er det interessante startsted. Kunne man forestille sig, at det i første omgang bliver tænkt til en mere snæver gruppe, når der laves en prototype. Projekt R16.15 - Brugsscenarier for geodata i brønden Angiv prioritering: _3 Det anbefales, at der nedsættes et udvalg af repræsentanter fra forskellige bibliotekstyper til at foretage udvælgelsen og beskrivelsen af de relevant brugsscenarier. Med mængden er potentielle data, er det vigtigt, at der udvikles ud fra relevante (borgernære) brugsbehov. Projekt R16.16 - Service til konvertering og udlevering af geodata Angiv prioritering: 3_ se R16.15 Projekt R16.17 - Konsolidering Fase 2 - Konsolidering af de fælles mobile løsninger til den nye arkitektur Angiv prioritering: 2_ 24

Enig med FGI. Dog anskues som 2=medium relevant Projekt R16.18 - Konsolidering Fase 2 - Konsolidering af de sidste nationale funktioner og idriftsættelse af bibliotek.dk Angiv prioritering: 2_ Enig med FGI. Dog anskues som 2=medium relevant af København Projekt R16.19 - Konsolidering Fase 2 - Nationale funktioner fra bibliotek.dk til DDB CMS Enig med FGI. Dog anskues som 2=medium relevant af København Projekt R16.20 - Netpunkt.dk: fase 2 af ny grænseflade til netpunkt.dk Enig med FGI Projekt R16.21 - Bibliotek.dk: Integration med andre systemer Enig med FGI Projekt R16.22 - BOB: Låse en bestilling i BOB- implementeringsprojekt Ikke relevant set med København øjne. Behovet er meget lokalt, da der er forskellige arbejdsmetoder ved forskellige biblioteker. Behovet bør præciseres inden analysen igangsættes. Projekt R16.23 - Automatisk fjernlån som service: Hvem kan levere først? Angiv prioritering: som FGI_ Hvis udviklingen betyder, at man kan integrere eget bibliotekssystems reserveringkø med de indkommende bestillinger i bibliotek.dk, vil det være et stort løft. Systemet med automatisk fjernlån af eget materiale opleves af flere kolleger som meget uretfærdigt, da lånere som reserverer i eget system risikerer at stå i kø meget længere, end hvis man bestiller i bibliotek.dk. 25

En præcisering af løsning ville dog være rar, da der det ikke er klart, hvordan løsningen vurderer hvem der kan levere først Projekt R16.24 - Skalering af databrøndens repositoriestruktur Angiv prioritering: som FGI_ Enig med FGI Projekt R16.25 - Udbygning af OAI-PMH høst fra Danbib R16.25 hedder noget andet i høringsmaterialet. Projekt R16.26 - Dataflow til Danbibs nye Data I/O System Angiv prioritering: som FGI Enig med FGI Projekt R16.27 - Repository til autoritetsdata Alle biblioteker der anvende den fælles nationale infrastruktur vil være relevante samarbejdspartnere. Det er vigtigt, at repositoriet udvikles med en facetteret model for samarbejde om autoritetsdata. Det bør desuden overvejes, om der 3. parter der kan levere/vedligeholde visse aspekter af dataene til repositoriet indirekte fx andre ABM-institutioner, men potentielt også institutioner uden for biblitoekssektoren, hvis der er relevante for den givne autoritetsdata. Projekt R16.28 - Servicelag til autoritetsdata repository Samme som R16.25. 26

Projekt R16.29 - Implementering af RDA i den nationale infrastruktur Som beskrevet, er datamodellen sandsynligvis afgørende i forhold til implementering af RDA, da det fulde potentiale ikke vurderes at kunne udnyttes i marc-formatet. Beslutninger i relation til RDA skal således ses i relation til R16.31. Således bør også dette drøftes bredt i sektoren, således der kan laves en fornuftig prioritering om implementering af RDA. Projekt R16.30 - Data: Analyseprojekt vedrørende BIBFRAME Se kommentar til R.16.29 Projekt R16.31 - Linked data i den nationale infrastruktur Enig med FGI, dog har København en anden relevansvurdering, nemlig 3. Der anbefales desuden en nærmere dialog med DDB og andre relevant aktører, fx Bibliografisk Råd på baggrund af 2015-analysen. Projekt R16.32 Automatisk fjernlån af eget materiale Det er fint med en ekstra standardmodel med parametre defineret af FFU-bibliotekerne. Det ville stadig være optimalt, hvis vi kunne få udviklet folkebiblioteksmodellen, så der kan trimmes på ventetid i eget system. Vi synes stadig 14 dages ventetid er lidt, når man som vi har ex., som kan nå at komme hjem inden for den periode. Projekt R16.33 - Yderligere udvikling og effektivisering af fjernlån Ja, det er fint at afsætte ressourcer til disse projekter for mindre FFU-biblioteker. 27

Projekt R16.34 - OpenOrder: Migrere php-openorder til JavaEE Når det medtages udviklingsplanen, bør der fremgå tydeligere, hvordan det skaber en mere optimal driftsafvikling og som følge deraf en optimering af bibliotek.dk/danbib/ddb s driftsøkonomi Dette gælder også for R16.36-R16.40 Projekt R16.35 - OpenHoldingStatus: Optimering af holdingsopslag mod FBSbiblioteker Projekt R16.36 - OpenHoldingStatus: Migrere php-openholdingstatus til JavaEE Projekt R16.37 - OpenRS: Migrere C++-delen til JavaEE Projekt R16.38 - OpenRS: Skifte DBMS fra Oracle til Postgres Projekt R16.39 - OpenRS: Flytte z3950-holdingsopslag til migreret (JEE)- OpenHoldingstatus-webservice I indledningen efterlyste via et mere bredtfavnende sprogbrug. Her i beskrivelsen har man dog oppet sig og anvendt halløjet som beskrivelse. Festligt, men er det nu også en så livlig begivenhed. Eller er det reelt koden og således algoritmens logiske snigen. 28

Projekt R16.40 - VIP-basen (OpenAgency) migreres til Postgres 29

Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: ddb@kulturstyrelsen.dk med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl 12.00. 1. Bibliotek og kontaktoplysninger: Bibliotekerne i Vejles centralbiblioteksområde. Lilli Mortensen, Vejle Bibliotekerne 2. Generelle bemærkninger: Det er svært at få et overblik over hvad der bliver udviklet i DBC/DDB-regi ud over det, som er indeholdt i dette høringsoplæg. For at tage stilling til releaseplan 2016, kræver det overblik over alle udviklingsaktiviteter i 2015 hvilket ikke foreligger. Set fra et formidlingsmæssigt synspunkt undrer vi os over, at der ikke i Releaseplan 2016 er indeholdt mål inden for hverken VoxB eller Forsideservice. Det er væsentlige komponenter der beriger brugergrænsefladerne. Vi tror, at der er behov for at tage højde for mulig dobbeltudvikling inden for recommendation (Forslagsstiller, ADHL, Personalisering). Mange punkter fra Releaseplan 2015 går endvidere igen i Høringsoplægget til Releaseplan 2016, hvilket vi undrer os over. Det får nærmest karakter af en generel buffer for alle de større projekter, hvilket måske kunne have været undgået, hvis der forelå en 3-årig it-strategi for den nationale biblioteksinfrastruktur, sådan som det var meningen ifølge Releaseplan 2015. 3. Prioritering og kommentering af udviklingsprojekter Hver projektkandidat gives en prioritet fra 0 til 3, alt efter hvor relevant udviklingsprojektet anses for at være: 0 = Bør ikke gennemføres 1 = Lav relevans 30

2 = Medium relevans 3 = Høj relevans Projekt R16.01 - Bibliotek.dk: ADHL (digitale lån) Projekt R16.02 - Børneforslagsstiller: Underholdning og læring Angiv prioritering: _1 Projekt R16.03 - Forslagsstiller og rankering - oplevelsesindhold Angiv prioritering: _1 Projekt R16.04 - Det dynamiske vidensystem alle grænseflader Angiv prioritering: _1 Projekt R16.05 - Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering: _1 31

Projekt R16.06 - Adgangsplatformen (analyse) Hvis det er muligt bør det gennemføres allerede i 2015, idet det er på som Tema 6 i Releaseplan 2015 (nemmere og mere sømløs adgang til både fysiske og digitale materialer) Projekt R16.07 - BOB-basen: Vis infomedia-links i artikelbestillinger Projekt R16.08 - Bibliotek.dk: Vis nærmeste bibliotek der har åbent Angiv prioritering: _0 Opleves ikke som relevant i vores område af landet Projekt R16.09 - Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: _2 Dobbeltudvikling i forhold til bl.a. BPI bør undgås Projekt R16.10 - Bibliotek.dk: Bestil flere materialer i et hug Angiv prioritering: _2 Kun relevant i forbindelse med Indkøbskurv/varekurv jf. nuværende debat om manglende afhentning af bestilte materialer Projekt R16.11 - Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt 32

Angiv prioritering: 3_ Projekt R16.12 - Søgning i eksterne dataset gennem OpenSearch Projekt R16.13 - Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: _2 Projekt R16.14 - KontekstSØG for forskere og studerende Angiv prioritering: _1 Projekt R16.15 - Brugsscenarier for geodata i brønden Angiv prioritering: _2 Har været på tegnebrættet meget længe, og bør nu færdiggøres Projekt R16.16 - Service til konvertering og udlevering af geodata Angiv prioritering: _2 Har været på tegnebrættet meget længe, og bør nu færdiggøres. 33