Juli 2011 (1. juli 2011) Værk type 1 Værk type 2 Enheds Enheds Bibliografisk relation: Addi relation: Primære relationer:
1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Baggrund og formål... 3 3 Datamodel for brønden... 4 3.1 Konceptuel model... 4 3.2 Logisk model... 5 4 Modtagelse af data til brønden... 13 4.1 Hovedflow... 13 4.2 Dataflows fra forskellige kilder... 14 5 Anvendelse af datamodellen i forskellige samarbejder... 16 6 Ordliste... 17 Datamodel for brønden Juli 2011 Side 2/20
2 Baggrund, formål og opsummering I forbindelse med beslutningen om at bibliotek.dk og DanBib skal migreres til brøndteknologi, nedsatte DBC en intern arbejdsgruppe, der skulle udarbejde en ny datamodel for Brønden. Brønden skal dels rumme brøndbibliotekernes bibliotekskataloger, med adgang via fx Ting eller Artesis, og dels de fælleskataloger DBC drifter. Det vil være den samme brønd data hentes fra ved søgning og visning. I løbet af det næste års tid bliver i første omgang bibliotek.dk omlagt til brøndteknologi. Mere konkret gik opgaven ud på at formulere en konceptuel datamodel, og omsætte denne til en logisk datamodel, som kan realiseres fysisk i brønden. I denne sammenhæng skal konceptuel, logisk og fysisk datamodel forstås således: konceptuel datamodel: begrebsmæssige entiteter og relationer uden hensyntagen til en konkret implementering logisk datamodel: model som er klar til implementering i brøndmiljøet fysisk datamodel: den konkrete implementering Modellerne er udarbejdet på baggrund af en vidensindsamling fra de eksisterende systemer. Den konceptuelle model tillige med input fra FRBR-modellen. Hvor dokumenter og beskrivelser fra såkaldte kilder i den hidtidige datamodel placeres i separate siloer indenfor brønden, placeres de i den nye datamodel i brønddataer, som kan deles af flere institutioner. Dette indebærer umiddelbart at et brøndbibliotek knyttes til folkebibliotekernes fællespost, hvis det er et folkebibliotek. Datamodellen tillader at andre biblioteker kan indlede et lignende samarbejde. Det er således muligt for forskningsbiblioteker at indgå i et udvidet katalogiseringssamarbejde, hvor bibliografiske data deles. Udover de gevinster et sådant samarbejde i øvrigt har, vil det sikre at antallet af er i brønden holdes nede, og at antallet af indekseringer reduceres. Ethvert bibliotek kan umiddelbart koble sig på eksisterende brønddataer, eventuelt med egne lokaldata og beholdningsdata. Hvis samarbejdet skal indebære mulighed for at rette i fællesposterne, vil det imidlertid kræve et administrationsapparat, som holder styr på hvilke biblioteker, der indgår i samarbejdet. Dette apparat er ikke beskrevet i nærværende rapport. Folkebibliotekernes katalogiseringssamarbejde varetages pt i Basis, dvs. udenfor brønden. Denne egenskab ved datamodellen bygger blandt andet på introduktion af begreberne dataejer, afsender og materialeejer til afløsning af begreberne kilde og submitter i den hidtidige datamodel. Afgrænsning af kataloger skal ske på basis af disse nye begreber. Da brønden fortsat vil indeholde forskellige bibliografiske poster, som beskriver det samme, rummer datamodellen det såkaldte enheds, som repræsenterer hele klyngen af brønddataer for de pågældende bibliografiske poster. Datamodellen giver endvidere mulighed for eksplicit at repræsentere værker efter forskellige definitioner. En række andre brønder har været under overvejelse. Det gælder bl.a. licenspakker, temaer, agencyer samt autoritetsdataer. Sådanne er vil senere kunne indføres som udvidelse af modellen. Alle brønder, både brønddataer, enhedser og værker, er udstyret med persistent identifikation. Arbejdet med datamodellen har gjort det klart, at det er bydende nødvendigt at have et veldefineret begrebsapparat når datamodellen diskuteres, udvikles og anvendes. Ved læsning af rapporten skal man være opmærksom på at en række begreber er nøjere beskrevet i afsnit 6, Ordliste. Datamodel for brønden Juli 2011 Side 3/20
3 Datamodel for brønden Indledningsvist beskrives den logiske model konceptuelt, vha. et ER diagram. Dernæst beskrives den logiske model med de entiteter som kan anvendes i Fedora 1. Det er værd at bemærke at kun relationer på overordnet niveau beskrives direkte i modellen. Udover disse kommer naturligvis en lang række relationer af mere berigende karakter, der tilsammen vil lægge en form for netværk ned over erne i Fedora. 3.1 Konceptuel model Den konceptuelle model kan grafisk afbildes som Figur 1. Figur 1 - Konceptuel model for den logiske datamodel Centralt i modellen er brønddata indeholdende beskrivende data, med eventuelle lokaldata og beholdningsdata tilknyttet. Sådanne bibliografiske brønddata kan indgå i enhedsdata 2. Enhedsdata kan igen indgå i værkdata, efter flere forskellige kriterier. Samme enhedsdata kan kun indgå i ét værkdata efter samme kriterium. Den anden hovedtype er brønddata som rummer et dokument. 1 Som er den databaseteknologi som brønden bygger på. 2 Det har været vanskeligt at finde et passende ord for dette relationsniveau, som ikke i forvejen var brugt i andre sammenhænge. Ordet udgave var i brug længe, men vi opfattede det som et problem, at vores definition af udgave for den konceptuelle model, og i al almindelighed, ikke passede med anvendelsen i den logiske model. Derfor faldt valget på enhed, hvor der er større overensstemmelse imellem definitionen af enhedspost, enhed og enheds som anvendt i den logiske model. Datamodel for brønden Juli 2011 Side 4/20
3.2 Logisk model 3.2.1 Objekter i brønden Brønden rummer forskellige slags dataer. Forenklet kan vi skelne mellem dokumenter (fx fuldtekster, film, musik) og metadata (data som beskriver dokumenter). I dette notat bruges den neutrale fællesbetegnelse brønddata, og betegnelserne dokument-brønddata eller bibliografisk-brøndata, hvis vi vil præcisere nærmere. Bemærk at der kan meget vel optræde brønddataer, som både kan opfattes som dokument- og som bibliografisk-brønddata. Udover brønddataer rummer denne version 2.0 af modellen enhedser og værker, hvor værkerne kan være af forskellig type. Enhedser dannes ved enhedsmatch af brønddataer, og værker ved værkmatch af enhedser. Dette er ikke ukompliceret. Og nærværende rapport beskriver ikke sagen udtømmende, men kun principperne for match. DBC kan imidlertid trække på stor erfaring fra DanBib og bibliotek.dk på dette punkt. Alle er i brønden er identificeret ved én entydig og persistent identifikation, dannet som funktion af de indeholdte komponenter. Dette er vigtigt aht. udveksling af data med 3 part, fx OCLC. En række andre er har været på tale, licenspakker, temaer (til Palles Gavebod) og agency-er til afgrænsning mm. Men de indgår ikke i denne version af modellen. Dette gælder også autoritetsdataer. Det er gruppens vurdering, at sådanne er senere kan indføres som udvidelse af modellen. Selvstændige autoritetsdataer, forudsætter at der etableres mulighed for samindeksering af forskellige brønddataer. 3.2.2 Objektkomponenter er, enhedser og de forskellige typer værker kan rumme komponenter, dvs. nærmere specificerede data. Om den faktiske implementering bliver strømme, er eller tabeller i en relationsdatabase er op til den fysiske implementering; her spiller performance naturligvis en stor rolle. Fx kunne mere flygtige data, som fx beholdningsdata, der ændrer sig meget over tid, overvejes placeret udenfor Fedora. er rummer følgende komponenter: DKABM (forenklede metadata, som er dannet på baggrund af data fra en given kilde) [1:1] Bibliografisk post (originale metadata) [0:1] Lokaldata (bibliografiske data som for et givet bibliotek erstatter eller supplerer den bibliografiske post) [0: ] Beholdningsdata (hel eller delvis beskrivelse af et givet biblioteks beholdningsdata for den pågældende bibliografiske post) [0: ] Dokument [0:1] Netdokumenter (dvs. dokumenter som ikke indgår i brønden, men tilgås via nettet) kan være direkte angivet via en URL, eller kan linkresolves på basis af metadata. Sådanne relationer fremgår ikke af den logiske model. er kan som nævnt have relationer til andre brønddataer i Fedora eller til er/data udenfor Fedora. I det følgende behandles kun relationer til andre brønddataer i Fedora, se afsnit 3.2.7 Relationer. Enhedser rummer en enkelt komponent: Lokaliseringsdata [0:1] Værker rummer ingen komponenter. 3.2.3 Formater Objektkomponenter indeholder data i forskellige formater. DKABM rummer data i DKABM-formatet Datamodel for brønden Juli 2011 Side 5/20
Bibliografisk post rummer en danmarc2 post indpakket i MarcXchange rammeformat eller en originalpost for poster modtaget i et andet format end danmarc2 Lokaldata rummer felter fra danmarc2 indpakket i MarcXchange rammeformat Beholdningsdata her er formatet ikke fastlagt! Dokument kan rumme flere formater afhængig af dokumenttypen. DocBook er det valgte fællesformat for fuldtekstdokumenter i brønden. Det anvendes fx til Faktalink, Forfatterweb og Materialevurderinger. 3.2.4 Dokument-brønddata Dokument-brønddataer rummer dokumenter, fx fuldtekster, lydfiler eller billeder. Sådanne brønddataer vil som hovedregel indeholde komponenterne DKABM og dokument. Figur 2 viser et sådant dokumentbrønddata. DKABM Dokument Objekt: Objektkomponent: Figur 2 Dokument brønddatabjektet indeholder DKABM og dokument. 3.2.5 Bibliografisk-brønddata Det bibliografiske-brønddata indeholder som minimum komponenterne DKABM og bibliografisk post. Dette er fx tilfældet for artikelmetadata (artikelposter). For egentlige biblioteksmaterialer kan brønddataet tillige indeholde et antal lokaldata og et antal beholdningsdata komponenter. Objektkomponenten bibliografisk post er entydigt identificeret ved dataejer-id og data-id. Dataejer-id identificerer dataejeren, dvs det bibliotek eller et konsortium af biblioteker, som ejer posten og som er ansvarlig for tildeling af data-id. Kun dataejeren kan rette posten. Bemærk at dataejeren ikke behøver at være identisk med afsenderen af den pågældende post. Afsenderen er identificeret ved afsender-id, hvilket fremgår ikke af selve posten, men af afleveringstransaktionen. Dataejeren behøver heller ikke at være ejer af selve biblioteksmaterialet. Materialeejerne er identificeret ved materialeejer-id, som findes i 096-felter i posten eller som indberettes separat. Hvis dataejeren er et konsortium bestående af flere biblioteker, kan alle rette efter nærmere aftalte regler. Eventuelle lokaldata samt beholdningsdata for det enkelte bibliotek rummes i komponenter herfor. et, som indgår i et sådant samarbejde, fungerer altså som fælleser for de pågældende biblioteker. Eventuelle lokaldata har ikke indflydelse på dannelsen af enhedset, og heller ikke på dannelsen af addirelationer til andre brønddataer (enhedser og addi-relationer beskrives nedenfor). Dette fastlægges af alene af den bibliografiske post. Hvis lokaldata fx fastlægger en anden navneform for en given forfatter, vil det fortsat være navneformen i den bibliografiske post, der vil blive brugt til enhedsmatch. Figur 3 viser hvordan en post fra Basis (dvs. en fællespost for folkebiblioteker) kan være repræsenteret i den logiske model. I eksemplet har tre brøndbiblioteker indlagt lokaldata, og to har indlagt beholdningsdata. Hvilke biblioteker, der rent faktisk ejer det pågældende materiale fremgår af materialeejeren, som er registreret i komponenten lokaliseringsdata i enhedset. Datamodel for brønden Juli 2011 Side 6/20
DKABM Lokaldata Lokaldata Lokaldata Bibliografisk post Beholdningsdata Beholdningsdata Objekt: Objektkomponent: Figur 3 Bibliografisk brønddata anvendt af flere biblioteker som deles om en fælles bibliografisk post Selvom dataejeren ikke er et konsortium, kan brønddataet udmærket indeholde både lokaldata beholdningsdata for det pågældende bibliotek. Og der er ikke noget i vejen for at andre biblioteker også kan koble sig på dette brønddata med egne lokaldata og beholdningsdata. Dette er ikke et eksisterende scenarium i DanBib i dag, men et muligt fremtidscenarium når DanBib integreres i brønden, specielt hvis brugergrænseflader for direkte katalogisering og materialanskaffelse indrettes til at udnytte denne mulighed. Figur 4 viser hvordan en typisk post fra et forskningsbibliotek kan repræsenteres som i brønden. DKABM Bibliografisk post Beholdningsdata Objekt: Objektkomponent: Figur 4 Bibliografisk brønddata anvendt af enkelt bibliotek 3.2.6 Særlige problemstillinger knyttet til bibliografiske brønddataer I det følgende præsenteres kort nogle overvejelser omkring repræsentation af flerbindsværker, musikposter og BibZoom poster. Flerbindsværker: Der findes to flerbindsværkformater i dm2 flerpostformatet og superpostformatet. DBC tilbyder tillige endnu et dataudvekslingsformat minisuperpostformatet. Flerbindsværker kan således modtages på tre forskellige former. For flerbindsværker formateret efter flerpostmodellen, vil hovedpost, sektions- og bindposter blive indpakket i hvert sit brøndatad. Denne repræsentationsform stiller krav om samindeksering af bindpost med de tilhørende sektions- og værkposter. Flerbindsværker formateret som minisuperposter vil resultere i et brønddata for hvert bind, hvilket direkte kan danne grundlag for indeksering. Et flerbindsværk katalogiseret efter Datamodel for brønden Juli 2011 Side 7/20
superpostmodellen vil derimod kun resultere i et enkelt brønddata, hvilket indebærer søgemæssig støj. De forskellige former betyder søgeproblemer og manglende mulighed for enhedsmatch. Der er altså behov for en normalisering, som sikrer at flerbindsværker kan enhedsmatches og søges ensartet. Normaliseringen må ikke indebære datatab. Poster som modtages i et specifikt format skal kunne eksporteres i samme format. Dette er blandt andet nødvendigt for poster fra Basis (som anvender flerpostmodellen). Der er ikke taget stilling til normaliseringsmetode, men en model kunne være at supplere de oprindelige poster med minisuperposter: Musikposter: Flerpostformatet: Bindpostens brønddata suppleres med en minisuperpost dannet automatisk ud fra bindpost, sektions- og hovedpost. Superpostformatet: For hvert bind dannes automatisk et brønddata indeholdende en minisuperpost. Disse dataer relaterer sig til superpostens data. For DBC s musikposter er det praksis at katalogisere et album samlet i én bibliografisk post. De enkelte skæringer er beskrevet i analysefelter. Dette indebærer en række søgemæssige uhensigtsmæssigheder, og umuliggør enhedsmatch på skæringsniveau. En ekstra krølle på sagen er, at flere skæringer på et album kan indgå i en sammenhæng, fx satser i et klassisk musikstykke. Dette kalder derfor også på en automatisk normalisering af data. Der er ikke i modellen taget stilling til hvordan dette kunne finde sted, men løsning kunne bygge på automatisk dannelse af brønddataer for hver enkelt analyse. Disse brønder relaterer sig til den post, som de er dannet ud fra. Dette løser dog ikke spørgsmålet om sammenhørende skæringer. BibZoom (netmusikken): I modsætning til DBC s musikposter indgår BibZooms poster i en hierarkisk struktur, bestående af albums og tracks. Albums indeholder links til tracks og tracks indeholder links til albums. Albumposterne består også af data fra tracks. Problemstillingen med tracks vs. albums, bør inddrages i overvejelserne vedrørende normalisering af musikposter. 3.2.7 Relationer er kan indgå i et væld af relationer. Heraf afspejles nogle grundlæggende relationer i datamodellen. Øvrige relationer, fx temarelationer, er ikke omfattet af modellen. Strukturrelationer afspejler strukturelle sammenhænge mellem brønddataer, fx sammenhængen mellem de enkelte dele af et flerbindsværk, mellem anmeldelse og anmeldt værk og mellem BibZooms albums og tracks. Såvel dokumenter som metadata kan optræde som supplerende data til et givent brønddata. En sådan relation kaldes en addi-relation. Eksempler på supplerende data: En forside er et dokument, som supplerer de metadata, der beskriver det dokument, som forsiden er del af En anmeldelse er et dokument, som supplerer de metadata, der beskriver det dokument, som anmeldelsen vedrører En anmeldelsespost er metadata, som supplerer de metadata, der beskriver det dokument, som den anmeldelse, anmeldelsesposten beskriver, vedrører. er kan endvidere være blade i en i en FRBR-lignende træstruktur. Dette kaldes en bibliografisk relation. enheds værk En primærrelation udpeger det primære I en klynge (se nærmere under enheds og værk nedenfor): Værk primært enheds Enheds primært brønddata Datamodel for brønden Juli 2011 Side 8/20
3.2.8 Enheds Formålet med enhedset er at sammenknytte alle bibliografiske brønddataer, hvis bibliografiske post beskriver det samme materiale. Et enheds kan således have en bibliografisk relation til 0 eller flere bibliografiske brønddataer. Et tomt enheds, dvs. et enheds uden tilknyttede bibliografiske brønddataer, kan anvendes som delete- ved eksport til 3. part. Relationen mellem enheds og klyngen af bibliografiske brønddataer kaldes som tidligere nævnt, en bibliografisk relation. Figur 5 viser relationerne mellem enheds og den tilhørende klynge af bibliografiske brønddataer. Enheds : Enheds Bibliografisk relation: Primær relation: Figur 5 Relationer mellem enhedsog brønddataer Enhedset bliver dannet ved at enhedsmatche bibliografiske brønddataer efter samme principper som den nuværende udgavematch i bibliotek.dk og danbib. Dette indebærer at bibliografisk post komponenterne i klyngen af bibliografiske brønddataer for samme enheds, alle skal matche mod hinanden. Ethvert enheds har (med mindre det er tomt) et primært brønddata udvalgt fra klyngen brønddataer. Prioriteringsmekanismen er ikke nærmere beskrevet i modellen. Denne relation mellem enhedset og det primære brønddata kaldes som tidligere nævnt en primær relation. Enhedset rummer ikke en bibliografisk post, men skal søgemæssigt opfattes som foreningsmængden af brønddataerne. Dette sikrer at data fra ét brønddata kan berige hele klyngen. I forbindelse med upload af data til Worldcat, vil det være naturligt at posten fra det primære brønddata med tilhørende lokaliseringer. Når et brønddata oprettes, tjekkes dataindholdet for den bibliografiske post automatisk. Hvis den rummer tilstrækkelige data foretages en enhedsmatch. Hvis denne enhedsmatch udpeger et eksisterende enheds, dannes relation hertil, og den nævnte prioriteringsmekanisme tjekker om det nye brønddata skal overtage rollen som primært brønddata for enhedset. Hvis enhedsmatchen ikke udpeger et eksisterende enheds, oprettes et nyt enheds, med brønddataet som primært brønddata. Hvis et brønddata rettes, foretages en ny enhedsmatch. Hvis dette resulterer i udpegning af et andet enheds, afhænger den videre håndtering af om brønddataet er primært eller ej. Tilsvarende gælder hvis et brønddata slettes. Hvis det ikke er et primært brønddata, kan relationen uden videre fjernes eller flytte til et andet enheds. Persistens af id-numre for enhedser er sikret, da de ikke slettes, men kun slettemarkeres. Det er muligt tillige at bevare en historik for enhedsers livscyklus, men dette ligger udenfor datamodellen. Som nævnt i afsnit 3.2.2, Objektkomponenter, rummer enhedset én enkelt komponent lokaliseringsdata. Ligesom for brønddataernes komponenter er det op til implementeringen hvordan denne komponent realiseres. Datagrundlaget for lokaliseringsdata komponenten findes enten i de bibliografiske poster i brønddataerne eller i et separat register i Basis. Sammenhængen mellem lokaliseringsregistret i Basis og lokaliseringsdata i brønden er ikke behandlet i nærvarende rapport. Datamodel for brønden Juli 2011 Side 9/20
Enheds Lokaliseringsdata Objekt: Objektkomponent: Figur 6 viser enhedset med sin komponent Figur 6 - Enheds med lokaliseringsdata 3.2.9 Værker Når man ser på de grænseflader vi benytter i dag til brønden, bibliotek.dk og danbib, er der mange forskellige måder at præsentere et værk på. Man kan således tale om flere værktyper. Nogle er definerede i (web)grænsefladen. Værker i denne rapport beskæftiger sig alene med de værktyper, der direkte er repræsenterede i brønden. Dette er væsentligt, da det er forholdsvis vanskeligt at danne værktyperne on-the-fly i Fedora. Et værk er et produkt at en værkdefinition. En værkdefinition fastlægger hvordan enhedser via deres primære bibliografiske knyttes sammen som værker. Et værk kan have en bibliografisk relation til 0 eller flere enhedser. Et værk uden relaterede enhedser, kan anvendes som delete- ved eksport til 3. part. Figur 7 viser relationerne mellem værk og den tilhørende klynge af enhedser. Værk Enheds Enheds Enheds Værk : Enheds Bibliografisk relation: Primær relation: Figur 7 Relationer mellem værk og enhedser Når et enheds oprettes eller rettes foretages et værkmatch for hver værktype. Værkmatchen sker ved at sammenligne bibliografiske data i enhedsets primære brønddata med bibliografiske data i værkernes primære enhedss primære brønddata. Hvis matchen ikke udpeger et eksisterende værk, oprettes et nyt værk med det pågældende enheds som primært enheds. Kun en ændring af det primære bibliografiske brønddata i et enheds, vil afstedkomme en ommatchning af værket. Man kan definere mere end én værkdefinition i systemet. Et eksempel på forskellige værkdefinitioner kunne være at den ene medtager sprog som kriterium som dannelse af et værk og den anden ikke. Datamodel for brønden Juli 2011 Side 10/20
Et enheds kan derfor tilhøre flere værker, således som det fremgår af Figur 8. Værk type 1 Enheds Enheds Enheds Værk type 2 Værk type 1: Værk type 2: Enheds: Bibliografisk relation: Figur 8 Enheds relateret til to værker af forskellig type 3.2.10 Ejerskab til data og materialer Ejerskab til et givet biblioteksmateriale fremgår af materialeejer-id, som indgår i lokaliseringsdata. Ejerskab til data fremgår af dataejer-id. Dataejer-id identificerer den instans, der er ansvarlig for tildeling af data-id, eventuelt ved genbrug af andet unikt id (fx ISBN), og som kan rette posten. Når flere biblioteker arbejder sammen i et katalogiseringsfællesskab, er det vigtigt at skelne mellem dataejer-id (som findes i fællespostens felt 001), afsender-id (som er knyttet til afleveringstransaktionen) og materialeejer-id (som kan indrapporteres i 096-felter, eller ved separate lokaliseringsindberetninger). Folkebibliotekernes fællesposter har dataejer-id = 870970 3, og det er derfor nødvendigt med afsender-id, således at brønden kan skelne om posten kommer fra et folkebibliotek eller fra DBC. Udover at gøre det muligt at aftale andre sådanne katalogiseringsfællesskaber, indebærer denne skelnen mellem dataejer-id, afsender-id og materialeejer-id, at ethvert bibliotek kan genbruge enhver post, og at alle poster således kan opfattes som potentielle fællesposter. Folkebibliotekernes fællesposter vil fx umiddelbart kunne genbruges af andre biblioteker, med mulighed for at tilknytte lokaldata og beholdningsdata. 3.2.11 Persistente identifikatorer Såvel bibliografiske poster som dokumenter skal ved modtagelsen være entydigt identificeret ved et data-id og et dataejer-id. For danmarc2-poster vil data-id og dataejer-id fremgå af felt 001. Eksempler: data-id = lokalt id-nummer data-id = lokalt id-nummer data-id = ISBN data-id = decentralt faustnummer data-id = centralt faustnummer data-id = centralt faustnummer dataejer-id = biblioteksnummer (generel form) dataejer-id = pseudobiblioteksnummer (generel form) dataejer-id = biblioteksnummer (forskningsbiblioteker) dataejer-id = biblioteksnummer (indberetning til Basis) dataejer-id = 870970 (Basis og folkebiblioteker) dataejer-id = biblioteksnummer (forskningsbiblioteker) 3 For sådanne fællesposter er sagen dog mere kompleks, idet det egentlige ejerskab fremgår af felt s10. Så længe Basis-systemet ikke er integreret i brønden, kan vi dog, set fra brønden, opfatte alle Basis-poster som ejet af DBC. Datamodel for brønden Juli 2011 Side 11/20
Da vi må regne med, at skulle eksportere brønddataer, enhedser og værker til 3. part, skal disse er også have en persistent identifikator, aht. resolving og opdatering. Modellen tilgodeser dette krav. 3.2.12 Supplerende brønddatadataer Såvel bibliografiske brønddataer som dokument brønddataer kan fungere som supplerende til et bibliografisk brønddata. Fx forsider, indskannede indholdsfortegnelser, flaptekster, materialevurderinger og anmeldelser. Relationen kaldes en addi-relation. I datamodellen er relationen knyttet til enhedset, således at alle brønddataer i klyngen får glæde af det supplerende brønddata. Oprettelse eller ændring af et brønddata skal afstedkomme en addi-match 4 på det ændrede eller nye brønddata. Ved fjernelse af et brønddata, f.eks. fordi det flytter til et andet enheds, skal alle de tilbageblivende brønddataer tjekkes for addi-relationer. At et brønddata optræder som supplerende data til et andet brønddata, har betydning i forhold til de valg, der skal træffes bl.a. i forbindelse med søgning og præsentation. Disse valg ligger uden for denne rapport. 3.2.13 Grafisk model Figur 9 er ikke en fuldstændig udfoldelse af alle de muligheder der findes, men giver et eksempel på en struktur. Værk type 1 Værk type 2 Enheds Enheds Bibliografisk relation: Addi relation: Primære relationer: Figur 9 Eksempel på struktur i den logiske datamodel 4 Efter den nuværende procedure i brønden. Datamodel for brønden Juli 2011 Side 12/20
4 Modtagelse af data til brønden Data kan modtages som batchleverancer eller som enkeltdataleverancer, hvor enkeltdata kan være en bibliografisk post, en katalogpost, et dokument, lokaldata eller beholdningsdata. Enkeltdataleverancer kan modtages i forbindelse med direkte indlægning (fx som bibliografiske poster fra en katalogiseringseditor eller som dokumenter fra en skriveservice). Ved direkte indlægning kan man i det efterfølgende behandlingsflow tillade sig at forudsætte, at der er foretaget en forudgående søgning i brønden. På den anden side stiller direkte indlægning krav om tidstro feedback. Batchleverancer er en samling af enkeltdata, som er skabt over en længere periode. Der er ikke nødvendigvis foretaget en forudgående søgning i brønden. Batchleverancer kan have følgende former: Grundleverance Supplerende leverance 4.1 Hovedflow Hovedflowet beskriver principielt og overordnet behandlingen af de modtagne enkeltdata (poster eller dokumenter). Det gør ikke rede for de forskelle som batchleverancer og enkeltdataleverancer måtte kræve. Dannelse af relationer er heller ikke omtalt. Ved den fysiske implementering vil en rettelse sandsynligvis blive udført ved at foretage en sletning af brønddataet efterfulgt af en oprettelse af det rettede brønddata. Data i form af dokumenter eller metadata er entydigt identificeret i form af dataejer-id og data-id. Desuden er afsenderen identificeret ved afsender-id. Hovedflowet kan resultere i en af følgende muligheder: afvisning oprettelse af et brønddata med tilhørende komponenter rettelse af en eller flere komponenter i eksisterende brønddata sletning af en eller flere komponenter i eksisterende brønddata 4.1.1 Afvisning Dette sker hvis det modtagne enkeltdata ikke opfylder grundlæggende valideringskrav. 4.1.2 Oprettelse Hvis det modtagne enkeltdata ikke via sin identifikation udpeger et eksisterende brønddata, dannes et brønddata, som indlejrer det modtagne enkeltdata, og forskellige afledte data og relationer. ets identifikation dannes ud fra det modtagne enkeltdatas identifikation, dvs. data-id og dataejer-id. 4.1.3 Rettelse Hvis det modtagne enkeltdata identificerer en komponent i et eksisterende bibliografisk, rettes den pågældende komponent i henhold til rettelsesalgoritme. Rettelsesalgoritmen involverer blandt andet begrebet ejerskab (se afsnit 3.2.10 Ejerskab til data og materialer). 4.1.4 Sletning Variant af rettelse, hvor den identificerede komponent slettes (eller slettemarkeres). 4.1.5 Søgning Da modellen opererer med persistente numre for enhedser, kan man udtage søgeregistre både på brønddata-, enheds- og værk-niveau. Søgning på enheds-niveau inddebærer at de samlede bibliografiske data i samtlige tilknyttede brønddataer søges under et. Datamodel for brønden Juli 2011 Side 13/20
Dette forslag til datamodel indebærer at afgrænsning (fælleskatalog, bibliotekskatalog andre kataloger) skal ske på basis af dataejer-id og materialeejer-id. 4.1.6 Visning Man kan enten se den bibliografiske post i det prioriterede brønddata knyttet til en enhedspost, eller man kan se den bibliografiske post i et specifikt brønddata, eventuelt modificeret med lokaldata, svarende til den afgrænsning, man har valgt. Ønsker man at se værket eller andre dele af basen, fx supplerende data, sker det ved at traversere erne i brønden med de links, den sætter til rådighed. Hvis man har valgt virtuelle-links indebærer det at web-laget foretager søgning eller lignende i de databaser, systemet benytter udover Fedora. 4.2 Dataflows fra forskellige kilder 4.2.1 Bibliografiske poster fra Basis dataejer-id = afsender-id = 870970 Posterne modtages som danmarc2-poster med flerbindsværker formateret efter flerpostmodellen. Hvis dataejer-id og data-id identificerer et eksisterende brønddata, rettes den indlejrede bibliografiske post. I modsat fald oprettes et brønddata med den pågældende bibliografiske post indlejret. 4.2.2 Bibliografiske poster fra et folkebibliotek, som er brøndbibliotek Et brøndbibliotek fremsender i dag følgende batchleverancer: Lokaliseringer til Basis Decentrale poster til Basis Rettelser til poster i Basis Biblioteksposter til brønden Det kan de principielt fortsætte med, bortset fra at de i fremtiden også skal fremsende beholdningsdata til brønden. Det er dog nærliggende at brøndbibliotekerne tilbydes en forenkling, således at de kan nøjes med at fremsende biblioteksposter + beholdningsdata til DBC, som ved modtagelse afgør hvorledes disse data skal håndteres i brønden og i Basis. De bibliografiske poster modtages som danmarc2-poster med flerbindsværker formateret efter flerpostmodellen. Der er ikke på dette niveau taget stilling til formatet for beholdningsdata de kan enten indgå i den bibliografiske post eller som selvstændige poster. De fremsendte data kan være ledsaget af information om formålet med leverancen. Dette kunne være i form af en simpel kode, som angiver at der er tale om en forkatalogisering, en decentral post, en rettelse eller en supplering af emneord til Basis. Hvis formålet er opdatering af brønden, skal lokaldata og beholdningsdata kunne afgrænses. DanMARC2 fastlægger en række felter til lokal brug. Det omfatter blandt andet bogstavfelterne. Det skal dog sikres, at den lokale brug ikke kolliderer ved indlæggelse i brønden. DBC anvender en række lokale felter (jævnfør DBC s praksisregler), fx det tidligere omtalte s10. Nedenstående skema gengiver principperne for denne håndtering. Der ses bort fra fejlhåndtering. I visse tilfælde forudsættes fx at en Basispost allerede findes i brønden, når et bibliotek indsender den pågældende post med henblik på indlæggelse i brønden (og det holder ikke nødvendigvis i den virkelige verden). Postens behandling afhænger af dataejer-id, afsender-id og om posten skal til Basis (i skemaet noteret som Basiskode) dvs indberetning af en decentral post, eller en rettelse eller et supplement til en eksisterende post i Basis. Praksis for opdatering af poster i Basis, er at posterne har dataejer-id = 870970 og data-id = centralt faustnummer. Der er imidlertid forskellig praksis for opbevaring af fællesposterne i lokalsystemerne. I DDELibra har de dataejer-id = 870970; dette gælder selvom lokaldata er tilføjet. Integra opbevarer derimod både fællesposten (dataejer-id = 870970) og en kopi heraf med eventuelle lokaldata tilføjet (dataejer-id = biblioteksnummer). I nedenstående skema forudsættes at fællesposter fremsendes med dataejer-id = 870970 og afsender-id = biblioteksnummer, uanset om de rummer lokaldata eller ej. Datamodel for brønden Juli 2011 Side 14/20
Bemærk endvidere at folkebiliotekerne, i henhold til nuværende praksis, fremsender lokaliseringsindberetninger til Basis. Nedenstående skema angiver ikke sammenhængen mellem lokaliseringsregistret i Basis og lokaliseringsdata i brønden, men brøndens lokaliseringsdata bør naturligvis opdateres i alle fire nævnte tilfælde. dataejer-id = 870970 afsender-id = biblioteksnr Basis=nej dataejer-id = 870970 afsender-id = biblioteksnr Basis=ja dataejer-id = afsender-id = biblioteksnr Basis=nej dataejer-id = afsender-id = biblioteksnr Basis=ja Kommentar Data-id er et centralt faustnummer. Posten identificerer et brøndatad som indeholder en Basispost. Data-id er et centralt faustnummer. Posten identificerer et brønddata som indeholder en Basispost. Data-id er et decentralt faustnummer. Data-id er et decentralt faustnummer. Handling Eventuelle lokaldata eller beholdningsdata for det pågældende afsender-id oprettes eller opdateres i det identificerede brønddata. Eventuelle lokaldata eller beholdningsdata for det pågældende afsender-id oprettes eller opdateres i det identificerede brønddata. Posten videresendes til Basis til opdatering af den pågældende post. Hvis dataejer-id og data-id identificerer et eksisterende brønddata, rettes dette. I modsat fald oprettes et brønddata ud fra de fremsendte data. Hvis dataejer-id og data-id identificerer et eksisterende brønddata, rettes dette. I modsat fald oprettes et brønddata ud fra de fremsendte data. Posten videresendes til Basis. Hvis posten findes i forvejen, sendes meddelelse til biblioteket herom. Hvis posten ikke findes i forvejen, tildeles et centralt faustnummer. Det er brøndbibliotekernes ansvar at opdatere brønden efterfølgende. Det kan eventuelt også forekomme, at DBC ikke ønsker at optage posten i Basis. I så fald vil posten vedblivende optræde i brønden med sit decentrale faustnummer. 4.2.3 Bibliografiske poster fra et folkebibliotek, som ikke er brøndbibliotek Disse folkebiblioteker sender uændret lokaliseringer, decentrale poster og rettelser til Basis. 4.2.4 Bibliografiske poster fra et forskningsbibliotek, som er brøndbibliotek Der er pt. ingen forskningsbiblioteker, der er brøndbiblioteker 4.2.5 Bibliografiske poster fra et forskningsbibliotek, som ikke er brøndbibliotek Bibliotekerne fremsender biblioteksposter, som identificeres ved afsender-id, dataejer-id og data-id. Normalt er afsender-id og dataejer-id ens. Hvis den identificerede post ikke findes i brønden, oprettes et brønddata, som indlejrer den bibliografiske post. Findes posten allerede i brønden, overskrives den. 4.2.6 Bibliografiske poster og dokumenter fra anden kilde Det drejer sig typisk om dokumentsamlinger som fx Faktalink, men kan også omfatte rent bibliografiske data som fx Artikelbasen. Dataflowet er individuelt for hver enkelt kilde. Datamodel for brønden Juli 2011 Side 15/20
5 Anvendelse af datamodellen i forskellige samarbejder Herunder gives en kort beskrivelse af hvordan datamodellen kan anvendes til at repræsentere bibliografiske data i henholdsvis folkebiblioteker og i forskningsbiblioteker. Desuden gives forslag til fremtidige udvidelser af katalogiseringssamarbejdet. 5.1.1 Folkebiblioteker Folkebiblioteker, herunder brøndbiblioteker, vil som udgangspunkt dele bibliografiske brønddataer. Data fra folkebiblioteker kommer fra 2 kilder Basis og brøndbibliotekerne. Brøndbibliotekerne indberetter pt. både til Basis (lokaliseringsdata og decentrale poster) og til brønden (biblioteksposter). Dette foreslås ændret, således at brøndbibliotekerne i fremtiden kun fremsender biblioteksposter, jævnfør dataflow beskrevet i afsnit 4.2.2, Bibliografiske poster fra et folkebibliotek, som er brøndbibliotek. Dette indebærer at fællesposter vedligeholdes i Basis, hvorfra de overføres til brønden, mens lokaldata og beholdningsdata vedligeholdes i brønden. Lokaliseringer vedligeholdes også i Basis, men spørgsmålet er om dette ikke med fordel kunne flyttes til brønden. Både den bibliografiske fællespost, beholdningsdata og lokaldata skal være søgbare (samindeksering). 5.1.2 Forskningsbiblioteker Bibliografiske brønddataer dannes ud fra fra de indberetninger som sker til DanBib (og bibliotek.dk). Ejerskabet er fastlagt ud fra posterne dataejer-id (bibliotekskoden i felt 001*b). Kun ejeren kan rette og slette brønddataet. Se afsnit 4.2.5. I de fleste tilfælde vil der kun være et sæt beholdningsdata nemlig det pågældende biblioteks. Nogle biblioteker administrerer imidlertid fællesposter for flere bibliotekers. Sådanne fællesposter vil rumme beholdningsdata i 096- felter. Modellen rummer mulighed for at de enkelte biblioteker kan indrapportere lokaldata, analogt til folkebibliotekernes fælleser. 5.1.3 Udvidet katalogiseringssamarbejde (fremtidscenarier) Datamodellen rummer, som nævnt i afsnit 3.2.10 Ejerskab til data og materialer, mulighed for at alle brønddataer kan danne grundlag for et udvidet katalogiseringssamarbejde mellem bibliotekerne. Datamodellen skelner mellem dataejer-id og afsender-id, hvilket indebærer at ethvert bibliotek kan genbruge enhver post 5, og at alle poster således kan opfattes som potentielle fællesposter. Folkebibliotekernes fællesposter vil fx umiddelbart kunne genbruges af andre biblioteker, med mulighed for at tilknytte lokaldata og beholdningsdata. Dette indebærer dog ikke umiddelbart mulighed for at rette i fællesposten. Samarbejdet kan endvidere udvides, således at bibliotekerne også har mulighed for at rette i fællesposten. Der er principielt to muligheder, hvorpå dette kan administreres: Der udpeges et dataejer-id, som repræsenterer en fri pulje af brønddataer, hvor alle kan rette den indeholdte bibliografiske post. For at sikre entydig identifikation, tildeler brønden automatisk et data-id, når en ny post oprettes. En række biblioteker indgår aftale om at kunne rette i hinandens poster, dvs. bibliografiske poster med et dataejer-id for et af de biblioteker, der indgår i samarbejdet. Dette indebærer at brønden skal rumme et administrationssystem, som holder styr på hvilke biblioteker, der har indgået et sådant samarbejde. For at det skal kunne fungere, skal der være en form for tidsstempel, således at man kan lave en afslappet låsning. Dvs. en metode til at undgå at en rettet post overskriver en post, som er blevet rettet i mellemtiden af et andet bibliotek. Sådanne samarbejder ligner på mange måder folkebibliotekssamarbejdet. Administrationen af dette, herunder rettelser af folkebibliotekernes fællesposter, sker imidlertid pt. i Basis. 5 Dvs. komponenten bibliografisk post i et brønddata Datamodel for brønden Juli 2011 Side 16/20
6 Ordliste For hver term er angivet en definition, og eventuelt eksempler på brug i danske biblioteker. Tillige er om muligt angivet begreber, som ligner, fra hhv. ISO 8459 og Informationsordbogen. Afsender Afsender-id Analyse Beholdningsdata Bibliografisk post Bibliotekskatalog Biblioteksmateriale Bibliotekspost Instans som sender brønddata til indlæggelse i brønden Entydig identifikation af afsender Bibliografisk beskrivelse af en del af et biblioteksmateriale. Fx et afsnit i en bog, en enkelt sang af flere på en cd, en artikel i et tidsskrift, et enkelt hæfte i en mappe eller en del af et sammensat materiale. Analyser kan indgå i beskrivelsen af det samlede biblioteksmateriale som noter, eller de kan udformes som selvstændige registreringer, der desuden refererer til det samlede materiale 1: Samtlige eksemplardata for et givent biblioteksmateriale for et eller flere biblioteker 2: Objektkomponent i brønddata, indeholdende udvalgte eksemplardata for et givent biblioteksmateriale for et givent bibliotek ISO 8459: Holdings Data structure describing a bibliographic resource or group of like or similar resources and one or more institution s copies of the resource or resources 1: Beskrivelse af en given udgave af et biblioteksmateriale 2: Objektkomponent i brønddata, indeholdende en danmarc2-post i MarcXchange rammeformat ISO 8459: Catalogue record Example Of ISO 8459: Record Group of data elements usually treated as a unit, and often organised into sub-units called fields, that identifies, describes and facilitates retrieval of an entity Samling af biblioteksposter med tilknyttede beholdningsdata(1) for de biblioteksmaterialer, som biblioteket ejer Informationsordbogen: Bibliotekskatalog Katalog over bog- og tidsskriftbestanden i et bestemt bibliotek, jf. kortkatalog, OPAC og fælleskatalog 1 Ressource som et bibliotek ejer eller har brugsret til, og som biblioteket stiller til rådighed for sine lånere, fysisk eller via nettet. Biblioteksmaterialet kan forefindes i et antal ens eksemplarer Et biblioteks version af en bibliografisk post Data som opbevares i brønden Datamodel for brønden Juli 2011 Side 17/20
Brønd Data-id Dataejer Dataejer-id Dokument Brønd som rummer beskrivende data og/eller en digital ressource. Alle brønddataer rummer komponenten DKABM. Øvrige mulige komponenter er dokument, bibliografisk post, beholdningsdata og lokaliseringsdata, enheds, værk Entydig identifikation af brønddata fra en given dataejer Instans, der er ansvarlig for tildeling af data-id for brønddata og regler for hvem der må rette de pågældende brønddata Entydig identifikation af dataejer Objektkomponent i brønddata, indeholdende en digital ressource, fx fuldtetekst, lydfil, billede DKABM Eksemplar Eksemplardata Enhedsdata Enheds 1: Dansk metadataformat, udviklet til brug på tværs af arkiver, biblioteker og museer. Formatet bygger på det internationale Dublin Core format 2: Objektkomponent i brønddata, indeholdende XML dokument med DKABM metadata Fysisk eller elektronisk instans af et biblioteksmateriale. Et eksemplar kan omfatte en eller flere dele, som håndteres samlet ISO 8459: Copy Tangible instance of a bibliographic resource or set, whether physical or electronic, comprising one or more pieces Informationsordbogen: Eksemplar Et dokument ud af en mængde af ens dokumenter Data som knytter sig til det enkelte eksemplar Eksemplardata omfatter blandt andet materialenummer (som vil kunne genfindes på stregkoden eller RFID-taggen) og placeringsangivelse (profildata) ISO 8459: Copy information Group of data elements providing details of a specific physical or digital resource Klyngen af alle bibliografiske poster, der beskriver det samme biblioteksmateriale eller samme del heraf Brønd som repræsenterer klyngen af alle bibliografiske brønddataer, der beskriver det samme biblioteksmateriale eller samme del heraf Datamodel for brønden Juli 2011 Side 18/20
Fælles Fællespost Fælleskatalog Lokaldata Lokaliseringsdata Lokalkatalog Materialeejer Materialeejer-id Objektkomponent Et brønddata, som deles af en række biblioteker. Note: For folkebibliotekerne udgør brønddataerne dannet fra posterne i Basis sådanne fælleser Bibliografisk post som deles af flere biblioteker Samling af bibliografiske poster som beskriver biblioteksmaterialerne i samtlige biblioteker i en nærmere afgrænset sammenhæng, f.eks. en region, med angivelse af hvor biblioteksmaterialerne kan findes Informationsordbogen: Fælleskatalog Katalog der under ét, dækker fysisk adskilte dokumentsamlinger, fortrinsvis selvstændige biblioteker, jf. accessionskatalog. Objektkomponent i brønddata, indeholdende lokale varianter af specifikke bibliografiske data i en fællespost. De kan enten supplere fællesposten eller overskrive den ifm søgning og visning i bibliotekets OPAC 1: Oplysning om hvilke biblioteker, der har et givet biblioteksmateriale. Begrebet anvendes i fælleskataloger. Lokaliseringsdata omfatter ikke detaljerede beholdningsdata, men grundlæggende blot en markering af at biblioteket har den pågældende titel samt en oplysning om tilgængelighed (om den fx lånes ud). 2: Objektkomponent i enheds, indeholdende liste af materialeejer-id ISO 8459: Locations count Count of the number of physical locations having one or more copies of a bibliographic resource. Informationsordbogen: Lokaliseringsbase Bibliografisk database som under hver post oplyser i hvilke(t) bibliotek(er) det tilsvarende dokument findes. Note: I Basis er de materialer, der findes i de enkelte biblioteker, angivet som lokaliseringer knyttet til de enkelte poster. Markeringen kan være suppleret med en kort eller en lang note. Disse lokaliseringer ligger fysisk i en separat tabel, lokreg. I forbindelse med overførsel til DanBib og bibliotek.dk anføres lokaliseringerne i 096-felter. Af hensyn til aktualitet foretages dog opslag i lokreg i forbindelse med visning. Se bibliotekskatalog Institution som ejer et givet biblioteksmateriale, eller brugsret hertil Entydig identifikation af materialeejer Data knyttet til et brønd Datamodel for brønden Juli 2011 Side 19/20
Oplag Udgave Værk Værkdata Værk Mængden af alle eksemplarer af en udgave, som er fremstillet i den samme proces Informationsordbogen: Oplag Mængden af eksemplarer af en udgave 1 der er trykt i én og samme trykgang (arbejdsproces) Mængden af alle ens eksemplarer af et publiceret materiale. En udgave kan forekomme i flere oplag. ISO 8459: Edition Identifier of a group of copies of a resource produced from one master copy or produced with substantially the same type image and having the same content Informationsordbogen: Udgave 1 Den samlede mængde eksemplarer af et dokument fremstillet fra samme sats eller fra samme (uændrede) forlæg. En udgave kan omfatte flere optryk 1 eller flere oplag Samling af alle publicerede versioner med principielt samme indhold. Der findes forskellige værkdefinitioner, som kan have relevans i brugergrænseflader Klyngen af alle bibliografiske poster, der beskriver det samme værk ifølge en specifik værkdefinition Brønd som fungerer som fælles beskrivelse for alle enhedser, der beskriver det samme værk efter en given værkdefinition Datamodel for brønden Juli 2011 Side 20/20