Bibliotek.dk - webservices

NOTAT 7. februar 2005 LEA Bibliotek.dk - webservices Forord Som en del af bibliotek.dk udviklingsplan 2004 bad Biblioteksstyrelsen medio 2004 Dansk BiblioteksCenter as om at udarbejde et notat, som kunne danne baggrund for beslutning om evt. at udvikle web-services ud fra bibliotek.dk. Notatet blev leveret ultimo 2004 og offentliggøres hermed på Biblioteksstyrelsens hjemmeside med henblik at interessenter kan anvende det som udgangspunkt for diskussioner om mulige web-services leveret af bibliotek.dk. Der er sat et foreløbigt beløb af til udvikling af sådanne projekter, som i givet fald igangsættes under forudsætning af sammenhæng med igangværende eller planlagte driftsløsninger. Introduktion Webservices er et begreb som vises stigende interesse. Dette skyldes blandt andet et ønske om at kunne præsentere eksisterende tjenester fra forskellige websites som en integreret del af et andet website. Men det er naturligvis også muligt at udvikle webservices, som ikke er født som del af et website. Og visionen er i øvrigt ikke kun rettet mod brug af webservices i websites og webportaler, men også i diverse mere eksotiske apparater såvel til håndtasken eller lommen, som i diverse af de apparater vi i øvrigt omgiver os med i huset og i bilen. Nærværende notat handler dog alene om de mere traditionelle anvendelser af webservices dvs. indbygning i brugergrænseflader. Der er i den danske biblioteksverden en stor interesse for at opbygge et samarbejde baseret på webservices. Som eksempel kan nævnes Netbiblioteksprojektet, der blandt andet trækker på flere webservices, heriblandt Litteratursiden som webservice samt en webservice til ForfatterWeb. Et andet eksempel er DEF systemarkitekturgruppens 3 lags model XWS (XML webservices). Ifølge systemarkitekturgruppen er sigtet med denne model at flytte DEF arkitekturen til webservices indenfor en 3 års horisont. Se handlingsplan http://www.deflink.dk/upload/doc_filer/doc_alle/1274_handlingsplan%20systemarkitektu r.pdf Lige fra bibliotek.dk s start har der været eksempler på webservices-lignende brug af bibliotek.dk. For nogle af disse er denne brug efterfølgende bortfaldet, eller er ophørt med at fungere. Som grundlag for eventuelle fremtidige planer om at stille funktioner fra bibliotek.dk til rådighed i form af webservices, har BS bestilt nærværende notat, som har til formål at foretage en overordnet kortlægning og en jordnær beskrivelse af problemstillingen ud fra en teknisk vinkel. Nyhavn 31 E 1051 København K Tlf. 33 73 33 73 Fax 33 73 33 72 E-post bs@bs.dk www.bs.dk

BS understreger at en eventuel implementering forudsætter, at der ikke er tale om en genopfindelse af den dybe tallerken, at funktionen med andre ord ikke allerede er alment implementeret med anden teknologi, fx Z39.50. Desuden skal det i givet fald ske ud fra anerkendte standarder. Det gælder såvel de basale standarder, der ligger til grund for webservices generelt, som de standarder, der skal gælde for de enkelte webservices. Notatet indleder med at give eksempler på, hvorledes funktioner i bibliotek.dk er blevet integreret i andre portaler hvilket kan give et indtryk af det basale behov for bibliotek.dk webservices. Dernæst beskrives, hvad der forstås ved en webservice, hvilke standarder der indgår, samt hvornår det er relevant at bruge en webservice. Dette efterfølges af en beskrivelse af standardiseringsprocessen, implementeringsstade, anvendelsesscenarier og behov for yderligere standardisering. Endelig gives et bud på en række funktioner i bibliotek.dk, der kunne være kandidater til at blive webservices. Eksempler på webservice-lignende brug af bibliotek.dk Selvom det ikke er en officiel bibliotek.dk service, er der alligevel en række websites, der foretager såkaldt dyb linkning til bibliotek.dk. Dette sker typisk ved at danne en søge-url, dvs. udnytte bibliotek.dk s URL-syntaks til at foretage søgninger i bibliotek.dk, således at brugeren kan viderestilles til det færdige søgeresultat i bibliotek.dk. Søgeresultatet kan være en konkret titel, eller en række af titler. Der er ikke overblik over hvor mange, der har benyttet sig af denne mulighed. Nedenfor er et lille udvalg. Forfatterkartoteket (http://intra.nakskov-gym.dk/biblio/forfatterkartoteket/) Denne service findes på Nakskov Gymnasiums hjemmeside. For hver forfatter er anført en knap, som foretager en fritekstsøgning på den pågældende forfatter i bibliotek.dk. Pensum.dk (www.pensum.dk). Denne portal foretager søgning i en række netboglader, hvilket giver mulighed for at foretage prissammenligning og køb. Portalen rummer også en brugtbørs. Som en ekstra service linkede Pensum.dk i starten også til titlen i bibliotek.dk, men det lader til at være ophørt. Heste-Nettet.dk (www.hestenettet.dk) Under overskriften Læsehesten giver denne portal en oversigt over litteratur for hesteinteresserede. For hver titel er anført en låneknap og en købeknap. Låneknappen linker til titlen i bibliotek.dk ved hjælp af en søge-url. Epoke (www.e-poke.dk) Epoke en del af litteratursiden.dk. På forsiden findes en søgeboks i øverste højre hjørne med titlen find bogen på biblioteket. Indtaster man en søgeterm dannes en søge-url til bibliotek.dk. Epoke indeholder også en række litteraturlister, og med tilhørende søge- URL erne til bibliotek.dk. Eks. http://www.e-poke.dk/blicher_landsby_7_litt.asp DEFKAT (http://katalog.deff.dk/) Denne DEF-service giver mulighed for, at man kan søge i et nærmere afgrænset antal bibliotekskataloger. Søgningen er baseret på Z39.50. Når man efter en søgning vælger detaljeret visning af post vises 2 links, som muliggør at man foretage bestillingen direkte hos det bibliotek, der ejer titlen, eller via bibliotek.dk. For at undgå døde links dannes linket til bibliotek.dk kun, hvis et forudgående Z39.50-opslag fra DEFKAT til bibliotek.dk viser at titlen faktisk findes i bibliotek. 2

Hvad er en webservice og hvilke standarder er omfattet? Webservice er en herlig rummelig term, som kan betyde mange forskellige ting. Umiddelbart skulle man tro, at det slet og ret betegnede en service, som er tilgængelig via en webside. Og i så fald ville bibliotek.dk jo allerede være en webservice. Ordet betegner imidlertid også en service (i form af et program), som er tilgængeligt på Internettet, og som kan tilgås fra klienter (i form af programmer) andre steder på Internettet via en standardiseret protokol. Da servicen således ikke er snævert bundet til World Wide Web, er betegnelsen webservice altså ikke specielt velvalgt. Kommunikationen foregår ved at klienten sender serviceprogrammet en besked (message), som efterfølgende resulterer i et svar (response). Da al kommunikation sker i XML (Extensible Markup Language), er den frigjort fra operativsystemer og programmeringssprog. Denne frigørelse fra operativsystemer og programmeringssprog betyder eksempelvis at Windows programmer kan kommunikere med Unix programmer. Der findes andre teknikker, som kan det samme, og endda mere effektivt. Men enten er de ikke platformsuafhængige (eks. Remote Procedure Call), eller også har de en meget snæver udbredelse (eks. Z39.50 udenfor bibliotekssektoren). I nærværende notat vil vi holde os til webservices, således som de er specificeret i W3C (WorldWide Web Consortium). There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition: A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. (fra Web Services Glossary, http://www.w3.org/tr/ws-gloss/ ) Dette uddybes kort nedenfor, idet det dog understreges, at der er tale om en yderst summarisk beskrivelse. En webservice er forenklet sagt en tjeneste, som stilles til rådighed på nettet for såkaldte klienter som fx kan præsentere servicen for slutbrugeren i en webportal. klient webservice WWW En webservice kan være katalogiseret i et centralt register (UDDI - Universal Description and Discovery Integration). Ideen er at det skal være muligt for en klient at slå op i et sådant register for at finde en relevant webservice. En webservice skal være beskrevet som en WSD (Web Services Description) i WSDL (Web Services Description Language). Man kan for mange anvendelser sammenligne kaldet af en webservice med et procedurekald, som kan foretages af et program, når en given opgave ønskes udført. WSD en indeholder de nødvendige oplysninger om hvorledes kaldet skal foretages herunder messageformat og serviceadresse. 3

Selve kaldet sker ved at klienten sender en message til webservicen. Hertil bruges protokollen SOAP (Simple Object Access Protocol), som billedligt talt i en kuvert (en såkaldt SOAP-envelope) kan rumme de nødvendige oplysninger. Hvis kaldet er korrekt udformet, vil webservicen returnere det ønskede i en returkuvert. Som bæreprotokol anvendes normalt den fra websider velkendte protokol HTTP (Hypertext Transfer Protocol). Og alt bygger på XML (Extensible Markup Language). Hvornår er webservices relevante? Det siger sig selv, at det kun har mening at etablere en webservice, hvis der er brug for den. Eksempler på hvornår en webservice kan være relevant: mange potentielle sklienter dynamiske data servicen giver basis for ny funktionalitet Eksempler på hvornår en webservice ikke er relevant: klienten kan umiddelbart udføre opgaven selv klienten er tæt på at være en ren kopi af et andet website funktionen er allerede udbredt implementeret med eksisterende teknologi (Z39.50) Der er endvidere et performanceproblem at tage hensyn til. Den vidtstrakte brug af XML indebærer at funktioner, som ved andre metoder kan beskrives meget kompakt, svulmer voldsomt op. Det betyder en hel del arbejde for server og klient med at pakke oplysninger ind og ud af XML. Specielt kan det blive et problem for klienten, hvis den gør brug af mange webservices. Standardiseringsprocessen og status for implementering Indledning Nedenfor følger en overordnet beskrivelse af standardiseringsprocessen og herunder den organisation, der varetager udviklingen af den vifte af standarder, der ligger til grund for webservices. Denne organisation består i sin kerne af en koordinationsgruppe og 6 arbejdsgrupper. Da arbejdet bygger på en række grundlæggende standarder, som fortsat videreudvikles, og endvidere har relationer til standardiseringsinitiativer udenfor kerneorganisationen, er den totale mængde af involverede særdeles omfattende. Og her taler vi kun om det basale grundlag for at lave webservices. For hver enkelt webservice findes et særskilt standardiseringsaspekt. Sammenfattende kan man sige, at grundlaget for at lave webservices omfatter mange standarder. De vigtigste er så nogenlunde på plads, men rummer fortsat fejl og fortolkningsmuligheder. Der pågår fortsat arbejde med udvikling af standarderne. Det skal dog understreges, at man kan komme langt på det eksisterende grundlag. Standardiseringsprocessen Udviklingen af webservicebegrebet og de tilknyttede standarder blev påbegyndt af W3C i september 2000. Arbejdet foregår i et antal arbejdsgrupper med hvert sit speciale. Og da fundamentet er XML, trækkes der naturligvis også tråde til den mere basale udvikling af XML standarderne, herunder specielt selve XML sproget og XML-Schema. Arbejdet koordineres af en koordinationsgruppe (Web Services Coordination Group). 4

Arkitekturgruppen (Web Services Architecture Working Group) har udarbejdet en række basale dokumenter, og synes at have afsluttet deres arbejde. Protokolgruppen (XML Protocol Working Group) har udviklet SOAP Version 1.2, som blev udgivet som en W3C Recommendation den 24. juni 2003. Gruppen arbejder videre med diverse optimeringer, forventeligt frem til februar 2005. Adresseringsgruppen (Web Services Addressing Working Group) er ganske ny (oprettet oktober 2004), og forventes at arbejde frem til marts 2006. Servicebeskrivelsesgruppen (Web Services Description Working Group) stiler mod at producere en WSDL Version 2. Der foreligger et Working Draft fra august 2004 for dette centrale beskrivelsessprog. Gruppen forventes at arbejde frem til februar 2006. Koreografigruppen (Web Services Choreography Working Group) arbejder med samspillet mellem webservices. Målet er et Web Services Choreography Description Language. Der foreligger et Working Draft fra oktober 2004. Gruppen er kun hyret frem til udgangen af 2004, så status for dette arbejde virker lidt uklart. Semantikgruppen (Semantic Web Services Interest Group) er tilsyneladende ikke en egentlig arbejdsgruppe, men mere et forum for interessenter. Den ser ud til at være oprettet i slutningen af 2003. Som det fremgår, indgår opslagstjenesten UDDI ikke i W3C s arbejde. Dette arbejde varetages af et konsortium af platforms- og programmelleverandører, samt e-handels virksomheders OASIS. UDDI bygger videre på standarder fra W3C og IETF (Internet Engineering Task Force) XML, HTTP and Domain Name System (DNS) samt på en tidlig version af SOAP. Jævnfør http://www.uddi.org/. Implementeringsniveau Der er stor interesse for at skabe grundlag for implementering af webservices hos de firmaer og udviklingsmiljøer, hvor værktøjerne er i fokus. Dette afspejler den interesse, der er for området blandt udviklere og i virksomheder og institutioner. Mainstreamudviklingsmiljøerne til skabelse af weber og -løsninger fokuserer derfor på webservices. Dette gælder i særlig grad udviklingsmiljøerne.net og JAVA men også i OPEN SOURCE miljøet, PHP og særlige XML-værktøjer tages naturligvis hånd om webservices. I en fase hvor standardiseringsprocessen ikke er afsluttet, og hvor standarderne fortsat rummer fejl og fortolkningsmuligheder, er det imidlertid i praksis umuligt for udviklingsmiljøer og værktøjer at holde trit med udviklingen af standarderne. Derfor vil man opleve, at det også kan være attraktivt at programmere webservices direkte igennem diverse kodesprog, dvs. uden brug af særlige faciliteter. Webservices kan nemlig også programmeres direkte i mange værktøjer med enkle midler. Webservices implementeres ikke kun i bibliotekssegmentet eller den bibliografiske sektor. Der er netop tale om en bred interesse fra mange brancher og domæner, hvilket dermed også skaber potentielle fordele for bibliotekssektoren. Summa summarum En webservice er karakteriseret ved en WSD (Web Services Description). I visse tilfælde kan funktionen være så indlysende at WSD en er tilstrækkeligt grundlag for at programmere klienten, men det almindelige vil være, at den skal suppleres med 5

en beskrivelse af formål og semantik. I praksis vil der indtil videre næppe være behov for en UDDI-registrering af webservicen. Det er relativt let at lave og anvende en enkel webservice. Men som ved al anden programmering kan det hurtigt blive mere komplekst. Den vigtigste funktionalitet er beskrevet i standarder, og implementeret. Men området må dog fortsat karakteriseres som relativt umodent. Generelt kan man sige, at man skal holde sig til den basale funktionalitet, hvis man vil være nogenlunde sikker på ikke at løbe ind i fejl. Scenarier og behov for yderligere standardisering Etablering af en webservice rejser spørgsmål om, hvem der skal fastlægge formål, indhold og tekniske specifikationer i form af WSD er. Det er indgangen til en velkendt standardiseringsproblemstilling, som kort behandles i de nedenstående 3 scenarier. Et helt centralt område som ikke er fastlagt af W3C er spørgsmålet om adgangskontrol (autentifikation). Det kan løses på mange måder. Som minimum skal der altså foretages et valg. De konkrete behov for yderligere standardisering berøres under de enkelte kandidater i næste afsnit. Hver kandidat kan realiseres ved en enkelt webservice eller en samling af webservices. Som generel bemærkning gælder, at standardiseringsprocessen skal sikre, at disse webservices, ikke kun udvikles snævert til det specifikke formål, men kan genbruges bredt. Én til én (model 1-1) klient Webservice I dette scenarium indgår kun 2 parter webservice-udbyder og klientimplementør. Hovedreglen vil her være at de to parter laver de nødvendige aftaler. Der er ikke behov for yderligere standardisering, med mindre parterne har ambitioner om at udbrede servicen mere generelt. Én til mange (model 1-n) webservice I dette scenarium tilbydes en unik webservice til mange klienter. Hovedreglen vil her være at servicen beskrives af udbyderen eventuelt i dialog med klient- 6

implementørerne. Hvis servicen udbydes bredt til bibliotekssektoren bør det overvejes at kanonisere den via et forum som fx danzig. Mange til mange (model n-m) webservice webservice webservice I dette scenarium tilbydes en række ensartede webservices til mange klienter. De kan være helt identiske (fx vejrudsigter for samme region), eller de kan være af samme kategori (fx bibliografiske databaser). I den udstrækning man kan bygge på eksisterende nationale eller internationale standarder, er alt godt. Når dette ikke slår til, vil der være behov for en standardiseringsproces, som inddrager alle interessenter. I praksis vil dette ofte starte som et regionalt initiativ, som efterfølgende kan videreformidles til et større forum. Hvis initiativet starter i bibliotekssektoren kunne opgaven tænkes varetaget af danzig eller et parallelt forum. Den videre udbredelse kunne herefter ske via det nationale (Dansk Standard S24) og det internationale standardiseringsforum (ISO TC46), som begge dækker området Information og Dokumentation. Kandidater til bibliotek.dk webservices Dette afsnit forsøger at opliste hvilke funktioner i bibliotek.dk, der kunne være kandidater til at blive realiseret som webservices. De oplistede kandidater er fremkommet ud fra en intellektuel øvelse. Der er ikke foretaget en behovsvurdering, og ej heller en vurdering af, hvad det i givet fald vil koste at udvikle den enkelte webservice. Ved udviklingen af bibliotek.dk har fokus ikke været på webservices, men alene på optimering af brugergrænsefladens funktionalitet. En funktion i bibliotek.dk, som umiddelbart forekommer enkel, kan derfor meget vel være tung at realisere som webservice. Formålet med listen er derfor at give grundlag for at udpege nogle relevante kandidater, som herefter skal gennemgå en nærmere analyse. Basale søgefunktioner Disse webservices skal muliggøre, at en klient kan foretage søgninger i bibliotek.dk, og efterfølgende præsentere søgeresultaterne i egen brugergrænseflade. Hensigten er at disse webservices skal kunne udføre det samme som søgninger baseret på Z39.50. 7

De vil dermed være relevante i de sammenhænge, hvor det af den ene eller anden grund er uhensigtsmæssigt at basere søgningerne på Z39.50. Det vil være oplagt at genbruge de webservices, der i internationalt regi er udviklet under betegnelsen SRW (Search/Retrieve Web Service). SRW omfatter 3 webservices: Explain Scan SearchRetrieve De 3 webservices er pendanter til tilsvarende services i Z39.50. Explain er en service, som kan give oplysninger om den pågældende base fx databasens adresse og en beskrivelse af dens indhold samt hvilke dele af Z39.50-protokollen, der er understøttet. Scan er en service, hvormed man kan browse igennem basens registre. SearchRetrieve er selve søgetjenesten. Som i Z39.50 er det muligt at formulere komplicerede søgeforespørgsler med brug af logiske operatorer. Der er udviklet et særligt søgesprog til dette formål, CQL (Common Query Language). Det er endvidere muligt at anføre, hvorledes man ønskes søgeresultatet sorteret naturligvis forudsat databasen understøtter denne funktion. De 3 SRW webservices kan etableres fra scratch, men hvis man har en Z39.50 Target kan man skyde genvej ved at indskyde en gateway. klient SRW gateway Z39.50 Target WWW En sådan gateway tager udgangspunkt i de indholdsmæssige og strukturerede oplægninger, der er resultatet af Z39.50-udviklingen. Da DanBib og bibliotek.dk og i øvrigt de fleste bibliotekskataloger har en Z39.50-grænseflade vil disse databaser derfor forholdsvis nemt kunne tilgængeliggøres via de omtalte SRW webservices. Uddybende bemærkninger SRW indgår i ZING (Z39.50-International: Next Generation), som omfatter et antal initiativer som alle har til formål at gøre det intellektuelle/semantiske indhold af Z39.50 mere bredt tilgængeligt for informationsleverandører, udviklere og brugere. SRU er en ZING-søgeservice analogt til SRW SearchRetrieve. Søgeparametrene overføres via en søge-url i stedet for i en SOAP-envelope, så der er altså ikke tale om en webservice i W3C- forstand. Links: http://www.loc.gov/z3950/agency/zing/zing-home.html http://www.loc.gov/z3950/agency/zing/srw/ http://www.loc.gov/z3950/agency/zing/srw/sort.html http://www.loc.gov/z3950/agency/zing/srw/sru.html Det danske softwarefirma Index Data har som bekendt opbygget en stor ekspertise på Z39.50, og har nu også udbygget denne ekspertise til at omfatte SRW og SRU. Index Data har udviklet en SRW-gateway. 8

Behov for yderligere standardisering For så vidt angår bibliotek.dk må løsningen være at tilbyde SRW via en indskudt SRWgateway. Dette kræver dog afklaring af spørgsmål knyttet til danmarc2, præsentationsog downloadformater samt danzig-profilen danmarc2: Pt. er følgende formater anvendelige i SRW - Dublin Core, Onix, MODS, og MarcXml. MarcXml er MARC21 indpakket i XML. Andre formater kan defineres lokalt. Når vi taler om bibliotek.dk skal de bibliografiske formater udvides med danmarc2. Løsningen er indførelse af en mere generel XML-indpakning end MarcXml. Dansk Standard har i dialog med NISO udarbejdet et forslag, MarcXchange, til en XMLindpakning, som kan rumme samtlige MARC-formater, herunder også danmarc2. Forslaget blev vel modtaget i den internationale standardiseringsorganisation ISO TC46 (Information and Documentation) på årsmødet i november 2004. Præsentations- og downloadformater: Hvis den lokale sklient selv kan forvandle den rå danmarc2-post til et præsenterbart format, vil der ikke være behov for yderligere standardisering på dette felt. Erfaringen fra Z39.50 viser imidlertid, at der er behov for at kunne modtage færdige præsentations- og downloadformater. Dette kan enten ske ved at kunne rekvirere det specifikke format eller ved at kunne rekvirere det nødvendige konverteringsprogram (i form af et style sheet). danzig-profilen: På følgende side er opført hvilke profiler der er indarbejdet i SRW: http://www.loc.gov/z3950/agency/zing/srw/profiles.html Af disse er Bath-profilen det nærmeste, vi kommer noget, der ligner danzig-profilen. Det skal derfor afklares hvorledes danzig-profilen kan indarbejdes i SRW. Udvidede søgefunktioner Der tænkes her på funktioner som er komplicerede eller umulige at realisere via de basale søgefunktioner. Eksempler kunne være litteratur om forfatteren, bøger der ligner eller komplicerede prædefinerede kombinatoriske søgninger.. Eksempler på webservices kunne være: Litteratur om forfatteren returnerer hits/ikke hits Bøger der ligner returnerer forslag til videresøgning Det er naturligvis op til sklienten at viderebehandle svarene. Behov for yderligere standardisering Da der ikke findes eksisterende specifikationer svarende til fx SRW, skal disse i givet fald udformes. 9

Værkvisning Formålet er at tilbyde en service, som kan bruges lokalt til at præsentere et søgesæt mere eller mindre udfoldet i henhold værkstruktur. Et eksempel på en webservice kunne være: Værkklynge på baggrund af et ISBN returneres samtlige ISBN er i værkklyngen Dette kan fx bruges til at præsentere søgeresultater fra den lokale katalog i en værkstruktur. Behov for yderligere standardisering Da der ikke findes eksisterende specifikationer svarende til fx SRW, skal disse i givet fald udformes. Biblioteksvejviser Webservices som giver adgang til informationer fra VIP-basen. Udvikling af sådanne services indgår i projekt 13 XWS- Pilot Webservice: Dansk Biblioteksvejviser som er beskrevet i DEF systemarkitekturgruppens handlingsplan. Systemarkitekturgruppen har her formuleret følgende vision og formål: Vision: Visionen er at demonstrere implementeringen af en webservice oven på en bestående tjeneste. Webservice en skal leve op til anerkendte standarder for webservices (XML, HTTP, SOAP, WSDL, UDDI) og stille en service til rådighed for en bredere kreds af biblioteker (og andre) via internettet. Det skal samtidig demonstreres at servicen kan anvendes i praktisk sammenhæng og indgå i nuværende og planlagte er. Projektets formål er at implementere en webservice oven på DBC s nuværende Biblioteksvejviser, V.I.P basen), der opfylder følgende kriterier: 1. Servicen skal stille sine tjenester til rådighed via HTTP/SOAP over internettet. 2. Servicen skal annonceres via en wsdl og kan evt. annonceres via UDDI. 3. Som et minimum skal servicen returnere biblioteksoplysninger ved opslag i vejviseren med følgende kriterier: Biblioteksnummer, biblioteksnavn eller telefonnummer. 4. Servicen skal returnere velformet XML, validerbart mod et schema. 5. delen af servicen skal fungere mod Statsbibliotekets nuværende brugerdatabase samt Fremtidsmusikkens brugervalidering. Med andre ord er formålet, i samarbejde med DBC, at etablere en webservice der kan levere biblioteksoplysninger ved opslag på enten biblioteksnavn, biblioteksnummer eller telefonnummer via en SOAP/XML baseret webservice. Fra Systemarkitekturgruppens handlingsplan: http://www.deflink.dk/upload/doc_filer/doc_alle/1274_handlingsplan%20systemarkitek tur.pdf 10

Behov for yderligere standardisering Specifikationen er foregået indenfor projektets rammer, dvs. efter aftale mellem DBC og Statsbiblioteket. Hvis søge- og præsentationsmuligheder skal svare til mulighederne i bibliotek.dk skal webservicen udvides. Kan købes knap At give adgang til funktionalitet svarende til købeknappen i bibliotek.dk. Eksempler på webservices: Kan titlen købes? returnerer ja eller nej (1) Link til titel returnerer søge-url til bibliotek.dk (2) Køb servicen returnerer nødvendige oplysninger til at fortsætte processen i klienten (3) De 2 første kan bruges til at viderestille til købemuligheden i bibliotek.dk. Den første og den tredje kan bruges til at etablere en lokal købeknap. Behov for yderligere standardisering Da der ikke findes eksisterende specifikationer svarende til fx SRW, skal disse i givet fald udformes. Bestil At give adgang til funktionalitet svarende til bestilfunktionen i bibliotek.dk. Eksempler på webservices: Må titlen bestilles? returnerer ja eller nej, baseret på bibliotekets oplysninger i VIP (1) Hent søge-url til bibliotek.dk returnerer søge-url til bibliotek.dk (2) Hent beholdningsdata returnerer beholdningsdata for en given titel (3) Er biblioteksnummer kendt? returnerer ja hvis det er kendt i VIP-basen (4) Hvor kan titel bestilles? returnerer liste af biblioteksnumre (5) Bestil via postkasse afleverer en bestilling til DanBib-postkassen (6) Hvis titlen ikke findes i eget katalog kan klienten viderestille brugeren til at foretage bestillingen i bibliotek.dk (1+2) eller selv foretage en tilsvarende bestilling efter at have checket låneren i den lokale base (1+4+5+6). Alternativt kan hentes beholdningsdata således at klienten kan foretage fjernlånsbestilling via ILLXML (1+3). Det fremgår af beholdningsdata om biblioteket selv har titlen, og i så fald kan klienten i stedet lade bestillingen ske i det lokale katalog. 11

Behov for yderligere standardisering Udover format for beholdningsdata (som indgår i danzig profilen) findes der ikke eksisterende specifikationer, og disse skal derfor i givet fald udformes. Litteraturovervågning (SDI) At kunne yde en lokal SDI-service. Eksempler på webservices: Tegn abonnement dvs. opret central SDI-profil (1) Hent nyheder returnerer søgesæt med nye titler svarende til profilen (2) Dette er nok lidt kunstigt. I givet fald bør de nye titler formentlig matches mod et lokalt katalog, således at titler, der ikke findes heri, frafiltreres af klienten. Behov for yderligere standardisering Da der ikke findes eksisterende specifikationer svarende til fx SRW, skal disse i givet fald udformes. Emnehierarki At give mulighed for at integrere bibliotek.dk s emnehierarki i en lokal. Eksempler på webservices: Hent under returnerer alle underemner (1) Hent over returnerer overemne (2) Hent søgespecifikation returnerer søgespecifikation svarende til et givet emne (3) Disse services giver en række anvendelsesmuligheder i den lokale. En model kan være at selve emnehierarkiet haves lokalt og kun søgespecifikationerne hentes fra bibliotek.dk (3). En anden kan være at al navigation i emnehierarkiet sker ved at hente oplysningerne fra bibliotek.dk (1+2+3). Selve søgningen kan herefter foregå i den lokale katalog eller i bibliotek.dk. Ved søgning i bibliotek.dk, fx ved brug af de tidligere beskrevne basale søgefunktioner, overføres søgeresultatet til den lokale, som herefter kan præsentere titlerne med ikoner for om de haves, kan reserveres eller kan fjernlånes. Behov for yderligere standardisering Da der ikke findes eksisterende specifikationer svarende til fx SRW, skal disse i givet fald udformes. 12

Download til viderebehandling i fx Reference Manager At tilbyde mulighed for at downloade poster. Denne mulighed er allerede indeholdt i de basale søgefunktioner, men ønsker om særlige downloadformater kan resultere i et behov for en særlig webservice eller en udvidelse af SRW. Afrunding Kandidatlisten omfatter hvad vi umiddelbart har kunnet forestille os. I første omgang vil interessen sikkert samle sig om de basale søgefunktioner, herunder både SRW og SRU, ikke som en erstatning for Z39.50, som fortsat vil være fundamentet i bibliotekssektoren, men som et redskab til inddragelse af institutioner og virksomheder udenfor bibliotekssektoren. Men webservices kan, som det fremgår af listen, bruges til meget andet end søgning. Og det kan sagtens tænkes, at der er oplagte anvendelsesmuligheder, som mangler i listen. Der er som sagt ikke foretaget en behovsvurdering, og ej heller en vurdering af, hvad det i givet fald vil koste at udvikle den enkelte webservice. Listen skal derfor betragtes som et katalog af muligheder til nærmere overvejelse. 13