eMunch.no

— om tekniske og praktiske løsninger i arbeidet med et digitalt arkiv for Edvard Munchs tekster

Se lysbildepresentasjon (pdf)

Hilde Bøe

Innledning

Målet for eMunch

Prosjektet Munchs tekster skal resultere i et digitalt arkiv hvor alle tekster legges ut i fulltekst og som digital faksimile. Tekstene skal følges av summariske bibliografiske opplysninger og manuskriptbeskrivelser, samt av noter, kommentarer og koblinger mot Munchs billedkunst og andre versjoner av teksten. Arkivet skal også inneholde skoleoppgaver tilpasset undervisning i norsk grunnskole og videregående skole. Arkivet skal vedlikeholdes og suppleres av museets ansatte når prosjektet er sluttført. Det skal fortrinnsvis være mulig å bygge det ut med nye funksjoner gitt senere økonomisk mulighet.

For museet handler prosjektet om å vise fram for publikum en stor del av samlingen som hittil har vært utilgjengelig, og å gjøre det på en måte som sikrer materialet vitenskapelig standard.

Materialet

Edvard Munch testamenterte ved sin død i 1944 alle de kunstverkene han eide og alt skriftlig materiale han hadde tatt vare på, til Oslo kommune. Derfor eier Munchmuseet ikke bare en svært stor kunstsamling, men også et stort skriftlig materiale. Samlet regner man med at det finnes om lag 13 000 sider etter Munch, og av disse eier museet omtrent 90%. Det er med andre ord en anseelig del av Munch-materialet som er i det offentliges eie. Hittil har imidlertid ikke det betydd at materialet har vært særlig tilgjengelig for den interesserte allmennhet. Den begrensa tilgangen har selvfølgelig også hatt med diskresjon å gjøre: Materialet er fortsatt relativt nytt, og man har derfor hatt hensyn å ta i forhold til familie og andre omtalte. Den som har villet fordype seg i materialet har måttet komme til museet og arbeide der. Der har man kunnet lese museets egne transkripsjoner og studere originalmateriale.

Munchs egne tekster har dermed i liten grad nådd publikum. Et utvalg tekster redigert av Poul Erik Tøjner er blitt publisert og også noen brevvekslinger (bla. Schiefler-korrespondansen og familiebrevene). I forskning har det vært en tendens til at man siterer hverandre heller enn å gå til originalene og finne nytt materiale.

Å gjøre hele materialet tilgjengelig for publikum, det være seg en forsker eller en Munch-fan, har i lang tid vært et ønske i museet. Hittil har det vært svært vanskelig å realisere fordi så mye av materialet ikke egner seg for publisering i bok. Jeg skal si litt om materialets karakter for å klargjøre hvorfor:

Materialet inneholder brev, brevutkast, litterære dagboksnotater, skjønnlitterære utkast, forretningsbrev, kontrakter, utkast til selvangivelser, notater og lister til utstillinger — alt ispedd tegninger, drodling og kludring. Munch skrev tekster til mange av bildene sine, mest kjent er nok Skrik, som fins i et titalls versjoner, både som tekst og som bilde. Det finnes mange tilfeller av parallelle versjoner av tekster også ellers i materialet. Til enkelte brev kunne Munch skrive opptil 18 utkast. Det er ikke enkelt å avgjøre hvilke(t) av utkastene som skal trykkes når det genetiske forholdet mellom utkastene er infløkt. Tekster til bilder finnes også i flere forskjellige versjoner, og her kan det virke som om Munch ikke egentlig skrev for å lage en endelig versjon, men like mye for å bearbeide motivet videre parallelt med den billedkunstneriske bearbeidingen. Hvilken versjon skulle vi i så fall velge? Og kunne vi la være å reprodusere bildene? Tekstene framstår ofte som uferdige. Det er en prosesskarakter i mye av det skriftlige materialet som gjør det svært krevende å begrense materialet ved en bokutgivelse. Et utvalg vil gi det man hittil har fått; bare en smakebit. Å publisere alt vil medføre mange gjentagelser, som nok vil oppleves som unødvendige og umotiverte.

I dagens digitale virkelighet er tilgjengeliggjøring for offentligheten endelig innenfor rekkevidde.

Faktorer som begrenser

Men selv i den digitale virkelighet er alle prosjekter omgitt av et sett forutsetninger, som er bestemmende og ofte begrensende for hvordan prosjektet kan gjennomføres. De viktigste i vårt prosjekt er:

De valg museet allerede hadde tatt angående programvare, metodikk, retningslinjer osv. Kompetanse som det gjennom dette innehar. Endringer her vil bety at mer tid og ressurser vil gå til opplæring etc. og at tid og ressurser dermed ville være tapt for hovedsaken, det å få tekstene ut på nettet. Vi har derfor forsøkt å bruke det som allerede finnes på huset.

Ressurser — tid og økonomi: Vi må velge, vi kan ikke rekker over alle oppgaver vi kunne tenke oss å gjøre, og vi har ikke tid til å gå dypt inn i tekstene. Vi ederer ikke tekstene, men transkripsjonene er kvalitetssikret og standarden er vitenskapelig: Tekstene er kollasjonert og korrekturlest i flere omganger. Brukerne våre kan stole på det de får tilgang til.

Arkivfunksjonen: Målet er altså et arkiv over tekstene, og det er dermed tekstene som har prioritet.

Framtidig vedlikehold og oppdatering: Vi må sørge for at nettstedet kan vedlikeholdes og oppdateres av de ansatte på museet. Når prosjektet er fullført forsvinner stillingene og kompetansen som finnes i dem fra museet. Vi forsøker å opprettholde og bygge videre på eksisterende kompetanse og programvare nettopp av hensyn til framtida, siden vi da enklere kan lage rutiner for vedlikehold og oppdatering som vil fungere.

En spesiell begrensende faktor: Format for transkripsjon av håndskrifter

Så har vi en heller banal ressurstyv: Munchmuseet har transkribert Munchs tekster i flere tiår. Først ved hjelp av skrivemaskin, etter hvert i ymse tekstbehandlingsprogrammer hvorav det siste selvfølgelig og dessverre, må man nok si, var Microsoft Word.

Retningslinjene for transkripsjon er ikke dokumentert, men har ut fra det man kan se når man sammenlikner med originalmanuskriptene, variert betydelig gjennom årene. Munchs egne strykninger er gjerne utelatt. Sensitive opplysninger det samme. Likeså redigeringer gjort av Munchs søster Inger i forbindelse med publiseringen av familiebrevene. For å nå vitenskapelig standard har det vært og blir det gjort et stort arbeid bestående av korrekturrunder mot faksimile av original og ny-transkripsjon.

Transkripsjonene har vært samlet som utskrifter og skrivemaskin-manuskripter i ringpermer på museets bibliotek. Denne delen av materialet er ocr-lest og slik overført til digitalformat.

Overføringen av transkripsjonene fra Word til xml er en hodepine. Vi har forsøkt å automatisere prosessen, men fordi det ikke er brukt en enhetlig mal er det blitt vanskelig å gjenfinne fenomener ved hjelp av «søk og erstatt»-rutiner, noe som ellers hadde kunnet fungere. Nå må isteden en god del markering gjøres manuelt og på nytt i xml-filene direkte. Arbeidet med å standardisere merkingen kan dermed like gjerne gjøres i xml som i Word siden det er til xml tekstene skal. Dette dobbeltarbeidet er frustrerende (i parentes bemerka: Spesielt for de som må gjøre det), og det framstår som ressurssløsing, hvilket det jo også er.

Å unngå denne typen dobbeltarbeid er mulig gitt at man så tidlig som mulig i planleggingen av et prosjekt bestemmer seg for hvordan transkripsjon skal gjøres. Transkripsjon, korrekturlesing og koding er langsomt og krevende arbeid og jo mer effektivt man kan gjennomføre det, jo bedre for prosjektets økonomi. Man bør først undersøke materialet og bestemme hvilke tekstlige trekk som skal markeres i transkripsjonene. Skal man arbeide i en tekstbehandler som Word bør man deretter lage en mal som skal brukes av de som transkriberer. På den måten vil det være mulig å automatisere overføring til xml-formatet.

Skal eller vil man ikke gå veien om en tekstbehandler, tror jeg man skal satse på at de som skal transkribere lærer seg å kode også slik at begge prosesser kan gjøres parallelt. Det gir nok en bratt læringskurve for dem som ikke har gjort noen av delene før, men lære oppgavene må de uansett gjøre, og opplæringen er ikke så (tid-)krevende at det ikke lønner seg likevel når man sammenlikner med all den tida som går med til dobbeltarbeid når Word-transkripsjonene ikke kan overføres til xml på automatisert vis.

For oss var dessverre ingen av delene mulig siden materialet allerede forelå i Microsoft Word-format, transkribert etter varierende retningslinjer og med varierende markering. Vi er et lite prosjekt og finansieringsperioden er kort, så vi har mye annet vi gjerne skulle brukt ressurser på istedenfor dette dobbeltarbeidet, men vår erfaring er at uansett hvordan vi går fram, ender vi med å måtte gjøre mye manuelt og på nytt. Det bærer unektelig preg av det (jeg tror det var) Kim Bjørklund i sitt foredrag i går kalte «utilstrekkelig planlegging».

Strategier for å møte begrensningene

Så hvordan forholder man seg til forutsetninger? Å lykkes med prosjektet er jo også — så sant rammene ikke er helt urealistiske — å holde seg innenfor grensene som spesielt tid og økonomi setter, med andre ord: Å fullføre gitt de forutsetningene man har. Vi har satset på det følgende:

• følge internasjonale standarder
• holde oss innenfor standardene
• velge fri programvare og åpen kildekode
• velge dokumenterte, velprøvde løsninger andre har lykkes med

Vi skal ikke finne opp kruttet på nytt. Vi skal bygge et fungerende digitalt arkiv innenfor de rammene prosjektet har fått.

Byggeklosser

De tekniske byggeklossene vi bruker i arbeidet med prosjektet og arkivet, ser dere en oversikt over her. De er valgt dels fordi de var i bruk ved museet (Filemaker) og dels fordi de kompletterer hverandre og kan brukes som deler i en arbeidskjede.

• TEI P5 XML, XHTML
• XInclude, XSLT, XPath, XQuery, JavaScript, CSS
• FileMaker-databaser
  • med eksport til XML, hos oss mao. TEI P5
• Image Markup Tool
  • som har TEI P5 innebygd
• Oxygen XML Editor
  • med støtte for XML, TEI P5, XSLT, CSS og for arbeid mot xml-data i xml-databasen eXist
• eXist-db. Open Source Native XML Database
  • med svært gode muligheter til å søke strukturert ved hjelp av XQuery
  • kan integreres med nettstedsverktøyet Cocoon
• Byggeklosser for selve nettarkivet er enda ikke helt avgjort, men alternativene våre er
  • Plone CMS. Plone er en cms-programvare, dvs. et informasjonsorganiseringssystem
  • Cocoon + et lokalt bygg for å holde sammen arkivet

Om Filemaker

Jeg kommer nå til å gå litt nærmere inn på hvert enkelt verktøy, noen viktige aspekter ved dem og arbeidsgangen i dem.

Munchmuseet har i en årrekke brukt Filemaker-databaser til å organisere og ta vare på informasjon om alle de objektene samlingen består av. Medarbeiderne på museet kan bruke disse, og det er dermed fornuftig at vi legger opp til at dette forblir arbeidsverktøyet også etter at det digitale arkivet blir publisert på internett. Dermed må vi sette opp et system som gjør det mulig å hente ut av databasene den informasjonen vi skal bruke i arkivet. I Filemaker kan man eksportere innholdet i databasene til mange typer formater, bla. xml. Vi utvikler derfor xslt-stilark som lar oss eksportere direkte til TEI P5 XML. Eksporten blir dermed en automatisert kodeprosess.

Vi gjør eksporten i to omganger. Først til TEI P5, siden til xhtml. Det hadde vært uproblematisk å eksportere innholdet direkte til xhtml. Årsaken til at vi går veien om TEI P5 er metadata: Vi kan bruke xml-en til å forbedre søkefunksjonen.

Det er viktig at denne prosessen blir så automatisk som mulig, slik at den ansatte som skal vedlikeholde arkivet ikke trenger mye kompetanse innen xml, nettpublisering osv. for å gjøre vedlikeholdsarbeidet.

Jeg kommer tilbake til innholdet i basene seinere i foredraget.

Om Image Markup Tool

Image Markup Tool (populært kalt IMT) er laget ved universitetet i Victoria, Canada under ledelse av utvikleren Martin Holmes. IMT er gratisprogramvare og har åpen kildekode.

Det er et verktøy for å koble annotasjoner mot digitale bilder ved hjelp av xml-koding. Man arbeider i to vinduer, ett hvor man har det digitale bildet og ett hvor man lager annotasjoner. Annotasjonene kan kategoriseres. På Munch-prosjektet har vi tre kategorier: Transkripsjon, filologiske noter og kommentarer. Når man vil legge til en ny annotasjon, velger man først annotasjonskategori, klikker på knappen for ny annotasjon og får deretter opp en stiplet ramme som kan flyttes til ønsket sted på bildet og hvis størrelse kan tilpasses det som skal markeres. Deretter legger man inn det man vil ha i annotasjonen, lagrer og fortsetter arbeidet.

Vi arbeider gjerne slik at vi først setter opp de ønskede annotasjons-rammene på bildet, så fyller vi inn transkribert tekst fra transkripsjonen, som delvis er kodet vha makro kjørt i Word. Deretter lagrer vi filen i IMT og går over til Oxygen og gjør ferdig detaljene i kodearbeidet der. Dette skiftet av programvare skyldes at Oxygen er en mer effektiv xml-behandler enn IMT, som på det feltet enda mangler litt.

En stor fordel med IMT er at det er xml-formatet TEI P5 den lagrer bildeannotasjonene i. Programmet er med andre ord skrevet for oss som ønsker en tett sammenheng mellom tekst og bilde. Martin Holmes er veldig imøtekommende og har ved flere anledninger lagt til tastaturkommandoer og tilpasset programmet etter henvendelser fra oss og andre brukere.

En annen fordel med programmet er at man ved et enkelt tastetrykk kan lage en webvisning av bildet man koder. Vår foreløpige visning, som dere ser her, bygger på IMTs webvisning. Vi har tatt utgangspunkt i stilark og skript fra IMT og videreutviklet dette slik at man alltid ser den transkriberte teksten parallelt med bildet og sånn at man kan bla gjennom sidene i objektet. Siden vi har eget stilark for vår visning bruker vi Oxygen og ikke IMT for å lage visningene.

Om Oxygen XML Editor

Oxygen er en kommersiell xml-programvare, men har rimelige lisenser for akademiske brukere og er svært interessert i det akademiske markedet. Det kommer bla. til uttrykk i deres deltakelse på konferanser i det internasjonale miljøet for digital humaniora. Programmet har innebygd støtte for mange forskjellige xml-standarder, bla. TEI. I tillegg til xml er programmet også laget for å arbeide med de øvrige xml-teknologiene: xslt, xsl-fo, XPath, XQuery m.fl. Programmet inneholder ferdiglagde stilark osv. bla. for TEI-kodede tekster.

Vi bruker Oxygen til

• å kode ferdig filer som er påbegynt i IMT
• å transformere xml-filene til interne korrekturvisninger og til webvisningsfiler i xhtml-format
• å transformere eksport-filene fra Filemaker til TEI-kodet xml og videre til xhtml

Siden Oxygen forholder seg til de internasjonale standardene er man også sikret at de filene man lager her, blir valide i henhold til standarden.

Fra Oxygen kan man også jobbe i materiale som er lagret i xml-databasen eXist.

Om eXist-db. Open Source Native XML Database

eXist er en xml-database hvor både databasen og kildekode er fritt tilgjengelig. Den er utviklet ved hjelp av xml-teknologi og lagrer xml-data i henhold til datamodellen for xml. Ved hjelp av XQuery tilbyr eXist effektiv indekseringsbasert filbehandling. I et mer hverdagslig språk kan man si at man kan søke i, hente ut og presentere innholdet i basen svært effektivt på denne måten.

Å legge til nytt materiale i en xml-database høres kanskje vrient ut, men er ikke vanskelig. Det kan gjøres via et nettlesergrensesnitt på omtrent samme måte som man laster opp bilder på nettet eller legger til et vedlegg i en epost.

eXist støtter en rekke nett-teknologiske standarder (XQuery, XPath, xslt, HTTP-grensesnittsteknologi), og den er derfor et godt utgangspunkt for å lage nettpublikasjoner. XQuery-søkene man foretar kan også danne grunnlaget for det som skal publiseres på internett. eXist kan nemlig integreres med nettstedsverktøyet Cocoon — standard-eXist leveres sågar med Cocoon innebygd.

Om Plone CMS og Cocoon

Hva som blir byggeklossen for selve nettarkivet har vi enda ikke avgjort, men alternativene er Plone CMS og Cocoon. I begge tilfeller vil vi bruke xml-databasen eXist og dens innebygde søkemuligheter.

Plone er en cms-programvare, dvs. et system for informasjons-organisering. Denne typen systemer brukes på nettet eller i intranett. De har enkle grensesnitt som ikke krever høy teknisk kompetanse av den som oppdaterer og legger til materiale, og de egner seg derfor godt for videre arbeid med oppdatering og supplering av arkivet. Man trenger ikke teknisk kompetanse utover den man får fra daglig bruk av arbeidspc. Det er et tungt argument for Plone.

Med Cocoon-løsningen vil man sannsynligvis trenge teknisk assistanse hvis man ønsker å utvide nettstedet. Jeg sier sannsynligvis fordi dette er noe vi foreløpig ikke vet nok om, og derfor holder på å finne ut av.

Plone er imidlertid ikke laget for nettsteder som er xml-baserte, og det kan se ut til å bli vanskelig å integrere eksterne komponenter, som kan behandle xml, i Plone. Cocoon derimot er laget nettopp for xml.

For begge løsninger gjelder at man enkelt kan legge til mer materiale fordi publiseringssystemet kommer til å ha innebygd hvordan det skal forholde seg til materialtypene.

Cocoon er et nettstedsbyggeverktøy som kan danne rammeverket om ressursene man ønsker å publisere. Cocoon kan administreres fra et nettleservindu på tilsvarende måte som eXist.

I Cocoon bygger man opp nettapplikasjonen som et sett komponenter hvor man dermed enkelt kan holde viktige oppgaver fra hverandre. I programmeringskretser kalles denne tilnærmingsmetoden for «pipeline». På norsk er det nok riktigere å assosiere dette med samlebånd enn rørledning, fordi poenget er å dele opp oppgaver i mindre biter som utføres separat og er koblet sammen omtrent på den måten man ser for seg at samlebåndsproduksjon foregår. Hver oppgave kan ses på som et separat samlebånd og hele applikasjonen er da fabrikken hvor de forskjellige delene til nettpublikasjonen produseres.

Om tekstkoding

Dette var en gjennomgang av programvare i bruk eller under utredning ved Munch-prosjektet. Jeg skal nå gå nærmere inn på hva vi praktisk arbeider med og resultatet av arbeidet. Jeg skal da begynne med å se nærmere på tekstkoding, både generelt, i form av TEI P5 og lokalt hos oss.

Om tekstkoding i xml

Det er tekstens struktur som skal kodes, ikke dens layout. Koder er reserverte tegn eller tegnstrenger som «sier noe» om hvordan andre tegnstrenger skal behandles. Å kode en tekst betyr dermed å markere trekk som ikke kan representeres direkte, altså å legge til metainformasjon om utvalgte innholdsstrukturer i teksten, f.eks. kapitler, overskrifter og avsnitt eller resultatet av en metrisk analyse av teksten.

Hensikten med xml-koding (og med all xml-teknologi) er dels:

• å sikre at tekstene skal forbli tilgjengelige i fremtiden
• å sikre at tekstene forblir uavhengige av de til enhver tid rådende standarder for maskinvare, operativsystemer og annen programvare

Standardisert koding forenkler altså datamaskinell behandling av tekstene og gir dem lenger liv uavhengig av programvare. I tillegg sikrer tekstkodingen:

• at teksten kan brukes i ulike media (utskrift, trykk, nettlesere, e-bøker, mobiltelefon mm.)
• gode søkemuligheter
• at man kan tilrettelegge teksten for ulike brukergrupper og for ulike behov

Og i forbindelse med dette en kommentar til Johnny Kondrups foredrag: Spørsmålet om levetiden for en digital utgave dreier seg også om at vi foreløpig ikke tar det nye mediet på alvor. Vi trenger både en ny type kompetanse, jf. hvordan journalistyrket endret seg da radio- og tv-mediene ble introdusert, og vi behøver å utforske og utvikle hva den digitale utgaven skal være. Når kompetanse og konvensjoner kommer på plass, tror jeg vi ikke lenger vil se på dette problemet som så akutt.

Om TEI P5

TEI P5 er xml-standarden for digital tekstrepresentasjon som utvikles og vedlikeholdes av Text Encoding Initiative Consortium (som vi vel alle nå kort og godt kjenner som «T-E-I» eller «TEI»). TEI-standarden dekker mange fagområder, spesielt innenfor humaniora.

Standarden har et bredt spekter av koder som gjør det mulig å merke tekstene presist og konsistent. Det er viktig for gjenfinning og organisering. Standarden er også svært fleksibel, og man kan lage nye eller endre eksisterende koder hvis man trenger det. Man velger selv hvor overfladisk eller detaljert man ønsker å kode tekstene, og det er uproblematisk å legge til eller ignorere koding senere. Det er også mulig å kode detaljert for enkeltdeler av innholdet i tekstene, mens andre deler behandles mer overfladisk. Man kan også kode tekst utenfor selve tekstfilen, såkalt «stand off encoding» hvor kodingen knyttes til filen ved hjelp av lenking.

Et stort internasjonalt fagmiljø arbeider med TEI-koding av tekster og med utvikling av stilark og programvare for videre bruk av de kodede filene. Dette er et generøst miljø som gjerne deler erfaringer og gir en hjelpende hånd til andre fagfolk.

Om koding i eMunch

Når det gjelder koderetningslinjer har vi lagt oss tett opptil TEI P5 og unngår avvik fra standarden hvis vi kan. Før kodingen ble satt i gang bygde vi opp en kodebok som definerte hvilke koder som skal brukes og til hva de skal brukes. Dette ble gjort etter en gjennomgang av et forhåpentlig representativt utvalg tekster slik at vi dekket de fleste tekstelementer. Det er kommet til noe nytt etter hvert, og det er neppe til å unngå siden et håndskriftsmateriale alltid er heterogent. Det gjelder imidlertid detaljer — de større tekstelementene er det mulig å fange opp ved en innledende dokumentanalyse.

I Munch-prosjektet legger vi spesielt vekt på følgende i tekstkodingen:

• tilføyelser, strykninger og andre endringer
• det grafiske oppsettet på sida
• datoer, navn på personer, korporasjoner og steder
• innholdsrelaterte emneord

På den måten sørger vi for at vi både kan lage dokument-nære visninger og gi gode søkemuligheter. Vi ønsker å gjøre søkeverktøyet funksjonelt og satser på strukturerte søk i xmlen pluss fritekstsøk, hvor vi ønsker å tilrettelegge for treff på tross av Munchs varierte ortografi.

Vi bygger opp tekstene side for side og konstruerer hele teksten via ei samlefil hvor vi bruker XInclude-koding. Tekstens struktur (det vil i praksis si tekst(del)er, avsnitt og lister) blir dermed underordnet sidens struktur. Vi koder bare inn de strukturkodene vi trenger for å få valid koding, og vi legger ikke inn lenking av delte elementer. Det vil dermed ikke være mulig å analysere hvordan teksten er bygd opp via kodingen. Samtidig vil det på grunn av samlefilsløsninga være veldig enkelt å bygge opp alternative rekkefølger eller kaste om på rekkefølgen av sidene i teksten. Med flere samlefiler kan vi dokumentere alternative rekkefølger uten f.eks. å operere med flere sett originalfiler (noe som skaper risiko for feil når filene må oppdateres). Munch hadde en tendens til å skrive hulter til bulter og til å oppbevare papirene sine nokså skjødesløst, så i en del tilfeller blir tekstrekkefølgen i samlefilene våre en annen enn i originaldokumentene.

Arkivet

I tillegg til de kodede tekstene og de digitale faksimilene, skal vi forsyne arkivet med sekundæropplysninger. Disse lagres i et sett Filemaker-databaser.

Denne skissen viser alle databasene våre og relasjonene mellom dem. I basene har vi et solid grunnlag for å koble sammen informasjon og tekster. Vi har følgende databaser:

Registrant med underregistrant

I registranten registrerer vi alle tekstobjekter: Signatur, eierinstitusjon osv. og opplysninger om objektets mål, omfang, papirtype m.m. I tillegg lagrer vi f.eks. opplysninger om teksttype, skriftspråk, mottaker (for brev og brevutkast), og om under-/delobjekters avvikende egenskaper (f.eks. papir, teksttype).

Vi registrerer også semantiske sammenhenger mellom objektene. Hensikten er å gjøre det mulig å koble dem sammen:

• Versjoner: F.eks. brev med x antall utkast
• Brutt sammenheng: En sammenhengende tekst som er delt over flere inventarnumre som følge av Munchs løsbladsystem
• Innlegg: Blad kan være revet ut av skissebøkene, eller ilegg kan være tatt ut av sin opprinnelige sammenheng. Sammenhengen kan avdekkes ved å studere detaljer ved de fysiske dokumentene (f.eks. rustmerker etter binders o.l.)

Personregister

Her registrerer vi alle personer som er brevmottakere eller blir omtalt av Munch. Opplysninger i personregisteret inkl. kallenavn, korporasjonstilknytning, nasjonalitet, yrke osv. Vi lagrer opplysninger i den grad vi klarer å finne fram til dem. Siden ikke alle personer er identifiserbare har vi opprettet «uidentifisert mann» og «uidentifisert kvinne» hvor vi registrerer uidentifiserte personer. Alle brev en person er mottaker av kobles til personens post i personregisteret. Personen kobles også mot de korporasjoner vedkommende har vært knyttet til.

Korporasjonsregister

Likner i all hovedsak på personregisteret. Personer tilknyttet korporasjonen som medlem, ansatt, eier e.l. registreres. Alle brev korporasjonen er mottaker av kobles til registeret.

Stedsregister

En fortegnelse over alle steder som er nevnt i Munchs tekster. Vi skiller mellom kategoriene eiendomsnavn, gateadresse, bydel, sted (by), nasjonal region, land, internasjonal region. Vi oppgir alltid enten land eller internasjonal region i tillegg til stedets navn og kategori, men forsøker ikke å oppspore samtlige detaljer for alle innførsler.

Hendelsesregister

I denne registrerer vi viktige begivenheter i Munchs liv og knytter disse til tekster, personer, korporasjoner og steder. Det er planen at vi bla. skal visualisere all denne informasjonen ved hjelp av et kart kombinert med en tidslinje. En test av hvordan det fungerer, ligger på hjemmesidene våre.

Eksport

Som jeg tidligere har sagt er det mulig å eksportere innholdet i Filemaker-filene til xml. Filemaker har egne enkle xml-formater, men i og med at man i eksportprosessen kan angi hvilket xslt-stilark som skal brukes, kan man eksportere til det xml-formatet man selv ønsker. For oss er det selvfølgelig TEI P5.

Ordet stilark gir i dette tilfellet feilaktige assosiasjoner, siden stilarket i veldig liten grad angir hvordan baseinnholdet skal se ut. Det gjør derimot et css-stilark som blir knyttet til innholdet senere i prosessen. Xslt-stilarket transformerer derimot Filemakers xml-format og dataene i basen til en TEI P5-kodet fil. Det koder og omformer altså innholdet.

Et eksempel: For å navngi filer, bilder og lage unike id-referanser i databasefilene har vi tatt utgangspunkt i museets inventarnumre. Transkripsjoner og bilder skal kobles sammen, men har av ymse hensyn og grunner fått forskjellige navn som dessuten er med eller uten blanke. Fellesnevneren er at alle inneholder inventarnumret i en eller annen form.

I xslt-transformasjonen omformes id-referansen i registranten til inventarnummeret og til filnavnet slik at det både kan genereres overskrifter i overenstemmelse med museets retningslinjer og lenker der vi vil ha det i arkivet.

Avslutning

For å samle trådene: For tiden arbeider vi med å få dette til i xml og videre ut i web-visning. Denne skissen viser hvilke koblinger det vil være mulig å gjøre i materialet og hva vi håper vi kan få til.

Etter tidsplanen skal det digitale Munch-arkivet være på nettet neste høst. Vi satser på å klare det, men innser også at det nok vil være deler vi ikke er ferdige med. Det vi mener haster mest fram mot lanseringa er det digitale «byggverket» og funksjonene det skal ha. Hvis vi har det på plass, kan materialet og tilleggsopplysninger legges til i årene som kommer i takt med de ressursene museet kan bruke på arkivet. Det er meningen at dette skal bli et levende arkiv, som alle interesserte kan bruke, og da må museet fortsette å oppdatere og utvide arkivet.