Indledning

Første skridt i DOMS-projektet har været afsøgning og kortlægning af eksisterende digitale samlinger på Statsbiblioteket. Dette er sket for at have et fornuftigt grundlag for at vurdere systemer til anvendelse som DOMS-systemer.

Afdækningen har fokuseret på at finde ud af

Det har mundet ud i en udførlig oversigt over eksisterende projekter på projektets wiki.

Denne liste vil være en vigtig del i vores arbejde med at identificere krav til et DOMS-system, og vælge strategier for opbevaring af data og metadata.

Statistik

En optælling af filer indeholdende digitale ressourcer giver ca. 1,6 millioner, gående fra 53 filer fra Tidsskrift for sprogforskning til 1.100.000 filer fra Radioavis-manuskripter. Ved en repræsentation af disse i en DOMS, vil antallet af objekter variere noget fra dette tal, da en del af materialet kræver grupperepræsentationer og opsplitning i flere enheder.

Den samlede størrelse af materialet er p.t. ca. 93 TB. Dette er meget skævt fordelt, med fire projekter (TV/Radio, Radioavis-manuskripter, Eventide og CD-ripning), der udgør 92 af de 93 TB.

Dataformater

Eksisterende projekter på SB er meget homogene mht. valg af dataformater. Størstedelen af materialemængden ligger i følgende fire formater:

Det er vor bedømmelse at ovenstående formater er gode kandidater som bevaringsformater. Der mangler imidlertid en mere specifik standardisering indenfor disse formater. I praksis er WAV enten Broadcast WAVE eller Windows standard WAV, MPEG er MPEG 1 eller 2, mens PDF og TIFF er meget varierede. En normalisering af eksisterende materiale er triviel ved WAV og TIFF, næppe ønskelig ved MPEG og kompleks ved PDF.

Nævneværdige undtagelser for ovenstående er

Konvertering af billedmaterialet til f.eks. TIFF er trivielt, mens HTML kan volde problemer.

Til præsentation anvendes der bl.a.

Det forventes at DOMS skal kunne håndtere disse og andre formater til præsentation, men at der ikke stilles nogen krav til bevaring.

Metadata

Langt størstedelen af eksisterende SB projekter anvender ad-hoc standarder til metadata, gemt på vidt forskellig vis, gående fra relationelle databaser til velformaliseret XML. En del af disse indeholder dele af eller hele DC (Dublic Core) og det anslås at der kan udtrækkes brugbar DC fra de resterende projekter. En enkelt undtagelse for ad-hoc valget er TV/Radio, der anvender PBCore (Public Broadcasting Metadata Dictionary).

Relationer

Under gennemgang af eksisterende og kommende projekter på SB blev der isoleret forskellige typer relationer mellem enheder. Disse præsenteres i prioriteret rækkefølge:

  1. Projektinterne relationer.
    Der ønskes generelt en modellering med mange atomare enheder, frem for færre sammensatte enheder. Dette kræver en relationsmekanisme mellem enheder. Teoretisk kunne denne mekaniske være projektspecifik, men dette ville ødelægge muligheden for en generel navigeringsmekaniske, på tværs af projekter.

  2. Relationer mellem tæt koblede enheder, på tværs af projekter.
    Eksempler på sådanne er

    • Relationer mellem TV/Radio digitalisering og TV2 reklamefilm, hvor enheder fra TV2-projekter har en del metadata, mens TV/Radio har kontekst.
    • De danske aviser (bog om aviser) og Gamle danske aviser (scannede avissider) repræsenterer henholdsvis beskrivelse og indhold.
    • Programoversigter og TV/Radio er ligeledes beskrivelse og indhold.

  3. Begivenhedsbaserede grupperinger på tværs af nyhedsmedier.
    En begivenhed, der behandles i forskellige nyhedsmedier, kunne sammenkobles med direkte referencer mellem de respektive enheder. En renere modellering ville være en eksplicit repræsentation af begivenheden, med referencer til de konkrete værker.
    Rent praktisk er der p.t. ret få forskellige nyhedsorienterede projekter med tidsmæssig sammenfald - Eventide og VHS-digitalisering ser ud til at være de eneste, når Netarkivet undtages. Netarkivet er oplagt at koble sammen med TV/Radio, og for den sags skyld Reklamefilm og CD-ripning. Eftersom Netarkivet ikke forventes at blive en del af DOMS, er der imidlertid en del ekstra overvejelser, der skal gøres i den forbindelse.

  4. Ad-hoc relationer.
    Sammenkobling af cd'er med udsendelser om kunstneren, referencer fra sogn i Vort sogns historie til hjemmesider for området etc.
    Der er en del kritiske overvejelser til dette: Har sådanne referencer reel værdi? Er der ressourcer til vedligeholdelse? Skal referencer kunne angives af andre end fagfolk?

Vælges der en generel referencemekanisme, hvor det oplagte valg er RDF (Resource Description Framework), er der ringe teknisk forskel på ovenstående løsninger. Det er dermed et overvejende politisk spørgsmål, hvilke referencer der skal understøttes.

Konklusion

Det viser sig at materialet på Statsbiblioteket er langt mere homogent hvad angår fil-formater and vi havde troet, hvilket er meget positivt. Indenfor de enkelte formatvalg er der dog store variationer, som sikkert med fordel kunne afhjælpes.

Hvad metadata angår er resultatet dog langt mindre positivt. Næsten ingen projekter følger en standard for metadata, hverken hvad angår det egentlige metadata-format eller opbevaringsmetoden.

Det viser sig at det i noget mindre grad end forventet vil være relevant at lave relationer mellem de nuværende forskellige digitaliserede samlinger, da overlappet mellem disse er overraskende lavt. Det er dog stadig relevant at fokusere på interne relationer, og det virker som fornuftigt at benytte et generelt system til at håndtere disse, ås begge slags relationer er en mulighed.

Vi har fået kortlagt mængden af data, og har dermed et rigtig godt udgangspunkt for at vurdere skaleringskrav til vores system.

Endelig har vi fået bekræftet at et DOMS-system er nødvendigt for at vi faktisk kan have et overblik over hvor vores materialer er, da det er meget svært at få et overblik over data i de mange meget forskellige systemer.

Fremtidigt arbejde

Næste skridt i arbejdet er at vurdere de kommende projekter efter samme skema som de vurderende. Det vil i høj grad være en opsøgende proces til de enkelte afdelinger. Vi har i forvejen identificeret de fleste af disse projekter, men mangler i høj grad detaljer.

Det er ikke vores mening at bruge lang tid på dette, vi regner med at de eksisterende projekter giver et rimeligt klart billede, og vil derfor hovedsageligt opsøge projekter vi forventer kan give ekstra eller anderledes input. Vi forventer ca. 3 mandeugers arbejde i dette.

Efter dette skridt forventer vi at have et godt overblik over hvilke formater af data og metadata vi har brug for at opbevare, og med udgangspunkt i dette er det vores forventning at kunne bede samlingsafdelingerne vedtage en mængde af anbefalede standarder for disse typer data. Kandidaterne til filformater er rimeligt klare, mens kandidater til metadataformater kan blive en større opgave. Ca. 4 mandeuger er estimeret til dette skridt.

Endelig vil vi have brug for at undersøge forskellige drift- og udviklingsmæssige krav til systemet.

Det samlede resterende arbejde for at kunne bygge en kravspecifikation er vurderet til 11 mandeuger (inklusive de ovenstående opgaver).

Status report may 2006 (last edited 2010-03-17 13:12:55 by localhost)