UPTEC IT 10 004

Examensarbete 30 hpJanuari 2010

Lingvistik och användbarhet i sökmotorer

Sven Vidén

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress: Box 536 751 21 Uppsala

Telefon:018 – 471 30 03

Telefax: 018 – 471 30 00

Hemsida:http://www.teknat.uu.se/student

Abstract

Linguistics and Usability of Search Engines

Sven Vidén

This is a master thesis from Uppsala University in collaboration with B Locket AB(more known as www.blocket.se). B Locket AB is a large ad-company from Sweden,located in Stockholm.

Search engines on the market today are becoming more and more complex. Whenthey were first introduced, they only had one function and that was to producesearch results containing the string that the user had typed. Today, users want it tobe able to spellcheck, produce more results and sort search results on specific fieldsas well. Preferably, all these features should not affect the performance as a whole.

The reason to why these demands have come up is that users are getting more andmore used to internet services as a whole and they want everything to be as easy aspossible.

The user ability has become a substantially more important area in the computerindustry and this needs to be taken into account when it comes to B Locket AB andits search engine. This is one of the reasons to why this report has been made,another one is that B Locket AB:s search engine is a bit outdated and lacks some ofthe new features.

This report is a further development and a small evaluation of a search engine at BLocket AB. The search engine was evaluated in cooperation with B Locket AB:shead-developer and the person responsible for new features on the site. Furtherdevelopment was only done in consultation with both of them.

The evaluation showed flaws in B Locket AB:s search engine. These flaws were thereports key issues when starting the development of an improved model. The keyissues were autocomplete, spelling and stemming. The final result was a prototypewith these features implemented.

Tryckt av: Reprocentralen ITCUPTEC IT 10 004Examinator: Anders JanssonÄmnesgranskare: Iordanis KavathatzopoulosHandledare: Zakay Danial

Sammanfattning

Detta ar ett examensarbete for Uppsala Univestitet i samarbete med B Locket AB1. B

Locket AB ar ett stort annonsforetag i Sverige. De tillhandahaller en tjanst dar anvandare

lagger in annonser och kan ta kontakt med andra annonsorer for att pa sa satt kopa och

salja begagnade saker.

Sokmotorer ar nagot som far hogre och hogre krav pa sig fran anvandarna idag. Tidi-

gare var kravet enbart ett sokfalt och resultat som inneholl den eftersokta soktermen, idag

vill anvandaren att sokmotorn ska hjalpa denna att soka, stava och sortera sokresultaten.

Dessutom ska allt detta fortfarande ske precis lika snabbt som tidigare och det far inte

paverka anvandaren negativt.

Anledningen till alla dessa krav ar att anvandarvanligheten har blivit en allt storre

aspekt inom IT-branschen. I stort sett all ny mjukvara har genomgatt en ganska stor pro-

cess dar en kontroll av anvandbarheten hos just den produkten gjorts. Detta kan goras pa

olika satt, t.ex genom att lata vanliga anvandare testa produkten och darefter saga vad de

tyckte eller bara helt enkelt att utvecklarna gar igenom och testar anvandarvanligheten.

Detta examensarbete ar en vidareutveckling och en mindre utvardering av en sokmotor

pa B Locket AB. Sokmotorn utvarderades tillsammans med B Locket AB:s chefsutveck-

lare och publiceringsansvarig. Vidareutvecklingen skedde endast i samrad med dessa.

Resultatet av utvarderingen visade brister hos B Locket AB:s nuvarande sokmotor.

Dessa brister blev fokus-fragorna i vidareutvecklingen av den nya sokmotorn. De tydli-

gaste bristerna var att sokmotorn inte klarade av rattstavning, autocomplete och att den

hade problem med stemming2. I slutet gjordes darfor en prototyp med dessa delar och

andra forbattringar av den redan existerande sokmotorn implementerade.

1Mer kant som www.blocket.se2Ordstams-sokning

Innehall

1 Introduktion och bakgrund 4

1.1 Problembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Syfte och fragestallningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Begransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Analys 9

2.1 En sokmotors uppbyggnad . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Spindling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Indexering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 Forfragningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Rattstavning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Algoritmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Lucene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 Hunspell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4 Utvardering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Sarskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Morfologisk analys . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Stemming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Algoritmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.2 Utvardering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Lemmatization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Synonymer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7 Autocomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.1 Submission throttling . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7.2 Browser-side-cache . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7.3 Memcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

2.7.4 Utvardering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7.5 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7.6 Krav pa sokmotorn . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Resultat och utvardering 25

3.1 Rattstavning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Sarskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Stemming och Lemmatization . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Synonymer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Autocomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Slutsats, diskussion och framtida arbete 33

4.1 Slutsats och Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Framtida arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Litteraturforteckning 37

Appendix 41

A Autos.java 41

B Auto.java 44

C main.c 47

D Mailkonversation med Martin Hassel pa KTH:s sprakvetenskapliga in-

stitution 54

E Resultat av rattstavningsjamforelse 56

F Resultat av stemmingjamforelse 57

3

Kapitel 1

Introduktion och bakgrund

B Locket AB ar ett foretag inom annonsbranschen. Affarsiden gar ut pa att salja annons-

platser till privatpersoner och foretag pa natet. All forsaljning sker over natet genom dessa

annonser och B Locket AB:s kunder anvander pa sa vis enbart en webtjanst. Kunderna

skoter alltsa sjalva kontakten mellan annonsor och kopare.

Tjansten som B Locket AB tillhandahaller fungerar genom att anvandaren matar

in sokord och far da upp annonser som innehaller dessa sokord. Resultatet ar annonser

innehallande sokordet anvandaren ar intresserad av. Annonserna presenteras i form av

bilder och text, samt annonsorens kontaktinformation. Denna tjanst finns inte bara i

Sverige utan i mer an tio lander, dar marknadsfor sig B Locket AB pa ungefar samma

satt som i Sverige men med andra foretagsnamn.

For att hitta de annonser anvandaren ar intresserad av finns en sokmotor. Denna

ska hjalpa anvandaren att hitta information sa fort som mojligt, men aven precis den

information som anvandaren faktiskt ar ute efter. Det vill saga, anvandaren ska fa resultat

som ar sa precisa som mojligt utefter hans sokning. Detta helst utan att behova vara en

expert pa sokning via sokmotorer.

Sokmotorer har anda sedan de uppfanns anvants for att hitta information at anvandaren,

nagot som har utvecklats mer och mer, speciellt under de senaste aren. Med andra ord sa

blir sokmotorerna mer och mer anvandarvanliga, men samtidigt mer avancerade. De har

blivit snabbare efter hand som nya sokalgoritmer har uppfunnits och mer anvandarvanliga

efter hand som MDI1 har blivit viktigare och viktigare inom IT-branschen.

Den sokmotor som anvands pa www.blocket.se idag ar dock nagot foraldrad och

kan definitivt forandras till det battre. I dagslaget klarar sokmotorn inte av att hjalpa

1Manniska Dator Interaktion, forskningsomrade som innefattar interaktion mellan dator och

manniska, gar ut pa att fa datorsystem sa anvandarvanliga som mojligt.

4

anvandaren sarskilt mycket, vilket i langden gor att anvandaren inte hittar de annonser

han eller hon letar efter, atminstone inte lika fort och enkelt. Detta ar nagot som skulle

kunna paverka B Locket AB:s framgang.

I dagslaget nar nagon namner ordet ”sokmotor” tanker de flesta pa www.google.com2.

Denna sokmotor har blivit varldsledande under de senaste aren, till stor del pa grund av

dess enorma enkelhet och anvandarvanliga granssnitt. Oavsett vad anvandaren soker pa

forsoker den peka denne i ratt riktning. Det har gor att oavsett hur dalig anvandaren ar

pa att anvanda sokmotorn sa kommer traffar fortfarande att visas inom det omrade som

sokningen gjorts pa. Det ar dessa funktionaliteter som gor dagens sokmotorer bra och

anvandarvanliga. Manga foretag inklusive B Locket AB stravar efter att uppna liknande

funktionalitet i sina sokmotorer.

www.blocket.se har haft ett sarskilt tank med sin design anda sedan starten 1996.

Detta tank ar att allt ska vara sa enkelt som mojligt och det ska inte finnas nagra speciella

finesser som kan paverka anvandaren negativt. Malet med detta ar att de ska kunna na

ut till alla, gamla som unga, varfor denna rapport speglats av detta tank pa enkelhet.

Hur kan anvandarna fa sa mycket hjalp som mojligt utan att paverka dem negativt med

nya haftiga funktioner?

1.1 Problembeskrivning

Som sagts tidigare sa ar www.blocket.se:s sokmotor nagot foraldrad och klarar inte av

en del anvandarvanliga krav som foretaget har satt upp. De krav som B Locket AB vill

att sokmotorn ska klara av i framtiden ar:

• Rattstavning och sarskrivning

• Synonymsokning

• En forbattrad form av ordstamssokning

• Autocomplete

Om anvandaren far mycket hjalp kommer annonserna bli enklare att hitta och an-

nonsorerna kommer att fa fler intresseanmalningar pa sina annonser. Det gor att upp-

levelsen pa www.blocket.se blir battre och anvandaren slipper frustrationen over att

inte hitta det som eftersoks. Tyvarr finns valdigt lite information om dessa omraden i

foretaget. Darfor ska de undersokas och analyseras for att till slut ge en klar bild over

vad som kan anses vara anvandarvanligt i B Locket AB:s fall.

2Ett amerikanskt internetforetag, mest kant for just sin sokmotor

5

1.2 Syfte och fragestallningar

Syftet med detta projekt var att ta reda pa vilka delar som behovs for att gora B Locket

AB:s sokmotor mer anvandarvanlig och effektiv. Dessutom ska en prototyp visas upp med

de funktionaliteter som efterfragats. Denna prototyp ska vara valdigt enkel da huvudsyftet

med den ar att visa de nya funktionaliteterna och inte en snygg design.

Tva huvudfragor genomsyrade projektet.

• Vad gor att anvandaren paverkas negativt?

• Pa vilka satt kan anvandaren fa hjalp genom att enbart titta pa sokfaltet?

Anvandaren ska alltsa inte behova tanka pa att stava ratt eller om det finns annonser

innehallandes den soktermen och alltsa kanna sig saker pa det som matats in. Anvandaren

ska ocksa kunna anvanda forkortningar pa diverse produkter som kan tankas finnas i

annonserna. Om anvandaren hittar fler annonser som stammer in pa sokningen sa ar

ocksa sannolikheten storre att tjansten anvands mer frekvent.

Syftet med projektet var som sagt att fa fram en fungerande prototyp som han-

terar sokfragor pa ett anvandarvanligt vis med hjalp av lingvistik. Detta genom olika

hjalpmedel som undersokts under arbetets gang. De hjalpmedel som undersokts overvagdes

noggrant da de var tvungna att vara de basta i sin kategori for att sedan kunna imple-

menteras i den nya sokmototrn.

1.3 Metod

Tillsammans med handledare och publiceringsanvsarig pa B Locket AB har en lista pa

specifika onskemal fran anvandare och anstallda pa B Locket AB tagits fram. Denna lista

anvands for att undersoka de olika delar som pekats ut som bristfalliga eller som saknas

helt.

Varje punkt pa denna lista gas igenom noggrant och varje amne studeras genom att

lasa vetenskapliga artiklar, soka information pa internet och studera litteratur inom de

intressanta omradena. Detta gors for att ett beslut ska kunna tas om vilken metod som

bast loser varje delproblem. Nar informationen insamlats och behandlats fattas ett beslut

tillsammans med handledare och publiceringsansvarig.

Nar samtliga parter har kommit overens om vilken metod som ska anvandas for att

losa ett visst problem pa denna lista ska aven detta implementeras i en prototyp. Denna

prototyp som byggs upp fran borjan kommer mest att vara till for att kontrollera effekti-

vitet och funktion hos varje del. Nar varje delproblem har studerats och godkants i den

6

lilla prototypen kommer de att ga vidare till en stor implementation in i ett helt system

dar alla delproblem ska finnas representerade.

Varje del i den slutgiltiga prototyputvecklingen sker enligt den agila metoden ”XP”[6]3.

Detta innebar kortfattat att de problem som implementationen innebar delas upp i mind-

re delar. Varje problem blir en lapp pa en tavla, detta problem delas sedan upp i mindre

delproblem som ocksa ar representerade pa lappar. Nar alla delproblem ar losta ska alltsa

huvudproblemet var lost. For att detta ska fungera smidigt estimeras hur lang tid varje

lapp kommer att ta, angivet i mantimmar. Pa sa satt fas en tydligare overblick och au-

tomatiskt, en deadline att folja. Om prototypen uppfyller de krav som handledaren satt

upp kan lappen bockas av och arbetet kan fortsatta pa nasta lapp. Anledningen till att

metoden anvandes var framst for att B Locket AB redan arbetar utefter denna. Detta

gjorde att handledaren snabbt kunde se hur arbetet fortgick och kunde ge tips inom de

omraden dar arbetet faktiskt befann sig just da.

Alla bibliotek som anvandes i prototypen var utvecklade enligt Open-Source4 da B

Locket AB ville ha mojlighet att kunna modifiera sa mycket som mojligt efter eget tycke.

Den storsta anledningen var dock att de inte ville kopa nagon fardig produkt utan utveckla

storre delen for egen maskin. Under tiden som arbetet med sjalva sokmotorn fortgick

Figur 1.1: www.blocket.se idag. For mer information se www.blocket.se

3Extreme Programming, en arbetsmetod for mjukvaruutveckling.4Om mjukvara utvecklas enligt Open-Source sa innebar detta att mjukvarans kallkod ar tillganglig

for alla.

7

skrevs denna rapport. Atminstone en dag i veckan for att minska arbetsbordan i slutet pa

projektterminen. Rapporten kom sedan att presenteras del for del for amnnesgranskaren

pa Uppsala Universitet och for B Locket AB, detta for att sakerstalla att rapporten

fortfarande hade bra struktur och se till sa att ratt delar togs med i rapporten.

1.4 Begransningar

De begransningar som utforts ar att inte satta sig in i B Locket AB:s system da detta ar

alldeles for komplext for att kunna ta med i denna rapport. For att klara av att bygga

en prototyp av de fokus-fragor arbetet koncentrerats pa var detta ett maste. Det har

gjorde aven att fler delar av intresse for B Locket AB kunde gas igenom mer noggrant.

Dessutom om denna begransning inte gjorts hade rapporten fatt en helt annan inriktning

och eftersom fokus ska ligga pa efterforskning, enligt direktiv fran Uppsala Universitet,

blev detta ett krav.

8

Kapitel 2

Analys

Allman information om olika delar som berorts inom denna rapport och en djupare be-

skrivning av de omraden som B Locket AB velat ha mer information om. En jamforelse

mellan olika losningar inom samma omrade gors har for att kunna dra en slutsats om

vilken som ar bast anpassad till detta problem. Det ingar aven en del information om

vilka bibliotek som anvants i utvecklandet av prototypen.

2.1 En sokmotors uppbyggnad

En sokmotor[26] ar ett verktyg som hjalper anvandaren att hitta det han eller hon soker.

En webbsokmotor som detta projekt innefattar soker igenom webbsidor for att presen-

tera sitt resultat. Dessa resultat kallas for traffar och sorteras vanligtvis i en lista som

presenteras for anvandaren.

Dagens sokmotorer[34] arbetar i tre steg. Namligen:

• Spindling, insamlande av data

• Indexering, strukturering av data

• Forfragning, hamta resultat fran index

2.1.1 Spindling

Sokmotorn borjar med att hamta information fran sa manga platser som mojligt. Desto

storre informationsmangd desto battre resultat kan den ge. Detta gors med sa kallade

spindlar[31]. Spindlar ar program som genomsoker sidor efter lankar. De sparar lankarna

som information endast om lanken fungerar, annars inte. Dessa lankar som samlas in

9

blir sedan den information som sokmotorn anvander sig av for att hitta det anvandaren

ar ute efter. Efter att spindeln har samlat in dessa lankar gar den igenom sin lista for

att hamta hem den information som finns pa varje webbplats. Informationen kan vara

vanlig text, HTML-taggar eller lankar m.m. Hur informationen ser ut och anvands beror

lite pa vad sokmotorn anvands i for system. Det som beskrevs tidigare ar typiskt for en

webbsokmotor, t.ex. Google.

I Blockets fall daremot spindlas inte informationen in. Nar en anvandare skapar sin

annons sa laggs informationen automatiskt in i databasen. Den data som laggs in i da-

tabasen ar ren text, men denna ar forstas uppdelad i olika falt, sasom ”Rubrik”, ”Pris”

och ”Information”. Ett undantag till all text ar om anvandarna lagger in bilder till sina

annonser. Det stora steget for sokmotorn blir darfor indexeringen[10].

2.1.2 Indexering

Detta steg innebar att informationen som samlats in maste indexeras. Har maste, pa

ett smart satt, datan fa en sorts nyckel, for att snabbare kunna hitta ratt information.

Nyckeln i det har fallet motsvarar vad sjalva sokmotorn sedan kommer att soka pa, detta

for att undvika sokningar pa hela webbplatser vilket skulle ta oerhort mycket langre tid.

Indexering gor alltsa att datamangden som ska sokas igenom blir nagot mindre. Den

allra vanligaste metoden inom indexering ar hashing[7]. Har anvands en hashfunktion

for att indexera datamangden. Med hjalp av samma hashfunktion fas sedan resultatet

ur tabellen nar detta fragas efter av anvandaren. De allra viktigaste punkterna att ha i

atanke for att indexeringen ska fungera sa bra som mojligt ar:

• Sammanslagningsfaktorer, hur den nya datan matas in i det befintliga indexet.

• Lagringstekniker, hur indexet ska sparas, dvs. om informationen ska vara kompri-

merad1 eller filtrerad2.

• Indexets storlek, hur mycket utrymme behovs egentligen for att lagra all data.

• Snabbhet, hur snabbt ett varde kan hittas, detta ar den viktigaste delen for en

sokmotor.

• Underhall, hur indexet uppdateras over tid.

1Innebar att datan omkodas sa att mindre utrymme kravs for att lagra samma information.2Innebar att data som ar helt oviktig bortses fran, t.ex. om anvandaren har valt kategori sa tas bara

data inom denna kategori med.

10

• Feltolerans, hur viktigt det ar for tjansten att inte ge manga fel.

Blocket a andra sidan anvander sig av ett par taggar som bestams nar varje ny annons

skapas. Varje annons ar kategoriserad, tillhor ett visst lan och en viss ort. Detta anvands

vid indexeringen och informationen om detta hittas i deras databas. B Locket AB har

sju huvudkategorier och flera underkategorier i varje huvudkategori.

2.1.3 Forfragningar

Det sista steget ar helt enkelt sjalva sokningen. Skillnaden mot att sla mot en helt vanlig

databas ar i stort sett storleken. De vanligaste sokningarna som en anvandare gor kan

sammanfattas i dessa tre olika sorters forfragningar[35]:

• Informationsforfragningar, fragor som tacker in ett valdigt brett omrade, har kan

det finnas massor med relevanta resultat.

• Navigerbara forfragningar, fragor som riktar sig till en specifik webbplats, i www.

blocket.se:s fall kan det vara kategori.

• Affarsbesluts-forfragningar, fragor som anvandaren anvander sig av for att fatta

affarsbeslut, kopa bil eller liknande.

Det ar fortfarande vanliga SQL-fragor till den stora databasen som skapats av all den

information som spindeln samlat in. Detta ger anvandaren dess resultat. Fragan mot

databasen bildas da anvandaren slar in sina sokord. Har letar sokmotorn med hjalp av

sitt index igenom hela datamangden for att till slut visa sitt resultat for anvandaren. For

Blocket ar dock detta nagot annorlunda. De personer som anvander www.blocket.se

tar inte sokfaltet till sa mycket hjalp. Detta beror pa att Blocket redan har delat in

alla annonser i kategorier som ar valdigt detaljerade. Anvandaren klickar sig vanligtvis

vidare genom att valja kategori och under-kategori. Detta ar alltsa forinstallda fragor mot

databasen vilket gor att anvandaren upplever det som att sokning pa det har sattet gar

fortare. Eftersom dessa fragor redan har stallts mot databasen ar det ocksa ett snabbare

satt att fa fram information pa.

Sokfaltet pa www.blocket.se anvands mest for att verkligen specificera sin sokning,

t.ex. pa bilmodell, eller bara gora en forsta specifikation. Det ar alltsa nagot som gors

forst nar anvandaren har gatt ner i den kategori dar han kan hitta det som eftersoks.

Har ar omradet alltsa betydligt mindre att soka i an om han valt att soka redan fran

borjan innan vald kategori. Detta leder till att sjalva forfragningen mot databasen ocksa

blir snabbare.

11

2.2 Rattstavning

Det ar allmant kant att sarskrivning och felstavning ar valdigt stora problem i dagens

samhalle. Vi ar helt enkelt for vana vid att datorer rattar oss nar vi skriver fel. Om alla

ordbehandlare hanterar stavfel och sarskrivningar at anvandarna, vilket de flesta faktiskt

gor, sa ar det givet att ocksa sokmotorerna ska klara av denna uppgift. I dagslaget ar

det tyvarr bara nagra enstaka sokmotorer som har lyckats losa denna uppgift(exempelvis

Googles sokmotor).

Datorerna har inte bara medfort att vi stavar fel pa grund av for mycket hjalpmedel,

aven tangentbordet gor att orden kan bli felaktiga. Det ar namligen valdigt enkelt att tryc-

ka pa fel tangent. De fyra vanligaste felen som forekommer vid sokningar pa sokmotorer

och i texter som skrivs i ordbehandlare ar:

1. Att en bokstav har forsvunnit.

2. Att det har kommit till en extra bokstav.

3. Att en bokstav har bytts ut mot en annan.

4. Att tva bokstaver har bytt plats i ordet.

Dessa felstavningar kan faktiskt hittas i anda upp till 80 procent av alla felstavade ord.

Detta har pressat utvecklare och andra att forsoka komma fram till olika satt att losa

problemen pa. Anledningen till att www.blocket.se vill ha denna funktionalitet ar for

att hjalpa anvandaren att fa fler traffar pa sina sokord. Detta kommer gora annonser

mer lattillgangliga och forhoppningsvis blir annonsorerna och koparna mer nojda da an-

nonsorernas annonser visas mer, respektive att koparen faktiskt hittar fler annonser.

Rattstavningen kommer att ske utan att anvandaren behover fundera pa om han eller

hon faktiskt stavat ratt ifall fa annonser skulle visas, det kommer att visas ett forslag till

annan stavning om det skulle finnas ett annat alternativ som ar battre.

2.2.1 Algoritmer

I dagslaget finns det massor med olika alternativ for att kontrollera om ett ord ar ratt

stavat eller inte. Ett antal av dessa kommer att forklaras har nedan. Nagra av de alternativ

som finns idag for att hantera problemet med felstavning ar:

• Fonetiska algoritmer

• N-grams algoritmer

12

• Edit-distance algoritmer

• Bloom-filter

• Jaro-Winkler

Fonetiska algoritmer

Fonetiska algoritmer[30] ger varje ord en viss kod, denna kod motsvarar ordets fonetiska

skrift. Detta innebar att flera ord kan ha samma kod da vissa uttal ar valdigt lika, eftersom

uttal ar den enda faktorn kan detta bli en valdigt stor begransning.

For att denna variant ska fungera maste algoritmen ha tillgang till en ordlista, denna

ar indexerad enligt algoritmens koder for fonetisk skrift. Efter att ha matchat det inma-

tade och felstavade ordets kod med nagon kod i den indexerade ordlistan fas ett antal

alternativ pa vilket ord anvandaren kunde menat egentligen. Denna algoritm ger oftast

inte ett enda alternativ alltsa. Det har innebar att enbart denna variant inte racker for

att klara av en ”Menade du”-implementation3.

N-grams

N-grams[24] delar upp ord i n stora delar, algoritmen indexerar aven sin ordlista enligt

denna metod. Nar en anvandare skriver sitt ord delar n-gram algoritmen upp detta i delar

av n storlek. Dessa delar jamfors sedan med orden i ordlistan. Desto fler delar som det

inmatade ordet har gemensamt med nagot ord i ordlistan desto storre sannolikhet ar det

att det inmatade ordet faktiskt ar ordet i ordlistan. Ett exempel ar ordet ”hund” som da

blir uppdelat i ”hu”, ”un” och ”nd”, detta forutsatt att 2-grams anvands.

N-grams anvands ofta for att foresla ord inom rattstavning, framforallt anvander

ordbehandlare sig av denna teknik for att indexera sin ordlista. Precis som foregaende

algoritm kan inte heller denna foresla ett enda ord for anvandaren utan plockar ut ett

visst antal ord som innehaller n antal delar N-grams av det inmatade ordet.

Edit-distance algoritmerna

Edit-distance algoritmerna[18] anvander sig av att rakna pa avstandet mellan tva ord.

Med avstandet menas hur manga operationer som kravs for att ord1 ska bli ord2. Opera-

tionerna kan vara borttagning av och inforande av, samt utbyte av bokstav eller bokstaver.

3”Menade du” ar ett namnforslag pa den funktionalitet som ska presentera korrekt stavade ord for

anvandaren

13

Precis som foregaende algoritmer sa anvands ocksa har en ordlista for jamforelse. Pa se-

nare tid har aven algoritmer av denna sort utvecklats till att klara av transposition4 av

tva bokstaver. Operationerna har olika varden beroende pa hur tunga de ar, kostnaden

ar enligt foljande:

• Kopiering av bokstav fran ord1 till ord2 har kostnad 0

• Borttagning av bokstav fran ord1 till ord2 har kostnad 1

• Tillagg av bokstav fran ord1 till ord2 har kostnad 1

• Utbyte av bokstav fran ord1 till ord2 har kostnad 1

Edit-distance algoritmerna ar de som ar vanligast bland rattstavningsimplementationer

enligt KTH5:s sprakvetenskapliga avdelning[16]. Den stora anledningen till detta ar att

den ar valdigt snabb, val dokumenterad och har funnits under lang tid, vilket innebar

att den ar val testad och val anvand. Fordelen ar ocksa att den klarar av att hitta ett

specifikt ord i en ordlista och har mojlighet att bara ge ett alternativ till det felstavade

ordet.

Jaro-Winkler distance

Jaro-Winkler[13] ar en variant pa edit-distance. Precis som foregaende algoritm raknar

Jaro-Winkler ut avstandet mellan tva ord for att till slut hitta ett bra forslag pa vad

anvandaren matat in. Skillnaden dem emellan ar att ju hogre varde i Jaro-Winkler desto

narmre ar orden varandra i likhet, men i den vanligare varianten av edit-distance ar det

ett sa lagt varde som mojligt mellan tva ord som anger likhet. Avstandet mellan tva

ord ges av formel 2.1. Ytterligare delar som denna algoritm kan anvanda sig av ar att

dj =1

3

(m

|s1|+

m

|s2|+

m− t

m

)(2.1)

Tabell 2.1: m = antal matchande bokstaver i s1 och s2, s1 = ord1, s2 = ord2, t = antalet

transpositioner, dj = avstand mellan s1 och s2

ranka strangar som matchar pa prefix hogre an de som matchar senare. Detta kan vara

en fordel vid exempelvis namnuppslagning men kan ocksa vara en nackdel nar det galler

produkter eller andra strangar som innehaller nagot slumpmassiga teckenfoljder.

4Transposition inom lingvistik ar nar tva bokstaver har bytt plats i ett ord.5Kungliga Tekniska Hogskolan

14

Jaro-Winkler ar anpassad for att hantera kortare strangar eftersom den inte ar riktigt

lika snabb som edit-distance. dj som var avstandet mellan tva ord anges mellan 0 och 1

i flyttal, dar 0 anger ingen likhet och 1 sager att de ar exakt lika.

Bloom-filter

Bloom-filter[3] anvands for att detektera delelement i storre element, till exempel inom

lingvistik sa kan man se om ett specifikt ord tillhor ett annat storre ord. Precis som

flera av de tidigare algoritmerna anvander ocksa Bloom-filter en ordlista. Nar ordlistans

storlek okar sa finns risken att ord som skulle markerats som felaktiga faktiskt tolkas som

ratt, dock sa ger den aldrig felaktiga svar pa de ord som faktiskt ar fel.

Detta ar dock en metod som kan vara svar att implementera i en sokmotor, med tanke

pa att den faktiskt ger fler fel nar ordlistan blir storre. Eftersom ordlistan kommer vara

ganska stor i www.blocket.se:s fall sa kan detta gora att sokningarna blir helt felaktiga

i langden vilket kommer att resultera i en uppsjo av arga kunder, dessutom blir det svart

att bygga en ordlista av annonser med denna metod.

2.2.2 Lucene

Lucene[19] ar en sokmotor som helt ar uppbygd enligt Open-source-principen. Det gar

alltsa att anvanda denna sokmotor i vilket projekt som helst.

Inom omradet rattstavning finns det en hel del fardiga komponenter[20] till denna

sokmotor vilket gor den till en intressant kandidat for att skota denna uppgift pa www.

blocket.se. Den anvander sig av edit-distance-algoritmer for att kontrollera vilket ord

som kan tankas vara det ratta. Det finns aven tillagg for att anvanda Jaro-Winkler-

algoritmen. For att snabbare hitta de ord i ordlistan som byggs upp av annonserna

anvander sig Lucene av N-grams for att indexera hela denna lista. Nackdelen med just

denna variant ar att den ar nagot anpassad for det engelska spraket, vilket gor att den

inte kan hantera sarskrivningar.

Som kan lasas pa [19] sa finns det mycket i denna sokmotor som redan ar implemen-

terat. Detta eftersom manga redan har utvecklat komponenter till den, vilket gor den

valdigt smidig att anvanda, en vanlig fordel vid anvandande av Open-source-projekt.

15

2.2.3 Hunspell

Hunspell ar ett bibliotek6 som ar byggt for att utfora bland annat rattstavning. Detta

bibliotek anvands i manga ordbehandlare och aven webblasare for just rattstavning. Hun-

spell anvander sig av edit-distance-algoritmer for att kontrollera likhet mellan ord och

N-grams for att indexera sin ordlista, alltsa liknande algoritmer som Lucene anvander sig

av. Den stora skillnaden ar att Hunspell har utvecklats under en langre period samt att

det ar utvecklat enbart for lingvistik och har stod for valdigt manga sprak, samt att det

klarar av sarskrivning.

2.2.4 Utvardering

En kombination av edit-distance och N-grams ar de vanligaste som finns implementerade

i dagens ordbehandlare[25]. Ordbehandlare behover dock inte tanka pa prestanda lika

mycket som sokmotorer da de inte behover vara fullt sa snabba, samt att de inte har lika

stor datamangd att hantera.

Vad galler ordlistor sa ar detta ett alternativ som anvands mest i ordbehandlare.

Anledningen till detta ar for att det mest handlar om skriftsprak nar dessa anvands.

Ordlistorna som finns idag ar uppbyggda manuellt och uppdateras nagra ganger per ar,

detta gor att de kan bli nagot forlegade nar de anvands under lang tid och i en sokmotors

varld behover de uppdateras valdigt frekvent.

Sokmotorer i allmanhet anvander inte ordlistor i samma utstrackning, detta eftersom

de ska klara av talsprak pa ett helt annat satt. I B Locket AB:s fall ar det dock lite

speciellt eftersom annonser innehaller lite av bada delar, darfor kommer fokus att ligga

pa bade skriftsprak och talsprak.

2.3 Sarskrivning

Sarskrivning ar nar ett ord skrivs som tva, denna del innefattar aven det laget som ar

tvartom, alltsa dar tva ord skrivs som ett.

Vad galler sarskrivning sa ar detta ett amne som ar betydligt mycket svarare att losa.

I dagslaget finns ingen algoritm som ar valkand for att losa detta fenomen. Det beror

delvis pa att ordbehandlare med mera, framst utvecklas for det engelska spraket, dar

sarskrivningar inte forekommer i sarskilt stor utstrackning. Samt att manga losningar ar

patenterade och valdigt svara att hitta information om.

6Ett bibliotek inom programmering ar en samling funktioner som anvands for mjukvaruutveckling.

16

Nagra av de bibliotek som finns i dag anvander sig av edit-distance algoritmen for att

losa aven sarskrivningar. Ett antagande gors om att det har inforts ett extra tecken, i

detta fall ett mellanslag, nar detta tas bort fas en traff pa ett helt ord i ordlistan. Tyvarr

fungerar inte detta om aven det sarskrivna ordet finns i ordlistan, vilket ar fallet i denna

rapport da ordlistan kan innehalla felstavade ord.

De algoritmer som loser sarskrivningen pa battre satt anvander sig istallet av mor-

fologisk analys[22]. Har specificeras speciella regler for vad som ar en sarskrivning och

inte.[37]

2.3.1 Morfologisk analys

Morfologisk analys innebar att ordens struktur tas fram, form och bojning. En morfologisk

analys tittar pa hur stor del av ordet som kan passa ihop med ett annat ord i ordlistan,

vilket leder till att de foreslar en sammansattning av tva ord istallet for den sarskrivna

formen.

For att detta ska fungera anvands en ordlista med samtliga ord taggade enligt svenska

sprakets regler for rattstavning. De ord som kan forekomma i en sammansattning av

tva ord far en tagg for detta, det specificeras aven om de kan vara en borjan pa en

sammansattning eller ett slut pa den. Nar anvandaren matar in sitt ord sarskrivet tittar

alltsa rattstavaren i sin ordlista efter ord som kan forekomma i sammansattningar. Om

den hittar ord som liknar det anvandaren har matat in fast sammansatt sa foreslar den

det ordet istallet.

Denna metod ar alltsa sakrare an att gora antagandet att mellanslaget ar en felaktig

bokstav. Finns sarskrivningen i ordlistan kan problem uppsta, vilket kommer att vara

fallet for B Locket AB och deras ordlista. En losning pa detta kan vara att varje ord i

ordlistan rangordnas och nar forslag ska tas fram kontrolleras vilket av dem som rankas

hogst, det ord som da rankas hogst kommer att foreslas som det ratt stavade.

2.4 Stemming

Stemming[32] innebar att prefix och suffix kapas bort fran ett ord. Suffix ar andelser pa

ord och om det tas bort gor det bara att ordet blir kortare men fortfarande har samma

innebord. Prefix ar begynnelser pa ord och om det tas bort gor det att ordets stam hittas,

vissa ord kan aven ha flera stammar, t.ex ”forskajak” som har stammarna: ”fors” och

”kajak”. Vad ar da syftet med detta och varfor ar det nodvandigt for www.blocket.se?

I sokmotorer anvands denna metod for att ge anvandaren fler traffar inom samma

17

omrade som det han eller hon sokt pa. Detta fungerar eftersom ordets stam tas fram

och inte tvartom, dvs. forsoker skapa nya ord. Denna funktionalitet finns redan pa www.

blocket.se men fungerar inte fullt ut, darfor ska en undersokning goras pa det alternativ

som anvands idag och se ifall det finns nagot som ar battre, eller om den funktion som

redan finns kan forbattras pa annat satt.

2.4.1 Algoritmer

De tva olika varianterna som undersokts i denna rapport ar en algoritm utan ordlista och

en variant med ordlista. Dessa varianter ar egentligen tva bibliotek for programmerings-

spraket C, namligen Snowball som klarar sig utan ordlista och Hunspell som anvander

en ordlista. Anledningen till att det bara ar tva varianter som undersokts ar for att ett

av B Locket AB:s grundlaggande krav var att de fardiga delar som skulle anvandas var

gratis och helst Open-source alternativ. Den framsta anledningen till att detta krav kom

upp ar for att foretaget vill undvika onodiga kostnader till andra foretag.

De tva algoritmerna beskrivs har nedan.

Snowball

Detta ar den variant som inte anvander nagon ordlista for att lista ut ordens stam. Har

tittar algoritmen helt enkelt pa ordet och ser vad det slutar pa, vilket betyder att denna

”stemmer” utan ordlista enbart tittar pa suffix. Detta ar en begransning som kan innebara

vissa felaktigheter i sokresultaten.

I denna variant maste regler deklareras for hur varje ord far andras, vilka andelser

som kan tas bort och pa vilket satt detta ska goras. Detta gor att det ganska snart blir en

valdigt komplex och stor lista med regler, dessutom oavsett hur mycket regler som infors

sa blir det nastan omojligt att tacka alla fall.

Fordelarna med de algoritmer som inte anvander ordlistor ar att de ar valdigt snabba

och kraver valdigt lite utrymme, de kan alltsa vara bra vid fall dar prestanda ar viktigare

an precisa resultat och framforallt nar prestandan ar begransad. Nackdelen ar dock att

de kan ta bort for stor del av ordet sa att det far en helt annan betydelse7, men aven att

ett ord som inte finns uppkommer. Om detta intraffar sa ar stemmingen helt bortkastad,

anvandaren kommer att fa traffar pa helt andra saker an det han faktiskt sokt pa, eller

inga alls, vilket kan leda till en allvarlig bugg.

Det Open-Source alternativ som finns for den har sortens stemming heter Snowball[28].

7Nar ordet far en annan betydelse kallas det att ordet flatas samman med ett annat.

18

Hunspell

Hunspell[9] anvander sig av en ordlista uppbyggd med hjalp av morfologisk analys for att

ta reda pa ordets morfem8.

Med hjalp av den morfologiska analysen hittas alltsa den minsta gemensamma namnaren

mellan orden i ordlistan och det anvandaren har matat in. Ordets stam, som blir resul-

tatet, ar det som den totala sokningen baseras pa for att fa fler traffar, precis som sagts

tidigare.

Den morfologiska analysen utfors pa ordlistan vid indexeringstillfallet, ordlistan byggs

da upp med sa kallade taggar. Varje ord far en taggning som beskriver vilken ordklass det

tillhor, hur det kan bojas och aven dess struktur. Har kopplas ord samman med varandra

om de tillhor samma grundform, detta med hjalp av de regler som satts upp av den affix-

fil programmet anvander. En affix-fil innehaller regler pa hur ord kan kortas ner, detta

baserat pa sprakets vanliga prefix och suffix.

Nackdelen med dessa affix-filer och ordlistor ar att de byggs upp manuellt, anledningen

till detta ar att det blir oerhort svart att bygga detta automatiskt eftersom lingvistiken

ar sa oerhort komplex. Andra alternativ som kan stallas in i en affix-fil ar bland annat:

• Hur manga bokstaver varje ord som ingar i en sammansattning maste ha

• Om programmet ska ge forslag pa tva separata ord som en sammansattning

• Vilka ord som kan inga i en sammansattning

• Vilken ordklass varje ord tillhor. . .

2.4.2 Utvardering

Stemming utan ordlista hittar ordets stam men gor valdigt ofta fel, Hunspell daremot

hittar ordets korrekta stam betydligt mer frekvent. Om anvandaren matar in ordet ”ka-

jakerna” sa lyckas den med ordlista att fa fram ordet ”kajak” som da ar ordets stam.

Detta skulle stemming utan ordlista fa fram ordet ”kajaker” utav, om ordet hade varit

mindre komplext hade aven denna metod lyckats hitta ratt ordstam.

Hunspell ar inte lika snabb som stemming utan ordlista men ger betydligt farre fel,

dessutom ar sammanflatning inte alls lika vanligt, detta gor att anvandaren far mer

precisa resultat och framforallt ratt resultat.

8den minsta betydelsebarande enheten i ett sprak.

19

2.5 Lemmatization

Denna metod liknar stemming som namnts tidigare i 2.4. Den stora skillnaden ar att

istallet for att hitta ordets stam hittas ordets lemma. Lemma ar ordets grundform, t.ex.

”samre” som har grundformen ”dalig”. For att bestamma ordets lemma behover algo-

ritmen veta vilket sprak det ar och i vilket sammanhang ordet anvands. En nackdel har

ar alltsa att vissa ord faktiskt har flera betydelser vilket kan leda till valdigt komplexa

operationer. De komplexa operationerna gor att det kan bli stora pafrestningar pa den

maskin som utfor dem och sjalva systemet kan upplevas som segt, dessutom fungerar

denna metod bast nar ordet satts i ett sammanhang, vilket sallan ar fallet i en sokterm.

Fordelen ar att Lemmatization[17] overvinner problemet med att liknande, ickerele-

vanta ord hamtas. Det har problemet uppkommer daremot ofta vid stemming.

Lemmatization ar fortfarande en valdigt bra metod for att hjalpa anvandaren hitta

vad han eller hon letar efter. Antalet fel ar valdigt sma i forhallande till vad som skulle

kunna handa med stemming och den ar framforallt valdigt exakt.

2.6 Synonymer

For att en sokmotor ska bli riktigt bra maste den klara av att forsta synonymer. Synony-

mer ar ord som har samma betydelse som ett specifikt annat ord. I sokmotorns fall innebar

detta att anvandaren kan fa fler traffar, om han eller hon t.ex. soker pa ”rullbrada” sa

ska traffar aven ges pa ordet ”skateboard” och andra synonymer. www.blocket.se har i

dagslaget inte nagon sadan implementation och nar det galler annonser ar denna funk-

tion valdigt viktig. Anledningen till detta ar for att B Locket AB anvands av sa skilda

aldersgrupper, darfor kan de skriva valdigt olika ord men faktiskt mena exakt samma

sak. Vad finns det da for alternativ som gor detta?

Vad galler Open-source alternativ finns det bara ett som ar vanligt och ordentligt

beskrivet, detta heter MyThes och anvands i bland annat OpenOffice9.

MyThes[23] anvander sig av tva filer for att kontrollera ord och dess synonymer.

Huvudfilen ar uppbyggd enligt denna struktur:

Ord — antal betydelser

betydelse1 — syn1 — syn2 . . .

.

.

9Ett Open-source-alternativ till Microsoft Word.

20

.

betydelseX — syn1 — syn2 ...

Ord – ordet som matats in och som finns i ordlistan

Antal betydelser – hur manga olika sorters betydelser det ordet kan ha

Varje rad som foljer denna innehaller en betydelse och den har i sin tur sina synonymer

efter sig enligt denna ordning:

1. betydelse – specifik betydelse for ordet

2. syn1 – synonym nummer ett for den specifika betydelsen

3. syn2 – synonym nummer tva for samma betydelse osv.

Den andra filen byggs upp med hjalp av denna huvudfil genom att enbart ta med antal

synonymer totalt och siffran pa detta i toppen av filen, samt var i huvudfilen som orden

kan hittas. Denna fil kan ses som en indexfil och totala antalet synonymer innebar alla

synonymer som ingar i databasen.

Nar ett ord matas in i sokfaltet av anvandaren kontrollerar programmet i sin indexfil

var den kan hitta andra betydelser av det inmatade ordet i sin synonymordlista. Om

den hittar nagra synonymer matas dessa ut enligt betydelse och med dess synonymer

uppradade, detta kan anvandas for att anvandaren ska fa fler traffar inom samma omrade

och aven for att hitta det som kan vara lite svarare att lokalisera.

2.7 Autocomplete

Autocomplete[15] hjalper anvandaren genom att foresla ord for denne, dessa ord baseras

pa vad anvandaren har slagit in for bokstaver i sokfaltet, exempel pa hur detta kan se ut

kan ses i figur 2.1.

Denna metod ar framforallt valdigt effektiv nar det ar enkelt att gissa vad anvandaren

vill skriva. De fall nar det blir enkelt ar nar antalet mojliga forslag ar begransade eller

att datamangden inte ar sa stor, med andra ord, desto fler ord anvandaren matar in i

sokfaltet desto farre alternativ finns det att valja bland och sokningen gar snabbare.

Den storsta anledningen till att autocomplete anvands ar for att lata anvandaren

komma fram till det han eller hon soker snabbare och for att undvika felstavningar,

samt peka anvandaren i ratt riktning. Denna tjanst ar oftast valdigt svar att fa enkel,

vilket kan komma att forstora www.blocket.se:s ide, vilken innebar att allt ska var

21

Figur 2.1: Ett exempel pa autocompletion i ett textfalt fran den forsta prototypen som

gjordes.

sa enkelt som mojligt pa hela sidan. Den forslagslista som dyker upp for anvandaren

kommer att sorteras enligt de specifikationer som utvecklaren bestammer. B Locket AB:s

ide ar att titta pa alla annonsrubriker och implementera autocomplete med hjalp av

dessa. Nar anvandaren matar in bokstaver i sokfaltet far denne alltsa forslag pa olika

annonsrubriker innehallandes den strang anvandaren matat in, nagra andra exempel pa

vilken data forslagslistan kan skapas av ar:

• Historiska sokningar, dessa loggas av sokmotorn och presenteras for anvandaren i

fallande ordning baserat pa hur manga ganger de gjorts.

• Personliga historiska sokningar, sorterade pa antal ganger de gjorts for just den

anvandaren, svart med datamangd.

• Nyligen gjorda sokningar, mindre datamangd

Hur detta ska sorteras baseras pa vilken sorts applikation det ar som ska anvanda tjansten,

men for att fa den sa snabb som mojligt ar det bra att basera det pa en sa liten datamangd

som mojligt, den far dock inte vara for liten eftersom det kan leda till daliga forslag eller

inga alls.

Den andra delen av forslagslistan ar sjalva ordningen pa den. Hur detta ska ordnas

bestams ocksa av utvecklaren men aven har finns ett antal olika forslag.

• Beraknad sannolikhet, t.ex. Hur ofta sokningen gjorts historiskt sett.

• Senast forfragningen gjordes, Om det ar intressant ur historisk synpunkt.

• Alfabetisk ordning, Detta beror givetvis pa vilken sorts applikation det ar som

anvander sig av forslagen.

22

Normalt uppdateras forslagslistan efter varje tangenttryckning, vilket leder till en ganska

kostsam operation for servern. Om ett sant har anrop ska goras for varje anvandare

flera ganger under en kort period sa ar det stor risk att den maskin som hanterar

forfragningarna blir overanstrangd. For att undvika att detta problem uppstar anvands

submission throttling[33] och cache[5].

2.7.1 Submission throttling

Submission throttling innebar att istallet for att lata Autocomplete-metoden anropa ser-

vern vid varje tangenttryckning sa sker anropen med ett visst tidsintervall. Anropen sker

alltsa mer sallan och problemet med att de anvandare som skriver valdigt snabbt far

konstiga forslag undviks. De konstiga forslagen uppkommer helt enkelt eftersom servern

inte hinner med att hantera varje anrop. Om fokus istallet laggs pa cache for att forsoka

oka snabbheten sa kan detta goras med olika metoder, tex Browser-side-cache[4] eller

memcache[21].

2.7.2 Browser-side-cache

Browser-side-cache anvander sig av cache-minnet som finns i webblasaren, nackdelen med

detta ar att denna cache begransas till en viss storlek, ju mer data som cachas desto langre

tid tar det for webblasaren att visa sidan. Detta kan paverka anvandarens surfupplevelse,

speciellt om han eller hon har en aldre dator, det har ar alltsa ett typiskt exempel pa hur

anvandaren kan paverkas negativt aven om malet ar att gora sidan mer anvandarvanlig,

darfor ar inte detta att rekommendera om datamangden ar stor.

Hur lange cachen ska sparas beror helt pa utvecklaren, detta da han kan satta specifika

villkor pa hur lange cachen ska hallas kvar lokalt hos anvandaren. Det kan goras med

bland annat bast fore datum eller med senast andrad taggar. Utvecklaren far dock inte

satta vilka villkor som helst for denna cache, vissa lagar maste foljas och dessa finns

specificerade i HTTP:s-specifikation[8].

2.7.3 Memcache

Memcache a andra sidan anvander sig av RAM-minnet pa servern, det har gor att listan

finns kvar hela tiden. Den ar alltsa helt oberoende av browserns cache och paverkar saledes

inte heller anvandarens surfupplevelse pa samma satt, vilket gor att det ar en metod

som ar att foredra pa betydligt storre system. Det ar alltsa helt avgorande hur manga

23

anvandare som utnyttjar tjansten, men aven hur mycket data som maste behandlas.

Detta kan vara ett aktuellt alternativ i B Locket AB:s fall.

2.7.4 Utvardering

Oavsett metod sa ar sjalva iden med cache att minska antalet forfragningar till servern,

detta dels for att snabba upp systemet men aven for att minska pafrestningen pa den.

Cache fungerar pa sa vis att det har en lista pa de ord, som exempelvis soks pa oftast,

sparad. For att undvika att denna lista vaxer till oandlighet, vilket skulle leda till ett lika

slott system som utan cache, maste det da och da kastas ut ord. Detta kan exempelvis

goras genom att de ord som sokts pa mindre an andra kastas ut, ord som forekommer

mindre frekvent an andra knuffas helt enkelt nerat i listan. For att undvika att listan bli

inaktuell maste denna uppdateras ganska frekvent.

Nar anvandaren borjar mata in sitt sokord kommer alltsa den forsta forfragningen att

ske mot cachen och om ord som liknar anvandarens finns dar kommer dessa att visas i

forslagslistan, om sa inte skulle vara fallet kommer en forfragning ske mot servern direkt.

Det kommer da att ta nagot langre tid att fa fram listan pa forslag men forslaget kommer

fortfarande att visas.

2.7.5 Granssnitt

Det finns flera bibliotek som klarar av autocompletion, de flesta skrivna i javascript[14]

eller AJAX[1]. De fungerar pa liknande satt allihopa, nagra exempel pa bibliotek for

autocompletion ar, scriptaculous[27] och jquery[15]. Valet foll pa jQuery enbart for att B

Locket AB redan anvander det och saledes utfordes ingen analys pa dessa delar.

2.7.6 Krav pa sokmotorn

For att denna del ska fungera i www.blocket.se:s fall behover sokmotorn kunna indexera

meningar samt varje ord i varje mening. I dagslaget klarar inte den sokmotor som anvands

av att indexera meningar pa detta satt, darfor kommer en helt ny sokmotor att behova

byggas for att en fungerande prototyp ska kunna produceras. Denna sokmotor kommer

dock att baseras pa ett redan fardigt ramverk och anledningen till att ett redan fardigt

ramverk anvands ar for att det tar mycket langre tid att bygga nagot fran grunden som

fungerar lika bra eller kanske samre an det som manga redan arbetat lange pa.

24

Kapitel 3

Resultat och utvardering

Har beskrivs varje del for sig samt vilka resultat som uppnatts inom varje omrade, aven

hur dessa delar har implementerats eller inte i den slutgiltiga prototypen.

3.1 Rattstavning

Efter att ha vagt de olika algoritmerna mot varandra kunde en slutsats dras om att en

kombination mellan edit-distance och N-grams var det basta alternativet for denna typ

av problem, detta for att N-grams ar en valdigt snabb algoritm som ger valdigt fa fel och

edit-distance ar valdokumenterad.

I den har rapporten anvands N-grams for att indexera ordlistan, detta gor att orden

kan lokaliseras snabbare an om enbart edit-distance hade anvants. Edit-distance anvands

istallet for att kontrollera de ord som N-grams plockar fram och ser vilket som ar mest

likt det ord anvandaren redan matat in. Anledningen till att edit-distance valdes ar for

att den ar specialkonstruerad for att jamfora tva ord och skillnaden dem emellan, just

den valda varianten klarar av transposition ocksa, vilket ar lite mer effektivt och gor den

annu battre.

For att minska arbetsbordan, men ocksa for att det var svart att uppna nagot lika

bra, valdes ett bibliotek med dessa egenskaper for rattstavning kallat Hunspell och en

separat sokmotor kallad Lucene ut. Hunspell anvands vanligen i de flesta Open-Source1-

projekten som behover rattstavning. Lucene a andra sidan anvands framst nar det behovs

en sokmotor med stor funktionalitet och enkel utbyggnad.

Ordlistan som Lucene och Hunspell anvander byggs nu upp av blockets annonsrubri-

1Open-Source ar en strategi for design, utveckling och distribution av programvara som erbjuder

praktisk tillgang till programvarans kallkod.

25

ker, den sorteras enligt hur ofta varje ord forekommer i fallande ordning.

Nar anvandaren matar in sitt ord i sokfaltet kontrolleras ordet mot ordlistan. Om ordet

inte finns med i ordlistan kommer en sokning att genomforas pa anvandarens felstavade

ord, men han kommer aven att fa upp ett forslag pa vad han kan ha menat egentligen. Det

forslag som anvandaren far upp ar baserat pa hur manga ganger det forekommer i alla

annonser och hur pass likt det ar ordet anvandaren matade in. Storst vikt laggs pa hur

pass likt ordet ar det inmatade ordet. For att bestamma vilket av de tva alternativen som

Figur 3.1: Pa detta satt kommer ordlistan att byggas upp nar Hunspell implementeras i

det fardiga systemet.

var bast anpassat till www.blocket.se gjordes tester genom att kora samma ord genom

de bada stavningskontrollerna (se appendix E). Det alternativ som efter tio felstavade

ord hade lyckats rattstava flest, blev det alternativ som www.blocket.se skulle anvanda

sig av. Under testet visade det sig att Lucene inte klarade sarskrivningar lika bra som

Hunspell och Lucene var inte heller lika anpassat till det svenska spraket som Hunspell.

Detta beror antagligen pa att Hunspell har anvants i manga ordbehandlare medan Lucene

enbart har varit anpassat for just sokfalt och dess huvudsyfte ar sok. Valet foll alltsa

pa Hunspell eftersom det klarade av sarskrivningar och hade stod for svenska i storre

utstrackning, men aven for att det har stod for manga andra sprak. Fordelen med att det

26

klarar av manga sprak ar att detta ska kunna lanseras i fler lander an Sverige.

Det finns dock vissa problem med Hunspell, speciellt nar ordlistan innehaller felsta-

vade ord, ordlistan ar namligen lag for Hunspell. Detta betyder att ordlistan inte far

innehalla nagra felstavade ord eller atminstone sa fa felstavade ord som mojligt, da det

inte ser sarskilt bra ut nar ett felstavat ord visas for anvandaren. Anledningen till att

detta problem uppstar ar for att ordlistan skapas av alla annonser. En losning ar dock

att Hunspell valjer det ord som rankas hogst beroende pa frekvens i alla annonser, pa sa

vis undviks detta problem.

Det viktigaste med denna funktion ar att den blir snabb och att resultatet syns tydligt

for anvandaren. Implementationen gor att anvandaren kan soka och fa traffar aven om

han eller hon har svart med stavning. Dessutom eftersom en felsokning aldrig korrigeras

kommer de annonser som stavats fel ocksa att visas. En stor aspekt i detta problem ar

att det maste se sa enkelt ut som mojligt for anvandaren, som sagts tidigare ar B Locket

AB:s filosofi att allt ska se sa enkelt ut som mojligt. Darfor har det lagts stor vikt vid

designen av detta, det ar ocksa nagot som kommer att vidareutvecklas aven efter detta

projekt.

For att ge en bild over hur det skulle kunna se ut ges ett exempel i figur 3.2. I detta

projekt togs designbesluten i diskussion med handledare och de ansvariga for designen

pa siten. Eftersom foretaget vill ha sitt att saga till om blev designen inte helt fullstandig

under projektets gang.

Figur 3.2: Ett exempel pa hur ”Menade du”-implementationen kan komma att se ut i

framtiden pa www.blocket.se, visas har som en bild pa den slutgiltiga prototypen.

27

3.2 Sarskrivning

Den implementation som testats av Hunspell klarar av sarskrivning valdigt bra forutsatt

att ordlistan innehaller det ratta ordet. Nackdelen med Hunspell i det har laget ar att den

inte klarar av att skilja pa sarskrivning och tva helt skilda ord. T.ex om soktermen ”volvo

v70” matas in ger Hunspell forslaget ”volvo”, vilket i det har fallet ar helt fel eftersom

anvandaren faktiskt var ute efter den specifika modellen ”v70”. Kan detta forhindras pa

nagot satt och hur kan Hunspell tvingas till att foresla ratt ord?

Sattet att losa detta problem blev att varje mening delas in i ordpar och sa vidare,

t.ex ”volvo v70’ blir ”volvo”, ”volvo v70” och ”v70”. Det har tvingar Hunspell att valja

”volvo v70”, forutsatt att det alternativet finns och ar hogt prioriterat. Tyvarr har inte

denna losning implementerats i den riktiga prototypen vilket gor att sarskrivningar kan

accepteras som godkanda soktermer. Anledningen till att detta inte implementerats var

for att tiden blev for knapp.

3.3 Stemming och Lemmatization

De alternativ som fanns var stemming utan ordlista eller med ordlista, samt lemmatiza-

tion. De tester som utforts visade ganska snart att stemming utan ordlista inte fungerar

eftersom den plockar ut sa pass manga felaktiga ordstammar. Hade denna anvants ha-

de anvandaren kunnat fa valdigt konstiga traffar och framforallt fatt traffar pa andra

omraden an det han eller hon var ute efter (se appendix F).

Lemmatization daremot ar enligt kallor alldeles for berakningstungt jamfort med

stemming, detta enligt doktor Martin Hassel vid sprakvetenskapliga institutionen pa

KTH, se appendix D. De tester som utforts av forskare inom lingvistik visar att stem-

ming med ordlista som genomgatt morfologisk analys ar tillrackligt bra for sokningar

efter artiklar[36]. Artiklar och annonser ar liknande i den meningen att de bada i stort

sett enbart bestar av text som kan vara skriven med talsprak och dessutom mycket fel-

stavningar. Darfor faller valet pa stemming med ordlista, eftersom ordlistan kan byggas

upp manuellt och kontrollerat. Dessutom ar denna variant som sagt betydligt mindre

berakningstung vilket ar ett stort krav da antalet annonser ar valdigt manga, trots att

den kan ge fler fel an lemmatization sa vager effektiviteten nagot tyngre i det har fallet.

Hunspell som kontrollerar stavningen kan aven utfora stemming. For att fortydliga

fanns det tva val med ordlista, stemming med ordlista som det ej utforts morfologisk

analys pa och stemming med ordlista dar det har utforts morfologisk analys. De ar ungefar

lika snabba men den variant som anvander morfologisk analys ar nagot mer precis och

28

ger farre felaktiga ordstammar. Denna metod ar alltsa battre och eftersom skillnaden i

hastighet dem emellan ar sa pass lag finns det ingen anledning till att inte valja den

metod som ger lagre antal fel.

For att stemming ska fungera sa bra som mojligt maste konstanta uppdateringar av

ordlistan ske, tyvarr kommer manga av dessa att behova ske manuellt, da det kan vara

svart att tacka in precis alla fall. Aven den svenska ordlistan uppdateras idag manuellt

eftersom det hela tiden laggs till nya ord i det svenska spraket.

Stemming ar nagot som redan ingar i dagens sokmotor pa www.blocket.se och aven

i de flesta moderna sokmotorer pa marknaden. Med denna rapport tillkommer dock en

forbattring av den redan existerande varianten av stemming med Hunspell.

Det stora problemet som fanns tidigare var att ord kunde sammanflatas och vissa

ord kunde kortas ner for langt sa att de inte langre hade nagon betydelse, detta lostes i

och med att ordlistan fick en konstant uppdatering. Nackdelen ar att det tar lite tid att

uppdatera ordlistan och det kan vara svart att se vilka ord som kortas ner felaktigt, men

nar uppdateringarna gors kommer ocksa forbattringen vilket gor att tiden som laggs ner

pa uppdatering tas igen i effektivitet.

Den har forbattringen av sokmotorn ar inget som anvandaren kommer att se men det

gor att traffarna han eller hon far blir fler. Stemming gor alltsa sokmotorn forbattrad i

fraga om att presentera fler relevanta resultat for anvandaren, vilket i sin tur gor att fler

annonser kommer synas och fler personer far mojlighet att salja sina begagnade prylar.

3.4 Synonymer

Synonymerna anvands for att lata anvandaren fa fler traffar. Det kommer framforallt att

anvandas for produkter som kan benamnas pa flera olika satt. T.ex. ”playstation 3”2 och

”ps3”. Detta kommer att anvandas varje gang en sokning gors.

Nar anvandaren har matat in sin sokterm skickas den termen till synonymbehand-

laren. Har kommer soktermen att jamforas mot synonymordlistan, darefter plockas dess

synonymer ut och anvands i den totala sokningen. Den stora nackdelen med implementa-

tionen ar att synonymordlistan maste byggas upp fran noll. Den kommer alltsa att byggas

upp manuellt och varje ord som finns i ordlistan har da kontrollerats av en utvecklare.

Tyvarr blir detta nagot omstandigt men samtidigt uppnas en valdig kontroll pa vilka ord

som faktiskt ska inga och forhoppningsvis kommer det att minska antalet fel.

Synonymimplementationen leder till en breddad sokning dar varje synonym och den

2En spelkonsol fran foretaget Sony.

29

ursprungliga soktermen kommer anvandas for att gora forfragningar mot databasen. I

forlangningen kan det har gora att sokmotorn blir nagot mer belastad men det ska inte

paverka den sa mycket att det inte ar mojligt att genomfora, detta har tagits i beaktande

av B Locket AB innan valet foll pa att det faktiskt skulle implementeras.

3.5 Autocomplete

Eftersom sokmotorn som anvands idag inte klarar av de delar som behovs for att utfora

autocomplete pa det satt som B Locket AB vill, byggdes en egen utefter en Open-source-

sokmotor kallad Lucene. Denna sokmotor ar anpassad for just textsokning i stora sy-

stem och med stora datamangder. For att kunna utnyttja denna sokmotor pa basta

satt anvands en sokserver kallad Solr[29], Solr ar anpassad till Lucene och har manga

redan fardigbyggda komponenter for att bade indexera och soka med hjalp av Lucene.

Sattet som autocomplete losts pa ar att sokmotorn enbart indexerar alla annonsrubriker.

Figur 3.3: Skillnaden mellan att spara falt och inte vid uppslagning mot index.

Pa sa satt minskar datamangden, vilket ger en snabbare funktionalitet och effektivare

forslagshantering, men forslagen blir fortfarande relevanta. For att ytterligare oka effek-

tiviteten vid extrahering av data sparas faltet (ID ar faltet som sparas och detta falt ar

30

unikt for alla entiteter)som anvands vid uppslagning i index, skillnaden mot att inte spa-

ra datan kan ses i figur 3.3. Beroende pa hur mycket data som innehaller den eftersokta

termen desto langre tid tar det att fa forslagen.

Varje annonsrubrik bestar av max 40 tecken vilket specificerats av B Locket AB som

darmed vill begransa anvandarna for att rubriken ska vara sa kort och koncis som mojligt.

Annonsrubriken ska helt enkelt bara innehalla nodvandig information om produkten. Vid

indexeringstillfallet ses varje ord i varje rubrik som ett N-gram, vilket innebar att varje

rubrik indexeras ord for ord. Detta ger manga fler platser i indexet, vilket kan gora

sokningen seg, men detta loses genom nagot som liknar memcache. Sa stora delar som

mojligt av datan sparas i RAM-minnet, vilket gor att den ar mer lattillganglig och darfor

gar snabbare att sla upp. Ett exempel pa hur denna uppdelning fungerar ar rubriken

”volvo v40 2,0” som efter indexering ser ut enligt foljande:

volvo volvo v40 volvo v40 2,0

v40 v40 2,0

2,0

Denna mening far alltsa 6 platser i indexet. Anledningen till att rubrikerna delas upp pa

detta satt ar for att anvandaren ska fa forslag pa just det ord han eller hon borjar skriva

och inte en hel rubrik pa en gang.

Nar anvandaren borjar mata in sin sokterm kommer ett anrop ske mot sjalva autocomplete-

delen. Har kontrolleras sedan vilka ord som kan passa ihop med det anvandaren redan

har skrivit.

Varje annonsrubrik har indexerats enligt tidigare forklarat satt, detta kallas inverted

index3[11, 12].

De bokstaver anvandaren slagit in matchas mot alla rubriker, darmed hamtas de rubri-

ker ut som innehaller den textstrang anvandaren matat in. Nasta steg ar att anvandaren

far upp en forslagslista med ett specifikt antal ord och ordpar som innehaller just den

strang han eller hon matat in, dessa forslag ar alltsa delar av annonsrubriker som in-

nehaller den strang anvandaren matat in. Hur manga ord och ordpar som ska visas i

denna forslagslista kan enkelt stallas in genom att andra pa en variabel.

Fordelen med denna teknik ar att anvandaren snabbare kommer fram till vad han

eller hon vill soka efter och eftersom forslagen ar rubriker pa annonser kommer traffarna

att vara mer exakta. Dessutom kommer anvandaren att fa nagra fler alternativ om listan

presenteras pa detta satt, vilket i sin tur gor att fler annonser kommer fa uppmarksamhet.

B Locket AB stravar namligen efter att alla annonser ska fa lika mycket utrymme eftersom

3Ett index till en samling texter av orden i texterna.

31

alla betalar samma pris inom samma kategori, enligt foretaget sjalvt stravar de efter att

uppna nagot som liknar allemansratten[2].

Det stora problemet med denna implementation forutom hur sjalva forslagslistan skul-

le skapas var att fa designen att se sa enkel ut som mojligt pa www.blocket.se. Just att

det ska se enkelt ut ar nagot som B Locket AB verkligen star for och jobbar hart for. Ett

forslag pa hur autocomplete kan se ut pa www.blocket.se kan ses i figur 3.4.

Figur 3.4: Ett exempel pa hur forslagslistan kan komma att presenteras for anvandaren

pa www.blocket.se.

32

Kapitel 4

Slutsats, diskussion och framtida

arbete

Vilka forbattringar har skett och vad kan goras for att forbattra dem ytterligare?

4.1 Slutsats och Diskussion

De krav som sattes pa prototypen av B Locket AB i projektets uppstart har motts till

viss del. Alla delar som undersokts och som B Locket AB ville ha implementerade hann

inte fa tillrackligt bra resultat for en implementation. Prototypen ar inte heller klar for

att ga i produktion da den maste genomga betydligt mer tester och framforallt testas

ur prestationssynpunkt nar flera anvandare utnyttjar den samtidigt. Det var dock inte

meningen fran borjan att den skulle bli klar for produktion sa detta ar inget misslyckande.

Nagra delar, som var mindre viktiga, ar inte implementerade eftersom det bara in-

nebar enklare modifieringar av det redan fungerande systemet. Dessa ar stemming och

synonymsokning. Stemming (se sida 17) finns som sagt sedan tidigare i B Locket AB:s

sokmotor och darfor ansags det onodigt att implementera denna funktionalitet i prototy-

pen. Stemming fungerar tillfredsstallande redan nu men kan forbattras avsevart genom

enkla uppdateringar i ordlistan, tyvarr manuella sadana. Inte heller synonymsokningen

implementerades da tidsramen inte rackte till, dessutom ar detta nagot som inte ar helt

omojligt att implementera under en kortare period i det redan fungerande systemet. Sy-

nonymdelen borde kunna goras pa egen hand eftersom den i grunden enbart handlar om

att koppla ord till andra ord. Den framsta anledningen till att de har bada delarna inte

implementerades var att de inte var lika viktiga for B Locket AB. De delar som mest

fokus lades pa var darfor rattstavningen och autocomplete, efter onskemal fran B Locket

33

AB. Med hjalp av Lucene:s API och dess redan fungerande komponenter var det relativt

Figur 4.1: Pa det har sattet skulle alla delar kopplas samman i slutprototypen om lite

mer tid funnits att tillga.

enkelt att implementera autocomplete i prototypen. Det som skapade problem var an-

passningen till www.blocket.se. Da vilken ordlista som helst inte kunde anvandas var

en egen tvungen att skapas, detta gjordes av alla annonsrubriker. Om en vanlig ordlis-

ta hade anvants hade det inte haft nagon som helst relevans till www.blocket.se och

34

anvandaren hade fatt upp helt meningslosa forslag. Annonsrubriker anvandes istallet for

hela annonser eftersom en sa liten men fortfarande relevant datamangd skulle anvandas.

Pa samma satt skapas ordlistan for rattstavning, tyvarr ar inte den slutgiltiga losningen

for rattstavning implementerad i prototypen eftersom denna kom till forst i slutet av

projektet. Versionen av rattstavning som ar implementerad i prototypen ar inte helt felfri

da den ibland kan ge konstiga forslag, men sjalva grundiden finns dar och den kommer

vidareutvecklas av B Locket AB under detta ar. De storsta delarna som tar hand om

autocomplete i prototypen kan ses i bilaga A och bilaga B.

Det stora problemet inom rattstavning ar framforallt sarskrivning. Hunspell borde

losa detta nar det implementeras, men det ar valdigt viktigt att ordlistan som skapas

uppdateras frekvent eftersom annonser kommer och gar ofta. Hunspell loste detta problem

nar det utfordes tester pa sma datamangder, risken ar dock att den blir for langsam nar

datamangden okar. For att se ungefar hur det fungerar idag kan bilaga C vara intressant.

Ett forslag ar att ordlistan skapas samtidigt som indexeringen sker, mest for att mins-

ka antalet tillfallen som sa tunga operationer gors. Slutsatsen som kan dras av hela

rattstavningsimplementationen ar att det egentligen inte ar en rattstavare. Det ar mer

korrekt sagt, en forslagsgivare som ger forslag pa vad det ar anvandaren kan ha menat

som sokord, dar forslaget ger fler traffar.

Om Hunspell blir for kravande ar valdigt svart att svara pa i dagslaget. Det har beror

pa att en modifikation har gjorts av sjalva biblioteket dar det blir en slags forslagsgivare

istallet for en rattstavare som det ar i grunden. Det kan dock inte fattas ett slutgiltigt

beslut om det ar for kravande eller ej forran det faktiskt testats fullt ut, vilket tyvarr inte

tidsramen tillat.

Pa relativt sma datamangder (ca 100 000 ord) klarar Hunspell av att leverera ett

forslag inom en tillfredsstallande tid, namligen under 0,5 sekunder.

Autocomplete daremot var nagot som den nuvarande sokmotorn inte hade klarat

av att implementera enligt B Locket AB:s krav. Detta eftersom den inte klarar av att

indexera sa att ord kopplas till ord, anledningen till att den inte klarar detta ar for att

den enbart behovde kunna soka i stora textmangder tidigare. Lucene daremot har denna

funktionalitet och darfor anvandes denna.

Lucene ar valdigt enkelt och har ett valdigt tydligt API1, vilket gjorde att det gick

betydligt snabbare att implementera autocomplete-funktionaliteten an om en sokmotor

skulle byggts fran grunden. Autocomplete fungerar sa pass bra att den skulle kunna

1Application Programming Interface, en regeluppsattning for hur en programvara kan kommunicera

med annan.

35

implementeras nastan pa en gang, anledningen till detta ar for att den testats med

www.blocket.se:s alla annonser redan och ger da svar inom 0-100ms, vilket ar en till-

fredsstallande tid enligt B Locket AB.

4.2 Framtida arbete

Vad kan goras for att forbattra de undersokta delarna i framtiden?

Autocomplete

Om annonsmangden blir storre kan denna funktionalitet behova fa sig en omstrukturering,

ifall effektiviteten skulle paverkas avsevart vill saga.

Eftersom autocomplete maste vara en snabb tjanst ar det bra om datamangden halls

nere, anledningen till kravet pa snabbhet ar for att det ska vara ett hjalpmedel och inte

ett storande moment i anvandarens upplevelse av besoket pa www.blocket.se. Detta

skulle till exempel kunna goras genom att indexeringen sker enligt huvudkategori eller

till och med kategori. Pa sa vis minskar datamangden, men samtidigt visas enbart funk-

tionaliteten nar huvudkategori eller som i andra fallet kategori valts, vilket kan vara en

nackdel.

For att undvika autocomplete forst nere i kategorilage behover applikationen testas

med storre datamangd och se ifall det paverkar snabbheten avsevart eller om det fortfa-

rande ror sig inom ungefar samma tidsram. Dessutom maste denna funktionalitet testas

pa www.blocket.se for att fa reda pa om det kommer att fungera i verkligheten, med

verkligheten menas att flera personer anvander tjansten samtidigt.

Efter diskussion med personal pa B Locket AB kom en losning fram som innebar att

sorteringen sker pa lan, kategori och underkategori. Om detta sen blir den slutgiltiga

versionen kommer autocomplete att finnas i alla steg och dessutom ge mer relevanta

forslag till anvandaren.

Rattstavning

Rattstavning och sarskrivning ar nagot som standigt kan forbattras, framst av den anled-

ning att datorer har valdigt svart for just detta problem. Darfor ar det bra om flera haller

koll pa nya forbattringar av de algoritmer som finns ute pa marknaden. Uppdateringar

av Hunspell kommer ganska frekvent och dessa innebar ofta en hel del ny funktionalitet.

Rattstavningen overlag behover hantera sarskrivningar pa ett battre satt. Eftersom

ordlistan skapas av annonser som ibland kan innehalla sarskrivningar maste varje me-

36

ning delas upp i ordpar och rangordnas efter hur manga ganger varje ord eller ordpar

forekommer. Detta gor att sarskrivningar undviks till storsta delen aven om det finns

en liten risk for att det kan handa att en sarskrivning kommer som forslag anda. Detta

skulle kunna forbattras enbart om algoritmerna som finns idag hanterade sarskrivning pa

andra satt. Med andra ord behover det testas nya satt att komma runt detta problem.

Synonymer

Har maste det goras en ordentlig lista pa vilka ord som ar synonymer till vilka for att fa sa

manga traffar som mojligt. Detta skall ocksa implementeras i B Locket AB:s nuvarande

sokmotor, vilket inte gjorts under detta projekt.

Stemming

I det har fallet ar det inte mycket som kan goras i framtida arbete. Det viktigaste ar att

tanka pa uppdatering av den ordlista med regler for hur varje ord far kapas ner. Som

diskuterades tidigare ar detta tyvarr ett fall dar manuella operationer maste goras for

att fa funktionaliteten att halla sa hog niva som mojligt, med andra ord minska antalet

felaktiga resultat.

37

Litteraturforteckning

[1] Ajax, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Ajax_

(programming).

[2] Allemansratten, kontrollerad senast 20100104. http://www.sverigeturism.se/

smorgasbord/smorgasbord/natrecspo/nature/every.html.

[3] Bloomfilter for rattstavning, kontrollerad senast 20100104. http://en.wikipedia.

org/wiki/Bloom_filter.

[4] Browser-side-cache, kontrollerad senast 20100104. http://ajaxpatterns.org/

Browser-Side_Cache.

[5] Cache, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Cache.

[6] Extreme programming, the agile method, kontrollerad senast 20100104. http://

www.extremeprogramming.org/.

[7] Hashing, functions and tables, kontrollerad senast 20100104. http://www.itl.

nist.gov/div897/sqg/dads/HTML/hash.html.

[8] HTTP och dess specifikationer, kontrollerad senast 20100104. http://www.w3.org/

Protocols/rfc2616/rfc2616.html.

[9] Hunspell, spellchecking, stemming and morphological analysis, kontrollerad senast

20100104. http://hunspell.sourceforge.net/.

[10] Indexering, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Index_

(search_engine).

[11] Inverted index, kontrollerad senast 20100104. http://www.itl.nist.gov/div897/

sqg/dads/HTML/invertedIndex.html.

[12] Inverted indexes, kontrollerad senast 20100104. http://pages.cs.wisc.edu/

~asaxena/docs/inverted_index.ps.

38

[13] Jaro-winkler, algoritm for avstandsmatning mellan ord, kontrollerad senast

20100104. http://www.itl.nist.gov/div897/sqg/dads/HTML/jaroWinkler.

html, http://en.wikipedia.org/wiki/Jaro-Winkler_distance.

[14] Javascript kontrollerad senast 20100104. http://en.wikipedia.org/wiki/

JavaScript.

[15] jquery autocompletion, kontrollerad senast 20100104. http://plugins.jquery.

com/project/auto-complete.

[16] Kth:s sprakvetenskapliga avdelning, implementering av en rattstavningsalgoritm,

kontrollerad senast 20100104. ftp://ftp.nada.kth.se/pub/documents/Theory/

Viggo-Kann/TRITA-NA-9813.pdf.

[17] Lemmatization, kontrollerad senast 20100104. http://www.diegesis.co.uk/

glossary.html#L.

[18] Levenshteins distance algorithm for comparison between strings, kontrollerad senast

20100104. http://en.wikipedia.org/wiki/Levenshtein_distance.

[19] Lucene search engine, kontrollerad senast 20100104. http://lucene.apache.org/

java/docs/.

[20] Lucenes rattstavningsimplementation, kontrollerad senast 20100104. http://wiki.

apache.org/jakarta-lucene/SpellChecker.

[21] Memcached, ett satt att fordela belastningen, kontrollerad senast 20100104. http:

//www.danga.com/memcached/.

[22] Morphological analysis, kontrollerad senast 20100104. www.cl.ut.ee/yllitised/

smugri_toolbox_2001.rtf.

[23] Mythes, a method for synonym fetching, kontrollerad senast 20100104. http://

lingucomponent.openoffice.org/thesaurus.html.

[24] N-grams, kontrollerad senast 20100104. http://www.w3.org/TR/ngram-spec/.

[25] Open-office, open-source alternative to microsofts office package, kontrollerad senast

20100104. http://www.openoffice.org/.

[26] Ordlista over vanliga termer inom data, kontrollerad senast 20100104. http://www.

nada.kth.se/dataterm/fos-lista.html#f99.

39

[27] Scriptaculous autocompletion, kontrollerad senast 20100104. http://wiki.github.

com/madrobby/scriptaculous/ajax-autocompleter.

[28] Snowball stemming, a library for stemmingalgorithms, kontrollerad senast 20100104.

http://snowball.tartarus.org/.

[29] Solr search platform, kontrollerad senast 20100104. http://lucene.apache.org/

solr/#intro.

[30] Soundex, kontrollerad senast 20100104. http://www.creativyst.com/Doc/

Articles/SoundEx1/SoundEx1.htm.

[31] Spider in search engines, also called web crawling, kontrollerad senast 20100104.

http://en.wikipedia.org/wiki/Web_crawling.

[32] Stemming, kontrollerad senast 20100104. http://people.dsv.su.se/~hercules/

papers/karlgrendalianisjongejan-LREC2008_final.pdf.

[33] Submission-throttling, kontrollerad senast 20100104. http://ajaxpatterns.org/

Submission_Throttling.

[34] Sokmotorns beskrivning, kontrollerad senast 20100104. http://en.wikipedia.org/

wiki/Web_search_engine.

[35] Sokstrang, kontrollerad senast 20100104. http://en.wikipedia.org/wiki/Web_

search_query.

[36] Bart Jongejan Jussi Karlgren, Hercules Dalianis. Experiments to investigate the

connection between case distribution and topical relevance of search terms in an

information retrieval setting, kontrollerad senast 20100104. http://people.dsv.

su.se/~hercules/papers/karlgrendalianisjongejan-LREC2008_final.pdf.

[37] Johan Carlberger Viggo Kann Rickard Domeij, Ola Knutsson. Granska - ett effektivt

hybridsystem for kontroll av svensk grammatik, kontrollerad senast 20100104. http:

//www.csc.kth.se/tcs/projects/granska/rapporter/Nodalida-sv.doc.

40

Bilaga A

Autos.java

Spellchecking code for Lucene/Solr.

1 import java . i o . IOException ;

2 import java . i o . Pr intWriter ;

3

4 import javax . s e r v l e t . Se rv l e tExcept i on ;

5 import javax . s e r v l e t . http . HttpServ l e t ;

6 import javax . s e r v l e t . http . HttpServ letRequest ;

7 import javax . s e r v l e t . http . HttpServletResponse ;

8

9 import org . apache . s o l r . c l i e n t . s o l r j . SolrQuery ;

10 import org . apache . s o l r . c l i e n t . s o l r j . So l rSe rve rExcept ion ;

11 import org . apache . s o l r . c l i e n t . s o l r j . impl . CommonsHttpSolrServer ;

12 import org . apache . s o l r . c l i e n t . s o l r j . r e sponse . Spel lCheckResponse ;

13 import org . apache . s o l r . common . params . Modi f iableSolrParams ;

14

15 /∗∗16 ∗ S e r v l e t implementat ion c l a s s Autos

17 ∗ Handles the ”Did You Mean:” r e q u e s t s

18 ∗/19 public class Autos extends HttpServ l e t {20 private stat ic f ina l long se r ia lVer s ionUID = 1L ;

21

22 public Autos ( ) {}23

41

24 private St r ing query ( S t r ing q ) {25 St r ing sugg = null ;

26 CommonsHttpSolrServer s e r v e r = null ;

27

28 try {29 s e r v e r = new CommonsHttpSolrServer ( ” http ://

l o c a l h o s t :8983/ s o l r ” ) ;

30 } catch ( Exception e ) { e . pr intStackTrace ( ) ; }31

32 // escape s p e c i a l c h a r a c t e r s

33 Modi f iableSolrParams params = new

Modif iableSolrParams ( ) ;

34 SolrQuery query = new SolrQuery ( ) ;

35 params . s e t ( ” qt ” , ”/ s p e l l ” ) ;

36 params . s e t ( ” s p e l l c h e c k ” , ” t rue ” ) ;

37 params . s e t ( ” s p e l l c h e c k . onlyMorePopular ” , ” t rue ” ) ;

38 params . s e t ( ” s p e l l c h e c k . c o l l a t e ” , ” t rue ” ) ;

39 params . s e t ( ” s p e l l c h e c k . q” , q ) ;

40 query . add ( params ) ;

41 query . setQuery ( ” ∗ :∗ ” ) ;

42

43 try {44 Spel lCheckResponse qr = s e r v e r . query ( query ) .

getSpel lCheckResponse ( ) ;

45 i f ( qr != null ) {46 sugg = qr . g e tCo l l a t edResu l t ( ) ;

47 }48 } catch ( So l rSe rve rExcept ion e ) {49

50 }51

52 return sugg ;

53 }54

55 public void doPost ( HttpServ letRequest request ,

42

56 HttpServletResponse re sponse )

57 throws Serv le tExcept ion , IOException {58 doGet ( request , r e sponse ) ;

59 }60

61 /∗∗62 ∗ @see H t t p S e r v l e t#doGet ( H t t p S e r v l e t R e q u e s t reques t ,

Ht tpServ l e tResponse response )

63 ∗/64 protected void doGet ( HttpServ letRequest req ,

HttpServletResponse r e s ) throws Serv le tExcept ion ,

IOException {65 St r ing q = req . getParameter ( ”q” ) ;

66 r e s . setCharacterEncoding ( ”UTF−8” ) ;

67 Pr intWriter w r i t e r = r e s . getWriter ( ) ;

68 St r ing sugge s t i on = query ( q ) ;

69 i f ( sugge s t i on != null ) {70 w r i t e r . p r i n t l n ( sugge s t i on ) ;

71 }72 }73 }

43

Bilaga B

Auto.java

Autocomplete in Lucene/Solr

1 import java . i o . IOException ;

2 import java . i o . Pr intWriter ;

3 import java . u t i l . L i s t ;

4

5 import javax . s e r v l e t . Se rv l e tExcept i on ;

6 import javax . s e r v l e t . http . HttpServ l e t ;

7 import javax . s e r v l e t . http . HttpServ letRequest ;

8 import javax . s e r v l e t . http . HttpServletResponse ;

9

10 import org . apache . s o l r . c l i e n t . s o l r j . SolrQuery ;

11 import org . apache . s o l r . c l i e n t . s o l r j . So l rSe rve rExcept ion ;

12 import org . apache . s o l r . c l i e n t . s o l r j . impl . CommonsHttpSolrServer ;

13 import org . apache . s o l r . c l i e n t . s o l r j . r e sponse . QueryResponse ;

14 import org . apache . s o l r . c l i e n t . s o l r j . r e sponse . TermsResponse ;

15 import org . apache . s o l r . c l i e n t . s o l r j . r e sponse . TermsResponse . Term ;

16

17 /∗∗18 ∗ S e r v l e t implementat ion c l a s s Auto

19 ∗ Handles the autocomplete−f e a t u r e

20 ∗/21 public class Auto extends HttpServ l e t {22

23 private stat ic f ina l long se r ia lVer s ionUID = 1L ;

44

24

25 public Auto ( ) {}26

27 private List<Term> query ( S t r ing q , S t r ing l i m i t ) {28 List<Term> i tems = null ;

29 CommonsHttpSolrServer s e r v e r = null ;

30

31 try {32 s e r v e r = new CommonsHttpSolrServer ( ” http ://

l o c a l h o s t :8983/ s o l r ” ) ;

33 } catch ( Exception e ) { e . pr intStackTrace ( ) ; }34

35 // Set the q u e r i e s f e a t u r e s

36 SolrQuery query = new SolrQuery ( ) ;

37 query . addTermsField ( ” p r e f i x 2 ” ) ;

38 query . setTerms ( true ) ;

39 query . setTermsLower ( q ) ;

40 query . setTermsPre f ix ( q ) ;

41 query . setQueryType ( ”/ terms ” ) ;

42

43 try {44 QueryResponse qr = s e r v e r . query ( query ) ;

45 TermsResponse resp = qr . getTermsResponse ( ) ;

46 items = resp . getTerms ( ” p r e f i x 2 ” ) ;

47 } catch ( So l rSe rve rExcept ion e ) {48 items = null ;

49 }50

51 return i tems ;

52 }53

54 public void doPost ( HttpServ letRequest request ,

55 HttpServletResponse re sponse )

56 throws Serv le tExcept ion , IOException {57 doGet ( request , r e sponse ) ;

45

58 }59

60 /∗∗61 ∗ @see H t t p S e r v l e t#doGet ( H t t p S e r v l e t R e q u e s t reques t ,

Ht tpServ l e tResponse response )

62 ∗/63 protected void doGet ( HttpServ letRequest req ,

HttpServletResponse r e s ) throws Serv le tExcept ion ,

IOException {64 St r ing q = req . getParameter ( ”q” ) ;

65 St r ing l i m i t = req . getParameter ( ” l i m i t ” ) ;

66 r e s . setCharacterEncoding ( ”UTF−8” ) ;

67 Pr intWriter w r i t e r = r e s . getWriter ( ) ;

68 List<Term> terms = query (q , l i m i t ) ;

69

70 i f ( terms != null ) {71 for (Term t : terms ) {72 w r i t e r . p r i n t l n ( t . getTerm ( ) ) ;

73 }74 }75 }76 }

46

Bilaga C

main.c

1 #include <s t d i o . h>

2 #include <s t d l i b . h>

3 #include <s t r i n g . h>

4 #include ” . . / hunspe l l / hunspe l l . h”

5 #include ”/ Users / b locke t /Downloads/ l ibstemmer c / inc lude /

l ibstemmer . h”

6 #include ”munch . h”

7 // Takes out one s u g g e s t i o n to the user , i f he has m i s s p e l l e d

h i s searchterm or i f h i s searchterm doesn ’ t g i v e as many

r e s u l t s as another

8 int numChar = 0 ;

9 char words [ 1 0 1 ] ;

10 char∗ sugge s t i on ;

11 int l ine num = 0 ;

12 int prev l ine num = 0 ;

13 int numLines ;

14 const sb symbol∗ stemmed ;

15

16 char∗ toLowerCase ( char∗ s t r )

17 {18 int d i f f e r = ’A ’− ’ a ’ ;

19 char ch ;

20 for ( int i =0; i < s t r l e n ( s t r ) ; i++)

21 {

47

22 strncpy(&ch , s t r+i , 1 ) ;

23 i f ( ch>=’A ’ && ch<=’Z ’ )

24 {25 ch = ch−d i f f e r ;

26 memcpy( s t r+i ,&ch , 1 ) ;

27 }28 }29 return s t r ;

30 }31

32 int s a v e p r i v d i c ( char ∗ f i l ename , char∗ w)

33 {34 FILE ∗ d i c = fopen ( f i l ename , ” r ” ) ;

35 i f ( d i c ) {36 f c l o s e ( d i c ) ;

37 d i c = fopen ( f i l ename , ”a” ) ;

38 }39 i f ( ! d i c ) return 0 ;

40 f p r i n t f ( dic , ”%s\n” , w) ;

41 f c l o s e ( d i c ) ;

42 return 1 ;

43 }44

45 // Checks which word , t h a t i s sugges ted , t h a t a c t u a l l y occurs

the most t imes in a f i l e

46 void sugges t ( int ns , char∗∗ sugg , char∗∗ cor r sugg , char∗ word )

{47 prev l ine num = numLines ;

48 l ine num = 0 ;

49 sugge s t i on = ”” ;

50 int k = 0 ;

51 for ( int j = 0 ; j < ns ; j++) {52 for ( int i = 0 ; i < numLines − 1 ; i++) {53 i f ( strcasecmp ( sugg [ j ] , c o r r sugg [ i ] ) ==

0) {

48

54 l ine num = i ;

55 break ;

56 }57 }58 i f ( l ine num < prev l ine num ) {59 i f ( sugg != NULL) {60 sugge s t i on = sugg [ j ] ;

61 }62 prev l ine num = line num ;

63 }64 }65

66 for ( int i = 0 ; i < numLines − 1 ; i++) {67 i f ( strcasecmp ( word , co r r sugg [ i ] ) == 0 && k ==

0) {68 l ine num = i ;

69 k = 1 ;

70 break ;

71 }72 }73 i f ( l ine num < prev l ine num ) {74 i f ( k == 1) {75 sugge s t i on = word ;

76 }77 }78 }79

80 int main ( int argc , const char ∗ argv [ ] ) {81

82 // This f i l e con ta ins words to check

83 FILE∗ f i l e ;

84 f i l e = fopen ( ”/ Users / b locke t /Documents/ workspace /

wordcount/swe2 . d i c ” , ” r ” ) ;

85 i f ( f i l e == NULL) {

49

86 f p r i n t f ( s tde r r , ” Error − could not open f i l e to

check\n” ) ;

87 } else {88 while (1 ) {89 char c = getc ( f i l e ) ;

90 i f ( c == EOF) {91 break ;

92 }93 numChar++;

94 }95 }96 f c l o s e ( f i l e ) ;

97 f i l e = fopen ( ”/ Users / b locke t /Documents/ workspace /

wordcount/swe2 . d i c ” , ” r ” ) ;

98 char most sugg [ numChar ] ;

99 while ( ! f e o f ( f i l e ) ) {100 f g e t s ( words , numChar , f i l e ) ;

101 s t r c a t ( most sugg , words ) ;

102 numLines++;

103 }104

105 char∗ co r r sugg [ numLines ] ;

106 co r r sugg [ 0 ] = s t r t o k ( most sugg , ”\n” ) ;

107 for ( int i = 0 ; i < numLines − 1 ; i++) {108 co r r sugg [ i ] = s t r t o k (NULL, ”\n” ) ;

109 }110

111 f c l o s e ( f i l e ) ;

112

113 char∗ d i c t = ”/ Users / b locke t /Documents/ workspace /

wordcount/swe2 . d i c ” ;

114 char∗ a f f i x d i r = ”/ Users / b locke t /Downloads/ dssobui ld

−1.0/ sv . a f f ” ;

115 munch handler ( d ic t , a f f i x d i r ) ;

50

116 const char∗ d i c t a f f = ”/ Users / b locke t /Documents/

workspace /wordcount/ swea f f . d i c ” ;

117 Hunhandle∗ hunhandler = Hunspe l l c r e a t e ( a f f i x d i r , d i c t a f f

) ;

118 Hunhandle∗ hunstem = Hunspe l l c r e a t e ( a f f i x d i r , ”/ Users /

b locke t /Downloads/ dssobu i ld −1.0/ sv . d i c ” ) ;

119 char∗ w l i s t = ( char∗) mal loc ( s izeof 101) ;

120 struct sb stemmer ∗ stemmer ;

121 char ∗ language = ” swedish ” ;

122 char ∗ charenc = NULL;

123 char∗∗ r e s u l t ;

124 char∗∗ r e s u l t 2 ;

125 p r i n t f ( ” Please ente r word to s p e l l and stem :\n” ) ;

126

127 // Wait u n t i l the user e n t e r s a word

128 while ( f g e t s ( w l i s t , 102 , s td in ) ) {129 ∗( w l i s t + s t r l e n ( w l i s t ) − 1) = ’ \0 ’ ;

130 /∗ do the stemming proces s wi th s n o w b a l l ∗/131 stemmer = sb stemmer new ( language , charenc ) ;

132 i f ( stemmer == 0) {133 i f ( charenc == NULL) {134 f p r i n t f ( s tde r r , ” language ‘%s ’

not a v a i l a b l e f o r stemming\n”

, language ) ;

135 e x i t (1 ) ;

136 } else {137 f p r i n t f ( s tde r r , ” language ‘%s ’

not a v a i l a b l e f o r stemming in

encoding ‘%s ’\n” , language ,

charenc ) ;

138 e x i t (1 ) ;

139 }140 }141

142 char∗∗ sugg ;

51

143 int ns = Hunspe l l sugge s t ( hunhandler , &sugg ,

w l i s t ) ;

144 sugges t ( ns , sugg , cor r sugg , w l i s t ) ;

145 i f ( strcasecmp ( w l i s t , sugge s t i on ) != 0) {146 p r i n t f ( ”\nMenade du : ” ) ;

147 i f ( sugge s t i on != NULL && sugge s t i on !=

”” ) {148 p r i n t f ( ”\”%s \”\n\n” , sugge s t i on )

;

149 }150 }151

152 p r i n t f ( ”\n\”%s \” has the f o l l o w i n g stems : \n” ,

sugge s t i on ) ;

153 stemmed = sb stemmer stem ( stemmer , ( sb symbol ∗)

sugges t ion , s t r l e n ( sugge s t i on ) ) ;

154 int n1 = Hunspe l l ana lyze ( hunstem , &r e s u l t ,

toLowerCase ( sugge s t i on ) ) ;

155 int n2 = Hunspel l stem2 ( hunstem , &re su l t 2 ,

r e s u l t , n1 ) ;

156 int n3 = Hunspe l l sugge s t ( hunstem , &sugg ,

toLowerCase ( sugge s t i on ) ) ;

157 i f ( n2 == 0 && n3 >= 0) {158 p r i n t f ( ”Added : \”%s \”\n” , sugge s t i on ) ;

159 for ( int i = 0 ; i < n3 ; i++) {160 H u n s p e l l a d d w i t h a f f i x ( hunstem ,

toLowerCase ( sugge s t i on ) ,

sugg [ i ] ) ;

161 p r i n t f ( ”%s\n” , sugg [ i ] ) ;

162 }163 // s a v e p r i v d i c (”/ Users / b l o c k e t /Downloads

/ d s s o b u i l d −1.0/ sv . d i c ” , toLowerCase (

s u g g e s t i o n ) ) ;

164 }165 // Hunspel l−stemmer p r i n t o u t

52

166 p r i n t f ( ”\nHunspel l stems : \n” ) ;

167 for ( int i = 0 ; i < n2 ; i++) {168 p r i n t f ( ”\”%s \”\n” , r e s u l t 2 [ i ] ) ;

169 }170 for ( int i = 0 ; i < n1 ; i++) {171 p r i n t f ( ”\”%s \”\n” , r e s u l t [ i ] ) ;

172 }173 p r i n t f ( ”\nSnowballs stem :\n\”%s \”\n\n” , stemmed )

;

174 sb stemmer de l e te ( stemmer ) ;

175 /∗ H u n s p e l l f r e e l i s t ( hunhandler ,& sugg , ns ) ;

176 H u n s p e l l f r e e l i s t ( hunhandler ,& r e s u l t , n1 ) ;

177 H u n s p e l l f r e e l i s t ( hunhandler ,& r e s u l t 2 , n2 ) ; ∗/178 }179 f r e e ( w l i s t ) ;

180 f r e e ( co r r sugg ) ;

181 f r e e ( most sugg ) ;

182 Hunspe l l de s t roy ( hunhandler ) ;

183 Hunspe l l de s t roy ( hunstem ) ;

184 return 0 ;

185

186 }

53

Bilaga D

Mailkonversation med Martin Hassel

pa KTH:s sprakvetenskapliga

institution

Hej!

Martin: Hej Sven,

Sven:Jag heter Sven Viden och haller just nu pa med mitt exjobb. Detta handlar om

sokmotorer och hur de ska kunna goras mer anvandarvanliga. Darfor arbetar jag nu med

morfologisk analys m.m. Jag rattstavar orden som anvandaren slar in i sokfaltet men for

att sokningen ska bli sa bra som mojligt maste ordet stemmas ocksa.

Martin: Var gor du ditt exjobb? Vem ar din handledare?

Sven: Det ar just med stemming som mina problem uppstar. Just nu anvander jag

hunspell for att utfora detta. Nackdelen ar att ju storre ordlista desto enklare blir det att

orden overstemmas. Anvandaren kan alltsa fa traffar som inte alls har med hans/hennes

sokning att gora. Ordlistan ar taggad enligt vissa regler, den ar baserad pa Den Stora

Svenska Ordlistan”.http://dsso.se/

Sven: Jag har aven testat ett verktyg som kallas snowball som ar en algoritmisk

variant. Denna anvander inte alls ordlistor utan forlitar sig helt pa olika regler. (Storre

risk for over-stemming)

Martin: Snowballstemmern, som ar en vidareutveckling av Martin Porters klassiska

stemmer ar en av de mer erkanda - speciellt for engelska.

Sven: Det jag undrar ar da om ni kanske kan ge mig lite ideer eller kanske helt enkelt

att vi kan ses for ett mote dar vi kan diskutera olika losningar m.m.

Martin: En artikel som kan vara intressant for dig ar denna: http://people.dsv.

54

su.se/~hercules/papers/karlgrendalianisjongejan-LREC2008_final.pdf

Sven: Finns det andra losningar att gora stemming pa? Laste om lemmatization

nyligen, finns det nagra Open-source alternativ inom detta?

Martin: Ja, det finns ett antal mer eller mindre fria system system som kan lemma-

tisera, t.ex. GTA eller Brill (inget av dem helt open source dock).

Martin: Rent typiskt vill du dock av flera anledningar ha stemming i en sokmotor,

snarare an lemmatisering. En anledning ar att man for att astadkomma lemmatisering

maste veta ordklassen pa ordet som ska lemmatiseras, vilket leder till att du maste ha

grepp om grammatik och anvanda dig av ordets kontext. Det ar alltsa en betydligt tyngre

process att stoppa in lemmatisering i en (storskalig) sokmotor, an en stemmer som rent

typiskt enbart tittar pa ett ord i taget. Ett annat problem, du kan ju aven behova nor-

malisera sokfragan - i en tva, tre termer lang sokfraga, hur vet du da i den varje terms

ordklasstillhorighet (och darmed bojningsparadigm)? En enkel heuristik skulle visserligen

kunna vara att alltid ta den vanligaste ordklassen for varje (bojd) form, men da maste

du ha listor pa det.

Martin: Vidare, i manga fall soker man pa ett amne, eller ett koncept, snarare an det

specifika ord som i sokfragan far representera det amnet/konceptet. En stemmer har i viss

man mojlighet att fora samman semantiskt relaterade ord fran olika bojningsparadigm -

t.ex. cykla, cykel och cykling skulle alla kunna stemmas till den gemensamma stammen

cykl.

Vanligen, Martin...

55

Bilaga E

Resultat av rattstavningsjamforelse

Strangarna som matades in i Hunspell och Lucene var: ”vovlo”,”klas”,”balerina”,”sbab”,”kajka”,

”sgel”,”skpa”,”soni”,”ipdo”,”ballerina skor”

Onskat resultat: volvo, klass, ballerina, saab, kajak, skap, sony, ipod, ballerinaskor.

Lucenes resultat: volvo, klass, ballerina, saab,

kajsa, spel, skp, sony, indo, carina skor.

Antal ratt: 5/10

Hunspells resultat: volvo, glas, ballerina, saab,

kajak, spel, skap, sony, ipod, ballerinaskor.

Antal ratt: 9/10

Det kan latt ses i sista exempelfragan att Lucene har stora problem med sarskrivningar.

Hunspell daremot uppfattar detta och ger ratt svar.

56

Bilaga F

Resultat av stemmingjamforelse

//Hunspell anvander morfologisk analys i ordlistan Please enter word to spell and stem:

”kajaker” has the following stems:

Hunspell stems:

”kajak”

” st:kajak fl:H”

Snowballs stem:

”kajak”

”komplett” has the following stems:

Hunspell stems:

”komplett”

” st:komplett”

Snowballs stem:

”komplet”

”ballerina” has the following stems:

Hunspell stems:

”ballerina”

” st:ballerina”

Snowballs stem:

”ballerin”

”bilen” has the following stems:

Hunspell stems:

”bil”

” st:bil fl:D”

Snowballs stem:

57

”bil”

”hammare” has the following stems:

Hunspell stems:

”hammare”

” st:hammare”

Snowballs stem:

”hamm”

”segel” has the following stems:

Hunspell stems:

”segel”

” st:segel”

Snowballs stem:

”segel”

”registreringsnummer” has the following stems:

Hunspell stems:

” pa:nummer”

Snowballs stem:

”registreringsnumm”

”bromsar” has the following stems:

Hunspell stems:

”broms”

” st:broms fl:G”

Snowballs stem:

”broms”

”forska” has the following stems:

Hunspell stems:

”forska”

” st:forska”

Snowballs stem:

”forsk”

”forskajak” has the following stems:

Hunspell stems:

” pa:kajak”

Snowballs stem:

”forskajak”

58