Rapport fra arbeidet med eksport av data fra SFX til BIBSYS

Rapport fra arbeidet med eksport av data fra SFX til BIBSYS Knut Hegna 14. mars 2006 Innhold 1 Bakgrunn 3 1.1 Spørsmålstillinger......................... 3 1.2 Løsningsforslag.......................... 3 2 Problemer 4 3 Ulike andre spørsmål 5 3.1 Én felles eksportfil........................ 5 3.2 SFX-knapp i BIBSYS Ask.................... 5 3.3 Lenking fra Ask til SFX..................... 5 3.4 Lenking på leverandørnavn i BIBSYS Ask........... 6 3.5 Anvendte bibliotekkoder..................... 6 3.6 Masker............................... 6 3.7 URI................................ 6 3.8 Gratistidsskrifter......................... 7 3.9 Global threshold - common................... 7 4 SFX XML-eksportformat 7 5 BIBSYS XML-skjema for tidsskriftdata 7 6 Hjelpefiler 7 6.1 SFX-pakker............................ 7 6.2 BIBSYS-pakker.......................... 8 6.3 Gratistidsskrifter......................... 8 A Nye SFX-dokid, gamle får status intern 8 A.1 Synspunkter fra UB Tromsø................... 9 A.2 Synspunkter fra UB Bergen................... 10 A.3 Synspunkter fra UB Trondheim................. 11 A.4 Synspunkter fra UB Oslo.................... 12 1

B Gratispakker 12 C SFX teksteksportformat 12 D BIBSYS XML-skjema 13 2

1 Bakgrunn I forbindelse med innføringen av UBenes bibliotekportal ble det på et tidlig tidspunkt besluttet å vedlikeholde bestandsinformasjonen for elektroniske tidsskrifter i SFX og ikke i BIBSYS. Begrunnelsen for dette standpunktet var to-delt: bestandsoppgavene i SFX holdt høyere kvalitet og ble vedlikeholdt på internasjonalt plan gjennom SFX-samarbeidet. bestandsoppgavene ble i BIBSYS på dette tidspunktet vedlikeholdt som mer fritekstlig informasjon lite egnet for identifikasjon av tidsskriftnummer og artikler slik meningen med SFX er. Derfor skulle bestandsdata overføres fra SFX til BIBSYS. I utgangspunktet skulle en tro dette ville berike BIBSYS-katalogen. Seinere har BIBSYS utviklet sin administrasjon av elektroniske dokumenter. Dette medfører blant annet at bestandsoppgaver registreres på en konsistent måte og at administrasjon av avtaler og abonnementer er knyttet opp mot eksemplarinformasjon (dokid) i katalogen. 1.1 Spørsmålstillinger Primærregistrering: Her trengs det en ny vurdering for å konfirmere eller forkaste nåværende politikk. Det er fortsatt slik at bestandsopplysninger blir best ivaretatt i SFX, mens bibliografiske opplysninger blir best ivaretatt i BIBSYS. Hva skal veie tyngst (hva er mest effektivt)? Bestandimport til BIBSYS: Her fins det mer eller mindre arbeidskrevende løsninger og de fører til mindre eller mer tekniske og administrative problemer. Særlig gjelder dette kopling av abonnement administrert i BIBSYS og pakke/abonnement i SFX. Dette kan løses ved at pakke, abonnement og bestand fra SFX gis eget dokid i BIBSYS, mens gamle dokid i BIBSYS gis en egen status. Se forslag fra UB Tromsø i appendiks A. Denne løsningen vil føre til noen problemer angående statistikkføringen. Men kravene til statistikken kan ikke være bestemmnde eller legge hindringer i veien for effektive løsninger forøvrig. Problemet er beskrevet nærmere nedenfor. 1.2 Løsningsforslag Etter fjorårets arbeid med dette, er det min mening at dette er det nærmeste vi kommer en løsning: 3

Postene med bestander fra SFX importeres i BIBSYS og gis nye dokid som også brukes i seinere importer (oppdateringer). Gamle, eksisterende, dokid, gis en spesiell status (f.eks. intern) som sikrer at disse dokid fortsatt kan brukes i administrativ sammenheng og for at kategorisering i form av fagkoder ikke går tapt. Løsningen vil føre til unøyaktig statistikk i det året løsningen innføres, men seinere vil det bli korrekt. Se forøvrig UB Tromsøs forslag til statusverdi som muligens kan omgå statistikkproblemet. 2 Problemer I utgangspunktet skulle det være tilstrekkelig å rapportere tittel og IS- SN/eISSN for et tidsskrift sammen med elektronisk bestand for hvert enkelt UB. Dette var også kravet fra BIBSYS i første omgang. Det er også ønskelig å sikre elektronisk tilgang til tidsskriftene via BIBSYS Ask. Det viste seg at ovennevnte data ikke var tilstrekkelige til å innpasse opplysningene i BIBSYSs datamodell. Denne datamodellen er bygget opp rundt BIBSYSs egen lenketjener og det administrative systemet for elektroniske dokumenter. Når en bestandsoppgave kommer til BIBSYS fra SFX, står man overfor to identifikasjonsoppgaver: identifisere riktig elektronisk tidsskrift i BIBSYS-katalogen. Et forsøk gjort i forbindelse eksportarbeidet viste at rundt 75% kunne identifiseres helautomatisk, mens resten i tilfelle dels kunne identifiseres halvautomatisk eller primærregistreres som nye. identifisere riktig eksemplar som bestanden skal oppdateres på. Dette kan være komplisert, ikke minst fordi UB-ene kan abonnere på samme tidsskrift hos flere leverandører. SFX har ikke den leverandør- og pakkeinformasjonen som skal til for å få treff på riktig dokid. Det første problemet vil i hovedsak være løst etter at førstegangsimport er fullført. SFX-eksporten vil inneholde en SFX-identifikator som vil bli lagt på de riktige objektpostene i BIBSYS (eventuelt lage en tabell som viser sammenhengen mellom SFX-id og objekt-id). Det andre problemet kan løses ved å sette opp en konkordansetabell mellom SFX-pakker og BIBSYS-pakker. Dette vil være et omfattende arbeid og det vil ikke ta slutt. Det kan også løses ved at gamle UB-dokid fjernes og nye settes inn med SFX-pakkenavn. Denne løsningen anses uakseptabel dels fordi det for en del UB-ers vedkommende er knyttet budsjettkontroll, fagkoder og administrasjon mot de aktuelle dokid-ene, dels fordi det for alles vedkommende ville føre til et brudd i statistikkføringen. 4

En tredje løsning kan være å la de gamle dokid-ene stå, men gi dem status intern. Bestandene fra SFX gis nye dokid og bare disse vil vises i eksterne kataloger. UB-enes kommentarer til dette forslaget er gitt som tillegg i denne rapporten. 3 Ulike andre spørsmål I forbindelse med eksportarbeidet har det dukket opp en rekke spørsmål/problemer som vært løst, til dels i forståelse med prosjektgruppene ved UB-ene. Noen av disse spørsmålene er nevnt nedenfor for at det ikke skal bli glemt hva man på et tidspunkt var enig om. 3.1 Én felles eksportfil Det ble på et tidlig tidspunkt klart at BIBSYS ønsket én fil med oppdateringer alle de fire UB-ene. Dette medfører at eksportfunksjonen ikke kan desentraliseres. 3.2 SFX-knapp i BIBSYS Ask UB-ene er enige i at SFX-knappen må flyttes fra den posisjonen den nå har (øverst til høyre) til kolonnen Bestand/Holdings utfor biblioteknavnet. BIBSYS har sagt at denne flyttingen først kan skje i versjon 2 av Ask. I mellomtiden står SFX-knappen øverst til høyre, men lenken på leverandørnavn gjøres til SFX (se nedenfor). Når SFX-knappen er på plass utfor biblioteknavnet, kan lenken på leverandørnavn fjernes for UB-ene. Bare leverandørnavnet med tilhørende bestand står tilbake. Det har vært reist spørsmål om å få en SFX-knapp allerede i trefflista i Ask. UBenes syn på dette er uavklart. For BIBSYS vil det bryte med den grensesnittfilosofien det er lagt opp til i Ask. Argument for: færre klikk, enklere tilgang. Argument mot: mister opplysning om lenke til trykt bestand som fins på posten i BIBSYS. 3.3 Lenking fra Ask til SFX UB-ene er enige i at lenking fra Ask skal gå til SFX selv om dette medfører at man går fra en side til en annen som har likelydende informasjon (dog med flere funksjoner i SFX-menyen). BIBSYS har foreslått at leverandørnavnet får en forklarende tilføyelse a la via SFX eller via lokal lenketjener for å unngå misforståelser (se ellers nedenfor). 5

3.4 Lenking på leverandørnavn i BIBSYS Ask I utgangspunktet ønsket BIBSYS at lenken på leverandørnavn i Ask skulle gå via BIBSYSs lenketjener til leverandør. Dette ville medføre at eksporten måtte inneholde data SFX i utgangspunktet ikke hadde eller som det ville kreve mye manuelt arbeid å framskaffe. Disse dataene måtte i så fall koples på i konverteringen ved hjelp av data fra BIBSYS og som nevnt ved hjelp av et manuelt arbeid som ikke ville ha noen sikker ende. I tillegg ville løsningen være skjør for endringer det ene eller andre stedet (masker, uri-er, se nedenfor). Løsningen er at lenken på leverandørnavnet går direkte til SFX (evt skjult via BIBSYSs lenketjener) ved hjelp av en tidsskriftidentifikator som kommer fra SFX. Dersom man på et seinere tidspunkt vil innføre leverandørlenking via BIBSYSs lenketjener, åpner konverteringsprogrammet for å inkludere masker og uri-er, men det forutsetter oppdaterte hjelpefiler (se om sfx-pakker og BIBSYS-pakker nedenfor). 3.5 Anvendte bibliotekkoder Bestanden rapporteres med bibliotekkoder i henhold til BIBSYS-katalogen (a for UBiT, c for UBTØ, d for UBB og ns for UBO). I henhold til brev fra BIBSYS av 19.april 2005 til UBO skal BIBSYS sørge for å splitte opp UBOs meldinger slik at tidsskriftene blir søkbare i UBOs lokale base og felles base UBO. 3.6 Masker Masker er enten registrert i BIBSYS eller SFX. Som masker regnes URL med en eller flere variabler som kan hentes fra de bibliografiske dataene, f.eks ISSN. Der SFX har BIBSYS-liknende maskemuligheter, kan de bli levert under tag-en <mask>. Etter avgjørelsen om å lenke direkte til SFX e denne opplysningen ikke lenger nødvendig i eksporten. 3.7 URI URI er URL-er direkte til tidsskriftet. Disse kan bli generert ved hjelp av omformere inne i SFX-systemet (parsere). Noen av disse kan ha en generell karakter og bli betraktet som en maske (for eksempel når det bare er en jkey som skal skiftes ut. De kan da behandles som maske forutsatt at det fins en fil som kobler ISSN og jkey. Dette er gjort for noen tidsskrifter for forsøkets skyld. Øvrige URI må genereres for hånd ut fra opplysningene i omformerne. Siden lenken i Ask nå skal gå til SFX, trengs ikke dette feltet i eksporten. 6

3.8 Gratistidsskrifter Gratistidsskrifter er assosiert til noen få SFX-pakker, se appendiks B. Disse tidsskriftene får verdien free i tag-en <charge> under de respektive SFXpakkene. Øvrige tidsskrifter får verdien licensed i samme tag. 3.9 Global threshold - common Felles beholdning i BIBSYS har samme definisjon som Global threshold i SFX. Denne opplysningen blir rapportert direkte under leverandøren for det aktuelle tidsskriftet merket med tag-en <common>. Dersom lokal bestand er identisk med det som er rapportert under <common>, rapporteres ikke lokal bestand. 4 SFX XML-eksportformat Det formatet for XML-eksport som SFX inneholder, er ikke egnet til å eksportere til BIBSYS. Blant annet transformeres bestandsdata til fritekstlig informasjon. Alle data blir knyttet opp mot MARC21-tagger. Dette formatet er likevel nødvendig for å kunne ta ut lister over tidsskrifter som er oppdatert siden forrige eksport (noe som ikke er mulig med regnearkformatet). 5 BIBSYS XML-skjema for tidsskriftdata Siste versjon av XML-DTD-en fra BIBSYS er gjengitt i appendiks D. Svakheten ved dette format qua kravspesifikasjon er at det er mer myntet på leverandører av tidsskriftpakker enn på BIBSYS-bibliotek som ønsker å levere bestandsdata (jfr problembeskrivelsen). 6 Hjelpefiler Hjelpefilene er til for å generere data som BIBSYS trenger for å få dataene inn i sin datamodell. I tillegg fins en hjelpefil for å identifisere gratistidsskrifter. 6.1 SFX-pakker Filen sfx-pakker.txt inneholder pakkenavn fra SFX. Hvert pakkenavn har en identifikator som viser til pakkenavn i BIBSYS. Ved eksport av tidsskrifter brukes SFX-pakkens navn til å slå opp i filen for å finne en identifikator som kan brukes til å slå opp i filen bibsys-pakker.txt for å få tak i opplysninger BIBSYS trenger for at hele posten skal gli inn i BIBSYS sin datamodell. 7

6.2 BIBSYS-pakker Denne filen inneholder alle pakkene som er registrert i BIBSYS med tilhørende tilleggsopplysninger som levid, pakkeid, maske. Her ligger masker, pakkeid-er og annet. SFX pakker ligger også her, men med mer eller mindre fullstendige tilleggsdata. 6.3 Gratistidsskrifter Denne hjelpefileninneholder bare en liste over hvilke SFX-pakke som inneholder gratistidsskrifter (se appendiks B). Alle tidsskrifter under disse pakkene får <charge>-tagen utfylt med free. Filen må holdes oppdatert! A Nye SFX-dokid, gamle får status intern I januar ble det sendt ut et spørsmål til UB-ene om det ville være en mulig løsning å gi gamle dokid status intern. Ordlyden i spørsmålet (utdrag): Ut fra svarene jeg fikk på forrige e-post om å slette gamle dokid (dvs sette avbrutt-status på dem), så er det nokså klart at det ikke er noen farbar vei. De gamle dokid er knyttet til budsjett- og bestillingsrutiner etc og kan ikke fjernes. Hovedproblemet med importen fra SFX ligger i å få koplet bestand i SFX med riktig dokid i BIBSYS. Vi har tidligere sett på muligheten av å vedlikeholde en tabell som viser sammenhengen mellom SFX-pakker og BIBSYS-pakker. Det vil være arbeidskrevende å opprette denne tabellen og det vil være et kontinuerlig arbeid knyttet til tabellens vedlikehold. Denne løsningen er derfor stilt i bero. I stedet har jeg foreslått at det rett og slett opprettes nye dokid for SFXdataene. Disse dokid-ene vil ha følgende data knyttet til seg blant annet for å gjøre seinere oppdatering enkel, men også for å tilpasse seg datamodellen i BIBSYS: levid = sfx pakkenavn = SFX-pakkenavn pakkeid = en identifikator vi holder orden på på SFX-siden. Men: Dersom vi bare beholder de gamle dokid ubehandlet, vil vi få kluss med statistikken (ugyldige dubletter blant annet) og visning i websøk og ask. Spørsmålet er så: Kan vi løse disse problemene ved å sette status intern på de gamle dokid-ene når dataene importeres fra SFX? I følge håndbøkene vil eksemplarer med intern-status ikke vises i publikumssøkeprogrammene. 8

Videre står det: Du bestiller og mottar bøkene som vanlig i BIBSYS, slik at budsjett og statistikk blir riktig oppdatert. Dette betyr vel at statistikken for elektroniske tidsskrifter fortsatt vil inneholde dubletter, men ellers ivaretas behovet for vedlikehold av budsjett og leverandørrutiner på vanlig måte i BIBSYS. Noen underordnete spørsmål: Introduserer vi nye problemer med løsningen? Er disse problemene evt uløselige? (kan vi f.eks løse statistikkproblemet v.hj.a statistikkmulighetene i SFX?) Krever det mer arbeid å løse dette enn å vedlikeholde en tabell som viser pakke-sammenheng? A.1 Synspunkter fra UB Tromsø På UB Tromsø har vi diskutert denne saka og vi kommer med følgende innspill: Vi er positive til at de gamle dokid-ene vil få status intern, og vi vil til og med foreslå å gå enda et steg videre, nemlig opprette en ny status for disse internpostene. Denne nye statusen skal ha samme funksjonalitet som status intern, men den skal ha et annet navn. Som navn på den nye statusen foreslår vi dublsfx eller noe lignende. Som med vanlig status intern vil heller ikke disse dokid-ene og tilgangene knytta til dem vises i BIBSYS Ask. Andre fordeler med å opprette en ny status for disse dokid-ene er at det blir lettere med statistikken, at man unngår sammenblanding med vanlig status intern og at man kan ta ut lister med denne nye statusen. Dersom det ikke lar seg gjøre å lage en ny status, foreslår vi at det blir lagt til en bemerkning i 096 $f på de dokid-ene som vil få status intern etter SFX-eksporten. Man kan for eksempel skrive Dublett SFX i dette feltet. På denne måten greier man da også å skille dokid ene med denne bemerkninga fra andre dokid med status intern. Dessuten kan man utelate disse dokid-ene i statistikksammenheng ved å ekskludere status intern + 096 $f Dublett SFX. Når det gjelder en tabell for å vise sammenhengen mellom SFX-targets og BIBSYS-levid, er vi litt skeptiske. Det vil bli mer arbeidsomt å vedlikeholde denne tabellen manuelt enn å eksportere fra SFX til BIBSYS og samtidig lage nye dokid. Videre lurer vi på hva som vil bli overskrevet når et dokid med levid sfx blir oppdatert, for eksempel når det er endringer i beholdninga. Vil da felt som pris, abonnementsnummer, lokale bemerkninger (MARC-felt 012) bli overskrevet, eller vil de forbli uendra under oppdatering fra SFX? Vi spør med tanke på om vi kan gå over til å bruke de nye SFX-dokid-ene til å administrere våre abonnement på enkelttitler. 9

A.2 Synspunkter fra UB Bergen Om det er mogeleg, synest vi det beste ville vere å gjere som UBTø foreslår, å opprette ein ny status for gamle dokumentpostar, der nye dokumentpostar importerast til BIBSYS frå SFX (gjerne med det namn UBTØ foreslår). Dersom dette ikkje skulle vise seg mogeleg, går vi for løysinga med å gi gamle dokid status intern og legge ein fast streng (eg. dublett SFX ) i 096 $f. På sikt (les: med betre eksportmuligheiter frå SFX) lurer vi på om det vil vere mogeleg å kjenne igjen dokumentpostar på basis av t.d. URL. I så tilfelle vil det kanskje på eit seinare tidspunkt vere mogeleg å gå tilbake til å ha berre eitt dokid, som så kan brukast både for bestandsoversikt utad og abonnementsadministrasjon innad? Ingen var begeistra for tanken på å vedlikehalde tabellar for samanheng mellom SFX-targets og levid. Når det gjeld problem med statistikken, var vi mindre bekymra. Vi ser for oss at dette vil by på flest problem i samband med første import (mao i statistikken for 2006). Dette meinte vi kunne supplerast med forklarande tolking (jf forslag frå Leif Longva). Dessutan burde BIBSYS kunne utarbeide algoritmar for utrekning av reelle (netto-)endringar. I tillegg til spørsmål vi blei bedt om å ta stilling til, vart fleire spørsmål reiste under møtet (jf spørsmålet som kom om kor vidt endring av rutinar ville medføre nye problem og desse evt ville medføre like stort meirarbeid som t.d. vedlikehald av tabellar. Vi drøfta følgjande: Hyppigheit av eksport/import? ExLibris legg på sikt opp til oppdatering av CKB annakvar veke. På den andre sida er vedlikehald av SFX ein kontinuerleg prosess, med aktivering av pakkar og korrigering av t.d. bestandsdata. Hyppigare eksport/import vil derfor vere gunstig for å ha eit fullstendig oppdatert BIBSYS. Kva er det realistisk å tenkje seg her? Med hyppig eksport vil det for eksempel vere vanskeleg å tenke seg noko form for utstrekt "handarbeidpå postar mellom eksportane. Status for postar importerte i BIBSYS: Iflg Elin Stangeland vil postar importerte til BIBSYS automatisk få status "mini". Kan det stadfestast at dette og gjeld for SFX-importerte postar? Presisjon i behaldningsdata: SFX har ikkje alle tider tilfredsstillande presisjon på bestandsopplysningane. For eksempel kan starttidspunktet vere oppgitt ved årstal, og utan at vol/hefte er oppgitt. Her vil i ein del tilfelle presisjonen i BIBSYS bli dårlegare om gamalt dokid får internstatus (fjernast frå 10

brukarane sine auge) og nytt dokid får dårlegare presisjon. Dette ser ut til mellom anna å ha med kva opplysningar ein får ut frå leverandør, derfor har ikkje dette alle tider vore perfekt i BIBSYS heller (skjønt, presisjonsnivået har vore høgare). Men dette kom vi fram til at vi kanskje berre måtte leve med, i alle fall inntil det evt er mogeleg å påverke ExLibris til å gi oss meir presise data. Eksport av tidsskrift som har skifta namn: korleis løyse dette med BIBSYS? I ein del tilfelle opererer SFX kun med ein tittel (den løpande) der tidsskrift har skifta namn undervegs. Dette er eit problem både ved bruk direkte av SFX og ved eksport til BIBSYS. Kort sagt om bruk i SFX: om ein brukar har ein gamal referanse (frå skriven referanse eller frå databasar som går langt tilbake) vil tittel ikkje gjenkjennast av SFX. Oppslag i A-Å-liste gir ikkje treff med mindre tittel kling svært likt eksisterande, og om ikkje ISSN er tildelt retrospektivt, vil ikkje brukar heller få tilbod om elektronisk tilgang via SFX-meny om han kjem frå database/citation linker. Dette er i seg sjølv problematisk. Ved eksport frå SFX ser vi eit problem med å få bestanden knytt til rett post, slik at det ikkje t.d. blir liggande ein bestand som går utover den perioden då tidsskriftet faktisk har hatt den aktuelle tittelen. Kan dette splittast opp? Per i dag er ikkje alle leverandørar like nøye med dei bibliografiske opplysningane ved utsending av lister over pakkeinnhald, korleis har import av denne typen postar vore ordna tidlegare? Har slike tilfelle blitt fanga opp og retta på manuelt? Er dette i så fall noko vi kan få BIBSYS til å gjere og for import frå SFX? Tilsvarande problemstillingar oppstår ved samanslåing og oppsplitting av tidsskrift. A.3 Synspunkter fra UB Trondheim UBiTs tidsskriftmatrise har sett på saken. Status intern er ikke problemet. Ved å innføre satus intern på de gamle dokidene våre, løses problemet med visning i bibsys nett og ASK, men vi problem med at alle lister og all statistikk vil bli feil. Lister og statistikk brukes i økonomisk og faglig styring av biblioteket. Spesielt gjelder det statistikk på tittelnivå. Alle dat for kassert, tapt og avbrutt blir feil. Biblioteket er pålagt å levere ABM-statistikk, men det blir raskt umulig. Statistikkproblemet kan ikke løses ved hjelp av SFX, da den er basert på lokale data. Bemerkning i 096$f er ingen god løsning, da det allerede ligger mye grums her. Kommer opplysninger av typen fjernlån tillatt med på SFX-posten? Hvilken status får de postene som importeres fra SFX? Får vi mulighet til å behandle dem i blåbibsys? 11

Legges det Dewey-klassifikasjon på postene? Dersom nye titler ikke blir klassifisert, vil vi ikke kunne ta ut lister etter fag. Sammenhengen ved tittelendringer vil forsvinne. Hvilken status får de nye bestillingspostene våre i Bibsys? A.4 Synspunkter fra UB Oslo Vi er ganske usikre på hva dette vil bety i det daglige arbeidet, men vi mener som UBTØ at det ser ut som en brukbar løsning at gamle poster får endret status til intern. Helst en helt ny status hvis det lar seg gjøre,( alternativt bemerkning i 096 $f) for administrering av tidsskriftene. Slik systemet er i dag, er det problematisk for UBO å bruke SFX- dokidet både for vedlikehold internt, og eksternt for visningen for brukerne. Vi er fire avdelingsbibliotek med ulike interne behov til budsjettkontroll, sortering og gjenfinning. Så vi regner med å trenge både SFX-dokidet og intern -dokidet. Når det gjelder tabell for visning av sammenhengen mellom SFX-pakker og BIBSYS, synes vi heller ikke det er noen god løsning med tanke på vedlikehold. Statistikken regner vi med vil kunne løses av BIBSYS???? Ved bestilling av nye enkeltabonnement må vi fremdeles opprette et dokid med status best. Når tilgangen er i orden, sendes melding til X-port. Hva skjer med statusen på den opprinnelige posten ved importen fra SFX til BIBSYS? Blir den automatisk omgjort til intern samtidig med opprettelse av nytt sfx-dokid eller må det gjøres manuelt? Hvordan er planene med hensyn til hyppighet av oppdatering fra SFX til BIBSYS? Det vil ha betydning for hvor mye vi må gjøre manuelt. B Gratispakker BioMed Central Open Access Free DOAJ Directory of Open Access Journals Free E- Journals Highwire Press Free PubMed Central C SFX teksteksportformat 0 TITLE_NORMALIZED 1 TITLE_DISPLAY 2 TITLE_NON_FILING_CHAR 3 ISSN 12

4 OBJECT_ID 5 TARGET_PUBLIC_NAME 6 AVAILABILITY 7 E_ISSN 8 @ABBREV_TITLE 9 SERVICE_TYPE 10 11 OBJECT_PORTFOLIO_ID 12 856 $u (base_url) 13 856 $y (link text) 14 852 $a (institution info) 15 245 $h (title note) 16 LOCAL_THRESHOLD 17 GLOBAL_THRESHOLD 18 TARGET_ID 19 TARGET_SERVICE_ID 20 OBJECT_PORTFOLIO_ID 21 CATEGORY-@SUBCATEGORY 22 LOCAL_OBJECT_ATTRIBUTE D BIBSYS XML-skjema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="http://ns.bibsys.no/eimport" xmlns:xs="http://www.w3.org/2001/xmlschema" targetnamespace="http://ns.bibsys.no/eimport" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="records"> <xs:complextype> <xs:sequence> <xs:element ref="record" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="record"> <xs:complextype> <xs:sequence> <xs:element ref="title"/> <xs:element ref="eissn"/> <xs:element ref="issn" minoccurs="0"/> <xs:element ref="localid"/> 13

<xs:element ref="publisher" minoccurs="0"/> <xs:element ref="supplier" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="title" type="xs:string"/> <xs:element name="eissn" type="xs:string"/> <xs:element name="issn" type="xs:string"/> <xs:element name="localid" type="xs:string"/> <xs:element name="publisher" type="xs:string"/> <xs:element name="supplier"> <xs:complextype> <xs:sequence> <xs:element ref="linkid" minoccurs="0"/> <xs:element ref="supplierid" minoccurs="0"/> <xs:element ref="note" minoccurs="0"/> <xs:element ref="uri" minoccurs="0"/> <xs:element ref="mask" minoccurs="0"/> <xs:element ref="common" minoccurs="0"/> <xs:element ref="charge" minoccurs="0"/> <xs:element ref="library" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="content" default="f"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:length value="1"/> <xs:enumeration value="a"/> <xs:enumeration value="f"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> <xs:element name="linkid"> <xs:complextype mixed="true"/> <xs:element name="supplierid" type="xs:string"/> <xs:element name="note"> <xs:complextype mixed="true"/> <xs:element name="uri"> <xs:complextype mixed="true"/> 14

<xs:element name="mask" type="xs:string"/> <xs:element name="common"> <xs:complextype> <xs:sequence> <xs:element ref="holdings" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="charge" type="xs:string"/> <xs:element name="library"> <xs:complextype> <xs:sequence> <xs:element ref="packageid" minoccurs="0"/> <xs:element ref="holdings" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="bibcode" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="2"/> <xs:enumeration value="a"/> <xs:enumeration value="d"/> <xs:enumeration value="c"/> <xs:enumeration value="ns"/> <xs:enumeration value="k"/> <xs:enumeration value="n"/> <xs:enumeration value="p"/> <xs:enumeration value="q"/> <xs:enumeration value="r"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> <xs:element name="packageid" type="xs:string"/> <xs:element name="holdings"> <xs:complextype> <xs:sequence> <xs:element ref="firstyear" minoccurs="0"/> <xs:element ref="firstvolume" minoccurs="0"/> <xs:element ref="firstissue" minoccurs="0"/> <xs:element ref="firstmonth" minoccurs="0"/> <xs:element ref="delay" minoccurs="0"/> <xs:element ref="lastyear" minoccurs="0"/> 15

<xs:element ref="lastvolume" minoccurs="0"/> <xs:element ref="lastissue" minoccurs="0"/> <xs:element ref="lastmonth" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="firstyear" type="xs:string"/> <xs:element name="firstvolume" type="xs:string"/> <xs:element name="firstissue" type="xs:string"/> <xs:element name="firstmonth" type="xs:string"/> <xs:element name="delay" type="xs:string"/> <xs:element name="lastyear" type="xs:string"/> <xs:element name="lastvolume" type="xs:string"/> <xs:element name="lastissue" type="xs:string"/> <xs:element name="lastmonth" type="xs:string"/> </xs:schema> 16