Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016

Transkript

1 Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl Bibliotek og kontaktoplysninger: Biblioteket Frederiksberg Michael Thomsen, Sektionschef, stab & administration 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 2 = Medium relevans 3 = Høj relevans Projekt R Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: 2 Projekt R Børneforslagsstiller: Underholdning og læring Angiv prioritering: 1 Projekt R Forslagsstiller og rankering - oplevelsesindhold Angiv prioritering: 2 Projekt R 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 R Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering: 1 2

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

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

5 Angiv prioritering: 1 Projekt R Konsolidering Fase 2 - Konsolidering af de sidste nationale funktioner og idriftsættelse af bibliotek.dk Angiv prioritering: 3 Projekt R Konsolidering Fase 2 - Nationale funktioner fra bibliotek.dk til DDB CMS Angiv prioritering: 2 Projekt R Netpunkt.dk: fase 2 af ny grænseflade til netpunkt.dk Angiv prioritering: 3 Projekt R 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

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

7 Projekt R Servicelag til autoritetsdata repository Angiv prioritering:? Projekt R Implementering af RDA i den nationale infrastruktur Angiv prioritering:? Projekt R Data: Analyseprojekt vedrørende BIBFRAME Angiv prioritering:? Projekt R Linked data i den nationale infrastruktur Angiv prioritering:? Projekt R Automatisk fjernlån af eget materiale Angiv prioritering:? Projekt R Yderligere udvikling og effektivisering af fjernlån 7

8 Angiv prioritering:? Projekt R 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 R 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 R 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 R 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

9 Projekt R 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 R 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 R 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

10 Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl Bibliotek og kontaktoplysninger: Aarhus Kommunes Biblioteker Møllegade Aarhus C. Kontaktperson: Per Kjær 2. Generelle bemærkninger: Personaliseringsprojektet bør inddrages i flere af projekterne: R16.02 ; R 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 R Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: 3 Ser det som en fordel for bibliotek.dk 10

11 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 R 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 R 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 R 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 R Det dynamiske vidensystem - nye dynamiske datasæt Angiv prioritering:

12 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 R 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 R 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 R 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 R Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: 1 12

13 Projekt R 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 R Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt Angiv prioritering: 1 Projekt R 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 R Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: 2 Enig i FGI s vurdering. Projekt R KontekstSØG for forskere og studerende Angiv prioritering: 0 13

14 Projekt R Brugsscenarier for geodata i brønden Angiv prioritering: 1 Projekt R Service til konvertering og udlevering af geodata Angiv prioritering: 1 Projekt R 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 R 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 R 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

15 Projekt R 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 R Bibliotek.dk: Integration med andre systemer Angiv prioritering: 1 Savner en beskrivelse af hvilke andre systemer bibliotek.dk skal integrere med. Projekt R BOB: Låse en bestilling i BOB- implementeringsprojekt Angiv prioritering: 0 Har aldrig haft dette problem, selv om vi er et stort bibliotek. Projekt R 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 R 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

16 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 R 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 R Dataflow til Danbibs nye Data I/O System Angiv prioritering: 3 Projekt R Repository til autoritetsdata Angiv prioritering: 2 Projekt R Servicelag til autoritetsdata repository Angiv prioritering: 2 Projekt R 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

17 fastlægge en ramme på 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 R Data: Analyseprojekt vedrørende BIBFRAME Angiv prioritering: 3 Projekt R Linked data i den nationale infrastruktur Angiv prioritering: 0 Enig med FGI s vurdering. Projekt R 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 R Yderligere udvikling og effektivisering af fjernlån Angiv prioritering: 0 Projekt R OpenOrder: Migrere php-openorder til JavaEE Angiv prioritering: 3 Enig med FGI s vurdering. 17

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

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

20 Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl Bibliotek og kontaktoplysninger: Københavns Biblioteker Krystalgade Københavns K reneho@kff.kk.dk tlf 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

21 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 R Bibliotek.dk: ADHL (digitale lån) Angiv prioritering: _som FGI Enig FGI s indstilling. Godt sammenhæng til digitale materialer. 21

22 Projekt R 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 R 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 R Det dynamiske vidensystem alle grænseflader Angiv prioritering: _2 Projekt R 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

23 Projekt R Adgangsplatformen (analyse) Enig i FGI s relevansvurdering. Måske skulle det bare kaldes Single sign on Projekt R 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 R 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 R Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: _som FGI Genbrug af Personaliseringsprojektet er fint. Enig med FGI Projekt R Bibliotek.dk: Bestil flere materialer i et hug Oplagt. Men hvorfor kun på bibliotek.dk? Projekt R 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

24 Projekt R Søgning i eksterne dataset gennem OpenSearch Angiv prioritering: _som FGI Enig med FGI. Projekt R 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 R 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 R 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 R Service til konvertering og udlevering af geodata Angiv prioritering: 3_ se R16.15 Projekt R Konsolidering Fase 2 - Konsolidering af de fælles mobile løsninger til den nye arkitektur Angiv prioritering: 2_ 24

25 Enig med FGI. Dog anskues som 2=medium relevant Projekt R 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 R Konsolidering Fase 2 - Nationale funktioner fra bibliotek.dk til DDB CMS Enig med FGI. Dog anskues som 2=medium relevant af København Projekt R Netpunkt.dk: fase 2 af ny grænseflade til netpunkt.dk Enig med FGI Projekt R Bibliotek.dk: Integration med andre systemer Enig med FGI Projekt R 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 R 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

26 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 R Skalering af databrøndens repositoriestruktur Angiv prioritering: som FGI_ Enig med FGI Projekt R Udbygning af OAI-PMH høst fra Danbib R16.25 hedder noget andet i høringsmaterialet. Projekt R Dataflow til Danbibs nye Data I/O System Angiv prioritering: som FGI Enig med FGI Projekt R 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 R Servicelag til autoritetsdata repository Samme som R

27 Projekt R 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 R Således bør også dette drøftes bredt i sektoren, således der kan laves en fornuftig prioritering om implementering af RDA. Projekt R Data: Analyseprojekt vedrørende BIBFRAME Se kommentar til R Projekt R 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 R Yderligere udvikling og effektivisering af fjernlån Ja, det er fint at afsætte ressourcer til disse projekter for mindre FFU-biblioteker. 27

28 Projekt R 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 R OpenHoldingStatus: Optimering af holdingsopslag mod FBSbiblioteker Projekt R OpenHoldingStatus: Migrere php-openholdingstatus til JavaEE Projekt R OpenRS: Migrere C++-delen til JavaEE Projekt R OpenRS: Skifte DBMS fra Oracle til Postgres Projekt R 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

29 Projekt R VIP-basen (OpenAgency) migreres til Postgres 29

30 Skabelon til høringssvar af udviklingsopgaver til Releaseplan 2016 Skabelonen udfyldes og sendes til postkassen: med emnet "høringssvar". Deadline er mandag den 4. maj 2015 kl 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 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

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

32 Projekt R 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 R BOB-basen: Vis infomedia-links i artikelbestillinger Projekt R Bibliotek.dk: Vis nærmeste bibliotek der har åbent Angiv prioritering: _0 Opleves ikke som relevant i vores område af landet Projekt R Bibliotek.dk: Lister/personaliseringsindhold Angiv prioritering: _2 Dobbeltudvikling i forhold til bl.a. BPI bør undgås Projekt R 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 R Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt 32

33 Angiv prioritering: 3_ Projekt R Søgning i eksterne dataset gennem OpenSearch Projekt R Bibliotek.dk: ADHL (udvidet filtrering) Angiv prioritering: _2 Projekt R KontekstSØG for forskere og studerende Angiv prioritering: _1 Projekt R 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 R 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