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: 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). 1

2 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) Kommentar: Enig FGI s indstilling. Godt sammenhæng til digitale materialer. 2

3 Projekt R Børneforslagsstiller: Underholdning og læring Kommentar: 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 Kommentar: 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 Kommentar: Projekt R Det dynamiske vidensystem - nye dynamiske datasæt Kommentar: 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) 3

4 Projekt R Adgangsplatformen (analyse) Kommentar: 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 Kommentar: 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 Kommentar: 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 Kommentar: Genbrug af Personaliseringsprojektet er fint. Enig med FGI Projekt R Bibliotek.dk: Bestil flere materialer i et hug Kommentar: Oplagt. Men hvorfor kun på bibliotek.dk? Projekt R Bibliotek.dk: Forbedret lånerstatus - implementeringsprojekt Kommentar: 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 4

5 Projekt R Søgning i eksterne dataset gennem OpenSearch 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 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_ 5

6 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. 6

7 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

8 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. 8

9 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. 9

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