.
ABM-temadagen

Den 2. juni 2005 afholdt Fabita en velbesøgt temadag på Vejle Biblioteket om ABM-samarbejdet, med deltagere fra alle tre sektorer. ABM står for arkiv, bibliotek og museum, og dagens emne var en diskussion af mulighederne for at samarbejde omkring formater, registrering, og udveksling af data. Kan det lade sig gøre? Hvilke forsøg er der gjort? For os fra biblioteksvæsenet bød dagen på et kig ind i et parallelt registreringsunivers med egne formater og regler. Henning Grauballes (Danmarks Biblioteksskole, Aalborg) oplæg fra dagen er ikke refereret her. I stedet har vi valgt at bringe en artikel af Henning.

Museernes registreringsprogram REGIN

referat af oplæg ved Eske Wohlfahrt, Kulturarvsstyrelsen

EW indledte med at præsentere REGINs internetadresse:http://regin.snorre.kuas.dk og hvordan vi kan prøve selv. EW’s powerpoints kan ses på Fabitas hjemmeside. REGIN er et stykke software, som kan bruges til museal registrering. REGIN opfylder en dokumentationsstandard.

Museal registrering startede i tidernes morgen med at skrive accession over modtagne genstande i en protokol i nummerorden. I løbet af 30’erne blev der brug for hurtig søgning bygget på faglige klassifikationer, som resulterede i “den grønne registrant” fra o. 1940. Den fik stor udbredelse. Dens betydning indskrænkes ved at afspejle det gamle bondesamfund og ikke informationssamfundet af i dag men den er fælles. I 1960’erne skifter fokus fra genstanden. Nu er det mere sammenhængen (kontekst), som har betydning for museumssagen – genstande, arkivalier, fotos osv. Som eksempel kan nævnes Søfartsmuseet i Esbjergs. Havnen i Esbjerg. Alt informationsbærende udstilles og registreres i museumssagen: Havnen i Esbjerg 1890-1995 :genstande, interviews, fotos.

Efterhånden vinder den gennemgående sagsregistrering indpas ude på museerne og ophøjes til standard. Dansk Museums Index er bygget til sagsregistrering; men udbredelsen blev ringe, da det kostede museerne en del penge og aldrig blev Windows baseret. Kulturarvsstyrelsen arbejder på en samlet central registrering for at prioritere forskning o s v og går endda ind for kassation. DMI indberettes; men DOS program kunne ikke køres sammen, derfor blev det ny system udviklet. EW gjorde derefter rede for sagsregistreringens struktur: Museumssag- korrespondance- genstand (aktør, sted, registrant, datering, opbevaring uddeponering, konservering, position) Registrator Interface = REGIN udviklet til registrering af museernes samlinger. Nationalmuseet og Tøjhusmuseet benytter ikke REGIN; men data kan udveksles. REGIN 2 eller 3 menes at medføre internationalt samarbejde. Internationalt hænger man stadig fast i genstanden; men Danmark samarbejder med 5-6 museer internationalt. Er REGIN godt nok? F. eks. er bibliotekssystemet bedre til bøger. Svaret er, at det er det enkelte museums ansvar: At man kan gå ind for det, der vises bl.a. også respektere eventuelt copyright. Hvad med mobile samlinger – udstilles i Århus f. eks. Svar: Udlånes, men registreres. Lånermuseet registrerer også.

Ref. Blide Kürstein Borg

“Bibliotekernes registreringssystem”

referat af oplæg ved Leif Andresen, Biblioteksstyrelsen

Leif indledte med en bemærkning om, at der var afsat meget kort tid til at gennemgå emnet, og at han derfor havde besluttet at benytte en anden indgangsvinkel end en gennemgang af danMARC2. Han havde valgt at koncentrere sig om, hvad bibliotekerne registrerer, den såkaldte FRBR-model, registreringsniveau, registreringsformater, udvekslingsformater, en status over standardiseringsniveau og udvekslingsmuligheder og til sidst en opsummerende afslutning. Han brugte kun 1 minut for meget – flot klaret.

Leifs powerpoints er tilgængelige på Fabitas hjemmeside og refereres derfor ikke i detaljer. Referatet forsøger at afspejle de kommentarer, Leif knyttede til sine dias.
I forbindelse med den lange liste over hvad der registreres, pointerede Leif, at registreringen af bøger sker som dokumentregistrering, altså dækkende en bestemt udgave af en titel og ikke værket som begreb.

Som formål for hvorfor bibliotekerne registrerer, beskrev Leif, at det består i at kunne finde og formidle konkrete materialer via udlån, kopiering, links til materialet eller brug på stedet. Han kommenterede, at formålet jo er det samme som for arkiver og museer.

Dernæst omtalte Leif Functional Requirements for Bibliographic Records (FRBR), der er en analysemodel bl.a. med det formål at anbefale et basisniveau for funktionalitet i især nationalbibliografiske poster. Modellen er interessant, fordi det er en international model, der forsøger at belyse brugernes behov for søgemuligheder i stedet for katalogiseringsreglernes afsæt i selve publikationen. Modellen kan i visse tilfælde give konflikter i forhold til katalogiseringspraksis, da den tager udgangspunkt i selve værket (det intellektuelle indhold, der ikke har manifesteret sig i nogen fysisk form) i stedet for den fysiske publikation, man sidder med, når man katalogiserer i dag. I bibliotek.dk er der fremskredne forsøg med værkvisning, der samler f.eks. alle udgaver af et værk eller alle fysiske medier, værket er udtrykt i, ved maskinelle analyser af de eksisterende katalogposter.
Leif gennemgik de fire lag i FRBR – værk, repræsentation af værk, dokument, eksemplar fulgt op med eksempler på de såkaldte kvalificerende attributter, der kan knytte sig til hvert lag. Han analyserede derefter bibliotekernes registreringer i forhold til modellen og nævnte de standarder, der knytter sig til de enkelte niveauer f.eks. danMARC2, ISO2709 og beholdningsformaterne. Og i den anledning viste han faktisk en rigtig danMARC2-post. Han opsummerede fordele og ulemper ved den nuværende registreringsmetode og gennemgik, hvilke lag der er egnede til udveksling.

Som afslutning sagde Leif, at det skulle klarlægges, hvilke formål ABM-samarbejdet kunne/skulle have, da de vil være bestemmende for, hvad, hvordan og mellem hvem der skal udveksles. Han nævnte selv det lokalhistoriske område som en oplagt og forholdsvis uproblematisk kandidat.

Ref. Bodil Dalgaard-Møller

Arkivernes registreringsprogram, ARKIBAS

referat af oplæg ved Asbjørn Hellum

Asbjørn Hellum fra Vejle Stadsarkiv præsenterede lokalarkivernes registreringsprogram, ARKIBAS, som bruges af 290 arkiver. Tidligere var der modstand mod EDB i arkivverdenen, og da man udviklede de tidlige versioner af ARKIBAS tilstræbte man, at databasesystemet skulle ligne de papirbaserede registreringsmetoder man var vant til.

Denne holdning har man gjort op med i ARKIBAS version 4. Det har i mange år været Sammenslutningen af Lokalarkivers (SLA) ønske at kunne tilbyde medlemmerne en ny udgave af ARKIBAS på en windows- eller web-platform. Da det er kostbart at udvikle specialprogrammer gik der er del år inden det økonomiske grundlag blev sikret gennem et tilskud på 2 mio. fra Kulturministeriet. Det, sammen med et tilsvarende bidrag fra lokalarkiverne har finansieret udviklingen af AKIBAS 4. ARKIBAS 4 består af moduler til: journalisering, registrering, søgning, visning og administration. Modulerne til journalisering og registrering har fem faneblade: stamkort-hændelser-historisk-indhold-relationer. Selvom fanerne hedder det samme i begge moduler, anvendes de forskelligt.

Arkivernes registreringssystem skal rumme oplysninger om, hvilke arkivalier der findes, hvor arkivalierne kommer fra, og hvor de er endt i samlingen. Lokalarkiverne har en dansk standard for registrering af arkivernes samlinger. Den er udgivet i form af “den gule arkivhåndbog”, som alle medlemmer af SLA modtager. Denne registreringsstandard er også grundlaget for udviklingen af ARKIBAS. En væsentlig forskel fra bibliotekernes verden er, at lokalarkivernes registrering som oftest tager udgangspunkt ikke i det enkelte dokument, men i et arkiv dvs. en samling dokumenter / arkivalier. En enkelt post beskriver således mange forskellige dokumenter. Det at mange dokumenter beskrives i en og samme post er udtryk for hvor vigtigt proveniens er som fælles karakteristik indenfor arkivverdenen.

165 lokalarkivers poster vedrørende arkivalier af privat oprindelse er søgbare via deres fællesdatabase, DANPA- Danmarks Nationale Privatarkivdatabase http://danpa.dda.dk. DANPA rummer over 100.000 poster. Arkiverne er ikke forpligtet til at levere poster til DANPA. Asbjørn Hellum mener at teknologiudviklingen vil bringe de faglige databaser på Internettet og dermed komme til at gøre de traditionelle fællesdatabaser overflødige

Ref.: Ruth Hedegaard og Kate Toft Madsen

Mapning af ABM-formater til Dublin Core

Af Henning Grauballe, Danmarks Biblioteksskole, Aalborg

Indledning

I dette indlæg præsenteres hovedresultater af et arbejde foretaget af Danmarks Biblioteksskole ved Haakon Lund og Henning Grauballe vedrørende mapning af registreringsformater fra ABM-sektorer til Dublin Core med henblik på anvendelse i en fælles brugergrænseflade.

Danmarks Biblioteksskoles bidrag til projektet omfatter følgende:

1) Mapping af udvalgte data, der skønnes relevante for “alment interesserede brugere”, i følgende fire standarder for

  • Biblioteker (DanMARC2)
  • Museer (Dansk Museumsstandard, d.v.s. standard for løs kulturarv)
  • Arkiver (2 standarder, heraf 1 for Statens Arkiver og 1 for de lokalhistoriske arkiver)

2) Identifikation og analyse af problemstillinger vedr. konvertering af data mellem de fire formater og Dublin Core.

Dublin Core generelt

Dublin Core Metadata Element Set (DC) er et simpelt registreringsformat som grundlæggende består af 15 metadata-elementer: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights. Registreringsformatet er oprindelig udviklet mhp. ophavsgenererede beskrivelser af dokumentlignende objekter (tekster i internet-regi) med fokus på genfinding (resource discovery). Fokus har således ikke været på f.eks. relevansbedømmelse.

Generelle principper for Dublin Core:

  1. Kernen i element-sættet kan udvides efter behovet i konkrete domæner
  2. Alle elementer er frivillige
  3. Alle elementer kan gentages
  4. Elementer kan modificeres/præciseres ved hjælp af “refinements”
  5. Data kan angives at stamme fra standardiserede lister, såkaldte “schemes”

Administrative Components

Nærværende korte introduktion til Dublin Core DCMI Administrative Components er baseret på http://www.bs.dk/standards/AdministrativeComponents.htm og
“DC/AC udvekslingsformatet”. PDF dokument tilgængelig via http://www.bs.dk
hvor yderligere information kan indhentes.

Dublin Core DCMI Administrative Metadata er udviklet som et værktøj til administration af metadata. Administrative Components (AC) indeholder dataelementer, der er nødvendige for administration og håndtering af poster i DC-metadata, såvel i enkelte baser som i forbindelse med dataudveksling mellem forskellige baser.

De administrative metadata opdeles i tre kategorier:
A. Data, som knytter sig til den samlede metadata-post
B. Særlige elementer, der angår transaktioner/ændringsdata
C. Headerinformation knyttet til batchfil

metadata.jpg

Grundlæggende problemstillinger

  1. Forskelle i registreringstradition indenfor ABM-sektorerne
  2. Forskelle i registreringsniveau indenfor ABM-sektorerne
  3. Problemer i opretholdelse af den oprindelige funktionalitet ved konvertering

I det efterfølgende uddybes disse problemstillinger med anvisninger hvordan problemerne kunne løses.

Forskelle i registreringstradition indenfor ABM-sektorerne.

Ved mapning fra de tre ovennævnte sektorer til et fælles format (Dublin Core) tages der udgangspunkt i registreringsformater der er specifikke for de enkelte sektorers systemer.
Disse formater er udviklet med vægt på kravene indenfor de enkelte ABM-sektorer inspireret af internationale standarder som f.eks. AACR2 og ISAD(G).
Registreringspraksis indenfor disse forskellige faglige domæner vil som udgangspunkt være inkonsistent, da der er tale om registrering af forskellige typer af artefakter.
Konsekvensen af dette er, at man i de enkelte sektorer har forskellige traditioner for hvad og hvordan data registreres, hvilket kan forårsage problemer når disse data skal konverteres til et fælles system.

Eksempler:

Ved angivelse af DC.creator vil der være tale om forskellige typer af ophav. Det kan være ophav til f.eks. en SAG hvilket kan være et Museum. I danMARC-poster vil der være tale om et ophav til det pågældende værk/dokument der er registreret og ved Statens Arkiver og Lokalarkiverne vil der være tale om den institution der har skabt de pågældende arkivalier.

Ved angivelse af DC.title vil der ligeledes være tale om forskellige typer af titler. I danMARC-poster vil det være en titel på det værk/dokument der er registreret. I forhold til museer og arkiver er der ingen garanti for at en titel i traditionel bibliografisk forstand er tilstede. Det kan derfor være nødvendigt at generere en titel på baggrund af f.eks. en betegnelse eller beskrivelse.

En vis ujævnhed i konverterede data må accepteres og dette må pointeres for brugerne af fællessystemet, f.eks. ved at angive hvilket system data oprindeligt stammer fra, således at der kan tages hensyn til dette ved søgning og præsentation af data.

Til identifikation af dataleverende system foreslås anvendt elementet post-identifikator i Administrative Components. Som identifier anvendes et fast ID for den enkelte ressource hentet fra det oprindelige system samt en værdi for registrerende entitet. Ved bibliografiske poster med oprindelse i DANBIB angives DANBIB som registrerende entitet.

Eksempel:

AC.Identifier = [identifier]
AC.Identifier.Proveniens = [id for entitet]

Forskelle i registreringsniveau indenfor ABM-sektorerne

Disse forskellige registreringstraditioner kommer bl.a. til udtryk i niveauet for registrering. For arkiver og museers vedkommende vil registreringen ofte være på et samlingsniveau (arkiv-fonds eller sager) således at en registrering er et aggregat af enheder. For bibliotekssektorens vedkommende vil en registrering i højere grad være på enhedsniveau, hvor undtagelsen dog er flerpoststruktur der kunne betragtes som samlingsniveau analogt med arkiver og museer.
Problemet er hvorledes denne hierarkiske struktur som samlingerne er udtryk for mappes til Dublin Cores flade struktur, således at det sikres at et minimum af funktionalitet bevares.

I modellen for mapning af data fra de forskellige systemer er der valgt at definere to niveauer for beskrivelse: et samlende niveau (Collection) og et niveau for enkelt del (Item). Denne opdeling er valgt da der i de museale systemer og i arkivsystemerne arbejdes med en sådan skelnen i de respektive registreringssystemer. Værdien Collection anvendes for alle poster på samlende niveau. Dette af hensyn til præsentation af poster således at den oprindelige sammenhæng i posterne kan bevares.
Angivelse af niveau findes i DC.Type med anvendelse af DCMI Type Vocabulary.
Eksempel:
Collection anvendes som betegnelse for hovedpost (danMARC2 felt 004 *a hvis værdien h), Text for bindpost (danMARC2 felt 004 *a hvis værdien b).

Sammenhæng mellem Collection og Item niveau skabes ved anvendelse af DC.Relation.

Problemer i opretholdelse af den oprindelige funktionalitet ved konvertering

Opretholdelse af den originale funktionalitet af data elementer ved konvertering til fælles format kan generelt være problematisk grundet den relative simplicitet i Dublin Core formatet. Der vil således ofte være en konflikt mellem optimering af søgeindgange og optimering af præsentation.

Eksempler:
Generelt konverteres delfelter til de tilsvarende specifikke DC elementer, således at data i eksempelvis felt 245 opsplittes og konverteres til henholdsvis DC.Title og DC.Creator.
Dette gøres i tilfælde hvor søgbarheden af data prioriteres højt. I visse tilfælde fraviges denne fremgangsmåde. Dette gør sig især gældende hvor “del-helheds relationer” kan identificeres. Eksempelvis konverteres felt 248 og 558 uden opsplitning til DC.Relation.
Dette gøres fordi den samlede præsentation af disse data prioriteres højt og det vurderes at være den bedste måde at undgå meningsforstyrrende informationstab omkring kontekst for disse data. Præsentationen bliver altså i disse tilfælde prioriteret på bekostning af at søgbarheden bliver mindre optimal.

Felt 440 kunne logisk set også betragtes som tilhørende “del-helheds relationer” og således mappes til DC.relation med de fordele dette vil give i forhold til angivelse af strukturer i præsentationsformat. På trods af dette er feltet mappet til DC.title, da det vurderes at være mest hensigtsmæssigt at disse data kan søges på lige fod med andre titeldata. Søgbarheden prioriteres altså i dette tilfælde på bekostning af præsentationen.

Eksempel på mapning

I nedenstående eksempel vises mapning af eksempelposter fra danMARC2. Der er givet eksempler af poster på samlings niveau (Collection) samt på Item niveau.

Eksempel på mapning af “Collection-level” post

acelement.jpg
Eksempel på mapning af post på Item-level

acelement2.jpg

Referencer

AC – administrative components : Dublin Core DCMI administrative metadata / Jytte Hansen og Leif Andresen (2003)
http://www.bs.dk/standards/AdministrativeComponents.htm

Collections and collection description focus /Pete Johnston & Bridget Robinson (2002)
http://www.ukoln.ac.uk/cd-focus/briefings/bp1/bp1.pdf

Dansk udvekslingsformat for metadata : DC/AC formatet / Susanne Thorborg og Leif Andresen (2003)
http://www.bs.dk/publikationer/andre/dcac/index.htm

DCMI metadata terms / DCMI Usage Board (2005)
http://dublincore.org/documents/dcmi-terms/

Discovering Online Resources : Unifying Resource Discovery Metadata for the Humanities:
An Application Based Upon the Dublin Core / Paul Miller (1997)
http://ahds.ac.uk/public/metadata/disc_05.html

Dublin Core metadata schema : ADS interpretation and mapping for the Arena project partners / Tony Austin (2003)
http://ads.ahds.ac.uk/arena/DCmeta.pdf

Guide to best practice : Dublin Core / Consortium for the Computer Interchange of Museum Information (2000)
http://www.cimi.org/public_docs/meta_bestprac_v1_1_210400.pdf

ISAD(G) : General International Standard Archival Description / adopted by the Committee on Descriptive Standards (2000)
http://www.ica.org/biblio/cds/isad_g_2e.pdf

Paneldebat med dagens oplægsholdere.

Ordstyrer Erik Thorlund Jepsen, Biblioteksstyrelsen

Erik Thorlund Jepsen satte som ordstyrer gang i diskussionen med følgende spørgsmål og emner til oplægsholderne:
Mapningsformat + standarder. Hvad kan de bruges til?

Hvad kan I forestille jer af applikationer for brugerne om 5 år?

Asbjørn Hellum: Hvis ikke fælles – så virtuel indgang på alle baser på én gang, men eventuelt afgrænset i geografi. Brugerne er ligeglade med, hvorfra data kommer.
Bodil Dalgaard-Møller: Hvordan karakteriseres de 3 centrale baser?
Asbjørn Hellum: Meget stærk Biblioteksstyrelse, ikke helt så stærk museumsstyrelse. Arkiv står svagest – har ikke noget ambitionsniveau.
Fra salen: Hvad gør man, når det står og falder med arkivet?
Spørgsmål fra salen: Kan REGIN bruges også til arkiver?
Eske Wohlfahrt: Om 5 år vil vi stadig have hver vores system, fordi vores verdener er så forskellige; men vi vil arbejde anderledes, for data vil kunne føres frem og tilbage og der vil opstå en underskov af ABM baser. Svar til spørgsmålene fra salen: I må vælge, om I vil være arkiv eller museum.
Spørgsmål fra Esbjerg: Er der ikke andre skismaer? Bl.a. også i biblioteksverdenen (KB – SB – folkebibliotekerne)
Leif Andresen: Bibliotek.dk findes stadigvæk. Der er et veldefineret brugerbehov og veldefineret institutionsbehov. Låneren er ligeglad med, hvor tingene findes.
Rasmus Falk Mikkelsen: Det er rigtigt for nogle af vores materialer. NOKS vil blive videreført om 5 år og vil være mere dækkende + emne services (f.eks. H.C. Andersen året) vil blive udbygget. RFM er mere skeptisk mht at søge virtuelt. For at få det til at spille sammen, skal data væltes rundt. Indholdet er for forskelligt – sted og tid f. eks. bliver ikke registreret på samme måde – ikke om 5 år – hvis om 10-15 år og så skal vi snakke standarder.
Erik Thorlund Jepsen: Bibliotek.dk indeholder også uensartede data: Folk finder ikke nær det, de kunne. Ville kunne afhjælpes ved f. eks. Google mapning. Konverteringsskemaer kunne lette lokalt.
Rasmus Falk Mikkelsen: Bibliotekets lokalhistoriske samling er nabo til stadsarkivet. Begge steder vil kunne søge og fortælle, hvor brugeren skal hen.

Hvad skal vi arbejde videre med?

Jens Topholm: Strukturen er kærnen. De 3 sektorer bliver stående. Datatab vil være uundgåelig.Man kan ikke samsøge uden at miste data. Fagspecifitet går ikke væk. Der skal besluttes, hvad standarderne er Vi må til Brian igen og fortælle ham om, hvad strukturer er. Sideløbende skal rigtige nørder skrue standarderne sammen.

Præsentation? Hvilke udfordringer eller problemer ser panelet?

Rasmus Falk Mikkelsen: Data præsenteres som de er og som de er lavet.
Asbjørn Hellum: Nogle materialer er lettere at præsentere end andre f.eks. billeder kontra artikler.
Jørgen Gram Christensen (Vejle) finder det oplagt, at forskelligt materiale får forskellig præsentation. Man skal ikke gøre ting ens, når de ikke er ens. Han foreslår konverteringsprogrammer, som oversætter, men ikke ændrer registreringspraksis.
Leif Andresen: Præsentationen er ikke problemet. Man må gerne kunne se, hvor man kommer fra. Problemet er emnetilgangen. Mapning med emneordningstemaer vanskeliggøres ved, at hierarkisk emneopbygning kun bruges nationalbibliografisk. Forskningsbibliotekernes emneord kunne ikke bruges – ihvertfald ikke for de penge Leif Andresen havde.
Jørgen Gram Christensen (Vejle) :Emneordssøgning i bibliotek.dk fungerer udemærket, da basen er rimelig homogen.
Eske Wohlfahrt: Vi bliver nødt til på tværs af sektorerne at enes om at konvergere på længere sigt. Målet for 20 år siden var en stor database. Nu ser vi mere afslappet på sagen: Brug den database, der passer jer bedst og søg så på tværs.

Økonomien er en ikke lille hurdle at overvinde: Kontingent til SLA er 900 kr. Statsanerkendte museer har REGIN gratis, hvorimod ARKIBAS koster 25 000 kr. i anskaffelse. Arkiverne har ikke lovgivernes interesse: det er dyrt at være lille og fattig. De, der er mest arkiv, men ikke har pengene, vælger selvfølgelig REGIN.
Jens Topholm: Kirkebøger er ikke lavet, for at vi nu kan slægtsforske.
Data er skabt til noget andet. Derfor skal de stadig kunne bruges. Helst af (os) alle.

Ref.: Blide Kürstein Borg