Henrik Ibsens Skrifter i Elektronisk utgave Versjon 1.0 – 11. jan. 2006 Bjørn Wang Trym Asserson

Forprosjektrapport

© Creuna 2005

1

Innhold

1 Intro og sammendrag .................................................................................................................. 3 1.1 Viktige funn i forprosjektet ......................................................................................................... 3 1.2 Nødvendig bakgrunnskunnskap ................................................................................................ 3 1.3 Om løsningsarkitekturen ............................................................................................................ 3

2 Dokumentasjon av designvalg ................................................................................................... 5 2.1 Bytte av XML-database ............................................................................................................. 5 2.2 Utvidet støtte for fritekstsøk ....................................................................................................... 5 2.3 Dynamisk innholdsvisning og oppdeling av XML-dokumentene ............................................... 6 2.4 Import av XML-data i emnekartet .............................................................................................. 6

3 Emnekart og TEI-XML .................................................................................................................. 7 3.1 Ontologi for HISe-løsningen ...................................................................................................... 7 3.2 Erfaringer fra implementering av ontologien ............................................................................. 8 3.3 PSI-er i emnekartet .................................................................................................................... 9

3.3.1 PSI'er hos Kulturnett ....................................................................................................... 10 3.3.2 Videre arbeid med PSI'er ................................................................................................ 10 3.3.3 Publisering av PSI'er ....................................................................................................... 10

3.4 Import av kildemateriale i emnekartet ..................................................................................... 11 3.5 Oppdeling av XML-dokumentene ............................................................................................ 12

3.5.1 XML-eksempel før oppdeling .......................................................................................... 13 3.5.2 XML-eksempel etter oppdeling ....................................................................................... 14 3.5.3 Elementer som potensielt må flyttes eller spesialhåndteres ........................................... 15 3.5.4 Uklar oppdeling av enkelte filer ....................................................................................... 15 3.5.5 Nødvendige endringer for identifikasjon av elementene ved oppdelt lagring ................. 16 3.5.6 Lagring av oppdelte XML-dokumenter............................................................................ 16 3.5.7 Mulighet for nedlasting av fullstendige XML-dokumenter ............................................... 16

3.6 Opprydding av doble identifikatorer ......................................................................................... 16 3.7 Verdiøkning og rettelser av XML-materialet ............................................................................ 17

3.7.1 Identifikasjon av XML-filene ............................................................................................ 17 3.7.2 Rettelser av ID-databasen fra FileMaker ........................................................................ 18 3.7.3 Feilaktig DTD-angivelse .................................................................................................. 19 3.7.4 Manglende felter i XML-filene ......................................................................................... 19

4 Teknisk plattform og arkitektur ................................................................................................ 20 4.1 Utviklings- og byggemiljø ......................................................................................................... 20

4.1.1 Automatisert enhetstesting ............................................................................................. 21 4.2 Komponenter i løsningsarkitekturen ........................................................................................ 22

4.2.1 Synkronisering av kjernekomponentene ved import ....................................................... 23 4.2.2 Webpubliseringsløsning .................................................................................................. 23

4.3 Driftsmiljø ................................................................................................................................. 24 5 Utforming av tjenesten .............................................................................................................. 25

5.1 Grafisk design .......................................................................................................................... 25 5.2 Målgrupper............................................................................................................................... 25 5.3 Prioriterte gjenfinningsbehov hos målgruppene ...................................................................... 26 5.4 Modell for gjenfinning i HISe .................................................................................................... 26 5.5 Prefererte gjenfinningsmetoder ............................................................................................... 27 5.6 Verket som navigasjonsknutepunkt ......................................................................................... 28 5.7 Visning av ederte hovedtekster ............................................................................................... 29 5.8 Informasjonsarkitektur og interaksjonsdesign ......................................................................... 29

6 Søk i kildematerialet .................................................................................................................. 30 6.1 Retningslinjer for global søkefunksjon ..................................................................................... 30 6.2 Modeller for søk ....................................................................................................................... 31

2

6.3 Skjermbildeskisser ................................................................................................................... 33 6.3.1 Avansert søk ................................................................................................................... 33 6.3.2 Avansert søk med kontekstavhengige undervalg ........................................................... 34 6.3.3 Gradvis innsnevring av søkeresultatet ("fasettert søk") .................................................. 35

6.4 Søk i dansk-norsk tekst ........................................................................................................... 36 6.4.1 Bruk av synonymord ....................................................................................................... 36 6.4.2 Publiserte søketreff ......................................................................................................... 37 6.4.3 Ordstamming .................................................................................................................. 38

6.5 Søk i webtekster ...................................................................................................................... 38 7 Erfaringer fra forprosjektets tekniske prototyper .................................................................. 39

7.1 Funksjonaltet som er prototypet .............................................................................................. 39 7.2 Tilgang til prototypene ............................................................................................................. 40 7.3 Komponenter som er testet i prototypene ............................................................................... 40 7.4 Samkjøring med Kulturnett ...................................................................................................... 41 7.5 Erfaringer med ulike XML-databaser ....................................................................................... 41

7.5.1 dbXML ............................................................................................................................. 41 7.5.2 Berkeley DB XML ............................................................................................................ 42 7.5.3 Sammenlikningstabell ..................................................................................................... 43

7.6 Erfaringer fra fritekstsøk i XML-dokumentene ......................................................................... 44 7.6.1 Erfaring med bruk av synonymord .................................................................................. 44 7.6.2 Ordstamming .................................................................................................................. 45

7.7 Erfaringer fra dynamisk innholdsvisning .................................................................................. 47 7.7.1 Ytelse .............................................................................................................................. 47 7.7.2 Kvaliteten på HTML-koden ............................................................................................. 47

8 Anbefaling videre prioriteringer ............................................................................................... 48 8.1 Kravspesifikasjon ..................................................................................................................... 48 8.2 Konkretisering av behovene for søk ........................................................................................ 48 8.3 Åpne for variable i hovedprosjektet ......................................................................................... 48 8.4 Egne prosjektressurser ............................................................................................................ 49 8.5 Kravområder ............................................................................................................................ 49

9 Vedlegg 1: Statistikk fra søkemotorindeksen ......................................................................... 50

3

1 Intro og sammendrag I forbindelse med Ibsenåret 2006 skal Henrik Ibsens skrifter gjøres tilgjengelige på nett. Denne rapporten er resultat av et 3 måneders forprosjekt som har prototypet og evaluert den påtenkte teknisk plattformen for nettløsningen. Forprosjektet har prototypet, testet og evaluert løsninger for bl.a.:

Automatisk konvertering og import av TEI XML-dokumenter i emnekartmotoren OKS. Bygging og vedlikehold av ontologi og emnekart vha. OKS Ontopoly. Verdiøket søk i Ibsens tekster vha. bl.a. ordstamming og definering av synonymord. Samspill mellom kritiske komponenter i løsningsarkitekturen. Lagring av XML-dokumenter i ulike XML-databaser. Brukergrensesnitt for edert visning av hovedtekster. Automatisert testing av alle arkitekturlag. Utviklings- og byggemiljø.

Funnene er dokumentert i denne rapporten, samt gjennom prototypene som er produsert i løpet av forprosjektperioden. Prototypene er åpent tilgjengelige fra følgende URL'er: http://prosjekter.creuna.no/hise/hovedtekst.html http://demo.creuna.no:1088/ibsen/

1.1 Viktige funn i forprosjektet

Forprosjektet har vist at valgt løsningsarkitektur er velegnet for gjennomføring av hovedprosjektet, og oppfyller kravene til en sunn, vedlikeholdbar og testbar arkitektur. To viktige endringer i arkitekturen er besluttet gjennomført:

1. XML-databasen dbXML byttes ut med Berkeley DB XML fordi vesentlige mangler ble funnet i dbXML ved testing. Prosjektgruppen mener dette byttet vil representere en vesentlig risiko-reduksjon for prosjektet

2. Kravene til fritekstsøk er oppjustert, og søkemotoren Jakarta Lucene er derfor tatt med som en fullverdig og viktig del av løsningsarkitekturen.

1.2 Nødvendig bakgrunnskunnskap

Løsningsarkitekturen og -komponentene som er testet og evaluert i forprosjektet er beskrevet i Creunas tilbud på gjennomføring av forprosjektet, datert 16. september 2005. Det er en fordel å ha kjennskap til løsningsarkitekturen slik den er beskrevet i tilbudet når forprosjektrapporten leses. Forprosjektrapporten er refererer aldri direkte til tilbudet, og kan derfor leses relativt uavhengig av dette såfremt produktnavn, konsepter og ord og uttrykk fra tilbudet er kjent.

1.3 Om løsningsarkitekturen

Henrik Ibsens skrifter i elektronisk form (HISe) vil gå opp veien ift. mange nyskapende og spennende løsninger. Prosjektet er såpass nyskapende i sine ambisjoner at prosjektgruppen har ønsket å prioritert trygge, velprøvde løsninger på teknologisiden.

4

Målet er at endelig løsningen skal oppfylle følgende sunnhetsprinsipper:

• Sunn og vedlikeholdbar arkitektur med løse koblinger mellom enkeltkomponenter. • Testbare enheter, slik at videreutvikling og test kan gjennomføres presist og effektivt. • Åpne standarder (validert kode og opprettholdelse av standarder). • Dekkende og egnet funksjonalitet – høy relevans for målgruppene • Basert på velrenommerte, sterke produkter og leverandører med gode referanser

Disse prinsippene gjelder både for valget av Ontopia Knowledge Suite (OKS) som emnekartmotor og for open source-komponentene som skal benyttes i arkitekturen. Forprosjektets har søkt å verifisere kvaliteten på disse gjennom integrasjonstester og vertikal prototyping. De fleste komponentene i arkitekturen er velprøvde og produksjonsstabile, og forprosjektet har derfor fokusert på de mer ukjente komponentene, samt på samspillet mellom komponenter der det ikke finnes ferdige integrasjonsløsninger.

5

2 Dokumentasjon av designvalg Dette kapittelet tar for seg designvalgene vi har gjort i løpet av forprosjektet, basert på bl.a. testing og evaluering av de tekniske prototypene som er implementert. Den endelige arkitekturen er dokumentert i kapittel 4, og detaljer rundt konkrete testerfaringer finnes i kapittel 3, 5, 6 og 7. Oppsummering av anbefalte prioriteringer videre finnes i kapittel 8. Forprosjektet har tatt utgangspunkt i løsningsarkitekturen slik denne ble skissert i det opprinnelige tilbudet fra Creuna (se også avsnitt 1.2), og det anbefales at denne i hovedtrekk videreføres i det videre arbeidet med HISe-løsningen. Dette kapittelet beskriver derfor bare de erfaringsbaserte tilpasningene av komponentene i arkitekturen som er gjort i løpet av forprosjektet. Merk at det fortsatt finnes problemstillinger der endelig valg av systemdesign ikke er foretatt. I den grad slike problemstillinger er avdekket av forprosjektet diskuteres de i relevante kapitler i denne rapporten. En samlet oversikt over problemstillinger som krever oppfølging av HIS finnes i kapittel 8.

2.1 Bytte av XML-database

Det var opprinnelig tenkt å benytte dbXML som XML-database i HISe-løsningen. Testing av dbXML avdekket imidlertid en rekke feil og mangler – alt fra mangelfull dokumentasjon og uklare feilmeld-inger til utelatt funksjonalitet, feil i programgrensesnittet (API), ustabil drift og fraværende support. Hovedargumentene for å velge dbXML fremfor en mer utbredt og veltestet XML-database var at funksjonaliteten passet svært godt overens med behovene i HISe-løsningen. Særlig var det støtte for fritekstsøk i XML-basen som kunne ha forenklet arkitekturen. Dette argumentet bortfalt etter nærmere analyse av behovene knyttet til søk, fordi dbXML ikke kan oppfylle funksjonalitskravene som stilles. Forprosjektet har derfor valgt å bytte XML-database, og i stedet bruke Berkeley DB XML fra Sleepycat Software i den endelige arkitekturen. Berkeley DB XML er en rendyrket XML-database som mangler tilleggsfunksjonaliteten man finner i dbXML, men er til gjengjeld et langt mer stabilt og modent produkt. Når det nå er klart at det ikke er behov for tilleggsfunksjonaliteten som dbXML tilbyr, var det et enkelt valg å gjennomføre dette byttet. En veltestet og anerkjent XML-database vil representere en vesentlig risikoreduksjon for prosjektet, og bidra til å sikre sunnhetsprinsippene vi har definert for løsningen, hvor prinsippet om bruk av velrenommerte, sterke produkter står sentralt. Våre tester viser også at byttet har hyggelige bieffekter som bedret ytelse, samt at driftsmiljøet forenkles fordi Berkeley DB XML kjører som del av webapplikasjonen. Sammenligning av databasene gjøres i avsnitt 7.5 og driftsmiljøet omtales kort i avsnitt 4.3.

2.2 Utvidet støtte for fritekstsøk

Kravene til funksjonalitet i fritekstsøket har vært økende gjennom forprosjektet, etterhvert som den fulle kompleksiteten forbundet med søk har blitt avdekket. Det er bl.a. ønskelig at søkefunksjonen skal håndtere at søkekriterier formulert på bokmål skal gi treff i Ibsens dansk-norske tekster. For å håndtere denne typen krav trengs en dedikert søkemotor, og prosjektgruppen har derfor besluttet å inkludere Jakarta Lucene som en fullverdig og viktig del av løsningsarkitekturen. Lucene ble opprinnelig tatt med som en opsjon, som det var usikker om det var behov for.

6

Det planlegges nå definering av omfattende synonymorddlister og bruk av avansert søke-funksjonalitet som bl.a. ordstamming for oversettelse av søkekriterier angitt på bokmål. Ønsket søkefunksjonalitet er beskrevet i kapittel 6 og erfaringer fra søkeprototypen i avsnitt 7.6.

2.3 Dynamisk innholdsvisning og oppdeling av XML-dokumentene

Det er besluttet at lange XML-dokumenter skal deles opp før visning på web. Det er flere grunner til at dette er nødvendig. Særlig er det følgende hensyn som utmerker seg:

• Generell nedlastingstid for websidene • Hensyn til ytelse og minneforbruk ved generering HTML-sidene • Responstid ved variantvisning (når flere store tekster vises samtidig) • Mulighet for søketreff innenfor mindre tekstbolker enn et helt drama • Redusere sjansene for flaskehalser ved flere samtidige brukere • Caching på lavere granularitetsnivå for bedret effektivitet

Oppdeling av XML-dokumentene kan skje på to måter: (1) gjennomgående gjennom alle lag i løsningen, fra XML-databasen til presentasjonslaget, eller (2) bare ifm. webvisning ved at kun de aktuelle delene av XML-dokumentene hentes ut fra XML-databasen. Berkeley DB XML gir stor fleksibilitet til å skille lagringsformatet for dokumentene fra den faktiske bruken av dokumentene i logikk- og presentasjonslaget. Forprosjektet har ikke konkludert ift. preferert modell for gjennomføring av oppdelingen. Erfaringer ift. dynamisk innholdsvisning er beskrevet i avsnitt 7.7, og Berkeley DB XML i avsnitt 7.5.2.

2.4 Import av XML-data i emnekartet

Deler av datagrunnlaget i form av XML-dokumentene og FileMaker-databasen krever rettelser og verdiøking før import i emnekartet. Prosjektgruppen har derfor besluttet å gjennomføre konvertering og import vha. scripts og XSLT-transformasjoner. Dette gir høy fleksibilitet og mulighet for enkelt å tilrettelegge programlogikk som kan modifisere kildedata før import. Se også avsnitt 2.4.

7

3 Emnekart og TEI-XML 3.1 Ontologi for HISe-løsningen

Forprosjektet har jobbet med utgangspunkt i følgende ontologi for emnekartet i HISe-løsningen. Ontologien vil bygges og vedlikeholdes vha. OKS Ontopoly, og vil endres og tilpasses etter hvert som prosjektet skrider frem, til ontologien finner sin endelige form. Derfor er det emnekartet i Ontopoly som til enhver tid vil inneholde gjeldende versjon av ontologien. Disse diagrammene angir bare bare et tidsbilde av ontologien, men gir en god indikasjon om hva som er ontologiens sentrale emner.

8

Som del av arbeidet med ontologien er det også utarbeidet en detaljskisse over sammenhengen mellom verkene, tekstarkivet og oversettelser av tekstene:

3.2 Erfaringer fra implementering av ontologien

I forprosjektet har vi satt opp en begrenset ontologi bygget rundt sentrale emner i HISe-løsningen. Ontologien som er implementert dekker alle verkene, og det er lagt inn data om dramaene, alle brevene, hvilke dramaer som omtales i de ulike brevene, m.m. Ontologien er testet gjennom de tekniske prototypene, og i Omnigator. Tekstarkivet med grunntekster og tekstvitner er delvis modellert, men ikke testet med faktiske data. Følgende erfaringer ble gjort under implementering av ontologien:

• Det er behov for mekanismer som kan håndtere populærtitler på verk, f.eks. moderniserte navn på dramaene, som "Gjengangere"

• Emnekartet bør etablere sammenhenger mellom verk som bygger på hverandre eller har samme utgangspunkt, slik som Catilina 1850 og Catilina 1875.

• Det kan være behov for å etablere et abstrakt verksnivå som knytter sammen verk med samme utgangspunkt, som de to versjonene av Catilina. Dette nivået kan fungere som oppsamlingspunkt for felles informasjon om verksversjonene. Her kan f.eks. tilknytning av rollefigurer gjøres for å unngå duplikat angivelse. Spørsmålet er om dette muligens skaper merarbeid ved konvertering, fordi tilknytningen allerede er på verksnivå i XML-filene. Det er også viktig å bevare muligheten til å kunne uttrykke variasjoner mellom de ulike verksversjonene i emnekartet.

9

• Verkene må utstyres med visningsnavn, slik at basenavnene kan brukes til å differensiere mellom ulike versjoner av samme verk. Dette er nødvendig for at bl.a. publiseringsverktøyet Ontopoly skal være enkelt å bruke. Uten differensiering av verksnavnene er det bl.a. vanskelig å se hvilken versjon av verkene man redigerer. Vi har løst dette ved å legge årstall etter verksnavnet der det eksisterer flere verk med samme navn, eks. Catilina 1850 og Catilina 1875.

• Ontopoly fungerer svært bra for vedlikehold av emnekart og ontologi, og gjør det enklere å inkludere ikke-tekniske prosjektdeltakere i prosessen.

3.3 PSI-er i emnekartet

Vi har så langt det er mulig søkt å benytte kjente og etablerte PSI-er for emnetypene som i HISe-løsningen. Mange av PSI-ene blir likevel spesifike for HISe. Emnetype Kommentar PSI emnetype Organisasjon http://psi.ontopia.net/#organization Person http://psi.ontopia.net/#person By http://psi.ontopia.net/geography/#city Containee Brukes i relasjoner av typen by ligger i land http://psi.ontopia.net/geography/#containee Container Brukes i relasjoner av typen by ligger i land http://psi.ontopia.net/geography/#container Land http://psi.ontopia.net/geography/#country Ligger i Brukes i relasjoner av typen by ligger i land http://psi.ontopia.net/geography/#located-in Sted Superklasse for by og land http://psi.ontopia.net/geography/#place Årstall http://psi.semagia.com/datetime/calendar_year Basert på Når en karakter er basert på en virkelig person http://www.ibsenarkivet.no/psi/types/based-on Grunntekst http://www.ibsenarkivet.no/psi/types/basetext Karakter Karakterer i Ibsens stykker http://www.ibsenarkivet.no/psi/types/character Kommentar Kommentarfelt http://www.ibsenarkivet.no/psi/types/comment Drama http://www.ibsenarkivet.no/psi/types/drama Ansatt Fjernes? http://www.ibsenarkivet.no/psi/types/employee Arbeidsgiver Fjernes? http://www.ibsenarkivet.no/psi/types/employer Først publisert i Ref. til tidsskrift / avis der diktet først ble publisert http://www.ibsenarkivet.no/psi/types/first-published-in HIS-ID (forekomst) http://www.ibsenarkivet.no/psi/types/id Brev http://www.ibsenarkivet.no/psi/types/letter Hovedtekst http://www.ibsenarkivet.no/psi/types/maintext Omtalt Rolle for person eller verk som blir omtalt http://www.ibsenarkivet.no/psi/types/mentioned Blir omtalt i Et verk omtaler en per son eller et annet verk http://www.ibsenarkivet.no/psi/types/mentions Avis http://www.ibsenarkivet.no/psi/types/newspaper Ikke trykket i Ibsens levetid

Unær assosiasjon http://www.ibsenarkivet.no/psi/types/not-published

Sendt dato Avsenderdato for brev (forekomst) http://www.ibsenarkivet.no/psi/types/origdate Dikt http://www.ibsenarkivet.no/psi/types/poem Utgivelsessted Geografisk lokasjon for første utgivelse http://www.ibsenarkivet.no/psi/types/publish-location Utgivelsesår Assosiasjon mot utgivelsesåret (årene er emner) http://www.ibsenarkivet.no/psi/types/publish-year Utgitt av http://www.ibsenarkivet.no/psi/types/published-by Forlegger http://www.ibsenarkivet.no/psi/types/publisher Mottatt brev Assosiasjon med roller Mottaker og Brev http://www.ibsenarkivet.no/psi/types/received-letter Mottaker Rolle http://www.ibsenarkivet.no/psi/types/recipient Avsender Rolle http://www.ibsenarkivet.no/psi/types/sender Sendt fra Geografisk informasjon om hvor brevet er sendt fra http://www.ibsenarkivet.no/psi/types/sent-from Sendt brev Assosiasjon med roller Avsender og Brev http://www.ibsenarkivet.no/psi/types/sent-letter Undertittel (forekomst) http://www.ibsenarkivet.no/psi/types/subtitle Tittel (forekomst) http://www.ibsenarkivet.no/psi/types/title Tekst Superklasse for Gr.tekst, Hovedtekst og Tekstvitne http://www.ibsenarkivet.no/psi/types/text Tekstvitne http://www.ibsenarkivet.no/psi/types/textwitness Verk Superklasse for Dikt, Brev og Drama http://www.ibsenarkivet.no/psi/types/work Skrevet år Assos. mot året brevet er skrevet (årene er emner) http://www.ibsenarkivet.no/psi/types/written-year Fødselsår Assosiasjon mot fødselsår (årene er emner) http://www.ibsenarkivet.no/psi/types/year-of-birth Dødsår Assosiasjon mot dødsår (årene er emner) http://www.ibsenarkivet.no/psi/types/year-of-death

10

3.3.1 PSI'er hos Kulturnett

Kulturnett har blitt nevnt spesielt som en interessant samarbeidspartner for HIS og samordning av PSI'er mot kulturnetts emnekart er derfor særlig aktuelt. Det viser seg dessverre at Kulturnett i mange tilfeller har unnlatt å definere PSI'er. Dette ser bl.a. ut til å være tilfelle for emnene for personene Ibsen og Bjørnson. Vi antar imidlertid fortsatt at et samarbeid er i Kulturnetts interesse, og at de kjappt vil definere de nødvendige PSI'ene for samarbeid og evt. datauteksling ved behov.

3.3.2 Videre arbeid med PSI'er Arbeidet med å definere PSI'er vil fortsette så lenge vi jobber med ontologien til HISe-løsningen. Her gjenstår det fortsatt en rekke oppgaver i hovedprosjektet, siden det bare er kjerneontologien som er prøvet ut i forprosjektet. Det viktigste arbeidet med PSI'ene er å finne gode, etablerte standarder som kan gjenbrukes i HISe-løsningen der slike eksisterer. Dette vil være viktigst for sentrale emner og emnetyper, som det kan bli aktuelle å utveksle med andre løsninger. Interne eller svært spesifikke typer, som bare har mening for HISe-løsningen er det mindre viktig å lete frem ferdige PSI'er for. Videre er det lite trolig at slike PSI'er eksisterer.

3.3.3 Publisering av PSI'er For deler av emnene som datagrunnlaget beskriver, bl.a. verkene til Ibsen, kan man anta at HISe-løsningen blir den autorative fasiten for disse verkene. I slike tilfeller kan det være naturlig å publisere PSI'ene som er benyttet, slik at andre har anledning til å ta disse i bruk i sine løsninger. Det vil være mulig å lage webmaler som automatisk genererer lister over alle PSI'er som er benyttet i HISe-løsningen.

11

3.4 Import av kildemateriale i emnekartet

Emnekartmotoren i OKS støtter en rekke importmetoder som kan forenkle eller automatisere import av strukturerte data. V har vurdert flere enkle fremgangsmåter, men kommet til at HIS sine kildedata er for komplekse til at disse kan benyttes. Import vil i stedet gjennomføres vha. tilpassede scripts og XSLT-transformasjoner. Deler av datagrunnlaget må verdiøkes eller "rettes" før import. Enklere løsninger for automatisert import egner seg best til en-til-en oversettelse fra kildedata, og derfor er en script-basert løsning mer hensiktsmessig. Kombinasjonen av scripts og XSLT-transformasjoner gir høy fleksibilitet og mulighet for enkelt å tilrettelegge programlogikk som kan modifisere kildedata. Eksempler på verdiøkning og rettelser av kildedata omfatter bl.a.:

• Legge på korrekt type for verkene og stedene fra ID-listen i FileMaker-databasen.I denne listen er det ikke mulig å maskinelt plukke ut hva som er dikt og hva som er dramaer eller se hva som er en by eller et land.

• Koble data som mangler relasjoner i HIS sine kildedata, f.eks. hvilket land byene ligger i. Når vi begynner å planlegge en fullstendig import av alle kildedata i hovedprosjektet, forventer vi å finne en rekke liknende tilfeller hvor fleksibiliteten i en scriptet importløsning vil komme oss til gode. Se også avsnitt 3.7 for en fyldigere gjennomgang av potensielle utbedringer av XML-materialet. Følgende løsning er implementert for å teste automatisert import av brevene i forprosjektet:

TXT

TabseparertFileMaker-eksport

idtab2ltm.py(Python-script)

script XTM

ids.xtm

XML

TEI-kodedebrev

brev2xtm.xslt(XSLT-transformasjon)

XSLT

brev*.xtm

Ontopoly editor

TED

(Manuelt byggetontologi)

OKS

OKS-Import

XML

XTM

ontology.xtm

XTM

ibsen-emnekart.xtm

Flettet emnekartopprettet vha.<mergemap>

12

3.5 Oppdeling av XML-dokumentene

Av ytelses- og brukshensyn vil det bli nødvendig å dele opp dramaene i mindre bolker både i XML-databasen og i presentasjon for sluttbrukeren. Aktene ser ut til å være det mest naturlige nivået å legge seg på. Motivasjonen for oppdeling av dokmentene er bl.a.:

• Begrense minneforbruk ved transformasjoner av dokumentene for å kunne støtte visning for flere samtidige brukere

• Oppnå en mer håndterbar dokumentstørrelse for nettleserene og for brukere som ikke sitter på raske bredbåndslinjer

• Bedre søketreff, ved at brukeren kan få treff i en akt ikke bare i hele dramatekster. Mindre tekstbolker gjør det enklere å finne de faktiske tekstpassasjene det blir søkt etter.

• Forenkle variantvisning, som skal vise mange tekster samtidig hos brukeren. Hvis alle variantene vises i full tekstlengde vil nedlastingstiden bli alt for lang, og samtidig transformasjon av mange store XML-blokker vil også belaste serveren tungt. Visning på aktnivå er derfor å foretrekke.

• Caching på lavere granularitetsnivå og jevnere elementstørrelse i cachen for bedret effektivitet.

Forslagsvis deles dokumentene da opp i følgende bolker:

• <teiHeader> • <front> • Aktene, én fil pr. akt • <back>

Eksempel på faktisk XML-kode er gjengitt på neste side. Alle løse elementer, slik som <pb rend=""/> i eksempelet i neste avsnitt, må potensielt flyttes inn i en av de angitte hovedbolkene.

13

3.5.1 XML-eksempel før oppdeling

Følgende kodeeksempel viser hvordan selvstendige XML-elementer i et drama kan deles opp i mindre biter ifm. visning i web-løsningen. Hver bit vises da som en selvstendig webside. For å muliggjøre enklest mulig maskinell oppdeling bør fritstående elementer utenfor hovedfragmentene flyttes inn i et av hovedfragmentene. Foreløpig kan det se ut som elementene som ligger mellom hovedfragmentene bare har relevans for trykt versjon, og derfor kan ignoreres ved generering av webvisning. XML-fragmentene er angitt i mørkegrått, elementer som må flyttes i fete typer: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ... > <TEI.2> <teiHeader lang="nob"> ... </teiHeader> <text id="C1ht" lang="Dano-Norwegian"> <front> ... </front> <pb rend="noprint" ed="hu"/> <body> <div type="act" n="1"> ... <lg type="stikisk femfotsjambe blankvers" an="single" met="bi 10|11" rhyme="x|X|r|R"> <div type="scene" n="1"> ... </div> <div type="scene" n="2"> ... </div> <div type="scene" n="3"> ... </div> </lg> </div> <div type="act" n="2"> ... </div> <div type="act" n="3"> ... </div> </body> <back> <pb n="&lsqb;126&rsqb;"/> <div type="epilogue"> ... </div> </back> </text> </TEI.2>

Merk: Oppdelingen er basert på gjennongang av XML-koden i Catilina. Dersom andre dokumenter har flere elementer som vi må ta hensyn til, må dette også inn i modellen. I dette eksempelet må elementet <pb rend="noprint" ed="hu"/> potensielt flyttes inn i <front> eller legges først i akt 1. Dersom det ikke har relevans for webvisningen kan elementet ignoreres i HTML-sammenheng.

14

3.5.2 XML-eksempel etter oppdeling

Omsluttende XML-elementer dupliseres til hvert enkelt fragment ved oppdeling, som vist nedenfor. XML-hodet, <DOCTYPE> og det omsluttende <TEI.2> elementet angis i alle fragmentene, <text> og <body> benyttes ved behov. Eksempel <teiHeader> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ... > <TEI.2> <teiHeader lang="nob"> ... </teiHeader> <TEI.2> Eksempel <front> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ... > <TEI.2> <text id="C1ht" lang="Dano-Norwegian"> <front> ... <pb rend="noprint" ed="hu"/> </front> </text> <TEI.2> Eksempel 1. akt, <div type="act" n="1"> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ... > <TEI.2> <text id="C1ht" lang="Dano-Norwegian"> <body> <div type="act" n="1"> <pb rend="noprint" ed="hu"/> ... </div> <body> </text> <TEI.2> Eksempel <back> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ... > <TEI.2> <text id="C1ht" lang="Dano-Norwegian"> <back> ... </back> </text> <TEI.2>

<pb rend=""/> flyttes inn i en av fragmentene

Alt.1

Alt.2

15

3.5.3 Elementer som potensielt må flyttes eller spesialhåndteres

Vi har ikke brukt mye tid på å analysere XML-elementene som ligger mellom hovedelementene i XML-koden, bare konstatert at de eksisterer. Vi har allerede nevnt disse i foregående avsnitt. Disse elementene kan enten flyttes inn i en av hovedbolkene som XML-koden brytes opp, spesialhåndteres eller ignoreres. Valg av løsning er avhengig av om de har relevans for webvisningen eller bare for generering av trykt versjon av HIS-tekstene. Eksempler på elementer som ligger mellom aktene omfatter bl.a. disse: ... 2. akt ... </div> <lb/><fw type="sheet" place="bottom-right">6</fw> <div type="act" n="3"> … 3. akt … … siste akt … </div> <lb/><figure type="bar"></figure> <pb/> </body> Håndtering av disse elementene avklares i hovedprosjektet.

3.5.4 Uklar oppdeling av enkelte filer Enkelta av filene benytter <join> for å flette sammen flere tekster. Forprosjektet har ikke avklart hvordan disse tekstene skal håndteres ved oppdeling. Et godt eksempel finnes i hovedteksten til Norma, Noht.xml, som bl.a. inneholder to <front>-elementer. Det er ikke avklart hvordan disse skal håndteres ift. rekkefølge eller evt. sammenslåing: <text id="Noht" lang="Dano-Norwegian"> <group> <join targets="No1851-9 No1851-10" targOrder="Y"/> <text id="No1851-9" n="1"> <front> ... </front> <body>

<div type="act" n="1"> ... </div>

</body> </text> <text id="No1851-10" n="2"> <front> ... </front> <body>

<div type="act" n="2"> ... </div>

</body> </text> ... </text> Håndtering av disse elementene avklares i hovedprosjektet.

16

3.5.5 Nødvendige endringer for identifikasjon av elementene ved oppdelt lagring

Hvis oppdelt lagring av dramaene skal gjennomføres er det nødvendig å innføre informasjon i XML-filene som identifiserer teksten som de ulike fragmentene beskriver og som angir fragmentrekke-følgen. Denne informasjonen finnes i stor grad allerede i følgende elementer, men må generaliseres:

• ID-element: <text id="C1ht"> • Rekkefølge: <div type="act" n="1">

Følgende endringer må gjøres:

1. Alle verk, også brev og dikt, må få en ID på samme måte som dramaene, slik at XML-databasen alltid kan refereres på samme måte fra applikasjonen, uavhengig av type verk. Diktene har i dag ikke ID i <text>-elementet. (Eks: <text lang="Dano-Norwegian">)

2. Diktene i samlingen "Digte" må muligens deles opp eller spesialhåndteres?

3. Etter oppdeling mangler <teiHeader>-fragmentet angivelse av ID.

4. Rekefølgen på <front> og <back> er ikke angitt ift.aktene, men her kan det være naturlig å legge inn forretningslogikk i HISe-applikasjonen som gjør at systemet kjenner til rekkefølgen uten eksplisitt angivelse i XML-koden.

3.5.6 Lagring av oppdelte XML-dokumenter

Berkeley DB XML gir stor fleksibilitet ved valg av XML-dokumentenes lagringsform. Dokumentene kan lagres oppdelt i XML-databasen, eller lagres uendret ift. orginalversjon og i stedet deles opp av forretningslogikken i HISe-løsningen ved webvisning.

3.5.7 Mulighet for nedlasting av fullstendige XML-dokumenter

Sluttbrukere som er interesserte i å laste ned grunnlagsmaterialet i XML-format skal slippe å forholde seg til at dokumentene er delt opp i mindre fragmenter i databasen. HISe-løsningen skal tilby nedlasting av dokumentene i helhetlig form, dvs. at hvert dokument kan lastes ned som én fil, hvor alle XML-fragmenter inngår. Løsningen må derfor inneholde funksjonaltet som fletter sammen XML-fragmenter til fullstendige dokumenter før nedlasting hvis de ikke lagres helhetlig i XML-databasen.

3.6 Opprydding av doble identifikatorer

HIS opererer med doble sett identifikatorer for dramaene, hvor det defineres én ID-serie i FileMaker-databasen og en annen i XML-dokumentene. Identifikatorene i FileMaker starter med "wo," kort for "work," men er ellers identiske med identifikatorene i XML-filene. F.eks. er Catilina identifisert ved ID "C1" i XML-dokumentet for hovedteksten:

<bibl id="C1"> I FileMaker-databasen og i referanser i XML-filene benyttes i stedet "woC1," slik:

<rs type="work" corresp="woC1">

17

Vi har løst dette ved å fjerne alle innledende boksaver fra identifikatorene i FileMaker-databasen og i referanser i XML-filene ved import i emnekartet. For Catilina benyttes nå alltid "C1" som identifikator i emnekartet, aldri "woC1." I emnekartet inngår denne identifikatoren som del av en PSI, på følgende måte:

http://www.ibsenarkivet.no/psi/work/C1 Identifikatorene for personer og steder er omgjort på samme måte, ved at innledende "pe" og "pl" er fjernet fra identifikatorene. Vi ender da opp med følgende PSI for personen Ibsen:

http://www.ibsenarkivet.no/psi/person/HI Når det gjelder stedene er det anbefalt at allerede etablerte PSI-er gjenbrukes for disse. Her vil det derfor trolig være nødvendig med en totalgjennomgang i hovedprosjektet. Se neste avsnitt for mer informasjon om dette.

3.7 Verdiøkning og rettelser av XML-materialet

Generelt bærer datagrunnlaget preg av å være produsert med tanke på å lage en tekstkritisk utgave av tekstene i bokform. Dette er naturlig, i og med at dette er prosjektets hovedformål. Samtidig innebærer dette at noen valg har blitt gjort som i noen grad vanskeliggjør bruk av datagrunnlaget på nett. Noe informasjon som er viktig i nettsammenheng mangler også. Det som kanskje først og fremst mangler er informasjon utover den som finnes i datagrunnlaget. Tekstene inneholder f.eks. referanser til apoteket i Grimstad, Grimstad og Norge. Disse emnene er merket og identifisert, men datagrunnlaget har for lite informasjon om dem til at informasjonen direkte kan brukes i en portal på nett. Bl.a. fremgår det ikke av datagrunnlaget at Norge er et land, Grimstad en by, og apoteket et sted/en bygning. Tilsvarende vet man ikke at apoteket ligger i Grimstad, eller at Grimstad ligger i Norge. Denne informasjonen bør fylles inn, og brukes i nettstedet. En naturlig måte å gjøre dette på kan være å lage en enkel emnekartontologi for denne informasjonen og bruke emnekarteditoren Ontopoly til å fylle den inn og vedlikeholde den. For å kunne utnytte datagrunnlaget til fulle i HISe-løsningen vil man altså være nødt til å verdiøke det ved manuell å tilføre tilstøtende kunnskap i emnekartet. Manglende geografisk informasjon er den klareste kandidaten til slik verdiøkning. I dette arbeidet bør man ta utgangspunkt i etable PSI'er for landene og byene som berøres. Bl.a. finnes Grimstad definert på Kulturnett.

3.7.1 Identifikasjon av XML-filene

Det verdt å merke seg at XML-strukturen ikke er 100% konsistent ift. angivelse av ID-elementet i ulike filer. ID angis enten i elementet <bibl> eller <msDescription>. Forskjellen er at <bibl> skal brukes for trykte tekster, mens <msDescription> brukes for manuskripter. Dette har å gjøre med hvilke elementer som er tillatt hvor i TEI og at HIS trenger forskjellige elem-enter til beskrivelse trykte versjoner og manus. For trykk er det f.eks. vesentlig å oppgi forlegger, trykkeri, publiseringsår o.l. mens det for manuskripter er mer hensiktsmessig å si noe om eier-institusjon, manuskriptsignatur, tilblivelsesår o.l. Variasjoner i angivelse av ID vil vanskeliggjøre oppslag mot XML-databasen, fordi man alltid må gjøre oppslaget mot to XML-elementer i stedet for ett.

Trykte tekster: <bibl id="B18510928NN_Til_Abonnenterne">

18

Manuskripter: <msDescription type="letter" id="B18520425NTB"> For å finne et brev med en gitt identifikator må man benytte en boolsk eller i oppslaget og søke etter alle brev som inneholder enten <msDescription> eller <bibl> med den spesifiserte identifikatoren. På tilsvarende måte er det kronglete å søke frem alle brev basert på XML-koden, fordi type heller ikke er angitt konsekvent. For manuskripter er typen angitt som et attributt på <msDescription>-elementet, men på trykte verk må man lete etter elementet <letterinfo> inne i <bibl> for å avgjøre typen:

<msDescription type="letter" id="B18520425NTB"> ... </msDescription> <bibl id="B18510928NN_Til_Abonnenterne">

<letterinfo corresp="B18540401NN"> ... </letterinfo> </bibl> Vi anser det som en mangel at det ikke finnes en entydig måte å identifisere verkene og verkenes type på. Dette utgjør ikke et stort problem for HISe-løsningen, men kan påvirke ytelsen noe. Det bør i alle tilfelle vurderes om man kan finne en mer elegant løsning. En konkret løsning som kan vurderes er å legge presise metadata i Berkeley DB XML i tilknytning til XML-dokumentene. Berkeley DB XML åpner for å knytte metadata til XML-dokumentene uten å måtte endre selve innholdet i dokumentet. Vi kan da legge på metadatafeltene ID og type, og populere disse ved import av XML-dokumentene. Ulempen ved denne løsningen er at alle XML-dokumentene må importeres i hver sin fil. Bl.a. må samlefilene som inneholder brev fra lengre tidsperioder deles opp. Det er ikke mulig å knytte meta-data til enkeltvise XML-elementer. Metadata gjelder hver fil i sin helhet. Alternativt kan det vurderes å innføre en enhetlig angivelse av type og ID på tvers av alle filer. Dette vil være den mest elegante løsningen med tanke på HISe-løsningen, men vil kreve manuell endrng av alle XML-filene.

3.7.2 Rettelser av ID-databasen fra FileMaker

Datamodellen i FileMaker-databasen håndhever ikke regler for konsistens i datagrunnlaget, og dette åpner for manuelle feil ved innlegging. ID-databasen inneholder derfor en rekke variasjoner som vi nå har vært nødt til å korrigere i konverteringsscriptene. ID-databasen bør kvalitetssikres for å sjekke at det ikke kryper in flere feil etterhvert som det legges inn nye data. Identifiserte feil så langt omfatter følgende:

• "Abraham Lincolns mord" forekommer to ganger, med ulik ID. Dette må utbedres både i ID-listen og i evt. XML-filer som refererer til de aktuelle ID-ene.

• Store variasjoner i type-kolonnen åpner for feilkilder ved import. Person er kodet på 7 forskjellige måter ("person," "pe," "pers," "prson," "person," "person" og "pesron"), mens sted ("place" og "pl") og verk ("work" og "wo") har mindre variasjon. Variasjonene vi har funnet så langt håndteres av konverteringsscriptet, men scriptet må læres opp til å forstå evt. nye variasjoner som tilkommer.

19

• Verkstype (sjanger) er ikke angitt for verkene i ID-databasen, hvor både dikt og drama er kodet som "work." Heller ikke verksreferansene i XML-koden er spesifikke på dette. Vi har løst dette ved å kode inn kunnskap om alle dramaer i konverteringsscriptet basert på dramaenes identifikatorer. Alle øvrige verk i ID-listen antas å være dikt. Denne løsningen fungerer bra så lenge det bare er dramaer og dikt det refereres til fra XML-koden. Hvis referanser til andre brev tas i bruk må modellen utvides.

3.7.3 Feilaktig DTD-angivelse

Enkelte av dokumentene refererer til DTD på lokalt filområde hos HISe: "M:\Prosjekt\ibsen-xml.dtd." Vi har foreløpig endret dette manuelt der vi har kommet over denne feilen. Alle dokumentene må gjennomgås og rettes før import.

3.7.4 Manglende felter i XML-filene

Ved konvertering av kjernedata fra brevene til emnekartet fant vi at følgende brev manglet avgivelse av OrigDate, OrigPlace, Recipient eller Sender. Vi har ikke analysert dette nærmere: B1844-1871ht.xml Line #218; Column #-1; OrigDate on Budat1850-51CE was empty! Line #218; Column #-1; OrigDate on Budat18580616JCG was empty! Line #218; Column #-1; OrigDate on Budat1856-58JCDa was empty! Line #218; Column #-1; OrigDate on Budat18600931JCG was empty! Line #218; Column #-1; OrigDate on B18660504MB was empty! Line #218; Column #-1; OrigDate on B18660822FH was empty! Line #218; Column #-1; OrigDate on B18671209BB was empty! Line #218; Column #-1; OrigDate on Budat1866-68NR was empty! Line #218; Column #-1; OrigDate on B18700512JPA was empty! Line #218; Column #-1; OrigDate on B18700604MT was empty! B1872gt.xml Line #279; Column #-1; Recipient on B18720711KomTB was empty! Line #244; Column #-1; OrigPlace on B18720723GB was empty! Line #244; Column #-1; OrigPlace on B18720808FH was empty! Line #244; Column #-1; OrigPlace on B18720829GB was empty! B1875gt.xml Line #244; Column #-1; OrigPlace on Budat18750104SG was empty! Line #305; Column #-1; Sender on Budat18750104SG was empty! Line #305; Column #-1; Sender on B18750603EStj was empty! Line #244; Column #-1; OrigPlace on B18750816HL was empty! Line #244; Column #-1; OrigPlace on B18750820EGr was empty! Line #244; Column #-1; OrigPlace on B18750822FH was empty! Line #244; Column #-1; OrigPlace on B18750824NL was empty! Line #244; Column #-1; OrigPlace on B18750826JHT was empty! Line #244; Column #-1; OrigPlace on B18750916GB was empty! Line #244; Column #-1; OrigPlace on B18750918JHT was empty! Line #218; Column #-1; OrigDate on Budat1875-76NN_Dette_var was empty! Line #218; Column #-1; OrigDate on Budat1875-76NN_Lieber was empty!

20

4 Teknisk plattform og arkitektur Teknisk plattform for HISe-løsningen skal sikre at utgangspunktet for å gjennomføre prosjektet er best mulig, både mht. produktivitet, risiko, mulig funksjonalitet i løsningen og stabiliet i drift. Teknisk plattform omfatter Java utviklings- og byggemljøet Equinox, samt kjernekomponenter for å håndtere funksjonaliet i alle lag i løsningen. Vurderingen av teknisk plattform har vært konsentrert om byggemiljøet og kjernekomponentene i løsningen, dvs. XML-databasen og emnekartmotoren med relasjonsdatabase. Sentrale krav som teknisk plattform skal sikre er:

• Høy utviklerproduktivitet Skal sikres ved bruk av et ferdig byggemiljø (Equinox), effektive applikasjons- og presentasjonsrammeverk (Spring, Spring MVC, JSTL), samt arkitektur som sikrer testbarhet og løse koblinger mellom komponentene i løsningen.

• Risikoreduksjon

Prosjektet skal gå opp mange nye stier, og det vil derfor nødvendigvis inneholde en del prøving og feiling. Et viktig grep for risikoreduksjon blir derfor iterativ utvikkling av løsningen med hyppig avsjekk sammen med HIS. Teknisk plattform skal lege tilrette for en slik utviklingsmodell, og sikre lav risiko ved endringer gjennom korte utviklingssykluser og høy testbarhet (byggemiljø), samt enkel utskifting og uavhengig videreutvikling av enkelt-komponenter i løsningen (arkitektur).

• Funksjonalitet og stabilitet

Hovedkompenentene i teknisk plattform må levere nødvendig funksjonaltet og stabilitet, og spille sammen med utviklingsmiljøet. Forprosjektet har ved testing og utvikling av vertikale prototyper undersøkt robustheten til de ulike

4.1 Utviklings- og byggemiljø

Applikasjonen skal utvikles i Java J2EE basert på en rekke open source komponenter. Det har vært viktig å identifisere et ferdig utviklings- og byggemiljø som har ferdig støtte for flest mulig av de involverte produktene, og som dermed kan gi prosjektet en "flying start." Vi har brukt utviklings- og byggemljøet Equinox, som leverer følgende basisfunksjonalitet:

- Ferdig byggemiljø integrert med Tomcat - Funksjonaliet for pakking og automatisk distribusjon av applikasjon til test- og prod.miljø - Tett integrert med forretningslag-rammeverket Spring, og Spring MVC med JSTL - Ferdig miljø for kjøring av enhetstester

Equinox er en nedskalert versjon av det mer omfattende byggemiljøet AppFuse. Vi har vurdert Equinox ift. behovene for utviklingsstøtte under hovedprosjektet, og funnet at Equinox bør fungere svært bra. Equinox kommer med et ferdig oppsett av Spring og Sitemesh som er godt tilpasset behovene i HISe-løsningen, og viderefører oppsettet for automatisk testing m.m. fra AppFuse. Oppsett av Equinox i forprosjektet har vært konsentrert om å evaluere dette miljøet for bruk sammen med Spring Framework, OKS og en XML-database. Vi vet av erfaring at arkitekturmodellen som vanligvis brukes med OKS er dårlig tilpasset iterativ utvikling og krav til testbarhet og isolasjon av arkitekturlagene. Vi har derfor lagt særlig vekt på å teste bruk av OKS i en Model View Controller-arkitektur i samspill med Equinox og Spring MVC, og å sikre testbarheten i et slikt oppsett.

21

Heldigvis gjør Spring det enkelt å sikre testbarhet også mot OKS. Vi fant at bruk av et statisk, filbasert emnekart var en god løsning for å ivareta testbarheten. Et filbasert emnekart med testdata gjør det mulig å kjøre enhetstester isolert mot datalaget i applikasjonen. Spring gjør det enkelt å styre om OKS startes opp mot testfilen eller mot utviklingsdatabasen. På denne måten får man et stabilt testoppsett som ikke påvirkes av endringer i databasen under utvikling av løsningen. Totalt sett fungerer OKS svært bra i kombinasjon med Equinox, men krever noe tilrettelegging av standardoppsettet i Equinox ift. bl.a. plassering av biblioteksfiler (*.jar) og bygging av applikasjonen. Utviklingsmiljøet er testet mot XML-databasen dbXML, med fokus på å etablere løs kobling og isolasjon av XML-databasen vha. Spring, for å gjøre det enklest mulig å bytte til en annen XML-database på et senere tidspunkt. Løsningen er tilrettelagt for enkelt bytte til Berkeley DB XML, som er produktet vi anbefaler å bruke. Se kapittel 7.5 for videre diskusjoner om valg av XML-database. Bruk av Equinox har gitt betydelige besparelser allerede i forprosjektet, fordi det kommer med et ferdig konfigurert oppsett der mange av komponentene som HISe-prosjektet er avhengig av inngår. På toppen av dette leveres ferdig oppsett for bygging og testing av applikasjonen som skal utvikles. Vi har sett visse begrensninger i ift. å kunne pakke applikasjonen som en war-fil for forenklet distribusjon og installasjon, men regner ikke dette som noen stor sak. Begrensningene henger sammen med at OKS bruker filstier til å referere til konfigurasjonsfilene sine, og ikke er i stand til å finne dem når de er pakket inne i en war-fil. Ved behov kan man velge å skille ut konfigurasjonsfilene når hovedprosjektet skal gennomføres, slik at disse legges utenfor war-filen. Dette har også fordeler ift. miljøavhengig konfigurasjon som vil variere mellom utviklings-, test- og produksjonsmiljø.

4.1.1 Automatisert enhetstesting Equinox er ferdig integrert med JUnit for kjøring av enhetstester og lager praktiske rapporter over testresultatene. Skjerbildet viser 3 forekomster av uventet oppførsel i klassen org.appfuse.dao:

22

4.2 Komponenter i løsningsarkitekturen

Forprosjektet har vist at prinsippene i løsningsarkitekturen er fornuftige, men det har vært nødvendig å gjøre endringer på komponentnivå. De viktigste endringene er at Lucene har fått en fast plass i arkitekturen, og at XML-databasen dbXML er kastet ut til fordel for Berkeley DB XML.

Apache TomcatJava J2EE applikasjonsserverApache Tomcat

Java J2EE applikasjonsserver

PostgreSQLRelasjonsdatabase

Log

ikkl

agP

rese

nta

sjo

nsl

ag

Berkeley DB XMLXML-databaseBerkeley DB XML

XML-database

Ontopia Topic Map EngineEmnekartmotorOntopia Topic Map Engine

Emnekartmotor

Dat

alag

QueryEngine

FulltextSearch

SchemaTools

XPathQuerying

XQueryQuerying

IndexedLookup

Spring FrameworkLogikkrammeverkSpring Framework

Logikkrammeverk

Jakarta LuceneFulltekst søkemotorJakarta Lucene

Fulltekst søkemotor

TED

Bus

ines

s Lo

gic

Publ

iser

ings

logi

kk

TMR

APAu

tom

atis

k da

taut

veks

ling

Søk- og oppslagslogikkVerdiøket søk mot XML-databasen og OKSSøk- og oppslagslogikk

Verdiøket søk mot XML-databasen og OKS

HISe forretningslogikkGen. av tekstvitnekart, hjelpefunksj., caching, m.v.

HISe forretningslogikkGen. av tekstvitnekart, hjelpefunksj., caching, m.v.

Spring MVCSkiller presentasjon og kontrolllogikkSpring MVC

Skiller presentasjon og kontrolllogikk

HISe visningslogikkKontrollogikk for ulike skjermbilderHISe visningslogikk

Kontrollogikk for ulike skjermbilder

Navigator Fwk.Pres. av emnekartNavigator Fwk.

Pres. av emnekart

Web Ed. Fwk.Redig. av emnekartWeb Ed. Fwk.

Redig. av emnekart

JSP-malerGenererer HTML-presentasjonJSP-maler

Genererer HTML-presentasjon

Sitemesh FilterMalbasert dekorering av JSP-siderSitemesh Filter

Malbasert dekorering av JSP-sider TED

Publ

iser

ing

Om

niga

tor

Fri n

avig

erin

g

Vizi

gato

rV

isua

liser

ing

OKS-komponenter

Skreddersøm

Open source

OSCache Cache FilterHTML-cache for bedret ytelseOSCache Cache Filter

HTML-cache for bedret ytelse

JSTLVerktøykasse for presentasjonJSTL

Verktøykasse for presentasjon

23

4.2.1 Synkronisering av kjernekomponentene ved import

XML-databasen, emnekartmotoren og søkemotoren utgjør de tre hovedkomponentene i løsningen. Disse komponentene er ikke integrert med hverandre, men jobber med data fra samme kilde. Derfor blir det særdeles viktig å sikre at nødvendig synkronisering av disse ved ny import eller endring av eksisterende data.

XML-database Emnekartmotor

XML

LuceneFritekstsøk

XML-database Emnekartmotor

XML

LuceneFritekstsøk Data fra XML-databasen

og emnekartet flettesfør indeksering isøkemotoren

En ferdig løsning på denne utfordringen kan ikke utformes før vi har endelig oversikt over hvilke data som skal lagres hvor, evt. dobbeltlagres, hvor de ulike datatypene oppstår, og om denne datatypen skal indekseres for fritekstsøk. Noen typer data vil vedlikeholdes på fil og importeres, mens andre typer vil vedlikeholdes direkte i emnekartet. Figuren til venstre viser én mulig løsning, der alle data som skal deles mellom systemene vedlike-holdes på fil og importeres i alle de tre systemene. Til høyre vises en annen mulig løsning, hvor data fra XML-databasen og emnekartet flettes før indeksering i søkemotoren. Søkemotoren trenger ikke å vite hvilket system som bidrar med hvilke data. Løsningen til høyre kan f.eks. være aktuell hvis det er ønskelig å søke i tekstene basert på geografi. XML-filene inneholder mangelfull informasjon om sammenhengen mellom by og land, slik at det bl.a. ikke fremgår at København ligger i Danmark. Søk på brev som er skrevet i Danmark vil derfor ikke gi treff på XML-dokumenter som er merket med København. Koblingen mellom by og land kan opprettes i emnekartet, og dermed sikre at søkemotoren får et mer fullstendg datagrunnlag.

4.2.2 Webpubliseringsløsning

HISe-løsningen skal inneholde noe web-spesifik tekst. Dette kan omfatte alt fra presentasjon av prosjektet til hjelpetekst tilknyttet søkefunksjonen. Omfanget og vedlikeholdsbehovet forbundet med web-spesifik tekst er ikke kartlagt i forprosjektet, men som del av kravspesifisering av endelig løsning bør det vurderes om en publiseringsløsning for slikt innhold er nødvendig. Andre aktuelle alternativer er bruk av statiske HTML-innhold, som vil egne seg godt hvis det er lite innhold som sjelden endrer seg, eller bruk av et forenklet XML-format for publisering av webtekster. Disse XML-filene kan da lagres i XML-basen på samme måte som det øvrige XML-innholdet.

24

En webpubliseringsløsning – Web Content Management System (WCMS) på engelsk – vil kunne forenkle forvaltning av webstruktur og -innhold (tekst, grafikk og lenker), slik at dette ikke krever kunnskap om HTML eller webteknologi. De fleste systemene bruker en database til å lagre innholdet og et malbasert presentasjonslag som genererer HTML-sidene. Administrasjon av tjenesten skjer typisk gjennom et passordbeskyttet webgrensesnitt. Potensialet for forenkling må veies mot kompleksiteten ved å innføre en ny komponent i arkitekturen som vil kreve integrasjon og skreddersøm.

4.3 Driftsmiljø

Overgang til Berkeley DB XML vil redusere antall komponenter i driftsmiljøet, og derved forenkle drift av HISe-løsningen. Berkeley DB XML kjører "i applikasjonen," og krever ikke tilsyn av driftsansvarlig på samme måte som en database-server. Berkeley DB XML er designet for å kjøre uten vedlikehold. Planlagt HISe-løsning krever dermed bare drift av to hovedkomponenter: (1) Applikasjonsserveren Tomcat med HISe-løsningen og (2) PostgreSQL-databasen. Tomcat er kjent for for de fleste med erfaring fra drift av J2EE-applikasjoner, og er svært enkel både å installere og drifte. PostgreSQL vil trolig kreve noe mer kunnskap for å kunne sette opp pålitelig rutiner for sikkerhetskopiering, m.v.

25

5 Utforming av tjenesten Forprosjektet har jobbet med informasjonsarkitekturen i HISe-løsningen på overordnet nivå. Det er bl.a. gjennomført arbeidsseminar med HIS for å tydeliggjøre hvilke målgrupper tjenesten skal henvende seg til og primærbehovene disse gruppene har ift. gjenfinning. Det er også produsert en rekke prototyper med varierende grad av grafisk design.

5.1 Grafisk design

Prototypen har fått grunnleggende grafisk utforming som et forslag til mulig retning å gå i fra Creuna. Ved endelig utforming av tjenesten bør det settes av ressurser til å etablere en helhetlig grafisk profil, kanskje i samsvar med designarbeidet som er gjort på de trykte utgavene av HIS sitt materiale. Dersom HIS ønsker å benytte den håndtegnede Ibsen-logoen som er i bruk i prototypen må det sikres tillatelse for bruk fra opprettshaver. Vi antar at det er Gyldendal, evt. kunstneren selv, som sitter på disse rettighetene. Bildet som er brukt til logo er hentet fra Gyldendals nettside: http://www.gyldendal.no/Frameset/showarticle.asp?ID_Article=4443&ID_ParentChannel=698

5.2 Målgrupper

HIS jobber nå med totalt fire målgrupperfor HISe-løsningen. HIS definerer selv gruppene slik:

• Forskere: prioriterte faggrupper er litteraturvitere/tekstforskere, teatervitere, språkvitere, historikere etc. Utgaven skal tilgjengeliggjøre pålitelige tekster i alle kjente utgaver av Ibsens verker, brev, artikler og taler, og presentere gode verktøy for å arbeide med tekstene. Forskere skal kunne sammenligne utgaver, kontrollere mot faksimile, følge tekstenes utvikling/endringer, gjøre søk i materialet, velge tilpassede visninger for metrikkstudier, visninger av transkriberte manuskripter uten HIS’ ederinger, se statistikker over anvendte verseformer, typer endringer i manuskripter o.a.

• Studenter/skoleelever: Viktig for denne gruppen er i tillegg til å få tilgang til pålitelige tekster, samt til de samme verktøyene/spesialvisningene som forskerne (gjelder studenter på høyere grad), all metainformasjonen som kommentarmaterialet (i stort) tilbyr: lemmakommentarer knyttet til hovedtekstene, innledninger, personregistre, krønike. Kommentarmaterialet vil sette senere tiders fortolkere i stand til å forstå tekstenes bakgrunn bedre, og gjøre dem kjent med tekstenes samtid. Dette er viktig for skolebrukere, studenter og lesere så vel som for teaterfolk, oversettere og utgivere. Studenter/ skolelever kan dessuten ha nytte av fritekstsøk i kommentarmaterialet. (det bør da fremgå tydelig at det er kommentarnmaterialet det søkes i – her gjelder heller ikke dansk-norsk-problemet mht. fritekstsøk).

• Teaterfolk, oversettere og utgivere: Teaterfolk så vel som studenter og forskere kan i tillegg ha stor nytte av filtrerte spesialvisninger som for eksempel fremhever regianvisninger, bestemte rollenavns replikker etc.

• Allmenheten

26

5.3 Prioriterte gjenfinningsbehov hos målgruppene

Under arbeidsseminaret med HIS ble følgende gjenfinningsbehov trukket frem som ekstra viktige. 1. pri gjenfinningsbehov:

- Finne dikt/drama/brev - Krønike, årstall/dato, kronologi - Dikt: 1.linje, tittel - Populærnavn - Sjangerindeks, undersjanger, finne manuskripttyper - Brev basert på mottaker, sted, dato - Finne brev som omtaler et verk - Brev som omtaler bestemt person - Metrikklab - Manuskriptlab, manuskriptgenese - Usikker: Påvisekilder for sitater – dekkes av fritekstsøk, evt. med bruk av "near"-operator?

2. pri gjenfinningsbehov:

- Finne alle replikker av en aktør - Rollenavn (med forklaring) - Versemål, hele materialet – rimskjema, opptakt, formel

5.4 Modell for gjenfinning i HISe

Arbeidsseminaret brukte tid på å konkretisere en modell for gjenfinning i HISe. Den ligger nå til grunn for mye av tankegodset i denne rapporten. Modellen tar utgangspunkt i tre overordnede innganger til tekstene i HISe:

1. Navigasjon – Webnavigasjon i emnekartet, evt. publisert materiale

2. Fritekstsøk – Generelt fritekstsøk i kombinasjon med avgrensninger på f.eks. type, dato e.l.

3. Spesialisert søk – Spesialiserte søkefunksjoner som er tilpasset behovene for en spesifikk arbeidsoppave, f.eks. metrisk analyse. Vil ikke være globalt tilgjengelig, men tilbys som del av spesialiserte deler av tjenesten, f.eks. en "Metrikklab."

Gjenfinning på tekstnivå, dvs. internt i en tekst, gjør brukeren vha. nettleserens søkefunksjon, evt. vha. tilpassede filtreringsmekanismer i HISe-løsningen. Filtrering kan f.eks. omfatte visning/filtrering av metrisk informasjon, løpende kommentarer i tekstmaterialet, eller replikker fra utvalgte karakterer. Modellen for gjenfinning er illustrert på neste side.

27

FritekstsøkSøk i fritekst i kombi-nasjon med enkle av-grensninger på f.eks. dato eller type (drama, dikt, brev)

Resultatliste etter søkBrukeren velger søke-treffet som ser mest relevant ut.

TekstvisningVisning av brev, dikt eller dramatekster med hovedteksten som førstevalg

NavigasjonEksempler på inndeling:• Krønike (årstall/dato)• Geografi (hvor skrevet/utgitt)• Alfabetisk verksliste• Korrespondanse (mottaker, dato)• Metrikk (verseformer)• Variantliste

Spesialiserte søkSpesialisert brukersøk mot metadata eller spesifikke XML-elem-enter (implementeres hvis behov identifiseres i MetrikkLab e.l.)

Filtrert visningEksempler på filtrering:• Vise/skjule metrikk• Filtrere replikker (eks.bare vise Noras repl.)

• Vise/skjule løpendekommentarer i teksten

NavigasjonslisteListe over tekster innenfor valgt kategori(sikt, brev, drama)

Gjenfinning i HISe Eksponering fortekstvarianter

Alt. 1Eksponere brukeren for tekst-variantene allerede ved over-ordnet navigasjon eller i søke-skjermbildet (eks. avkryssningfor ”søk også i tekstvarianter”)

Alt. 2Eksponere brukeren forvariantene i navigasjons-og søkeresultatlistene

Alt. 3Eksponere brukeren forvariantene på tekstnivå,eks. på en oversiktsside fordet valgte verket før brukeren velger den konkrete variantenhun ønsker å se på

5.5 Prefererte gjenfinningsmetoder

Deltakerne på arbeidsseminaret sorterte de viktigste gjenfinningsbehovene ift. preferert metode for gjenfinning. Gjennomgangen viste at det foreløpig ikke finnes konkrete krav til spesialiserte søk. Pri Behov Navigasjon Fritekstsøk Spes. søk 1 Finne dikt, drama, brev x 1 Populærnavn x 1 Sjanger-indeks, undersjangere, manuskripttyper x 1 Krønike, årstall, dato, kronologi x x 1 Dikt: 1.linje, tittel x x 1 Dikt: Verseformer, varianter x 1 Påvise kilder for sitater (dekket av fritekstsøk) x 2 Brev som omtaler en person x 2 Brev som omtaler er verk x

28

Grunnleggende navigasjon etter sjanger, verkstittel og kronologi vil bli svært viktig for å orientere seg i materialet. Det kan i tillegg være behov for å legge tilrette indekser for mer spesialiserte gjen-finningsbehov, selv om de fleste trolig kan genereres fra emnekartet. Her kan bl.a. nevnes:

• Brev som omtaler et bestemt verk • Brev som omtaler en bestemt person • Brev til en bestemt mottaker • Førstelinjeindeks, dikt • Manuskripttyper

5.6 Verket som navigasjonsknutepunkt

Verkene utgjør naturlige knutepunkter i navigasjonen mellom tekstvarianter og informasjon i emnekartet. En sentral del av HISe-løsningens konsept blir derfor å videreføre denne sammen-hengen på web. Vi har brukt følgende skisse for å illustrere mulighetene i en slik løsning:

Catilina (1850)Catilina er utgitt i to ganger, først i 1850, og senere i en bearbeidet versjon i 1875.Forskjellene mellom de to tekstene er betydelige, og de regnes derfor som toseparate verk.

Les Catilina (1850)• Hovedtekst, Catilina (1850)Hovedteksten er en forsiktig omarbeidet versjon av grunnteksten med rettelser og noter fra HIS’ tekstforskere.

Relaterte verk• Catilina (1875)

Ibsens brev om CatilinaCatilina omtales i flere av Ibsens brev:

• Brev til kong Karl 15., 10.03.1863• Brev til Ole Carelius Schulerud,15.10.1849

• Brev til Ole Carelius Schulerud,05.01.1850

• Brev til Peter Hansen, 28.10.1870

TekstarkivGrunntekst:• Catilina førsteutgave (1850)

Tekstvitner:• Catilina arbeidsmanuskript (1849)

Avhenger av etablert koblingmellom de to verkene.

Kort introduksjonsteksttil hvert enkelt verk.

Skal det være mulig å gjøre variantvisning der teksterfra både 1850- og 1875-utgaven inngår?

Sammenligne varianter• Variantvisning, Catilina (1850)Variantvisningen gir deg mulighet til åsammenligne de ulike tekstvariantene fra tekstarkivet, og se hvilke endringer Ibsen gjorde fra versjon til varsjon.

I hovedprosjektet må man sikre at man får et helstøpt konsept, bl.a. ved å tenke gjennom hvordan siden som er illustrert kan integreres med søk. Se også illustrasjonen i avsnitt 5.4.

29

5.7 Visning av ederte hovedtekster

Det er utviklet en HTML-prototype på visning av ederte hovedtekster, som er tilgjengelig her: http://prosjekter.creuna.no/hise/hovedtekst.html Prototypen illustrerer mulige løsninger på visning av noter, faksimiler og emnekartreferanser, men den må integreres med den øvrige navigasjonen og spesielt knutepunkt-siden for verket, som illustrert i foregående avsnitt.

5.8 Informasjonsarkitektur og interaksjonsdesign

Gjenomtenkt informasjonsarkitektur og interaksjonsdesign blir et svært viktig fokus i hovedprosjektet. HISe-løsningen har særlige utfordringer på dette området fordi innholdet finnes i flere varianter og skal kunne vises på en rekke ulike måter. Det anbefales å få inn en interaksjonsdesigner som kan dra denne prosessen så tidlig som mulig i prosjektløpet, da interaksjonsdesignet vil ha følger for alle deler av HISe-løsningen.

30

6 Søk i kildematerialet Søk har vært et sentralt tema gjennom hele forprosjektet, og oppfattes som såpass viktig at alle hovedkompenentene i HISe-løsningen er planlagt med tanke på søkbarhet. Både XML-databasen og emnekartmotoren OKS støtter fritekstsøk og strukturerte søk i sine data. I tillegg inkluderte vi fra starten av Jakarta Lucene i arkitekturen for indeksering og fritekstsøk i tekstene i tilfelle kvaliteten på fritekstsøket i XML-databasen ikke var tilfredsstillende. Gjennom forprosjektet ble det stadig tydeligere at fritekstsøk vil by på særlige utfordringer pga. Ibsens dansk-norske språk, som vil være uvant for mange av brukerne. Det er ønskelig å kunne sikre søke-treff selv om brukerne formulerer sine søk på vanlig bokmål, slik at bl.a. ordene "mig" og "meg" bør være likestilt overfor søkemotoren. Slike utfordringer er det bare Lucene som kan håndtere, og det virker derfor sikkert at Lucene vil bli en svært viktig komponent for å sikre enkel gjenfinning. Diskusjon med prosjektgruppen og arbeidsseminar med Henrik Ibsens skrifter har vist at fritekstsøk i kombinasjon med enkle avgrensninger på presise kriterier vil bli det viktigste værktøyet for søk. Presise kriterier det kan være aktuelt å avgrense på er bl.a. sjanger (dikt, drama, brev) og dato-periode, evt. sjangerspesifikke kriterier som mottaker for brev. Søkefunksjonen vil gi treff i tekstene slik de fremstår i web-tjenesten. Det betyr at dramaer deles opp i sine hoveddeler, front, back, og de enkelte aktene i body. For dikt og brev indekseres text i sin helhet, uten å deles opp. TeiHeader indekseres ikke for fritekstsøk, men er kilde til presise, søkbare meta-data som bl.a. type og dato. Vi har ikke sett behov for at søkfunksjonen skal ha kunnskap om tekstene på mer detaljert nivå en disse hoveddelene. Søkeindeksen for hovedsøket vil derfor bygges for å kunne vise hvilken akt den aktuelle teksten forekommer i, men den vil ikke støtte søk avgrenset til mer spesifikke elementer som f.eks. søk i replikker av en bestemt karakter, søk kun i sceneanvisninger, e.l. Til slike formål må det bygges spesialiserte søkeindekser, og det kan bli aktuelt f.eks. i MetrikkLab'en eller i andre spesiali-serte deler av HISe-løsningen.

6.1 Retningslinjer for global søkefunksjon

Det er i løper av forprosjektet etablert enighet om at den globale søkefunksjonen er til for å forenkle gjenfinning for alle sluttbrukere av HISe-løsningen. Dette har en rekke følger for utforming av søket:

1. Gjennomføring av søk skal ikke kreve noen form for kunnskap om XML-kodingen.

2. Hensikten med søk er å finne relevante websider (én webside pr. akt for dramaene), ikke å finne enkeltvise XML-elementer.

3. Søkefunksjonen skal tilby et godt fritekstsøk med muligheter for ytterligere avgrensning etter et fåtall forhåndsdefinerte kriterier som bl.a. type (drama, brev, dikt) og datoperiode.

4. Spesialserte oversikter, statistikk eller rapporter gjennomføres ikke ved søk, men forberedes så langt det er mulig på forhånd og publiseres i løsningen som statiske data.

5. Søk i datalaget, for å finne og laste ned XML-dokumenter, implementeres ikke. I stedet gjøres XML-dokumentene tilgjengelig gjennom oversiktslister i form av websider som lenker til XML-representasjonen av hvert enkelt dokument.

Spesialiserte søkeindekser kan bygges ved behov, men bør da spesifiseres i detalj som del av hovedprosjektet.

31

6.2 Modeller for søk

Under diskusjonene om søk i forprosjektet har vi sett på ulike modeller for avgrensning av rene fritekstsøk. Vi har tatt utgangspunkt i tre grunnleggende modeller:

1. Søk basert på presise søkekriterier Denne modellen fordrer høy kunnskap om materialet det skal søkes i, samt høy presisjon fra brukerens side. Ofte kreves det at brukeren formulerer søkekriterier på en spesiell måte. Modellen tillater svært presise søk, men gjør det ogs mulig for brukeren å utforme selvmot-sigende søk som ikke gir treff. Vi finner denne modellen særlig i bibliografiske systemer, der brukeren kan fylle inn kriterier knyttet til svært spesifikke metadatafelter, slik som forfatter, tittel, undertittel, ISBN, utgivelsesår, eller lignende. Denne modellen passer bra for de som vet hva de er på jakt etter, men utelukker til en viss grad andre brukergrupper.

2. Søk på kombinasjon av presise og upresise kriterier – søkemotoren hjelper brukeren

Dette er den fremherskende modellen for søk i dag. Brukeren spesifiserer sine søkekriterier i en enkel fritekstboks, evt. sammen med utvalgte lettfattelige, presise kriterier. Søkemotoren søker på tvers av alle kildedata, og brukeren trenger derfor ikke vite om ordet hun er på jakt etter er brukt i tittel, undertittel eller i innholdet. Søket er også "upresist" i den forstand at søkekriteriet reduseres til et søk etter ord med samme ordstammene, ikke nødvendigvis den presise ordformen som blir oppgitt i søkekriteriet. Denne typen søk gir noe mindre fleksibilitet til å uttrykke smale, presise søkekriterier, slik at søkeresultatene kan bli større enn ved presise søk, men intelligent prioritering av søketreff sørger for at de beste treffene som regel ligger øverst. Redaksjonell innsats kan brukes til å "lære opp" søkemotoren slik at den

3. Gradvis innsnevring av søkeresultatet ("fasettert søk")

I denne modellen gjør brukeren gradvis innsnevring av søket ved å navigere nedover i stadig snevrere deler av søkeresultatet. På denne måten blir kravene til å oppgi presise søke-kriterier i forkant redusert til et minimum. Fungerer best på presist kategoriserte data, eksempelvis produktkataloger, men kan f.eks. benyttes på sjanger, manuskripttype og tidsperiode i HISe-løsningen. Denne type løsninger fordrer at søkefunksjonen har dyp forståelse av strukturen av i det indekserte materialet, og de kan derfor være kostbare å implementere.

Vi anbefaler at HIS satser på et søk der der presise og upresise søkekriterier kombineres (modell 2), evt. i kombinasjon med en begrenset løsning for gradvis innsnevring av søkeresultatet – såkalt "fasettert søk" (modell 3). Utvikling av fasettert søk bør være en opsjon i hovedprosjektet som HIS kan velge å benytte seg av hvis behovet er tilstede og budsjettet tillater det. På neste side vises skjermbildeeksempler på bruk av modell 1 og 3. Skjermbildeskisser for bruk av søk i HISe-løsningen (modell 2) finnes i neste avsnitt.

32

Eksempel på presise søkekriterier: Søket omfatter mange felt som kan forvirre uerfarne brukere, som Institusjons-ID og Publikasjons-ID. Videre må brukeren selv sikre at bl.a. søk på forfatter utformes på riktig måte, med ettertternavn og fornavn angitt kommaseparert i riktig rekkefølge.

Eksempel på fasettert søk: Søket hos Kelkoo deler søketreffene opp i snevrere kategorier.

33

6.3 Skjermbildeskisser

Det anbefales at søkeskjermbildet tar utgangspunkt i kjente mønster for søk på web, med en enkel søkeboks tilgjengelig fra alle sider i tjenesten som en viktig ingrediens.

6.3.1 Avansert søk

Avansert søkeskjermbilde gir brukeren flere muligheter til å avgrense søket enn den globale søke-boksen. Antall valg på avansert søkeskjermbilde bør likevel holdes til et minimum.

Avansert søk

Avansert søk kan ta brukeren til det detaljerte søkebildet.

34

6.3.2 Avansert søk med kontekstavhengige undervalg

Som en alternativ løsning som muliggjør bruk av flere valg i søkeskjermbildet uten å overvelde brukerne, har vi diskutert bruk av kontekstavhengige undervalg som dukker opp når dokumenttype (sjanger) velges. Nedenfor vises et eksempel der feltene Send til og Sendt fra dukker opp idet brukeren har valgt dokumenttype "Brev." Disse feltene gir mulighet til ytterliger avgrensning av søket.

Merk at denne modellen er vanskelig å kombinere med fasettert søk, som vises i neste skjermbilde-skisse, slik at HIS bør holde seg til å velge én av disse modellene, ikke kombinere dem.

35

6.3.3 Gradvis innsnevring av søkeresultatet ("fasettert søk")

Skjermbildeskissen viser et eksempel på hvordan gradvis innsnevring av søkeresultatet kan tilbys gjennom bruk av fasettert søk i HISe-løsningen.

Søkeresultat

Søk etter "splid"; Viser treff 1-10 av totalt 19

Begrens søket til kategoriSjanger:Drama (10)Dikt (8)Brev (1)

Manuskripttype:Hovedtekst (16)Arbeidsmanuskript (2)Utkast (1)

Tidsperiode:1850-1859 (5)1860-1869 (9)1870-1879 (4)1880-1889 (1)

Merk at denne modellen er vanskelig å kombinere med kontekstavhengige undervalg i søkeskjemaet, som vist i foregående avsnitt, slik at HIS bør holde seg til å velge én av disse modellene, ikke kombinere dem.

36

6.4 Søk i dansk-norsk tekst

Vi har allerede nevnt at Ibsens dansk-norske språkdrakt vil gi særlige utfordringer ved søk. Dagens publikum vil være vant til å lese moderniserte utgaver av Ibsens tekster, og vil derfor med stor sannsynlighet utforme mange av sine søkekriterier på bokmål. Dette åpner for store sprik i stavemåte og ordbruk mellom søkekriteriene og kildetekstene det søkes i. La oss ta utgangspunkt i et sitat fra Catilina, og et tenkt søkekriterie: Kildetekst:: Her råder tyranni og uretfærd langt mer end nogensinde Søkekriterie: tyranni og urettferdighet mer enn noensinne Vi ser at det bare er tre av ordene i søkekriteriet som faktisk stemmer overens med kildeteksten: "tyranni", "og" og "mer." Dette er trolig et ganske representativt eksempel for hvordan mange av søkene vil utformes, selv om brukere gjerne er enda mer kortfattede når de søker. Det er sjelden brukere oppgir mer enn 2-3 ord i søkekriteriet, med mindre de søker etter en frase eller et sitat. Dette korte eksempelet hjelper oss likevel å trekke flere viktige slutninger:

- Søk med boolsk eller (OR) mellom søkeordene er å foretrekke fremfor boolsk og (AND), fordi forskjeller i stavemåte ellers fort vil ekskludere alle treff. Ved bruk av boolsk eller vil søke-motoren prioritere de dokumentet som gir best treff i søkeresultatet.

- Bruk av synonymord for å oversette søkekriteriene vil gi et viktig bidrag til bedret søkbarhet.

- Fordi mange meningsbærende ord (eks. "urettferdighet" her) ikke vil gi treff, blir det viktig å utnytte verdien av alle ordene i søkekriteriet – også ord som er så hyppig brukt at de normalt defineres som stoppord og ikke indekseres ("og," "mer" og "enn" her).

Jakarta Lucene støtter en rekke grunnleggende mekanismer for å sikre bedre søketreff. Disse omfatter bl.a. indeksering uavhengig av store og små bokstaver, intelligent prioritering av søketreff (alle ordene må ikke treffe) og mulighet for bruk av stoppordlister. Disse mekanismene alene er imidlertid ikke tilstrekkelige for å gi tilfredsstillende søkbarhet i Ibsens dansk-norske tekster. De følgende avsnittene ser på hvordan avanserte mekanismer som bruk av synonymord, publiserte søketreff og ordstamming kan bidra til å bedret gjennfinnbarhet ved søk i kildematerialet.

6.4.1 Bruk av synonymord

Eksempelet i foregående avsnitt viste hvordan viktige ord i søkekriteriet kan ha endret stavemåte siden Ibsens tid, og derfor potensielt ikke vil gi treff i kildematerialet. Problemene som dette for-årsaker kan utbedres ved å definere synonymer for hyppig brukte søketermer og hyppig brukte termer i Ibsens tekster. I eksempelet vårt kunne følgende synonymdefinisjoner sikret mye bedre søketreff:

urettferdighet uretfærd enn end noensinne nogensinde

Kanskje er det i tillegg ønskelig å opprette synonymkoblinger for ekte synonymord også, ikke bare ord som har endret stavemåte. Et eksempel på dette kan være:

urett uretfærd

37

Det er en uoverkommelig oppgave å definere synonymord for alle søkeord som er i bruk. Derfor trenger vi statistikk over faktiske gjennomførte søk som et utgangspunkt. Dette betyr at HISe-løsningen må inneholde logging av gjennomførte søk, og helst et analyseverktøy som produserer enkle statistikkrapporter som HIS kan ta utgangspunkt i når synonymer skal defineres. Neste avsnitt viser hvordan et fåtall populære søketermer utgjør størsteparten av gjennomførte søk i de aller fleste systemer. Dette gjør det mulig å kvalitetssikre synonymord for store deler av søkene som gjennomføres ved å gå gjennom et begrenset antall populære søkekriterier.

6.4.2 Publiserte søketreff Publiserte søketreff blir ansett som den beste mekanismen for å sikre relevante søk for flest mulig brukere. Utgangspunktet er at Pareto-prinsippet ("80/20-regelen") gjelder i ekstrem grad for gjennomførte søk, hvor et fåtall søketermer utgjør hoveddelen av søkene som gjennomføres. Trenden er universell og går igjen i alle søkesystemer man kikker på. Som eksempel har søkelogg-analyser fra Michigan State University vist at av 250.000 gjennomførte søk står 500 søkebegreper for hele 40% av søkene, 1000 søkebegreper dekker 50% eller mer. Videre analyse vil som regel vise at mange av søkene omhandler det samme, bare formulert forskjellig. Erfaringer fra Odin og andre store tjenester viser samme søkemønster. Dette betyr at man med små ressurser kan gå gjennom de mest populære søkene manuelt og sikre at de gir gode treff ved å publisere søketreff der relevante koblinger mangler. Kanskje kan man ved å gå gjennom så få som 100-200 søkebegreper kvalitetssikre 50% av søkene.

Grafene viser såkalte Zipf-kurver, med søketermene sortert etter avtagende popularitet langs X-aksen, og antall gjennomførte søk pr. søketerm langs Y-aksen. Publiserte søketreff gir andre muligheter til å påvirke søkeresultatet enn definering av synonymord, ved at man kan knytte søketreff til et søkeord uavhengig av om søkeordet faktisk forekommer i kildeteksten som publiseres til trefflisten. For eksempel kan det tenkes at mange søker på "Ibsenåret," "Ibsenmuseet" eller andre søkeord som det ikke finnes informasjon om i HISe-løsningen. Som en ekstra service til brukerne kan man da velge å publisere lenker til mer passende nettsteder. Alternativt kan det være ønskelig å sikre at kontaktinformasjonen til Henrik Ibsens skrifter alltid legger seg øverst på trefflisten når noen søker på "kontakt," selv om dette ordet også er i bruk i flere av Ibsens tekster.

38

6.4.3 Ordstamming Lucene har utvidelser for ordstamming på en rekke ulike språk, bl.a. norsk og dansk. Ordstamming fjerner alle ordendelser, som f.eks. -en, -ene, -et, før indeksering. Tilsvarende vil ordstamming brukes til å fjerne endelser på søkekriterier fra brukerne før søk gjennomføres. HISe-løsningen kan på denne måten sikre søketreff selv om brukeren ikke har brukt samme endelse i søkekriteriet som i det indekserte materialet.

den forhindr mig

den forhindret mi Søk

" ... Den forhindrer mig ... " "den forhindret mig"

den forhindr migOrdstammeneer like

Indeksering Søk

XML

Kildemateriale Fritekstsøk

Lucene gjør ordstamming basert på Dr. Martin Porters algoritmiske definisjoner for ordstamming, det såkalte Snowball-systemet – etter programspråket SNOBOL. Ordstammings-algoritmer basert på Snowball-systemet finnes for en rekke europeiske språk, bl.a. norsk og dansk. Se http://snowball.tartarus.org/ for mer informasjon. I løpet av forprosjektperioden har vi gjort praktiske forsøk med bruk av norsk og dansk ordstamming på Ibsens tekster. Se avsnitt 7.6.2 for mer informasjon.

6.5 Søk i webtekster

Det er ikke avklart om søket skal være begrenset til XML-materialet (Ibsens tekster med noter og kommentarer) eller om det også skal gi treff på webtekster som kontaktinformasjon, seksjonssider, og annet webrelatert innhold. Indeksering av denne typen innhold fordrer potensielt oppsett av en web-crawler som kan besøke og indeksere de aktuelle websidene, integrasjon med webpubliseringsløsningen som benyttes (hvis noen), eller på annen måte tilgang til det publiserte webmaterialet. Én mulig løsning kan være å vedlikeholde webtekster i et forenklet XML-format (TEI er mer omfattende enn nødvendig) og lagre dem rett i XML-databasen sammen med det øvrige innholdet. Dette vil kunne forenkle integrasjon med søkefunksjonen fordi TEI-dokumentene og webtekstene kan indekseres på samme måte av søkemotoren. Hvis det er snakk om mange web-spesifike tekster er det imidlertid mest hensiktsmessig å sette opp en webpubliseringsløsning hvor innholdet kan vedlikeholdes. Se også avsnitt 4.2.2 for flere detaljer.

39

7 Erfaringer fra forprosjektets tekniske prototyper Foreslått arkitektur for HISe-løsningen er testet gjennom en rekke vertikale, tekniske prototyper i løpet av forprosjektet. I dette arbeidet har vi fokusert særlig på testing av kjernekomponenter i arkitek-turen og samspillet mellom disse, men alltid i form av testbare web-prototyper som kan vurderes av prosjektgruppa hos Henrik Ibsens skrifter. Hensikten har vært å redusere risiko i hovedprosjektet, både ift. systemarkitekturen og løsnings-konseptet. For å validere løsningskonseptet er det også gjennomført både HTML- og papirprototyping av brukergrensesnittet, og arbeidsseminar med Henrik Ibsens skrifter om søk i løsningen. Synlige prototyper har vært en viktig del av arbeidet med å høste tilbakemedinger og bygge et nødvendig erfaringsgrunnlag for hovedprosjektet. Forprosjektet har gjort en rekke avklaringer ift prosjektets rammer og retning, og både avdekket og løst en rekke mindre problemer underveis. De viktigste erfaringene ift. løsningsarkitekturen er knyttet til den prefererte XML-databasen, dbXML, som viste seg å ha svært dårlig kvalitet. Vi går nå inn for å benytte Berkeley DB XML som XML-database i stedet. Dette er et trygt kort med mange gode referanser fra store løsninger. Videre er det verdt å nevne at søkemotoren Jakarta Lucene har seilt opp som en stadig mer sentral komponent i løsningen. Lucene var i utgangspunktet tenkt som en opsjon hvis fritekstsøket i dbXML viste seg å komme til kort. Utfordringer knyttet til fritekstsøk i Ibsens dansk-norske språk har vært utslagsgivende for valget av Lucene.

7.1 Funksjonaltet som er prototypet

Forprosjektet har prototypet HISe-løsningen ihht. opprinnelig plan, med noen mindre avvik grunnet omprioriteringer i løpet av prosjektperioden. Skissen viser den opprinnelige gjennomføringsplanen:

Analyse avXML-struktur og

emnekart-ontologi

Avklaring avkoblingspunkter

og ambisjonsnivå

SpesifikasjonXML-struktur og

emnekart-ontologi

Samkjøringav PSI-er

Prototype:Vise data fra

Kulturnetti HISe

Prototype:Vise datafra HISe iKulturnett

Utvilkings- ogbyggemiljø medenhetstesting

Installere XML-database og OKS(emnekartmotor)

Viktig innspill

til XML-strukturfor å sikre ytelse

Ontologi ogXML-hierarkiimplementert

Avdekke system-krav, overordnetsystemdesign

Overordnetsystemspek.

Viktige funksj.valg

Import av kjerne-dokumenter i

XML-databasen

”Lim” mellom OKSog XML-databasen

for auto. import

Prototype,auto. bygging avemnekart fra XML

"Mapping" forXML-import

definert i OKS

Prototype,søkemotor

(funksj./ytelse)

Dokumentasjonav designvalg

Iterativanalyse- og

designprosess

Erfaringerfra prototyperog tester sominnspill

Grunnlag forimplementasjonog prototyping

Prototype:Variantvisn.

m/tekst-vitnekart

Prototype:Visn. avederte

hov.tekster

Oppsett avtekn. rammeverk,presentasjonslag

VisningslogikkTEI-dokumenter(XSLT + CSS)

Utvidet prototypemed dynamiskinnholdsvisn

XML-hierarki

Prototype,Ibsen-krønike,registre, m.v.

Systemdesign Kulturnett PresentasjonslagTeknisk plattform

Datakonv. og -import

Prototype,søkegrensesnitt

11

44

22

33

40

Prosjektgruppen har valgt å prioritere grundigere undersøkelser av XML-databaser og analyse av problematikken forbundet med søk i Ibsens dansk-norske tekster. For å skape rom for dette ble følgende aktiviteter nedprioritert (punktene refererer til prosjektplanen på foregående side):

1. Automatisk utveksling av emnekartdata med Kulturnett.no. Se avsnitt 7.4 for detaljer. 2. Lim mellom XML-databasen og OKS for automatisk synkronisering. Se også avsnitt 4.2.1. 3. Ibsen-krønike. Ble prototypet til en viss grad, men det gjenstår avklaringer ift. hvordan

krøniken skal genereres – fra XML-data eller fra emnekartet. Når det gjelder automatisk import av XML-dokumenter i emnekartet er TEI-dokumentene for komplekse til at enkel "mapping" av elementer (pkt. 4) kan benyttes. Denne aktiviteten på prosjekt-planen ble derfor erstattet med en mer fleksibel, scriptbasert løsning. Se avsnitt 3.7 for fler detaljer.

7.2 Tilgang til prototypene

De tekniske prototypene er i skrivende stund tilgjengelige på Creunas demoserver: http://demo.creuna.no:1088/ibsen/

7.3 Komponenter som er testet i prototypene

Testing av løsningsarkitekturen har vært gjennomført ved vertikale prototyper, for å teste samspillet mellom komponenter i alle arkitekturlagene. Følgende komponenter og prinsipper er testet: Presentasjonslag:

• Sitemesh (visuelt malverk) • JSTL (presentasjonslogikk) • Displaytag (tabellpresentasjon av emnekartdata) • XSLT-konvertering vha. dbXML sine biblioteker (produksjon av HTML) • Spring MVC (presentasjonsrammeverk) • OKS Navigator Taglib ("Model 1"-arkitektur) – vanskelig vedlikehold og lite testbart, og vil

derfor ikke brukes i HISe-løsningen

Logikklag: • Spring-mapping av XML-database og OKS-ressurser (sikrer testbarhet og løs kobling) • ServletContextLoader-konfigurasjon av OKS (skiller forretningslogikk fra Tomcat og Java

J2EE-infrastruktur for å sikre testbarhet) • Delt, synkronisert emnekartcache mellom HISe-løsningen, Omnigator og Ontopoly via JNDI • Testoppsett for OKS med emnekart å fil som sikrer testbarhet uavhengig av databasen. • Kobling mot dbXML over XML-RPC (krever feilretting av dbXML sin kildekode) • Forretningslogikk for XSLT-transformasjoner med variable stilsett og parametre • Forretningslogikk for løst koblede oppslag mot av XML-dokumenter • Forretningslogikk for løst koblede oppslag mot OKS

Datalag: • dbXML • Berkeley DB XML • OKS (mot PostgreSQL og fil) • PostgreSQL

41

7.4 Samkjøring med Kulturnett

Det ble valgt å nedprioritere samkjøring med Kulturnett i forprosjektet for å fokusere på elementene som gir størst potensiale for risikoreduksjon i hovedprosjektet. Evt. samkjøring med Kulturnett i hovedprosjektet er planlagt gjennomført ved TMRAP1-kommunika-sjon mellom Kulturnett og HISe. Det ligger ferdig støtte for slik datautveksling i Ontopias OKS-plattform, som begge løsningene kjører på allerede. Fordi teknologien allerede er på plass vurderer vi risikoen for mislykket integrasjon som svært liten. Kritiske suksessfaktorene vil i stedet være god kommunikasjon mellom Kulturnett og HIS for tidlig avklaring av ambisjonsnivå, tydelig ansvarsdeling ift. eierskap og vedlikehold av de ulike emnene som utveksles, definering av felles PSI'er, m.v. For toveis visning av utvekslede data må det utvikles presentasjonsmaler i begge løsningene. Data-utveksling fordrer derfor mindre endringer også av Kulturnett.

7.5 Erfaringer med ulike XML-databaser

7.5.1 dbXML Vi startet forprosjektet med en klar preferanse for XML-databasen dbXML 2.0 fra dbXML Group. dbXML 2.0 er et ungt open source produkt, sluppet høsten 2004, og det er derfor begrenset erfaring med bruk av produktet i konkrete prosjekter. Mye tilsa likevel at dbXML var et godt valg:

• Funksjonsjonaliteten som dbXML tilbyr passer svært godt til behovene i HISe-løsningen.

• Prosjektet ble påbegynt allerede i 1999, og har vært sluppet i en rekke versjoner – kildekoden burde derfor være stabil og veltestet.

• Apache Xindice er bygget på den opprinnelige kildekoden til dbXML. Xindice er en av de mest populære open source XML-databasene.

• dbXML har fått mye positiv omtale på nettet, bl.a. på XML.com som indikerer at dbXML er et bedre valg enn Xindice.

Særlig er det følgende utlovde kvaliteter ved dbXML som ville gjort den spesielt velegnet til vår bruk:

• Innebygget fritekstsøk – kunne ha redusert kompleksiteten i løsningen betydelig ved å fjerne behovet for å integrere en tredjeparts søkemotor.

• Søk på tvers av kolleksjoner – ville gitt større frihet til å bygge opp dokumentkolleksjoner basert på dataenes den naturlige strukturen, uavhengig av HISe-løsningens tekniske behov.

• Intern XSL-prosessering – skulle etter sigende være i stand til å utføre transformasjoner med redusert minneforbruk fordi det ikke var nødvendig å laste hele dokumentet til minnet. Mange av dokumentene i HISe-løsningen er store, og løsningen må derfor planlegges spesielt ift. minneforbruk når mange dokumenter skal transformeres samtidig.

• Raske indekserte søk – skal bl.a. skille dbXML fra Xindice og eXist.

• Grafisk admingrensesnitt – for enkelt vedlikehold av XML-data også av HIS selv. 1 Topic Map Remote Access Protocol

42

Faktisk testing av dbXML viste imidlertid fort at produktet ikke kan holde hva det lover. Etter vår mening er dbXML langt fra produksjonsklar i foreliggende versjon. Manglende dokumentasjon og feil og mangler i produktet vanskeliggjorde testingen, og alle våre forespørsler om hjelp til dbXML Group og brukergruppene på nettet ble stående ubesvart. Det ble fort klart at miljøet som bruker og utvikler dbXML er for lite aktivt til å gi nødvendig brukerstøtte når problemer oppstår. Problemer vi har identifisert så langt omfatter bl.a.:

• Mangelfull dokumentasjon. • Feil i API'et, slik at deler av API'et ikke kan brukes. • API'et produserer ikke-validerbar XSLT-kode. Dette måtte vi selv utbedre i kildekoden. • Mangelfulle feilmeldinger – kaster exceptions uten beskrivelse av feilsituasjonen. • Ikke mulig å fritekstsøk til å fungere, og ikke mulig å få brukerstøtte. • Ikke mulig å gjøre søk på tvers av datakolleksjoner – begrenser fleksibiliteten i arkitekturen. • Noe ustabil drift, opplevd kræsj og heng med 100% CPU-forbruk. • Praktiske begrensninger på dokmentstørrelse – anbefalt maksimum 100kb. • Manglende support og produktoppfølging.

Det er særlig verdt å legge merke til at de to hovedargumentene for å ta i bruk dbXML bortfaller, fordi hverken fritekstsøk eller søk på tvers av kolleksjoner fungerer. Vi har nå to fungerende vertikale prototyper bygget på feilrettede versjoner av dbXML-kildekoden. Prototypene ser ut til å kjøre bra, men vi vurderer risikoen ved å basere HISe-løsningen på dbXML som høy, basert på erfaringene så langt.

7.5.2 Berkeley DB XML

I lys av erfaringene vi har gjort oss med dbXML var det naturlg å se på en annen XML-database som kan erstatte dbXML i den endelige løsningen. Det naturlige valget var da å kikke på Berkeley DB XML fra Sleepycat Software. Berkeley DB XML mangler fritekstsøk, intern XSL-prosessering og et grafisk admingrensesnitt, og er derfor å regne som en ren XML-database. Til gjengjeld bygger den på den allerede anerkjente open source databasen Berkeley DB. Vi mener at Berkeley DB XML utmerker seg blant open source databasene fordi:

• Berkeley DB XML bygger på databaseløsningen Berkeley DB. Denne databasen kjører i følge Sleepycat Software i mer en 200 millioner kopier rundt om i verden, takket være at Berkeley DB er i bruk i oprativsystemene Sun Solaris og Apple Mac OS X. Databasen er også i bruk hos store aktører som Google og Amazon. Vi mener at bruk av en veltestet database i bunnen på XML-databasen gir større datasikkerhet enn hva de andre open source alternativene kan tilby.

• Berkeley DB XML kjører som del av applikasjonen den tjener, ikke som en selvstendig server-prosess. Berkeley DB som ligger i bunnen er spesielt utformet for å kunne kjøre uten administrasjon. Dette er idéelt for HISe-applikasjonen, fordi databasen vil være usynlig i driftsmiljøet og ikke trenger spesielt ettersyn. Berkeley DB XML gir derfor et langt enklere driftsmiljø enn en løsnng med dbXML.

• Berkeley DB er kjent for å ha svært god ytelse. Berkeley DB XML har gjennom våre tester vist seg å være langt mer stabil og et mer modent produkt enn dbXML. Ytelsen er god og XQuery spørringer for uthenting av dokumenter har kortere responstid enn tilsvarende spørringer mot dbXML.

43

Et annet viktig moment i forbindelse med ytelse er at Berkeley DB XML er bedre skalert for større databaser og store XML-dokumenter enn dbXML. På dbXML opplevde vi tiltagende treghet ved innlegging av bare et fåtall dokumenter. Berkeley DB XML har kjørt smertefritt gjennomvåre tester. Størrelsesbegrensningen på dokumenter omgås ved introduksjon av et skille mellom såkalte dokument- og node-containere i Berkeley DB XML. Node-containere lagrer dokumenter oppdelt fysisk i noder på disk, og muliggjør ved dette lagring av tilnærmet ubegrenset store XML-dokumenter. For spørringer er denne oppdelingen transparent, og XML dokumentet hentes ut i sitt opprinnelige format med blank tegn og koding bevart. Dokument-containere lagrer dokumenter i sin helhet, og er godt egnet for små dokumenter eller dokumenter som alltid skal hentes ut i sin helhet ved enhver spørring. For HISe-løsningen gir node-containere mulighet til å lagre dramaer i XML-databasen uten oppdeling, uten nevnverdig tap av effektivitet ved kapitteldelt uthenting for visning i web-tjenesten. Dette gir større fleksibilitet ift. organisering av databasen, og kan potensielt spare oss for arbeid med oppdeling av dokumentene før import. I tillegg støtter Berkeley DB XML spørringer på tvers av innholds-kolleksjoner vha. XQuery. Dette regner vi også som et stort pluss. Administrasjon av og arbeid mot Berkeley DB XML gjøres fra kommandolinje eller programmatisk fra C++ eller Java. De programmatiske grensesnittene (API-ene) gir samme funksjonalitet som er tilgjengelig fra kommandolinje. API-ene dekker all funksjonalitet HISe-løsningen vil ha behov for. Manglende funksjonaltet for fritekstsøk i dbXML ser vi ikke alvorlig på. Forprosjektet har vist behov for bl.a. avansert ordstamming og håndtering av synonymord. For dette funksjonsområdet vil det i alle tilfelle være best å se på dedikerte løsninger for fritekstsøk.

7.5.3 Sammenlikningstabell

Egenskap / funksjon Støtte i dbXML Støtte i Berkeley DB XML Lagring av store XML-dokumenter

Nei, det anbefales å dele opp dokumenter som er større enn 100Kb.

Ja, håndteres transparent i databasen. Container-type bestemmer om om dokumentet lagres under ett eller deles i noder i XML-databasen. Databaser kan vokse til størrelser på inntil 256 TB (Terabytes)

Støtte for oppslag på tvers av kolleksjoner

Nei, XPath-spørringer og XSLT-queries (som gjør opp-slag på innhold først med XPath), kan bare gå mot én kolleksjon av gangen.

Ja, bruk av XQuery spørringer kan gå på tvers av containers og i tillegg aksessere eksterne XML kilder (via f.eks. URL).

Støtte for XPath-standarden

Ja Ja, Berkeley DB XML støtter XQuery standarden som bl.a. omfatter XPath 2.0

Støtte for oppdateringer av XML-dokumenter og -noder

Ja, benytter XML:DB XUpdate-spørringer

Ja, benytter eget API basert på XQuery for å gjøre endringer

Støtte for Metadata om XML-dokumentene

Nei Ja, lagres i container som ”data om XML data” – bra for data som ikke egner seg for lagring som elementer / attributter i selve XML dokumentene.

Støtte for indekserte oppslag mot XML-elementer

Ja Ja, også på tvers av kolleksjoner. Merkbart bedre ytelse enn i dbXML under våre tester.

44

Støtte for indeksert fritekstsøk

Visstnok, men fungerer ikke i våre tester til tross for feilsøk av API basert på øvrige brukeres erfaringer.

Nei, men det er mulig at dette er støttet på Berkeley DB nivå.

XSLT Transformasjon (internt v/XSLT Queries)

Ja, innebygd i API til tross for bugs i produktet som måtte rettes opp for å få det til å kjøre.

Nei, XML dokumenter og innhold hentes ut ved XQuery spørringer og XSL transformasjoner må utføres separat i J2EE applikasjon ved Xerces/Xalan.

Grafisk brukergrensesnitt (Admin-GUI)

Ja, men oppleves noe ustabilt og uferdig.

En 3. part produkt finnes som har plug-in for Berkeley DB XML, men testing av dette har kun belyst at dette også synes noe ustabilt i øyeblikket.

Databasemiljø Kjører som egen prosess og kan settes opp som service på server med kommunika-sjon over XML-RPC/REST-protokoll

Lever i samme prosess som Java J2EE-applikasjonen og. Har også shell aksess som kan koble seg mot databasen. Vil i vårt tilfelle bety forenklet drift.

Lagringsformat Fysiske filer på disk. Loggfiler og indekser på separate filer.

En fysisk fil på disk per opprettet container (containere inneholder XML innhold, indekser og metadata).

7.6 Erfaringer fra fritekstsøk i XML-dokumentene

Fritekstsøk er prototypet vha. Jakarta Lucene, og er testet med både norsk og dansk ordstamming. Prototypens viktigste hensikt er å bygge erfaring med de teknologiske mulighetene i Lucene hos HIS, som grunnlag for endelig kravspesifisering av HISe-løsningen. Her har det vært særlig viktig å demonstrere ordstamming og "upresist søk" i kontekst av Ibsens dansk-norske språk. Prototypen har også blitt brukt til test av ordstammere på dansk og norst, samt som konseptbevis ift. bruk av synnymord for å sikre bedre søketreff. En prototypen som er satt opp med norsk ordstamming er tilgjengelig fra Creunas demoserver: http://demo.creuna.no:1088/ibsen/search.html

7.6.1 Erfaring med bruk av synonymord

Synonymord kan tas i bruk med Jakarta Lucene på to måter:

• Synonymord legges i søkeindeksen Dette betyr at det legges flere termer i indeksen for hver enkelt tekst en det som faktisk forekommer i teksten. Med denne strategien må synonymene være kjent før indeksering, evt. må ny indeksering av alt materiale gjennomføres hver gang nye synonymer legges til.

• Synonymord legges til i søkekriteriet Her legges synonymordene til idet brukeren gjennomfører et søk. Synonymordene legges til ved å bruke Boolsk eller (OR) i søkekriteriet.

Ferdig indekserte synonymord vil ha noe bedre ytelse enn innlegging av synonymord i søkekriteriet, men dette ser ut til å være helt ubetydelig. Vi anbefaler derfor bruk av synonymord som legges inn i søkekriteriet. Dette gjør det enklere for HIS å legge til nye synonymord over tid, uten behov for å reindeksere alle tekstene.

45

Synonymord kan testes mot søkeprototypen ved å bruke parenteser i søkekriteriet. Lucene vil da legge Boolsk eller (OR) som operator mellom ordene som står i parentesen. Eksempelvis kan vi tenke oss at "moer" er definert som synonym for bokmålsordet "mor":

mor moer Søkekriteriet "hun er din mor" vil da skrives om til "hun er din (mor moer)." Tilsvarende gjelder for eksempelet vi brukte i avsnitt 6.4.1 om søk med synonymord. Der så vi på bruk av følgende synonymord:

urettferdighet uretfærd enn end noensinne nogensinde

Vi brukte følgende søkekriterie som eksempel:

tyranni og urettferdighet mer enn noensinne Etter omskriving er det følgende søk som faktisk vil gjennomføres:

tyranni og (urettferdighet uretfærd) mer (enn end) (noensinne nogensinde) For å redusere antallet synonymkoblinger det er behov for å vedlikehold bør synonymer defineres for ordstammene, ikke for hvert enkelt ord. I stedet for å definere tre synonymer for "urettferdighet," "urettferdigheten" og "urettferdighetene" defineres det altså bare ett synonym for "urettferd."

7.6.2 Ordstamming

For å kunne sammenligne norsk og dansk ordstamming i Lucene og velge den mest hensiktsmessige løsningen for Ibsens dansk-norske språkdrakt, har vi gjort tester med følgende passasjer fra Catilina:

Jeg må! Jeg må; så byder mig en stemme i sjælens dyb, – og jeg vil følge den. Kraft ejer jeg, og mod til noget bedre, til noget højere, end dette liv. En række kun af tøjlesløse glæder –! Nej, nej; de fyldestgør ej hjertets trang. Jeg sværmer vildt! Kun glemsel er min higen. Det er forbi! Mit liv har intet mål. (efter et ophold.) Hvad blev der vel af mine ungdomsdrømme? Som lette sommerskyer de forsvandt. Kun nag og skuffelse de lod tilbage; – hvert modigt håb har skæbnen røvet mig. (slår sig for panden.) Foragt dig selv! Foragt dig, Catilina! Du føler ædle kræfter i dit sind; –

Frygt ikke; – spejden er ej min bedrift; tilfældig kun jeg hørte eders tale. – Fra Allebrogerlandet kommer I? I Roma tror I retfærd er at finde? Vend om! Drag hjem! Her råder tyranni og uretfærd langt mer end nogensinde. En republik af navnet er det vel; og dog, hver borger er en bunden slave, forgældet, og afhængig som en træl af et senat – tilfals for gunst og gave. Forsvunden er den fordums samfunds-ånd, det frisind, Roma havde før i eje; – liv, sikkerhed, er af senatets hånd en nåde, som med guld man må opveje. Her gælder magtsprog, ej retfærdighed; den ædle står af vælden overskygget –

Vi har sett på hvilke ordstammer som fremkommer ved bruk av norsk og dansk ordstamming på disse sitetene som grunnlag for valg av den best egnede ordstammingsalgoritmen.

46

Testene viser at det bare er små forskjeller i algoritmene for norsk og dansk ordstamming. Den danske ordstammeren kjenner og fjerner flere av Ibsens ordendelser, bl. annet -te, -t, -ere, -mer, -igt, -get, -ighed, -ke, -hed, -felse og -me. Den danske ordstammeren kan mao. synes å ha en viss fordel over den norske når man ser på kilde-materialet isolert. Det er imidlertid et krav at samme ordstammer brukes på søkekriterier fra brukerne som på kildematerialet som indekseres. Hvis brukerne bruker bokmål i sine søkekriterier er dette et argument for å bruke den norske ordstammeren. Prototypen som er satt opp på Creunas demoserver benytter norsk ordstamming: http://demo.creuna.no:1088/ibsen/search.html Norske og danske ordstammer for testpassasjene fra Catilina

Tabellen viser forskjellene i ordstammene som genereres ved bruk av norsk og dansk ordstamming: Orginal Norsk Dansk af af af afhængig afhæng afhæng Allebrogerlandet

allebrogerland

allebrogerland

at at at bedre bedr bedr bedrift bedrift bedrift blev blev blev borger borg borg bunden bund bund byder byd byd Catilina catilin catilina de de de den den den der der der Det / det det det dette dett det dig dig dig dit dit dit dog dog dog Drag drag drag Du du du dyb dyb dyb eders eder eder efter eft eft ej ej ej eje eje eje ejer ejer ejer en en en end end end er er er et et et finde find find for for for Foragt foragt forag forbi forbi forbi fordums fordum fordum forgældet forgæld forgæld forsvandt forsvand forsvand Forsvunden forsvund forsvund Fra fra fra frisind frisind frisind Frygt frygt frygt fyldestgør fyldestgør fyldestgør føler føl føl følge følg følg før før før gave gav gav glemsel glemsel glemsel glæder glæd glæd

guld guld guld gunst gunst gunst gælder gæld gæld har har har havde havd havd Her her her higen hig hig hjem hjem hjem hjertets hjert hjert Hvad hvad hvad hver hver hver hvert hvert hvert højere højer høj hørte hørt hørt håb håb håb hånd hånd hånd I / i i i ikke ikk ikk intet int int Jeg / jeg jeg jeg kommer komm kom Kraft kraft kraft kræfter kræft kræft Kun / kun kun kun langt langt lang lette lett let liv liv liv lod lod lod magtsprog magtsprog magtsprog man man man med med med mer mer mer mig mig mig min min min mine min min Mit mit mit mod mod mod modigt modigt mod må må må mål mål mål nag nag nag navnet navn navn Nej / nej nej nej nogensinde nogensind nogensind noget nog nog nåde nåd nåd og og og om om om ophold ophold ophold opveje opvej opvej overskygget overskygg overskyg

panden pand pand republik republik republik retfærd retfærd retfærd retfærdighed retfærdigh

ed retfærd

Roma rom roma række rækk ræk røvet røv røv råder råd råd samfunds-ånd (1)

samfund samfund

samfunds-ånd (2)

ånd ånd

selv selv selv senat senat senat senatets senat senat sig sig sig sikkerhed sikkerhed sikker sind sind sind sjælens sjæl sjæl skuffelse skuff skuf skæbnen skæbn skæbn slave slav slav slår slår slår Som / som som som sommerskyer

sommersky

sommersky

spejden spejd spejd stemme stemm stem står står står sværmer sværm sværm så så så tale tal tal til til til tilbage tilbag tilbag tilfals tilfal tilfal tilfældig tilfæld tilfæld trang trang trang tror tror tror træl træl træl tyranni tyranni tyranni tøjlesløse tøjlesløs tøjlesløs ungdoms- drømme

ungdoms- drømm

ungdoms- drøm

uretfærd uretfærd uretfærd vel vel vel Vend vend vend vil vil vil vildt vild vild vælden væld væld ædle ædl ædl

47

7.7 Erfaringer fra dynamisk innholdsvisning

Evaluering av XML-databasen dbXML har gitt anledning til å vurdere hastigheten på transformasjon av XML-dokumenter. Vi har i hovedsak gjort tester med hovedteksten til Catilina, hvor vi bl.a. har målt tidsforbruket ved transformasjon ha. ulike XSLT-stilark.

7.7.1 Ytelse Tidsforbruket for en enkelt XSLT-transformasjon har ligget i området 2 til 7 sekunder, avhengig av stilark som benyttes. Dette er alt for mye, særlig med tanke på variantvisningen, som vil vise mange varianter av tekstene samtidig. Hvis vi tar utgangspunkt i visning av 4 tekster samtidig, gir dette genereringstid på 8 til 28 sekunder. Hvis vi samtidig regner med to eller flere samtidige brukere av HISe-løsningen, servi fort at dette ikke er holdbart. Tidsforbruket kan videre forventes å øke hvis man tar med behovet forå transformere og flette informasjon fra notetekstfilene inn i visningsversjonen av XML-dokumentene. Vi antar at noe av årsaken til tidkrevende transformasjon kan være knyttet til lite skalerbar eller ineffektiv mellomlagring av XSL stilark internt i dbXML sitt API. Vi fant såpass store mangler ved dbXML at det ikke er grunn til å tro at transformasjonslogikken er noe bedre. Problemene er dokumentert i mer detalj i avsnitt 7.5.1. Tiltak som langt på vei bør utbedre ytelsesproblemene omfatter:

• Overgang til annet verktøy for XSLT-transformasjoner, f.eks. Xalan • Oppdeling av XML-dokumentene, slik at bare et kapitel vises av gangen • Gjennomgang av XSLT-stilarkene for å gjøre dem mer effektive • Generere mer effektiv HTML-kode – koden er i dag svært verbos • Caching av alle genererte HTML-sider for å unngå gjentatt generering

Flaskehalsen ift. ytelse vil etter disse forandringene mest sannsynlig ikke være serveren, men linjekapasitet hos brukeren, evt. i driftsmiljøet hvis antall besøkende blir svært stor.

7.7.2 Kvaliteten på HTML-koden

Stilarkene som genererer HTML-kode fra XML-dokumentene synes å generere relativt verbose HTML-filer. I og med at det foreligger CSS-stilark for presentasjon av HTML-dokumentene, vil det være hensiktsmessig å ta en gjennomgang av XSLT stilarkene og foreta enkle inngrep som gjør at mindre HTML-kode genereres og CSS-stilarkene kan utnyttes bedre. Det er mye duplisert kode i HTML-filene som med fordel kan flyttes inn i CSS-stilarkene. Dette vil både kunne gi en raskere prosess ved XSL-transformasjon og HTML-koden som genereres for et gitt XML-dokument vil bli mindre i størrelse og derved kreve mindre båndbredde.

48

8 Anbefaling videre prioriteringer Etter at forprosjektet nå er avsluttet og dokumentert skal HIS gå videre med kravspesifisering av den endelige HISe-løsningen. Dette kapittelet anbefaler hvilke aktiviteter som bør prioriteres i det videre arbeidet, og samler også punktene fra forprosjektet som krever videre oppfølging fra HIS.

8.1 Kravspesifikasjon

Når det gjeldet kravspesifikasjonen bør HIS i første rekke søke å beslutte hvilken form denne skal ha. Vi vil anta at kravene bør prioriteres etter viktighetsgrad, slik at den endelige løsningen kan plan-legges og estimeres i form av opsjoner og tilvalgskomponenter som så det så kan velges mellom når størrelsen på budsjettmidlene blir kjent. Etter forprosjektet er det liten risiko forbundet med de teknologiske komponentene i arkitekturen. Vi vurderer nå at den største usikkerheten som gjenstår i prosjektet er endelig definering av hva HISe-løsningen skal inneholde. Det er bl.a. stor usikkerhet forbundet med den søkalte Metrikklab'ens omfang og innhold. For å tydeliggjøre omfanget av den totale HISe-løsningen anbefales det at man så tidlig som mulig setter igang arbeidet med interaksjonsdesign, slik at alle skjermbilder, navigasjonsveier, og all funksjonalitet er kjent. Dette omfatter også endelig spesifikasjon av søk. Det er vanlig å begynne et prosjektløp med interaksjonsdesign, og vi anbefaler sterkt at denne praksisen følges også for HISe-prosjektet.

8.2 Konkretisering av behovene for søk

Søk utgjør en stor og viktig del av HISe-løsningen, og det er derfor ønskelig at kravene til søk kan være så konkrete som mulig. Dette gjør det enklere å få opp et helheltlig kostnadsbilde. For å konkretisere behovene ift. søk kan HIS bl.a. prioriterer følgende aktiviteter:

• Evaluere søkeprototypen • Vurdere behovet for synonymord • Vurdere behovet for ordstamming på dansk/norsk • Vurdere behovet forpubliserte søketreff (synonymord gir treff på indeksert materiale,

publiserte søketreff kan styres uavhengig av teksten i ønsket søketreff) • Sette opp nøyaktig oversikt over hvilke data som skal være søkbare

8.3 Åpne for variable i hovedprosjektet

Enkelte valg ift. systemdesign og konseptuell utforming av HISe-løsningen må nødvendigvis skje i hovedprosjektet. Vi har allerede nevnt usikre faktorer som MetrikkLab'en, og løsningens interaksjons-design generelt, inklusive søk. Enkelte tekniske valg må også utsettes til de nødvendige forutsetningene for et informert valg er kjent. Dette gjelder bl.a. synkronisering av kjernekomponenter (se avsnitt 4.2.1), som i stor grad vil avhengig av hvilke data som skal indekseres for søk i Lucene, og krav til lagring av XML-dokumenter (se avsnitt 3.5.6), sett i sammenheng med behovet for entydige identifikatorer (se avsnitt 3.7.1). Prosjektet må planlegges med tanke på at disse beslutningene kan påvirke prosjektkostnadene.

49

8.4 Egne prosjektressurser

HIS må planlegge hovedprosjektet med tanke på egen ressursbruk. Forprosjektet har allerede avdekket en rekke aktiviteter som er avhengige av HIS, men det er grunn til å tro at disse bare er en liten del av totalen:

• 3.7.1: Identifikasjon av XML-filene • 3.7.2: Rettelser av ID-databasen (FileMaker) • 3.7.3: Rettelser av XML-materialet • 6.4.1: Tilrettelegging av synonymord

8.5 Kravområder

Mange kravområder gir seg selv på bakgrunn av forprosjektet. Andre igjen er detaljert i det opprinne-lige anbudsdokumentet fra HIS, og er ikke gjentatt her. Det er i alle tilfelle grunn til å tro at mange nye krav vil dukke opp når det konkrete arbeidet med kravspesifisering påbegynnes. Følgene kravområder er hentet fra forprosjektrapporten, med referanser tilbake til aktuelle kapitler: Kap. Beskrivelse - Krav til interaksjonsdesign, evt. prosessen med å utforme interaksjonsdesign - Krav til videreføring av arkitekturen som er definert 3.3.2 Krav til gjenbruk av etablerte PSI'er 3.3.3 Krav til publisering av PSI'er 3.4 Krav til import av kildemateriale i emnekartet 3.5 Krav til oppdeling av XML-dokumentene 4.2.2 Krav til evt. webpubliseringsløsning 4.3 Krav til driftsmiljø 5.1 Krav til grafisk design 6 Krav til søk (generelt) 6.3.1-2 Krav til avansert søkeskjermbilde 6.3.3 Krav til fasettert søk 6.4.1 Krav til støtte for synonymord ved søk 6.4.2 Krav til støtte for publiserte søketreff 6.4.3 Krav til støtte for ordstammeng ved søk 6.5 Krav til søk i webtekster 7.7.1 Krav til ytelse generelt eller caching (mellomlagring) spesielt ved visning av websider 7.7.2 Krav til forbedring av XSL-stilarkene og HTML-koden 7.4 Krav til Samkjøring med Kulturnett - Utforming av Ibsen-krøniken – generert fra importert XML, eller fra emnekartet - Krav til statistikk som grunnlag for forbedring av søk, innhold og navigasjon i tjenesten:

besøksstatistikk, statistikk over søkefraser, statistikk over eksterne søkemotorreferanser

50

9 Vedlegg 1: Statistikk fra søkemotorindeksen Her ligger statistikk over de hyppigst brukte termene hos Ibsen. Statistikken er basert på fritekst-indeksering av følgende kilder:

• Brand førstetrykk: Front, body (delt i 5 akter) • Catilina hovedtekst: Front, body (delt i 3 akter), back • Bryllupssang (dikt): Text • Brev B18720108FH: Text • Brev B18720112ChrTh: Text • Brev B18720119FH: Text • Brev B18720207FH: Text

Totalt er det 16 XML-filer som er indeksert opp som datagrunnlag. Lucene teller termene én gang pr. fil de forekommer i, så maks antall forekomster i statistikken er 16. Av statistikken fremgår det at ordene "en", "i" og "og" er mest brukt, og forekommer i alle de 16 tekstene som er indeksert. Merk at statistikken refererer til søkemotortermer, dvs. unike ordstammer. F.eks. vil både "kvinde" og "kvinder" indekseres som termen "kvind." Det er også viktig å være klar over at ulike ord i enkelte tilfeller vil indekseres med samme term pga. ordstammingen. Dette gjelder bl.a. "far" og "fare." Se avsnitt 0 om ordstamming i Lucene for mer utfyllende informasjon. Vedlagt liste dekker bare de mest populære termene. Fullstendig oversikt over statistikken er tilgjengelig som et separat Excel-regneark. Statistikken kan brukes til å identifisere potensielle kandidater for synonymord. Hyppig brukte ord som skiller seg i stavemåte fra bokmål vil være typiske kandidater. Eksempler fra listen kan være ordene "mig" (meg) og "vor" (vår). Generelt gjelder det likevel at overvåking av brukernes søkekriterier gir de beste indikasjonene på hvilke synonymord det kan være behov for. Ant. Term 16 16 16 15 15 14 14 14 14 14 14 14 13 13 13 13 13 13 13 13 13 12 12 12 12 12 12 12 12

en i og af den at de det for har med ved and da der dett er et ikk om som dem denn fra jeg mig tid und vil

12 12 11 11 11 11 11 11 11 11 11 11 11 11 11 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

vor vær grund han hjert ing kan men min mit mod sig skuld stor til alt att dag eft ell end endnu fald find først her herr hjemm hold hvad

10 10 10 10 10 10 10 10 10 10 10 10 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9

hvilk ind int kun kvind lad lev røst sind søn tænk var al all andr bland derfor diss dog engang fordi følg giv glæd ham hjem hun hvis hvor hænd

9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 8 8

hør jer kjend komm kund lig ligg lys man mer midt mind maa navn nog nok ord paa sid sidst skal snart svar syn ung ven vis aand aldr bedst

51

8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8

bliv bort bryst dal del did dig din dit drag drømm du død eder ene far fast fatt flugt fod folk forbi frem færd før gaml gammel gang gjennem glemt god godt grav gud gaa havd hel hen hend himl hist hjælp hos hul hver hvert hvorfor hørt haand ifr igj ild ja jo jord klar kom led lett lid liv lyd lægg læng magt mang mellem maatt natt ned nu nye nær naar o os over pand rett rig

8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7

rund sag sagt saml samm sand selv sin sit sjæl skjønt skrækk sligt sorg stands strand stund sætt saa tag tal tank to tung ud uden varm vel vent vi vild vred væk aar alting aner arm bag barm bedr begg bleg blev blot bo bryd brænd brød byd bær dyb dør eget fand fler frels frygt gav gjæld gjør glad halv handling hav hell himmel hus hvi hvo haab imod just kald kamp kast kjæmp knus krig land lang

7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6

langt lidt lill lov lykk lyn lyst længst lær løs mand meg mød mørk maal nærm nævn nød ogsa omkring rækk raab savn ser sidd skabt skar skjænk slægt smil sol sort spørg stand steds stemm still stod storm stort størr søg takk talt ton tre tro træd trækk træng trætt tusind tykk tænkt tør vend vid vidt vill vist vold vord vort væld vælg 2 afsted agn ak alen altid angst ban bar bed bemærk billed bind blind blod

6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6

bog brand bring brug bud bund baad derind daad egen elsk evig evn fik flokk flygt foer fred frist fulgt fyld gansk gerd gik glød grib gys hed helt henrik hid hin hoved husk hvem haard ibs idag idet igjennem iler jag kjær kjærlighed kold kort kraft krav kræft lagt leg lukk lytt lød løft laa mennesk mild muld mægt mænd nys nyt nægt peg pligt prest r rapp rejs rest rim riv rædd raad sagd sang se send skikk

52

6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

skill skimt skin skjæbn skjønn skrev skrig skriv skygg skyld slag slig slipp slog slukk slaa spor spredt stav sted stig strid strømm stærk staa tabt tegn thi tim tind tog trang tredj tror tætt varmt vej verd vig vind virk visst vov værd værk værn 10 agt altfor alvor baggrund barn bered betragt blir bod bord bratt bred bredd brev brist bygg byggd bytt bød bøn børn baand dans dern driv drog drøm dyr dæmp dømm ei ej enhv

5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

evigt fad faer farv farvel favn fejl fjeld fjern fjord flamm flok fogd forfærd forlad fort fortabt forud fremm fri frisk fuld fædr fæld fæst født føl ført faar gjort gjæst glemm godtfolk greb gru græd graa graad gaar ha had handl hegel held herfr hils hverv hvil hæng hæv højd højt ibland ifald ikkun imellem indr kind kirk klyng kløgt knappt knytt knæl kong kræv lamp list lod lokk luft ly læs løv mangl mangt matt mildhed mindr mindst

5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

moer mon muligt mund mængd mødt maan naturligvis nej nogl nytt næst naa naad off offr opp pass på ras rev rind ro rod rom rull rung rygg ryst rør rørt røv sad sal satt sejr skjul skjær skjøn skridt sky skynd slapp slett slug slør slaar smert smaa snar sot sov spil spring stillt stirr stiv stolt strax streng stryg strækk straal stygg stykk stængt stærkt stævn staaer staar sund svag svigt synk sæd sænk saadan tab tepp ti

5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

till ting tomm trygg tryggt trøst tungt tvivl tyng tænd taag taar ude udenfor udov uro vakt vand vandr ve veg vejr venn venstr vest vidd vilj ving vink vox værr vaab vaagn yrk øje øjn ønsk aabn act ad afbryd ald altsa anderl ang ansigt arv aureli av bagom bank bedrag behøv betænk bitter blad blank bli blæs blød boer bragt brast bræen byggt byrd bøj bølg bør baar catilin curius derpa digt dobbelt dom domm dreng dresd drev

53

4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

drikk dugg dølg dømt døs døv é egn ejes ejn elv endt enest ere falk fiend fir flag flest flyv foged fold foran forblind fordum forgjæv formeg formod forsta forstyrr fortalt fortid fortvivl foss fremmed fremtid frihed frugt fryd fugl furi førend faa gad gal gavn gjern gjerning glemsel glimt grønn gudern gulv gut hal hall hamr hast hatt hej hent herind hm hod hu hug hugg hurtigt hustru hvid hvordan hvorh hvormed hvælv hævn høj haar id ide ihug

4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

ilsomt imorg indtill kant karl kjærn kjød klag kling knug knust kran kunn kunst kveld kaar lag lensmand lentulus ler lettvind leved lign ligt lydt læg lænk løb løn lønn marg mark morgenrød mur myldr myr mærk møj n nedov netopp nord ny nærmer nøl oppov orm overrask par plad plan plett post provst prøv pust pøl rag red redd regn reis rejst ren rent ret revn rol rumm rygt rød røg s sadl sandhed see seng sikker skab skad

4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

skatt skjød skov skreg skræmm skuldr skyen skaal slang slidt slutt sløv smukt smul smaat spar spild spir stad statilius sten stillhed storhed straff strøg stuen stundom styggt styrk styrt stød størst støtt støv staaend staal sum sveg svundn svælg sværm syg synd saadant saar tarv taus tier tifold tigg tilbag tillbag tillsidst tolk tordn trod turd tvætt ungdom urd usl usling valg vidn vidst viet vogt vorherr vrag væd vægt vækk værst vaad vaag vaar ædelt øjeblik øst aa

3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

6 7 8 9 11 12 27 75 1872 adam afgrund afgud afkom akt aldel alf allersidst alternativ ambiorix an aned anledning arving ask bad bakk begrav begynd behov benytt berg beslutt besvær betal beving bevæg blidt blik blikk blink blund blus bluss blæst blaa bogtrykkeri bond borg brat bro brog brudt bønn cethegus coeparius datt dengang deraf derbort derom deropp dersom derud distrikt dobbel doktor drist drukn drøft drømt duft dulgt dunkl dverg dvæl dybt dybtfølt dynd dyrk dyrt

54