Indholdsfortegnelse 1 Indledning og problemfelt... 4 1.1 Problemfelt... 4 1.1.1 Problemformulering... 7 2 Metode... 8 2.1 Motivation... 8 2.2 Begrebsafklaring... 8 2.3 Valg af teori...10 2.4 Empiri...11 2.4.1 Prototypen...11 2.4.2 Polinfo-databasen...11 2.4.3 Målgruppe for Polinfo og prototypen...13 2.5 Sammenhæng mellem teori og empiri...14 2.6 Projektets videre opbygning...14 3 Det teoretiske grundlag...16 3.1 Information Retrival som felt...16 3.2 Indeksering...18 3.2.1 Metadata...19 3.2.2 Automatisk indeksering...19 3.2.3 Normalisering...21 3.2.4 Databasen er afgørende...22 3.3 Termvægt...23 3.3.1 Om termvægt generelt og fuldtekstsøgning...23 3.3.2 Vægtning og binær termvægt...24 3.3.3 Termvægt i Polinfo-databasen...26 3.3.4 Termfrekvensen...26 3.3.5 Inverse Document Frequency...27 3.3.6 Manuelt tildelt termvægt vigtighedsvægten...28 3.4 Vector space-modellen...32 3.4.1 Boolean Logic modellen...32 3.4.2 Vector space-modellen...33 4 Udvikling af prototypen...40 Side 1 af 92 sider
4.1 Beskrivelse af databasen...40 4.1.1 Den illustratitve opbygning af databasen...40 4.1.2 Den fysiske opbygning af databasen...41 4.2 Design og forklaring af Javadelen af prototypen...51 4.2.1 Brugergrænsefladen...55 5 Analyse...57 5.1 Indeksering...57 5.1.1 Opdatering af indekset...60 5.1.2 Normalisering...61 5.2 Termvægt...66 5.2.1 Vigtighedsvægten...66 5.2.2 Et eksempel på estimering af vigtighedsvægten...67 5.2.3 Termfrekvensen...71 5.2.4 Inverse document frequency-værdien...74 5.3 Vector space modellen...77 5.3.1 Eksempelgennemgang af IP-udregning...80 5.3.2 Eksempelgennemgang af CC-udregning...82 5.3.3 Diskussion af resultaterne fra eksempelgennemgangen...82 6 Afsluttende diskussion...82 7 Perspektivering...82 Litteratur...82 Side 2 af 92 sider
Bilagsliste Bilag 1: De to funktioner i databasen: Normalize og Split_string. Bilag 2: Den samlede Javakode Bilag 3: Stopordsliste Bilag 4: Artiklen Regeringen renser sig selv i Afghanistan-krig Bilag 5: Artiklen En Tolkien Light Side 3 af 92 sider
1 Indledning og problemfelt Søgning efter information er i dag ofte forbundet med en eller anden form for elektronisk søgning. Førhen var det mere almindeligt at benytte bibliografier eller andre fastformsdokumenter. Det var også tit nødvendigt at henvende sig til andre personer, der havde speciale i at finde viden, idet meget viden ikke var tilgængelig. Det har ændret sig i dag, da vi har mulighed for at benytte internettet, som giver mulighed for ubegrænset adgang til næsten alle former for viden. Problemet er dog, at den tilgængelige viden har vokset sig så stor, at den er svær at få overblik over. Derfor er der udviklet søgemaskiner, som for eksempel Google 1, ms. Dewey 2 og andre, der sørger for at hjælpe brugeren med at få opfyldt deres informationsbehov ved at lagre, repræsentere og formidle viden på en overskuelig måde. Søgemaskiner er blevet til redskaber, man bruger næsten hver dag. Man kan definere en søgemaskine som værende et it-system, som består af en mængde viden, der er lagret med det hovedformål at kunne genfinde det på et senere tidspunkt. Det er en måde at fange viden på, men det, der lagres i it-systemet, er en repræsentation eller en kopi af den rigtige viden. Repræsentationen kan behandles, lagres og formidles på mange måder, alt efter hvilken form for viden der er tale om. 1.1 Problemfelt Information retrieval (IR) omhandler hele processen fra, at en bruger indtaster et ønske om information, og systemet herefter fremviser informationen for brugeren. Optimalt set ville brugeren i dette tilfælde få den information ud, hun søgte, og IR-processen ville være slut. Dette er dog langt fra så simpelt, og der er gennem årene udviklet en masse teorier om, hvordan IR kan forbedres, både set ud fra brugeren og fra systemet. IR-systemer er udviklet, fordi en bruger har et informationsbehov. Dette system forsøger at oplyse brugeren om, hvor hun kan få mere viden om sit emne, som C. J. Van Riijsbergen skriver: An information retrieval system does not inform (i.e. change the knowledge of) the user on the subject of his inquiry. It merely informs on the existence (or non-existence) and 1 http://www.google.dk/ 2 http://www.msdewey.com/ Side 4 af 92 sider
whereabouts of documents relating to his request (Rijsbergen, 1979) For at kunne give brugeren, hvad hun søger, er der udviklet forskellige metoder til at optimere IR-systemer. Disse optimeringer omhandler alle dele af søgeprocessen en proces, som følgende figur illustrerer: Figur 1.1: Figuren viser den holistiske proces, der sker, når en bruger har et informationsbehov, og spørger et IR-system om hjælp til at finde informationen. (Figuren er inspireret af Berry & Browne 1999: 66) Første skridt (fase 1 i figur 1.1) i IR-systemet er brugerens indtastning af sit informationsbehov. Brugeren har ofte kun en vag idé om, hvilket spørgsmål hun ønsker besvaret, og denne idé skal hun oveni købet forsøge at indtaste med få ord i et søgefelt. En del af IR-teorien omhandler denne indtastning af informationsbehovet hvordan kan systemet gøre indtastningen lettere for brugeren, eller hvordan kan systemet hjælpe brugeren videre, hvis denne går i stå og ikke ved, hvordan informationsbehovet skal omformuleres til få ord eller en sætning. I næste fase (fase 2 i figur 1.1) skal systemet oversætte brugerens indtastning, så det kan søge i dokumentsamlingen efter den ønskede viden. Det betyder, at systemet skal kunne behandle det indtastede på en bestemt måde hvilken måde afhænger især af, hvordan brugeren har haft mulighed for at indtaste sin Side 5 af 92 sider
forespøgsel. Et eksempel er noget, som mange søgemaskiner kan i dag, nemlig behandle ord i gåseøjne på en bestemt måde. Andre søgemaskiner giver mulighed for at indtaste naturligt sprog, det kan være et spørgsmål eller en hel sætning, eksempelvis jeg vil gerne vide, hvor høj temperaturen er i Barcelona i næste uge, og det er så op til IR-systemet at kunne søge på denne sætning ved at pille nøgleord ud af sætningen og søge på dem ( Barcelona, temperatur osv.). Uanset hvad søgemaskinen giver mulighed for, skal den kunne behandle brugerens indtastning på en måde, der giver mulighed for en optimal søgning i søgemaskinens dokumenter. Det er denne søgning, der befinder sig i tredje fase i figur 1.1. Vi befinder os stadig på systemets side af søgeprocessen, og efter systemet har forberedt brugerens forespørgsel, skal svaret findes blandt alle de dokumenter, der er tilknyttet søgemaskinen ofte i en database indeholdende alle dokumenterne. Typen af dokumenter kan være alt lige fra korte tekster, lange tekster, billeder, lyd eller en kombination af det hele, som det for eksempel typisk ses på hjemmesider. Denne tredje fase er selve søgningen af dokumenter, og IRsystemet skal gerne hurtigt og præcist kunne finde de dokumenter, der passer på den gennembehandlede brugerforespørgsel og sende dem retur til brugeren. Det er her indeksering af databasen skal behandles som en væsentlig del af optimeringen af søgemaskinens hastighed og brugbarhed. Indeksering kan foregå på flere måder en af måderne er ved at indeksere efter ord (termer) og vægtning af disse. Sidste, men absolut ikke mindste fase, er fjerde fase. I fjerde fase evalueres de fundne dokumenter ud fra en forståelse af relevans hvilke dokumenter systemet tror, der er relevante for brugeren og resultaterne rangeres ud fra denne relevans, før de vises. Relevansen kan udregnes ud fra forskellige faktorer, for eksempel kan dokumenterne i databasen være vægtet forskelligt og dermed være mere eller mindre vigtige. I fjerde fase bliver dokumenterne sammenlignet med brugerns indtastning, og dokumenterne listes op i den rækkefølge, systemet har udregnet som den bedste for indtastningen af brugerforespørgslen. Der er udviklet mange modeller til at udregne den bedste metode, hvorpå man kan sammenligne en brugerforespørgsel og et dokument i databasen. Hvis systemet giver mulighed for videre søgning, kan brugeren starte processen forfra ud fra de resultater, hun vurderer passer bedst på hendes forespørgsel til søgemaskinen. De fire processer har ofte været behandlet hver for sig, men i 1990 erne opstod for alvor den holistiske tankegang om, at faserne ikke skulle ses adskilt, men derimod var det helheden i søgeprocessen, der skulle Side 6 af 92 sider
inddrages (Ingwersen & Järvelin, 2005). Skal IR-systemets hurtighed for eksempel vælges frem for grundigheden? Eller skal nemheden for brugeren vægtes mere end systemets effektivitet? Disse valg bliver systemudvikleren af det enkelte IR-system nødt til at forholde sig til i opbygningen af systemet. Målet med denne opgave er at afdække, hvordan denne proces foregår i en søgemaskine. Med fokus på de valg, der skal træffes i forbindelse med fase 2, 3 og 4, vil vi forsøge at klarlægge mulige optimeringer af søgningen i vores udvalgte database, blandt andet ved at opbygge en prototype for at afprøve de teorier, vi finder frem til undervejs i diskussionen og forklaringen af teorien bag. Den type information, vi beskæftiger os med i denne opgave, er nyhedsartikler fra Politikens artikeldatabase, Polinfo (nu InfoMedia) 3. Det stiller også krav til håndtering og brug af den specifikke database, blandt andet hvordan Polinfo er opbygget, og hvordan vi vil bruge denne opbygning i vores prototype. 1.1.1 Problemformulering Med udgangspunkt i de ovenfor beskrevne forestillinger om et IR-system vælger vi i denne opgave at fokusere på, hvordan man kan optimere en søgemaskine ud fra teorier om fase 2, 3 og 4, det vil sige, hvordan et informationsbehov kan forberedes til en søgning i en database; hvordan en database kan forberedes til denne søgning, herunder indeksering; samt behandling af søgeresultaterne, herunder vurdering relevans og rangering af resultaterne. Vi vil altså undersøge, hvordan en søgemaskine kan optimeres bagved brugergrænsefladen, således at systemet selv udregner en intelligent rækkefølge af søgeresultaterne ud fra opsatte og udvalgte kriterier, hvilket leder frem til følgende problemformulering: - Hvordan kan en søgemaskine optimeres mest muligt, så systemet finder de relevante dokumenter og rangerer dem efter relevans? Med tilhørende arbejdsspørgsmål: - Hvordan afgøres det, hvilke dokumenter der er mere relevante end andre? - Hvordan implementerer man vægtning af termer som en del af indeksering af fuldtekstdokumenter? - Hvordan kan databasen struktureres, så en søgning fungerer bedre? - Hvordan kan en søgeforespørgsel behandles, så en søgning fungerer bedre? - Hvordan kan man bedst muligt rangere søgeresultaterne? 3 http://www.infomedia.dk Side 7 af 92 sider
2 Metode I dette kapitel vælger vi at gå videre med figur 1.1, som vi præsenterede under problemfeltet. Vi har dog valgt, at brugerens indtastning af sit ønske i fase 1 kun vil blive overfladisk berørt, når dette er oplagt eller nødvendigt. Vi starter med at gennemgå vores motivation for at skrive dette projekt. Herefter præsenterer vi den valgte teori, og hvorledes vi har programmeret og designet vores prototype. Det gøres med et eksempel på en kort brugergennemgang, og hvilke programmeringsredskaber vi har benyttet. Vi gennemgår brugen af centrale begreber i dette projekt i begrebsafklaringsafsnittet. Vi afslutter metodeafsnittet med at anskueliggøre vores datagrundlag, både hvordan den oprindelige information var struktureret, men også hvilken information vi har valgt at benytte i vores prototype. 2.1 Motivation Dette projekt er skrevet af de studerende Anne Rosenstand Hansen og Marie Højlt på 2. modul på Datalogi i efteråret 2006. Marie læser Journalistik, Geografi og Datalogi. Anne læser Kommunikation og Datalogi. Vores programmeringsmæssige udgangspunkter for projektet er følgende: Marie har kendskab og erfaring med Java fra tre kurser på Datalogi: Indledende programmering, Begreber og redskaber i programmering, Interaktive systemer og projektledelse og tager sideløbende kurset Objektorienteret programmering. Hun har databaseerfaring fra kurset Database samt har benyttet SQL i MySQL fra projektet på 1. modul. Anne har kendskab til Java fra hendes 1. modulsprojekt, hvor hun var med til at udvikle en database med tilhørende web-brugergrænseflade, og herfra har hun også indledende kendskab og erfaring med SQL. Hun tager sideløbende Database-kurset og har gennemført kurserne Indledende programmering, Begreber og redskaber i programmering samt Interaktive systemer og projektledelse. 2.2 Begrebsafklaring I løbet af denne opgave benytter vi en del faglige begreber. Enkelte vil vi definere på forhånd, andre bliver defineret, når vi gør brug af dem. Da vores data er af journalistisk art, forekommer der nogle begreber i projektet, som kan tænkes ikke at være selvsagte, så derfor har vi listet dem nedenunder: Side 8 af 92 sider
Rubrik overskriften i en artikel. Manchet den del, der normalt står med fed eller kursiv i begyndelsen i artiklen. Brødtekst selve teksten i artiklen. For yderligere afdækning af disse begreber, henviser vi til afsnit 3.3, hvor vi uddyber de journalistiske elementer i vores data. Vores database indeholder data, som indenfor informationsvidenskaben og datalogien betyder en repræsentation af information, for vores vedkommende fuldtekst. Data er information, der er udformet på en måde, så det kan behandles af en computer. Definition af begrebet metadata også nævnt som metainformation i løbet af projektet. Det er en form for beskrivelse af artiklen eller data, der beskriver andre data, i vores tilfælde er det termer, der manuelt er tildelt de enkelte artikler. Som eksempel kan vi nævne emneordene. Vi har valgt at benytte Baeza- Yates definition af begrebet fuldtekst, som er, at alle de termer, der forekommer i artiklerne, skal gøres søgbare. Et hyppigt forekommende ord i denne opgave er begrebet term. En term bliver forstået i IR-sammenhænge som et enkelt ord eller en frase i den samling af dokumenter, man har med at gøre. For vores vedkommende drejer det sig hovedsageligt om termer i vores artikelsamling fra Polinfo. Man kan yderligere inddele termerne i to overordnede grupper funktionsord og indholdsord. Funktionsord er artikler (kendeord), pronominer (stedord), konjunktioner (bindeord), præpositioner (forholdsord), hjælpeverber (hjælpeudsagnsord) og interjektioner (udråb) altså ord som har en funktion i sproget. Indholdsord er substantiver (navneord), verber (udsagnsord), adjektiver (tillægsord) og adverbier (biord) ord der bruges til at beskrive indhold i tekster. Funktionsord er ikke gode til at beskrive en tekst, og derfor er de ofte adskilt fra de andre termer på en liste, der kaldes en stopordsliste, da de er hyppigt forekommende ord, og derfor har en inferiør søgeværdi, fordi de tjener et syntaktisk formål i forhold til indholdsordene, som er mere beskrivende (Salton, 1989). Indeksering er et begreb som i teoretisk sammenhænge ofte ikke bliver defineret og har derfor været en svær størrelse at arbejde med. Vores definition af indeksering er en måde, hvorpå man opbevarer en form for referencer til sine data i databasen, så det er muligt at finde denne data hurtigere via referencerne. Når vi taler om termvægt, er det kort sagt en vægt, der gives til hver term i et dokument. Hver term får tildelt en Side 9 af 92 sider
en værdi, der reflekterer den formåede vigtighed set i forhold til at identificere indholdet i dokumentet (Salton & McGill 1983:59). De søgeresultater, som vores prototype kommer frem til, skal gennemgå en form for vurdering. Det er naturligt derfor at involvere et relevansbegreb. Vi har valgt at inddrage C.J. Rijsbergens definition af relevans, som er målet eller graden af overensstemmelse mellem et dokument og en søgeforespørgsel (Ingwersen, 1992: 54). Vi vælger at benytte begrebet relevans i forbindelse med systemets måde at forholde sig til relevans på. Selvom det ikke er inde for dette projekts rammer at vurdere, hvad der ligger bag en brugerorienteret tilgang til denne definition, vil vi alligevel inddrage enkelte subjektive vurderinger (ud fra os selv), når vi finder det nødvendigt. Et eksempel på vores måde at benytte relevans på kan ses i vores brug af graden af similaritet mellem en forespørgsel og en artikel i databasen, der evaluerer hvorvidt disse er relevante i forhold til hinanden (se mere i kapitel 3.4). 2.3 Valg af teori Teoriafsnittet tager sit udgangspunkt i en indledning generelt om IR. Vi redegør her for udvalgte tanker bag IR, inden vi begynder på et afsnit om indekseringsmetoder. Denne indeksering bruger vægtning af termer som indekseringsmetode, hvorfor vores teorikapitel naturligt springer til teorien bag termvægt, og hvordan denne vægt kan udregnes og bruges. Vi har i termvægtafsnittet hovedsageligt benyttet tre vægte; inverse document frequency (idf), som er en vægt, der bliver udregnet på baggrund af alle dokumenter i databasen; term frequency (tf), som udregnes på baggrund af det enkelte dokument, termen befinder sig i; samt vigtighedsvægten, som bliver bestemt ud fra faktorer i polinfodatabasen. Efter diskussion af indeksering og termvægt, som drejer sig om at optimere opbygningen og indekseringen af en database, behandler vi teorien bag evalueringen af de resultater, vi modtager efter søgningen i databasen. Her inddrager vi en model ved navn vector space-modellen, samt en kort beskrivelse af den boolske model, da den sidstnævnte er en god kontrast til vector space-modellen. Disse to modeller sørger begge for at finde information i databasen, der forhåbentlig er den relevante information for brugeren, ud fra en indtastet forespørgsel. Denne genfindingsproces har de hver deres metoder til, hvilket også er en del af model-afsnittet. Side 10 af 92 sider
2.4 Empiri Vi har valgt at udarbejde en prototype som en del af vores empiri, da vi med denne selv kan afprøve vores teser og diskussioner gennem udviklingen af projektet. Som testgrundlag bruger vi Politikens artikeldatabase, Polinfo. 2.4.1 Prototypen Vores prototype er udviklet med det formål at eksemplificere forskellige aspekter af funktionaliteten bag en søgemaskine. Normalt vil en prototype indgå som en del af en pakkeløsning omkring analyse og udvikling af et større system, og prototypens opgave kan tænkes at være med til at sælge systemet og gøre ideer omkring design og funktionalitet mere spiselige for køberen. I denne opgave har vi ikke en fastlagt målgruppe, som vi udvikler til, og hvis det havde været tilfældet, så ville det formodentlig have medført, at vores udvikling af resultat havde set anderledes ud. Prototyper er som regel forenklinger af det egentlige system, hvor der ikke forekommer den store funktionalitet bagved brugergrænsefladen (Beynon-Davies 1999). Det er dog ikke tilfældet med vores prototype, hvor det modsatte faktisk gør sig gældende. Vi har valgt at implementere en brugergrænseflade til vores søgemaskine for at gøre søgeresultaterne mere overskuelige, da vi foretager rigtige søgninger som testbrugere. Da prototypen langt fra er færdigprogrammeret, er der en del fejl og mangler, som vi har valgt at nedprioritere at finde en løsning på. Der er specielt en del mangler i brugergrænsefladen, for eksempel at artiklen listes dobbelt, hvis man klikker på en rubrik i søgelisten to gange (og videre derfra, den listes tre gange ved tre klik osv.). Vi har heller ikke gennemtjekket prototypen for fejl, hvorved der kan forekomme uopdagede fejl rundt omkring. Heller ikke dette har vi opprioriteret, da vores behov er dækket med den nuværende søgemaskine. Af redskaber i vores udvikling af prototypen har vi benyttet programmerne Netbeans IDE 5.0, JDK Java 1.5.0_09. Til udvikling af databasen har vi benyttet Oracle SQL Developer version 1.0.0.15. Java Platform version 1.5.0_05. 2.4.2 Polinfo-databasen Vores database er, som nævnt i problemfeltet, et uddrag fra Politikens store artikeldatabase, Polinfo. Artiklerne er fra 1990 erne og ældre, og er derfor ikke aktuelle i dag, men det har ingen relevans for vores Side 11 af 92 sider
projekt. Artiklerne er gemt i databasen efter en struktur af såkaldte tags (attributten TID i nedenstående figur) et mærke som definerer, hvilken del af artiklen, vi har med at gøre. Tag ene er altså nogle koder tilknyttet hver række i databasen, som illustrerer, om denne række er eksempelvis en overskrift, et emne, et geografisk sted, et personnavn, en virksomhed eller det, der må formodes at være koder, der bruges i Polinfos arkiverings- og filsystem, for eksempel et Polinfonummer eller en fondbørskode. Der findes mere end 50 forskellige koder, og langt de fleste af dem er ikke relevante for vores projekt. Derudover er der koder, som kan illustreres ved hjælp af andre koder, fordi prototypen kun beskæftiger sig med udvalgte dele af databasen. Et eksempel på dette er, at vi har valgt at medtage koden emne for at kunne inddrage noget metadata, der beskriver artiklen i vores analyse. Her kunne vi også have valgt at medtage geografi eller personnavne, men vi mener, emne illustrerer denne brug af metadata udmærket i en prototype som vores, og derfor vil andet metadata blot være overflødig information i vores brug af Polinfo. Figur 2.4.1 Udsnit af vores oprindelige Polinfo data. Den nedenstående tabel viser de tags, som vi har valgt at benytte i vores prototype. Vi medtager en beskrivelse af de forskellige tags, for nemheds skyld: Side 12 af 92 sider
Tag Navn Beskrivelse RUBR: Rubrikken Overskriften på artiklen MANC: Manchetten Det første del af artiklen, der som regel står med fed skrift eller er kursiveret STAR: START Første del af brødteksten i artiklen SLUT: SLUT Anden del af brødteksten i artiklen EMNE: Emneord De tilknyttede emneord Tabel 2.2 Oversigt over de udvalgte tags, vi har valgt at benytte i projektet Som det kan ses, består selve brødteksten af både STAR- og SLUT-koder. Det er en måde, hvorpå Polinfo har valgt at opdele teksten i en artikel som en begyndelsesdel og en afslutningsdel (dette vil blive beskrevet yderligere i afsnit 3.3 om termvægt). Vores uddrag af Polinfo data består af cirka 400.000 artikler, taget fra et andet udpluk af Polinfo, som oprindeligt bestod af over 1.000.000 artikler. De 400.000 valgte artikler er taget ud fra den store database, da det var den del af artiklerne, som havde et eller flere emneord tilknyttet, det vil sige, at alle har tildelt tag en EMNE. Vi har dog foretaget flere afgrænsninger i databasen, for at vores afprøvning af søgemaskinen og behandling af resultaterne ikke skulle tage for lang tid. Vi tog i første omgang 100 artikler over i en separat tabel, som blev brugt til at konstruere og klargøre søgemaskinen til et større sæt artikler. Efterfølgende udvidede vi denne tabel til at indeholde 1000 artikler for at kunne foretage en søgning med et søgeresultat af en vis længde, så vi havde noget at evaluere efter. Oprindeligt var tanken, at hele databasen i sidste ende skulle inddrages for at undersøge konsekvenserne af en sådan skalering, men dette nåede vi ikke. 2.4.3 Målgruppe for Polinfo og prototypen Målgruppen til vores søgemaskine er bestemt af den type information som databasen lagrer nyhedsartikler fra Polinfos database. På InfoMedias hjemmeside oplyses om, at deres kundekreds repræsenterer mange forskellige brancher herunder omkring 800 kunder. Det indbefatter journalister, personer ansat i private og offentlige virksomheder, konsulenter og reklamefolk, studerende og undervisere på højere læreanstalter, folkeskoleelever, bibliotekarer og denne generelle befolkning, der benytter folkebiblioteker. Det er en stor og meget alsidig målgruppe, idet det kan indbefatte alle lige fra novicer til ekspertbrugere. Det sætter krav til systemets brugervenlighed, hvis vores prototype skal imødekomme dette. Side 13 af 92 sider
Man kunne tænke sig, at udgangspunktet for, at en bruger vil benytte vores søgemaskine, er fordi det er en nem og hurtig måde at finde information omkring et bestemt emne. Forskellige brugere som jurister, forskere og studerende, der er langt henne i studiet, vil gerne vide alt (tilstræbt), hvad der er skrevet og selv foretage et valg her ud fra. Andre, for hvem tidsfaktoren er vigtigere end grundighed, for eksempel journalister og stilskrivende skoleelever, vil være tilfredse med en mere målrettet søgning (Harter, 1986). Da vi ikke gør brug af en testbruger, er vores umiddelbare bias, at vi (som testbrugere) er godt kendt med systemets indhold og begrænsninger. Det skal tages med i vores betragtning af brugen af systemet. Vi vil ikke komme nærmere ind på målgruppen for vores prototype, da fokus er på systemet. 2.5 Sammenhæng mellem teori og empiri Med baggrund i eksisterende litteratur og teorier har vi forsøgt at få overblik og kendskab til det store felt, vi bevæger os indenfor. Vores forståelse af dette vil udarte sig i et praktisk stykke arbejde i form af en prototype, så vi kan undersøge, hvordan man i praksis anvender teorierne og afdække de problematikker, vi finder undervejs. Sammenhængen mellem den valgte teori og udviklingen af prototypen er derfor nært beslægtede. Vi har valgt at benytte teorier, der kunne applikeres praktisk, og som gør det muligt at udføre de ønskede søgninger i prototypen. Eftersom vi ikke har erfaring fra tidligere i udvikling af et søgesystem, valgte vi at afdække et traditionelt, klassisk IR-systems opbygning, hvor vi benytter termvægt samt modellen vector space i en søgemaskine. Vi implementerer begge dele i vores prototype, mens vi ud fra de fundne artikler i Polinfodatabasen vurderer, om resultatet er tilfredsstillende. Her inddrager vi to evalueringsmetoder til at vurdere søgeresultatets tilfredsstillelse. Undervejs i projektforløbet har vi løbende inddraget flere aspekter i prototypen, efterhånden som vi fandt frem til disse. Eksempelvis normalisering af termer og vores evalueringsmål. 2.6 Projektets videre opbygning I kapitel 3 vil vi gennemgå vores teoretiske grundlag, som indbefatter vores syn på IR efterfulgt af et indekseringsafsnit. Det leder os over i et afsnit om termvægt og brug af vector space-modellen og dens udvalgte dele. I kapitel 4 giver vi en præsentation af hele prototypen med eksempler på databasens opbygning og struktur, søgeprogrammet, samt vores brugergrænseflade. Vi præsenterer vores design af prototypen ved forskellige Side 14 af 92 sider
diagrammer, eksempler på kode, en præsentation af vores brugergrænseflade samt en kort gennemgang af vores målgruppe. Kapitel 5 indeholder vores egentlige analyse præsenteres og gennemgås. I dette kapitel tager vi udgangspunkt i eksempler fra vores prototype for at fokusere på, hvordan vores vægtning af termer behandles i databasen. Ydermere vil vi gennem nogle praktiske eksempler vise, hvordan den teoretiske vector spacemodel fungerer ved at kigge på rangeringen af søgeresultater. Vi ender ud i et afsluttende kapitel 6, hvor vi diskuterer pointerne fra analysen samt opsumerer konklusionerne. Vi afslutter opgaven med nogle perspektiverende tanker i kapitel 7 omkring, hvad de næste umiddelbare skridt ville være i det videre arbejde med prototypen. Side 15 af 92 sider
3 Det teoretiske grundlag I dette kapitel gennemgår vi de udvalgte teorier, som vi har valgt at beskæftige os med. Vi gennemgår samtlige faser fra søgeprocesmodellen, vist i problemfeltet. 3.1 Information retrival som felt Målet med et IR-system er kort sagt at svare på den søgeforespørgsel, som brugeren indtaster i systemet, herefter finde repræsentationer af information, der anses relevant for søgeforespørgslen, og efterfølgende give brugeren en relevant søgeresultatliste. Dette er ikke uproblematisk, hvilket vi klarlægge i følgende afsnit. Information retrieval (IR) is the science of searching for information in documents, searching for documents themselves, searching for metadata which describe documents, or searching within databases (Wikipedia, 2006). Der skeles typisk mellem to forskellige former for genfinding af data data retrieval og information retrieval (Baeza-Yates og Ribeiro-Neto, 1999). Forskellen mellem de to er behandlingen af de modtagne data. I data retrieval genfindes diverse data for eksempel dokumenter ud fra en forespørgsel, og de dokumenter, der findes, vises til brugeren. Men dette er ofte ikke nok til at tilfredsstille denne bruger. Brugeren har nemlig et behov eller ønske om at finde information ikke data om et bestemt emne. En måde, brugeren kan få tilfredsstillelse omkring informationssøgningen, er ved at systemet forsøger at analysere de modtagne data på en bestemt måde, før de præsenteres for brugeren. Det er denne måde, der behandles i et IR-system (Baeza-Yates og Ribeiro-Neto 1999). Et eksempel kan være at rangere resultaterne efter nogle forudbestemte parametre. Det kan også være at lade brugeren vægte de forskellige søgetermer. Normalt er der to sider af information retrieval, nemlig systemsiden og brugersiden. Brugersiden Forespørgsler, brugerdesign og brugerens mulighed for interaktion med systemet kom for alvor i fokus i 1990 erne. Systemet, brugeren og mellemledet mellem de to blev i højere grad set som en helhed, så søgningen blev en holistisk proces fra brugergrænsefladedesign over forespørgsler gennem mellemled ned i systemet samt evaluering af resultatet efter søgningen (Ingwersen & Järvelin, 2005). Side 16 af 92 sider
Hvor meget indflydelse brugeren skal have på denne proces, bestemmer udviklerne af søgemaskinen. Hvis brugeren for eksempel kun har mulighed for at indtaste en række ord og trykke søg, er det et absolut minimum, vedkommende kan gøre. Skal brugeren derimod have mulighed for en form for kontrol af indtastningen, kunne et skridt være at brugeren kunne vælge at markere det eller de ord i søgefeltet, der er vigtigst for brugeren. Eller den normalt brugte metode i søgemaskiner, at brugeren får lov til at putte gåseøjne omkring et par ord for at illustrere, at disse skal stå ved siden af hinanden. Yderligere kontrol for brugeren kunne være at lade brugeren skrive en label foran ordet; person:kvamm eller emne:musik ville lade brugeren definere inden for hvilken kategori, vedkommende søgte. Dette kræver dog, at brugeren har kendskab til disse labels og allerede her, øges sværhedsgraden af brugen væsentligt. Hvilke brugerhensyn udviklerne af systemet skal tage, afhænger både af målgruppe samt mulighed for fleksibilitet i systemet. Systemet En bruger har ofte ikke et forudbestemt mål til, hvad hun søger i en informationssøgningsproces. Hun har en vag ide og ud fra denne ide, stiller hun krav til søgemaskinen om, at denne giver hende den information, hun har brug for. Hun ved ofte ikke, hvad resultatet bliver, og vurderingen af resultatet bliver typisk en ad hocbeslutning fra brugerens side. Hvad brugeren til gengæld ikke kan svare på er: Mangler jeg at modtage information, der ellers ville være relevant for mig. Det er her, systemet skal træde til. Systemet skal kort og hurtigt kunne præsentere brugeren for en række resultater fra hendes informationssøgning. Det duer ikke at systemet lister 1000 resultater op på en skærm brugeren vil ofte miste overblikket over alle de listede resultater. Systemet skal altså på en eller anden måde kunne præsentere de fundne resultater i en ordnet rækkefølge for brugeren. Denne ordning eller rangering, som det kaldes, er et af de store problemer i systemorienteret information retrieval. For efter hvilke faktorer skal disse resultater ordnes. Det oplagte er at ordne dem efter brugerens behov, men denne kan som sagt ikke kortlægges fuldstændigt. (Berry & Browne, 1999). Systemet kan aldrig tage højde for alt. En brugerindtastning vil altid være subjektiv, ligeledes vil forventningen fra brugeren til resultatet. To forskellige brugere vil kunne indtaste den samme søgeforespørgsel, men mene Side 17 af 92 sider
noget forskelligt og søge efter forskellige dokumenter 4. Vi vil ikke inddrage dette i vores prototype, da det ligger udenfor vores fokus. Viderebehandling af resultater er en anden mulighed, systemet har for at blive mere påvirket af brugeren. Det kan gøres ved, at brugeren skal have mulighed for at udvælge resultater, der passer hende, for eksempel ved at klikke på en find lignende artikler -knap, der så ud fra den valgte artikel, foretager en ny søgning. 5 Det kan også være, at brugeren skal have mulighed for at sende feedback tilbage til systemudviklerne, så de kan foretage ændringer i den måde systemet er opbygget. I det næste afsnit vil vi gå i dybden med, hvordan det er muligt at strukturere information i form af indeksering af en database. 3.2 Indeksering Valg af indekseringstype har betydning for et systems organisering af information samt brugerens søgning af information. Det er derfor vigtigt at overveje, hvilken indekseringsteknik der skal benyttes, da dette har indflydelse på brugen af søgemetoder samt indholdet af databasen. Databasens struktur spiller ofte en afgørende rolle for, hvordan man skal indeksere (Salton & McGill, 1983). Indeksering af et system kan ses ud fra to sider. Den ene side er selve organiseringen af databasen, hvilket indebærer overvejelser om, hvilken måde en søgning skal foregå på, når der skal søges i databasen. Den anden side er værktøjer i databasen, der kan optimere hurtigheden af en søgning, for eksempel at skabe indeks på udvalgte attributter (ved brug af en create index- erklæring), hvorpå databasen selv sørger for at kunne finde rækker i databasen hurtigt ved hjælp af en indeksstruktur, der betyder, at kun en fraktion af databasen skal gennemsøges ved hver søgning (Garcia-Molina et al, 2002:605-606). Create index skal bruges forsigtigt, for selvom en søgning via et indeks bliver væsentligt hurtigere, bliver opdateringer af databasens indhold, for eksempel nye rækker, sletning af rækker eller opdatering af rækker, mere besværligt, fordi indeksene også skal opdateres i disse tilfælde (Garcia-Molina m.fl. 2002:297). Dette 4 Systemet kan til dels lære at tage højde for den enkelte brugers præferencer ved for eksempel login, cookies (i en webbaseret søgemaskine) eller andre former for identifikation af brugeren. 5 Dette kaldes også Relevance Feedback. Side 18 af 92 sider
gælder også indeks, der bliver oprettet i forbindelse med organiseringen af databasen, hvor man skal holde opdatering af databasen for øje, når man vælger indekseringsmetoder og -teknikker. Der findes forskellige datastrukturer, der kan vælges som indekseringsmetoder. En af de mest simple er et indeks på sorterede filer, hvor nøgler i indekset peger hen på de sorterede data i selve databasen. Indeks på usorterede filer er efter samme system, men her er filerne usorterede, mens nøglerne i indekset dog stadig er sorterede. I begge metoder gælder det om at skabe indeksnøgler, der peger hen på repræsentationer af data i databasen, og som er lette at genfinde, fordi nøglerne er sorterede (Garcia-Molina m.fl. 2002:622-626). Der findes flere måder at organisere disse nøgler på, så data i databasen hurtigt kan findes på grund af disse lettilgængelige indgange, indeksene skaber. 6 3.2.1 Metadata Metadata er meget brugt i indeksering af databaseindhold. Metadata kan, som nævnt i begrebsafklaringen, eksempelvis være en række emneord, der er tilknyttet et dokument i databasen, og som i en eller anden form er beskrivende for dokumentet. Metadata kan også være en lille tekst, der beskriver en større tekst, for eksempel som et abstract beskriver en rapport eller som bagsideteksten af en bog kan beskrive bogen. Uanset hvilken form metadata har, kan den ofte benyttes som nøgler i et indeks, da den skaber beskrivende muligheder for indgange til databasen (Salton, 1988). Metadata kan også være med til at udvide søgerens muligheder ved at indføre søgning på synonymer eller lignende. Med metadata er der dog det problem, at det ofte skal udarbejdes af mennesker bagsiden af en bog kan ikke skrives af en computer. Synonymer er heller ikke noget en computer kan finde, uden et menneske har været inde og fortælle den, hvilke ord der er synonymer osv. Der er derfor udviklet metoder til automatisk indeksering. 3.2.2 Automatisk indeksering Denne indekseringsmetode går primært ud på, at indekseringen udføres maskinelt, herunder at der udformes repræsentationer af den lagrede data ved at tildele indeksnøgler til dokumenter (Salton, 1988). Automatisk indeksering bruges især i strukturering af fuldtekstdatabaser, da det nærmest er en nødvendighed, når 6 B-trees og hastables er forskellige eksempler på organisering af indeksnøgler. Side 19 af 92 sider
databasen overstiger en vis størrelse. Hvis ikke der eksisterer nogen indekseringsindgange i en fuldtekstdatabase, og denne gøres tilgængelig til søgning, skal al data søges igennem, når der foretages en søgning, og det øger hurtigt søgetiden. En måde at skabe indekseringsindgange kan for eksempel være at termer, der allerede er en del af dokumenterne, trækkes ud af databasen for at bruges i indekset. Dette indeks kaldes et inverteret indeks og skaber indgange til dokumenter for hver eksisterende term i dokumenterne. Som med det manuelt skabte indeks, skabes det inverterede indeks ud fra en forestilling om, hvad der beskriver dokumenterne i databasen bedst (Salton & McGill 1983). Det inverterede indeks er opbygget ud fra en udtrækning af alle termer i dokumenterne. Dokumenterne tilknyttes hver term (når termen findes i dokumentet), og det er derved termen, der skaber indgangen til databasen. Termsiden i indekset kaldes the vocabulary og dokumenternes side kaldes occurences, som er en liste over alle de dokumenter, hvori den respektive term findes med en form for position, så termen peger hen på ordet i teksten. (Baeze-Yates & Ribeiro Neto 1999:192-193). Et eksempel på termers og dokumenters indeksering i en inverteret filstruktur er som følger term j d i vægt 1di - vægt 2di -... - vægt jdi hvor d i er dokument i, og vægt jdi og pos jdi er henholdsvis termvægten og termpositionen af term j i dokument i. Derved kan en term tilknyttes flere dokumenter, og indekset lagrer sammenhængen mellem termen og de mulige dokumenter (occurences). Vokabularet i et inverteret indeks er forholdsvis lille på grund af et begrænset antal termer. For hver gang et nyt dokument tilføjes, bliver antallet af termer, der skal tilføjes, mindre og mindre på grund af, at de fleste termer allerede forekommer i vokabularet. Til gengæld er occurence-delen stor, da en enkelt term kan have referencer til mange dokumenter, og jo flere dokumenter, der findes i databasen, jo flere pegepinde skal der være fra termen. Der findes metoder til at reducere størrelsen på occurence-delen, for eksempel block adressing, hvor termen i vokabularet refererer til blokke af tekst og ikke på den præcise position, termen har i artiklen. Blockadressering har også den fordel, at tilfælde hvor termen forekommer flere gange i én blok, bliver referencen til termen reduceret til én reference i stedet for to (Baeze-Yates & Ribeiro Neto 1999:193). Side 20 af 92 sider