Vidareutvecklat korpusverktyg med Granska som grund EMMA JOHANSSON

Transkript

1 Vidareutvecklat korpusverktyg med Granska som grund EMMA JOHANSSON Examensarbete Stockholm, Sverige 2009

2 Vidareutvecklat korpusverktyg med Granska som grund EMMA JOHANSSON Examensarbete i datalogi om 30 högskolepoäng vid Programmet för teknisk fysik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Viggo Kann Examinator var Stefan Arnborg TRITA-CSC-E 2009:127 ISRN-KTH/CSC/E--09/127--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Vidareutvecklat korpusverktyg med Granska som grund Sammanfattning Inom språkforskningen används stora mängder text, som organiseras i korpusar. En korpus är en ocensurerad textsamling. Texten i en korpus är ofta annoterad, vilket betyder att varje ord är uppmärkt med tilläggsinformation om exempelvis ordets grammatiska tillhörighet och meningstillhörighet. Att märka texten med grammatisk information kallas att tagga texten. Detta kommer av att ordets grammatiska information kodas i vad som kallas en tagg. Varje ord får således en tagg då texten taggas. För att som språkforskare arbeta med en korpus krävs verktyg som kan söka effektivt i textmängderna, som kan rätta fel i texten och som kan annotera texten ytterligare med manuella annoteringar. Det här examensarbetet går ut på att vidareutveckla en prototyp som byggts i två tidigare examensarbeten. Prototypen består av ett användargränssnitt med tillhörande användarserver som hanterar användarna och deras anrop samt en logikdel som hanterar all logik såsom sökningar i texterna och indexering av texterna för att förbereda sökning. I kärnan av logiksidan finnas grammatikgranskningsprogrammet Granska, som utvecklats på Nada institutionen för numerisk analys och datalogi, som är en gemensam institution för Kungliga Tekniska högskolan och Stockholms universitet. Den del av prototypen som hanterar användarna har, liksom själva användargränssnittet, skrivits i Java medan logikdelen är skriven i C++. Delarna ligger separat och kommunicerar med varandra över nätverket via socket/xml-uppkoppling. Prototypen använder sig av förindexering av korpus, för att få en effektiv sökning. Indexering görs på både taggbigram och token. Den vidareutveckling jag har gjort har varit inom tre områden. Jag har gjort utökningar i användargränssnittet som möjliggör att användaren gör flexibla ändringar i korpus, och inte bara accepterar de rättningar som verktyget föreslår. Jag har också utvecklat funktionalitet så att användaren kan spara sina rättningar och sedan använda dem vid fortsatt korpusarbete, dvs. verktyget tar hänsyn till användarnas respektive rättningar vid sökningar. Den sista delen av mitt examensarbete handlade om att ta fram ett förslag på hur man kan vidareutveckla verktyget för att hantera användardefinierade annoteringar. Ändringarna jag gjorde i lagring, indexering och sökalgoritm för att möjliggöra hanteringen av användarnas rättningar enligt krav var relativt framgångsrika. Jag kom dock fram till att ändringar i flera led, dvs. ändringar på ett ord som inte fanns i orginalkorpus utan som införlivats i meningen av en användare, inte fungerar i nuvarande lösning. För att klara av detta måste en justering i verktygets hantering av ordid göras. Justeringen kommer att slå igenom i flera lager. I orginalkorpus numreras orden i en text i löpordning och verktyget stomme som fanns innan mitt examensarbete tog vid, bygger i vissa delar på antagandet att orden har id i löpordning. För att spara utrymme innehåller överföringsprotokollet mellan logik- och användarsidan idag id för första och sista ord i en mening och användarsidan rekonstruerar sedan id på orden utefter detta och regeln att orden har löpnumrering. Detta måste ändras för att hantera ändringar i flera steg.

4 Tool for corpus correction and maintenance Abstract Within language technology research large amounts of text are used. The texts are organized in corpora, and often annotated, meaning that each word is noted with additional information such as word class, lemma and sentence belonging. To mark the text with this grammatical information is called to tag the text, since the grammatical information is encoded in a tag. Thus each word is labeled with a tag when the text is tagged. To work with a corpus as a language technology researcher you need tools to search efficiently in the texts, to correct errors in the text and to add your own annotations to the texts. This thesis aims to further develop a prototype with this functionality. The prototype was built in two previous theses. The prototype consists of a user interface with a user server that manages users and their work processes and a logical part that handles all the logic, such as searching in the texts and indexing of texts to prepare the search. The logic part is based on the grammar program Granska, which was developed at Nada The Department of Numerical Analysis and Computer Science which is a joint institution of the Royal Institute of Technology and Stockholm University. The part of the prototype that handles the users, and the actual user interface, is written in Java while the logic part is written in C++. The system is distributed and communicates over the network via socket/xml-connection. The prototype uses pre indexing of the corpus, to obtain an efficient search. Indexing is done on both tag bigram and token. I have extended the prototype in three areas. I have done extensions in the user interface allowing the user to make flexible changes in the corpus, and not only accept the corrections that the tool suggests based on rules. I have also developed functionality that enables users to save their corrections, and then use them further on in the continued work with the corpus, i.e. the tool takes the users respective corrections into account when processing queries. The last part of my thesis was to make a proposal on how to further develop the tool for managing userdefined annotations. The changes I made in the storage, indexing and search algorithm to enable the handling of user corrections as required was relatively successful. I came, however, to the conclusion that multiple changes, i.e. changes in a word that did not originally exist in the corpus but was inserted by a user, does not work in the present solution. To be able to handle this, an adjustment of the tool's handling of word ids must be made. This adjustment will affect several layers in the prototype. In the storage format of the original corpora the words are numbered in a text in consecutive order and the handling of corrections in the prototype is based on the assumption that words have id in consecutive order. This design was already made when I started my thesis. To save space, the transfer protocol between the server that handles the logic and the server that handles the user sessions only contain the id for the first and the last words in a sentence. The ids of the words in the sentence are then reconstructed on the user server based on the assumption that the words have ids in consecutive order. This must be modified in order to make the prototype able to handle multiple changes in a sentence.

5 Innehållsförteckning Inledning... 1 Bakgrund... 1 Uppgiften... 2 Rapportens struktur... 3 Bakgrund... 4 Språkteknologisk bakgrund... 4 Granska... 6 Annoteringsverktyget... 8 Överföringen mellan presentationslagret och logiklagret... 9 Presentationslagret Logiklagret Flexibla ändringar i korpus Bakgrund och användarkrav Vilka delar har förändras? Ny del av användargränssnittet Utökat överföringsprotokoll Förändringar i logiklagret Förslag på vidareutveckling Lagring av användarens rättningar Bakgrund och användarkrav Konstruktionsval Lagringsstruktur Lagringsformat Format för nya ord och för borttagna ord Överväganden vid implementationen Att distribuera ändringar Att radera ändringar Att ändra i flera led Framtida förbättringar Sökning med ändringar Bakgrund och användarkrav Konstruktionsval Överföring till indexstruktur Överväganden vid implementationen Överföring av loggfil till korpusformat Taggbigram... 28

6 Att skapa nya ordid:n Att skapa nya meningsid:n Hantering av nya ord- och meningsid:n Effektivitet Anpassad sökalgoritm Förslag på vidareutveckling Annoteringar Bakgrund och användarkrav Föreslagna konstrukstionsval Presentation av användarens annoteringar Presentation och redigering av användarens annoteringstyper Presentation och redigering av användarens annoteringar Lagringsstruktur för annoteringar Lagringsstruktur för annoteringstyper Lagringsformat för annoteringstyper Lagringsformat för annoteringar Utökningar vid implementation Förändringar i presentationslagret Förändringar i regelspråket Förändringar i överföringsprotokollet Slutsatser och diskussion Resultat Framtida förbättringsförslag Källförteckning Tryckta källor Intervjuer Webbsidor... 39

7 Inledning Inledning Bakgrund Inom språkforskningen finns behov av att samla ihop stora mängder text för att använda som forskningsmaterial. Textmängderna organiseras i s.k. korpusar. Det finns också behov av att förse varje ord med tilläggsinformation som beskriver meningsgränser, stycken och ordets grammatiska egenskaper såsom ordklass, grundform och meningstillhörighet. Att lägga till sådan information kallas att annotera eller tagga texten. En korpus är en stor annoterad textmängd. I en korpus finns det alltid en viss felfrekvens. Det kan vara både feltaggningar och fel i själva texterna. Det finns alltså ett behov av att kunna rätta och underhålla korpus och till det behövs kraftfulla verktyg. Det här examensarbetet bestod i att bygga vidare på en prototyp till ett sådant annoteringsverktyg. Den ursprungliga prototypen gjordes som två examensarbeten och består av ett användargränssnitt implementerat i Java av Helena Irhfors och en logisk del implementerad i C++ av Andreas Aarflot. Kärnan i den logiska delen utgörs av Granska, ett språkgranskningsprogram utvecklat på Nada. I sin vanliga form tar Granska vanlig text som indata och producerar med hjälp av ca 250 matchningsregler rättningsförslag som matas ut. I annoteringsverktyget används Granska på ett lite annat sätt. Indata är nu inte vanlig text utan taggad text. Användaren, en språkforskare, anger själv vilka regler som ska användas och vilka texter som ska bearbetas. Användaren kan själv skriva nya regler. Detta sker via ett gränssnitt. Informationen skickas sedan till en server där Granska analyserar texten med hjälp av den angivna matchningsregeln. Rättningsförslagen skickas sedan tillbaka till användaren som i ett svarsfönster manuellt markerar de rättningsförslagen som hon/han vill spara. Innan mitt arbete påbörjades kunde användaren bara välja att spara ändringar som Granska föreslår och inte skriva ändringar själv. Ändringarna sparades sedan bara som lokala loggfiler och användes inte till något. Verktyget kunde alltså endast användas till att söka på olika ord, ordföljder eller grammatiska konstruktioner, inte till att faktiskt införa ändringar. Min huvuduppgift har varit att göra det möjligt för användaren att införa sina sparade ändringar. Jag skulle dessutom lägga till funktionalitet som möjliggör för användaren att införa sina egna rättningar, inte bara sådana som Granska föreslår. Det var också önskvärt att utvidga verktyget med en funktionalitet som gör det möjligt för användaren att införa egna typer av annoteringar. Det ingick inte i min uppgift att implementera detta men att utreda och föreslå en lösning som ge användaren möjlighet att själv definiera upp nya typer av annoteringar, att annotera ett eller en följd av ord med sina egna annoteringstyper samt att visa text med annoteringar. Min föreslagna lösning gör det inte möjligt att söka på dessa nya typer av annoteringar, men lösningen har utformats på ett sådant sätt att en sådan utvidgning är möjlig, vilket ingick i uppgiftslydelsen. 1

8 Inledning Uppgiften Här följer en sammanställning av uppgiften för mitt examensarbete och de deluppgifter som skulle lösas. Lagring av användarens ändringar Alla användares ändringar lagrades innan mitt arbete tog vid i samma loggfil. Min uppgift var att hitta en lösning där varje användare kan lagra sina ändringar separat. Loggfilen som fanns förut låg lokalt på den server som hanterar de olika användarna och hade ingen kontakt med delarna där korpus och sökindex ligger. Den användes inte heller till något. Huvuduppgiften för mitt examensarbete var att implementera sökning med ändringar, se nedan, och jag var därför tvungen att ta ställning till var ändringarna borde lagras när de på lämpligt sätt ska införlivas i sökindex och på vilket sätt det nya sökindexet borde lagras. Ändringar i överföringsprotokollet var också aktuella för att möjliggöra ändringarna. Egna ändringar När en sökning görs i vald korpus enligt den regel som användaren skrivit, följer det med ett rättningsförslag till varje träff som påträffats i korpus. Rättningsförslaget baseras på den regeldefinition som användaren skrivit, där hon/han angett ett rättningsförslag som ska åtgärda felet i meningen, exempelvis att byta den mot det om substantivet står i neutrum. När mitt examensarbete tog vid, begränsades införandet av ändringar till valet att spara eller inte spara de föreslagna ändringarna. Min uppgift var att möjliggöra för användaren att enkelt kunna lägga till de ändringar som hon/han vill i en viss mening. En träff kan exempelvis härröra sig från en feltaggning, som användaren enkelt ska kunna åtgärda. Jag skulle hitta en lämplig lösning för detta i användargränssnittet och undersöka vilka eventuella ändringar i överföringsprotokollet som behövde göras. Sökning med ändringar Ytterligare en utökning var att göra så att det vid fortsatt korpusarbete, efter att användaren lagt till ändringar i texterna, är användarens uppdaterade version av texten som används. Rättningarna skulle enligt uppgiften inte införlivas direkt i korpus- och indexfilerna. Dels för att olika användare gör sina egna ändringar, men genom verktyget använder samma korpus- och indexfiler, dels för att det rör sig om mycket stora filer och sökstrukturer och att ändra i dem för varje ändring vore ineffektivt. Ändringarna skulle istället läggas separat. Detta innebär att ändringsindex måste byggas upp och vid sökning användas parallellt med vanliga index. Jag har utrett vilket format ändringarna bör lagras i när användaren vill införa dem i korpus. Jag har också gjort ändringar i sökalgoritmen så att den använder både originalindex och användarens eget ändringsindex och på så sätt tar hänsyn till användarens införda ändringar. Egna annoteringar Det är önskvärt för användare att kunna definiera och använda egna typer av annoteringar vid sådant korpusarbete som detta verktyg är ämnat för. Jag har undersökt vilken funktionalitet som önskas av användare och hur möjligheten skulle användas, och har sedan tagit fram ett förslag på lösning som tillfredsställer användarnas önskemål och systemets krav. Lösningen ger användaren möjlighet att själv definiera upp nya typer av annoteringar, att annotera ett eller en följd av ord med sina egna annoteringstyper samt att visa text med annoteringar. Lösningen är utformad på så sätt att det senare är möjligt att göra en utvidgning som möjliggör sökning på användardefinierade annoteringarna. Jag har levererat ett förslag på lösning som innebär 2

9 Inledning en enkel utvidgning av verktyget med funktionalitet för egna annoteringar, men har inte själv implementerat den. Rapportens struktur I andra kapitlet ger jag en språkteknologisk bakgrund till examensarbetet. Jag ger därefter en kort introduktion till Granska och en presentation av annoteringsverktyget före mitt examensarbete. I tredje kapitlet redogör jag för hur jag löst tillägg av flexibla ändringar. Fjärde kapitlet ägnas åt lösningen som möjliggör lagring och införlivande av användares rättningar samt hur jag gjort det möjligt att införa egna ändringar. I femte kapitlet beskriver jag hur sökning med användarens rättningar går till, samt hur jag överfört rättningarna till ett format som gör sökningen effektiv. Sjätte kapitlet behandlar en eventuell framtida utökning av verktyget med möjlighet att införa användardefinierade annoteringar. Jag utreder olika angreppssätt och ger ett förslag på lösning. I det sjunde och sista kapitlet följer slutligen diskussion och slutsatser. 3

10 Bakgrund Bakgrund Detta kapitel tar upp den språkteknologiska bakgrunden till detta arbete, grammatikgransningsverkytget Granska och, hur annoteringsverktyget såg ut före mitt examensarbete. Språkteknologisk bakgrund Både inom språkforskningen och för utveckling av datorlingvistiska verktyg, såsom datorstödd språkgranskning, finns behov av stora mängder text samlat i korpusar för att använda som referensmaterial. Ett exempel på en korpus är Stockholm-Umeå Corpus (SUC) [ som innehåller en miljon ord fördelade på ca 500 texter hämtade från bland annat facklitteratur, skönlitteratur, tidningstext och myndighetstexter. Ett annat exempel på korpus är BNC, The British National Corpus, som innehåller 100 miljoner ord. Parole är ett europeiskt projekt som bygger korpusar för många av de europeiska språken. När texterna till korpusen samlats in förses varje ord med tilläggsinformation som beskriver meningsgränser, stycken och ordets grammatiska egenskaper såsom ordklass, grundform och meningstillhörighet. Att lägga till information till korpus kallas för att annotera texten. När information om ett ords grammatiska egenskaper läggs till görs det genom att tilldela varje ord en tagg och det kallas för att tagga texten. En tagg är en kortform för ordets grammatiska egenskaper. Olika taggningssystem använder sig av olika tagguppsättningar och antalet taggar kan variera mellan ett dussin och flera hundra. Granskas system har 149 olika taggar. Särdragsklass Betydelse Särdragsvärden wordcl dt, jj, nn, pp, vb, ab, pm gender num case utr, neu, utr/neu, mas sin, plu, sin/plu nom, gen spec species (bestämdhet) ind, def, ind/def vbf verbform prs, pre, inf, sup, imp Echt techentyp mad, mid, pad Figur 1 Särdragsklasser hos taggar 1 1 Andreas Aarflot, Annoteringsverktyg med Granska som grund (2003) sid 8. 4

11 Bakgrund Sädragsvärde Betydelse Exempel dt determinerare (artikel) den, det jj adektiv svart nn nomen (substantiv) katt pp preposition på vb verb sitta ab adverb mycket pm egennamn Lars utr utrum en neu neutrum ett utr/neu utrum/neutrum de mas maskulinum bleke ind indefinit (obestämd) en def definit (bestämd) den vard vardagligt ord obb mad Figur 2 Särdragsvärden hos taggar 2 skiljetecken vid meningsslut En tagg i Granska är en kombination av ett eller flera särdragsvärden och kan exempelvis representeras på följande sätt: dt.utr/neu.plu.ind, vilket betyder att ordet är en determinerare i utrum eller neutrum som står i plural indefinit form. Korpusar kan taggas för hand, vilket innebär mycket manuellt arbete, eller med hjälp av språkteknologiska metoder, vilket ofta ger fler feltaggningar. Oavsett vilket finns det dock alltid en viss feltaggningsfrekvens. SUC, som är en handrättad korpus, har en felfrekvens på 0.5 procent. Förutom feltaggningar kan det dessutom finnas fel i själva texterna. Exempelvis kan inskannade texter ha tappat information. Att ha en så korrekt korpus som möjligt är givetvis viktigt. Granska använder sig exempelvis av SUC som statistisk referens. Om felfrekvensen kunde minimeras skulle Granskas skattningar av taggars sannolikhet vara ännu bättre. Det finns alltså ett behov hos språkforskare att enkelt kunna ändra i den korpus man jobbar med. Syftet med detta examensarbete är att utöka annoteringsverktyget för att erbjuda möjlighet till detta..!? 2 Aarflot, sid 8. 5

12 Bakgrund Text Den svarta katten satt på det lilla bordet. Taggad text Figur 3 Exempel på taggad text 3 Den (dt.utr.sin.def) svarta (jj.pos.utr/neu.sin.def.nom) katten (nn.utr.sin.def.nom) satt (vb.prt.akt) på (pp) det (dt.neu.sin.def) lilla (j.pos.utr/neu.sin.def.nom) bordet (nn.neu.sin.def.nom). (mad) Korpusar i annoteringsverktyget är idag annoterade med grammatisk information. Inom språkforskningen kan det finnas behov av även andra typer av annoteringar. Det vore därför önskvärt att utvidga verktyget med funktionalitet som stödjer annoteringar av andra typer än rent grammatiska och allra helst göra verktyget så flexibelt att användaren själv kan definiera egna typer av annoteringar. Vilka typer av annoteringar som kan vara användbara för någon användare i något skede är i princip okänt vid utvecklingen av detta verktyg, men annoteringsverktyget ska innehålla funktionalitet som efter leverans ger användaren själv möjlighet att definiera egna typer av annoteringar och sedan använda dessa. Detta kommer att utredas i detta examensarbete. Jag kommer att leverera resultaten av min utredning kring detta och också ett förslag på lösning baserat på mina reslutat. Någon implementation av detta kommer dock inte att genomföras inom ramen för detta examensarbete. Lösningen jag föreslår ska ge användaren möjlighet att själv definiera nya typer av annoteringar, att annotera ett eller en följd av ord med sina egna annoteringstyper samt att visa text med annoteringar. Lösningen behöver inte göra det möjligt att söka på dessa nya typer av annoteringar, men ska utformas på ett sådant sätt att en sådan utvidgning är möjlig. Granska Granska är ett grammatikgranskningsprogram utvecklat av forskare på Nada. Granska använder sig av både regelbaserade metoder och sannolikhetsmetoder för att uppnå hög effektivitet och robusthet. Granska tar vanlig text som indata och granskar den med avseende på stavfel, felaktigt skrivna tecken, stilavvikelser och grammatiska fel. Granskningen sker genom matchning mot en regeluppsättning om ca 250 regler som baseras på Svenska språknämndens skrivregler, SAOL, Myndigheternas skrivregler och Svarta listan. Reglerna specificerar mönster som vid granskning eftersöks i meningarna. Exempelvis kan en regel som hittar kongruensfel söka efter en determinerare, följt av noll eller flera adjektiv, följt av ett substantiv där determineraren och substantivet inte har samma genus. 3 Aarflot, sid 7. 6

13 Bakgrund Text som ska granskas Statistik (SUC) Ordlistor Lexikon (SUC & SAOL) Tokeniserare Taggare Grammatikregler Regelmatchare Stavningskontroll Figur 4 Granskas uppbyggnad 4 Presentation av rättningsförslag Granska består av olika moduler; tokeniserare, taggare, regelmatchare och stavningskontroll, se Figur 4. I tokeniseraren gås alla potentiella ord och specialtecken i texten igenom. Därefter tilldelar taggaren varje ord en tagg, som innehåller information om ordets morfologiska särdrag. Taggaren använder sig dels av uppslagning i lexikon och dels av en andra ordningens Markovmodell för att med hjälp av statistik och textuellt sammanhang räkna ut vilken tagg som ordet borde ha. Detta krävs eftersom de flesta ord kan tolkas på olika sätt; exempelvis kan ordet för vara preposition, substantiv och verb. Markovmodellen räknar för varje möjlig tagg för det aktuella ordet ut sannolikheten att de två föregående taggarna följs av den nya taggen. Denna sannolikhet multipliceras sedan med sannolikheten taggen har att överhuvudtaget förekomma i text. Den tagg med högsta resultat väljs som tagg åt det aktuella ordet. De nämnda sannolikheterna är uträknade utifrån statistik på alla förekommande följder av två och tre taggar i SUC, som är handtaggad. Valet att använda taggtrigram i statistikjämförelserna grundar sig på en avvägning. Om man baserar sig på en följd av två eller endast en tagg får man säker, men för lite information. Om man använder en följd av fyra eller fler taggar så blir informationen för gles och därmed för osäker. Det är viktigt att även kunna handskas med okända ord, eftersom språket hela tiden förnyas och frekvensen av sammansatta ord är så stor i svenska språket att man hela tiden stöter på nya sammansättningar. Därtill har vi alla egennamn. För okända ord använder Granska en statistisk, morfologisk analys som baserar sig på förekomsten av taggar på andra ord som slutar med samma 1 5 bokstäver. När det gäller sammansatta ord så tittar Granska på möjliga taggar för det sista ordet i sammansättningen. Om ett ord börjar med stor bokstav blir på samma sätt sannolikheten för att det ska vara ett egennamn stor. Dessa två analyser kombineras och på så vis skattas en sannolikhet för förekomsten av alla möjliga taggar för aktuellt ord. På så sätt kan man även här använda Markovmodellen precis som för kända ord, men med en skattad sannolikhet. I komplicerade fall där den stokastiska taggaren kan ha fel används taggningsregler hämtade ur SAOL för att hitta den korrekta taggningen. 5 Taggaren i Granska är således en kombination av 4 Johan Carlberger, Rickard Domeij, Viggo Kann och Ola Knutsson, A swedish grammar checker (2002). 5 Johan Carlberger och Viggo Kann, Implementing an efficient part-of-speech tagger (1999). 7

14 Bakgrund en stokastisk taggare och en regelbaserad taggare. Granskas taggare ger rätt taggar till 98 % av för den kända ord och 93 % av för den okända ord. 6 När texten är taggad går den vidare till regelmatcharen där felaktigheter i texten hittas genom att undersöka om någon av Granskas ca 250 regler matchar någon ord- eller taggsekvens i texten. Ett exempel på en regel är att det inte får förekomma en determinerare i neutrum följt av ett adjektiv följt av ett substantiv i utrum, såsom ett fin julgran. Regelmatcharen använder sig också av en rättstavningsmodul, Stava, även den utvecklad på Nada. Figur 5 Exempelregel i Granskas regelspråk 7 Granska kan testas i ett enkelt webbgränssnitt på adressen Granska har ett eget regelspråk där varje regel består av ett vänsterled och ett högerled separerade med en pil, se Figur 5. I vänsterledet anges vad som ska matchas i indata medan högerledet består av ett kommando som ska utföras på den indata som genererar en träff i vänsterledet. Ett exempel på hur en regel kan se ut visas i figur 2. X, Y och Z representerar tre på varandra följande tokens (ord). Regeln genererar träffar i texten där en determinerare följs av ett adjektiv som följs av ett substantiv vars genus är skiljt från substantivets genus. Exempelvis skulle ett vacker julgran generera en träff. I högerledet står kommandot corr som står för korrigera och i parentesen till korrigeringskommandot står ett rättningsförslag som rättar till felet i indata. Rättningsförslaget är att ändra genus på determineraren till substantivets genus, i vårt exempel skulle det bli en vacker julgran. Andra kommandon förutom corr är t.ex. mark, som markerar träffarna, och info, som ger kommentar till användaren. Granskas grammatikkontroll baseras på 250 regler. I annoteringsverktyget används Granskas logik för att hitta träffar, men inte Granskas egna regler, utan användaren skriver in sina egna, dock i Granskas syntax. Mer om detta under nästa rubrik. Annoteringsverktyget När mitt examensarbete tar vid så kan annoteringsverktyget användas till att skriva in egna regler, och sedan göra en sökning mot valfri korpus. Träffarna presenteras med rättningsförslag, och användaren kan välja att spara rättningen. Rättningen sparas då i en loggfil, men används inte vid det fortsatta arbetet med korpusen. Kör användaren samma sökning igen, så får hon samma träff och rättningsförslag som hon just sparade. Annoteringsverktyget är tänkt att användas som en distribuerad applikation där många användare via sina klienter jobbar mot en server som tar hand om allas anrop parallellt. Verktyget består därför av två delar; presentationslagret som tar hand om kommunikationen med användarna och det logiska lagret som exekverar de förfrågningar som kommer från 6 Carlberger et al Aarflot, sid 6. 8

15 Bakgrund användarna. Presentationslagret består i sin tur av en klient- och en serverdel, båda implementerade i Java. Klienten har ett grafiskt gränssnitt som visas i Figur 8 och en del bakomliggande logik som sköter kommunikationen med servern som administrerar alla användare och deras förfrågningar. Servern skickar vidare förfrågningarna till logiklagret, som består av en annan server, skriven i C++, som sköter det egentliga arbetet med sökning, lagring och indexering av korpusarna. En schematisk bild över de olika ingående delarna i verktyget visas nedan i Figur 6. Användargränssittet (Java) Användare (GUI) Nätverket Logik (C++) Granska Användare (GUI) Server Server Uppdragshanterare Indexerare/ optimerare Användare (GUI) Användardata Korpus- och indexkataloger Figur 6 Schematisk uppbyggnad av Annoteringsverktyget 8 Systemansvarig (förarbete) Överföringen mellan presentationslagret och logiklagret När användaren ger ett kommando, exempelvis för att söka i en viss korpus efter träffar enligt en viss regel, så skickas detta till användarservern som slussar förfrågan vidare till en server skriven i C++, som är den del av logiklagret som tar emot anrop, processerar dem och skickar tillbaka svar till användarna. Användarservern står i vänteläge från det att den skickat en förfrågan till dess att den antingen fått svar på förfrågan eller ett felmeddelande. Överföringen mellan programdelarna sker via klient- respektive serversocketar. En socket är en kommunikationskanal till en dator som använder TCP/IP-protokollet och består av datorns IPnummer och numret på den port som informationen ska skickas till när det gäller klientsocket respektive lyssnas på då det gäller serversocket. Informationen skickas via socketarna i ett överföringsprotokoll skrivet på XML-format. XML står för Extensible Markup Language och är en standard för att skapa ett markup languange, dvs. en struktur för att märka upp sin information. XML kan liknas vid HTML, då båda använder sig av taggar för att märka upp information. De största skillnaderna är att XML låter användaren definiera sina egna taggar, samt att XML är strikt hierarkisk dvs. inga taggar får överlappa varandra och varje tagg måste ha en sluttagg. Eftersom man definierar sina egna taggar i XML så krävs att man har sin struktur specificerad i en DTD (Document Type Definition) för att kunna använda XML i överföringen. I DTD:n listar 8 Aarflot, sid 17. 9

16 Bakgrund man de olika taggar som kan förekomma i XML-data och var i hierarkin de kan vara. Detta kan liknas vid grammatiken i det markup language man har skapat. På C++-sidan överförs informationen från och till XML-format genom en DOM-parser (Document Object Model) som tar DTD:n till hjälp för att tolka informationen i XML-format. På Java-sidan används JAXB (Java Architecture for XML Binding) som med hjälp av DTD:n skapar en mappning mellan XML-data och Javaobjekt genom att ha genererat ett antal Javaklasser som innehåller metoder för att instantiera klassen utifrån indata på XML-format och för att generera XML-data som representerar ett javaobjekt. Förutom dessa metoder finns det attribut i objekten som representerar XML-data. Överföringsprotokollet mellan användarsidan skriven i Java och logiksidan skriven i C++, består av: RunQuery; funktion som kör en sökfråga. GetTexts; funktion som hämtar aktuella texter som ligger lagrade på logiksidan. LoadCorpus; funktion som laddar aktuell korpus, dvs. förbereder logiksidan för att köra frågor mot viss korpus. Corrections; svar till RunQuery. Innehåller data med rättningsförslag från Granska. Texts; svar till GetTexts. Innehåller en lista över korpus och texter. Result; svar till LoadCorpus. Innehåller verifikationsmeddelande, eller orsak till misslyckad laddning. Error; som ersätter de övriga svaren då något fel uppstått. En översikt över överföringsprotokollet visas i Figur 7 nedan. Användargränssnitt (Java) Logik (C++) RunQuery() Corrections/Result GetTexts() Texts LoadCorpus() Result Error Figur 7 Överföringsprotokollet 9 9 Aarflot, sid

17 Bakgrund Presentationslagret Det ursprungliga användargränssnittet består av ett huvudfönster med en menylist högst upp där man kan nå andra fönster. Huvudfönstret visas i Figur 8. I huvudfönstret finns uppe till vänster regelfönstret där aktuell matchningsregel visas. Regelfönstret används även till att skriva nya regler och redigera gamla. Upp till vänster i huvudfönstret finns menyn limit, som sätter en gräns på hur många träffar man högst vill ha och randomize som slumpar fram vilka träffar som visas, om antalet träffar överstiger värdet man angett i limit. I mitten till vänster i huvudfönstret finns knappen Run Query för att köra en sökning med vald matchningsregel i aktuell korpus. Nedre delen av huvudfönstret utgörs av svarsfönstret där reslutat av gjord sökning presenteras. Svarsfönstret har sju kolumner som för varje träff från vänster till höger visar id för mening, grupperingsalternativ, början av mening, matchningen i mening, slutet av meningen, en kryssruta där användaren anger om rättningsförslaget ska accepteras och sparas och slutligen rättningsförslaget. Under svarsfönstret finns knapparna Save Corrections, som sparar de ikryssade rättningarna och Show Tags, som visar Granskas taggning av orden i kolumnerna med början, matchning och slutet av meningen samt taggningen av rättningsförslaget. Längst ned i huvudfönstret är statusraden som visar meddelanden som kommer från servern om hur anropen gått. Figur 8 Användargränssnittet Under File i menyraden finns valet New corpus som öppnar en dialog där användaren själv får komponera ihop en samling texter bland alla texter som finns i systemet. Detta kallas för en virtuell korpus, eftersom det inte rör sig om en vanlig korpus utan en samling texter som användaren plockar ihop från flera olika korpusar. Dialogrutan visas i Figur 9. 11

18 Bakgrund Figur 9 Dialogruta för att skapa en virtuell korpus 10 Användaren väljer själv vilken korpus som sökningen ska utföras mot under File i menyraden. På samma sätt väljer användaren vilken av sina sparade regler som ska användas vid sökningen. Se Figur 10. Figur 10 Att välja bland sina sparade regler 11 Presentationslagrets klient och server har betydligt mer omfattande kommunikation mellan sig än presentationslagrets kommunikation nedåt, till logiklagret, se Figur Helena Ihrfors, Annoteringsverktyg för korpusarbete användarapplikation (2003) sid Ihrfors, sid

19 Bakgrund Klient Server Logik (Java) SaveRule (Java) (C++) Result/Error LoadCorpus Result/Error RunQuery() Corrections/Result GetCorpusTexts Result/Error SaveCorpus Result/Error SaveCorrections Result/Error GetTexts() Texts SaveProfile Result/Error RemoveRule Result/Error RemoveCorpus Result/Error LoadCorpus() Result GetCorpus Result/Error GetProfile Result/Error Error GetRules Result/Error GetTexts Result/Error RunQuery Result/Error Login Result/Error Figur 11 Protokoll för hela verktyget Ihrfors, sid

20 Bakgrund Logiklagret Logiklagret tar emot anropen från presentationslagret, exekverar dem och returnerar ett svar, se Figur 11. I normalfallet handlar det om att utföra en sökning, RunQuery, i vald korpus. Textmassan ligger lagrad i ett korpusformat, som beskrivs nedan under rubrik Lagringsformat för korpusar, men för att kunna utföra en effektiv sökning krävs ett format anpassat för sökning. Ett förarbete krävs av en administratör då denne lägger in nya texter. Texten måste indexeras, dvs. indexfiler skapas. Hur detta format är uppbyggt beskrivs senare under rubriken Lagringsstrukturer. Lagringsformat för korpusar I varje korpuskatalog ligger det en eller flera texter, som har varsin underkatalog till korpusens katalog. Korpus lagringsformat i verktyget bygger på ett format som tagits fram av Johnny Bigert och Jonas Sjöbergh inom CrossCheck-projektet på Nada 13. Deras format består av ett antal XML-filer: Tokens Innehåller orden som står i källtexten. Tags Innehåller ordens tagg, med grammatisk information. Lemmas Innehåller ordens grundform, s.k. lemma. Taglemma Innehåller en kombination av ordens tagg och lemma. Tags inverterat Anger för varje tagg dess förekomster i texten. Lemmas inverterat Anger för varje lemma dess förekomster i texten. Phrase Innehåller början och slut på varje fras och stycke. Structure Innehåller id för start- och slutord för varje mening, samt typ av mening. Ett utdrag ur en tokensfil visas i Figur 12. Förkortningen wtl står för word, tag, lemma. 13 Johnny Bigert och Jonas Sjöbergh, Förslag på korpusformat (2002). 14

21 Bakgrund Figur 12 Utdrag ur tokensfil för texten aa01 i korpus SUC 14 I annoteringsverktyget används ett förenklat lagringssätt, med filtyperna Tokens, Taglemma och Structure, som ger tillräcklig information vid indexering av texterna. 15 En användares virtuella korpura lagras i en XML-fil. I Figur 13 syns ett exempel där en användare skapat en virtuell korpus med sju olika texter från korpusarna suc och test. 14 Aarflot, sid Aarflot, sid

22 Bakgrund Figur 13 - Exempel på virtuell korpus med sju texter från två olika korpusar 16 Unikt id för ord och mening Varje ord i texten har ett unikt ordid som består av textens namn och ordets löpnummer i texten, se Figur 12. Meningar identifieras med ett id som baseras på texttillhörighet samt första och sista ordid i meningen, t ex aa Då resultatet av en sökning skickas till presentationslagret, måste id skickas med, så att de rättningar användaren väljer att göra kan identifieras när de sedan skickas tillbaka till logiklagret. XML-formatet som används vid överföringen är ordrikt, och därför är det önskvärt att hålla informationsmängden som skickas till ett minimum. Detta gör att meningsid skickas med rättningen, och inte varje unikt ordid. I presentationslagret numreras sedan orden baserat på startid för meningen, med antagandet att orden numrerats löpande. Sökalgoritmen Sökalgoritmen baserar sig både på ord och på taggpar, s.k. taggbigram. Detta innebär att användaren både kan söka på specifika ord i texten och på grammatiska konstruktioner. Annoteringsverktyget analyserar texterna mening för mening, då korrelationen mellan ord och taggar över meningsgränser ofta är väldigt låg 17. När matchning gjorts så hämtas varje mening med matchning och analyseras i regelmatcharen var för sig. Om träff hittas så presenteras meningarna sedan en och en i en lista för användaren. Annoteringsverktyget har en sökstruktur för varje korpus. Detta är en medelväg mellan att ha en enda stor sökstruktur för alla ingående korpusar och en sökstruktur för varje text i varje korpus. Om en enda stor sökstruktur hade valts, hade sökningen varje gång blivit väldigt omfattande, och träffar hade behövts sållas bort efter sökning. Om man å andra sidan valt en sökstruktur för varje text, hade många olika sökningar behövt göras och söktiden blivit betydligt längre än vid sökning i bara en struktur. Sökindex för ord Sökningen använder sig av en sökstruktur i form av en tabell med en uppräkning av en treställig bokstavskombination följt av positionerna för första och sista ord som börjar med dessa tre bokstäver i en annan, stor sorterad indexfil. Mellan de två positionerna i indexfilerna binärsöks sedan efter det fullständiga sökordet, och sedan plockas indexinformationen fram. Att på detta 16 Aarflot, sid Carlberger et al

23 Bakgrund sätt använda sig av en kombination av latmannahashning och binärsökning ger en effektiv sökalgoritm, även för mycket stora indexfiler 18. Sökindex för taggbigram Granska har 149 olika taggar. Antalet möjliga taggbigram är alltså 149x149, dvs. ca Sökstrukturen för taggbigram består av en matris med platser, där det i varje plats står ett taggbigram och en position i en stor indexfil över taggbigramen i texterna för aktuell korpus. I indexfilen används sedan binär sökning precis som i sökningen för ord ovan. Taggarna översätts till sitt taggid, t ex 9 för taggen dt.urt/neu.sin.def/, se Figur 14. Figur 14 Exempel på tagg från Granska 19 Lagringsstrukturer Varje text representeras av ett antal indexfiler, som möjliggör en effektiv sökning: tokens-index Indexfil för ord. tokens-switchindex Hjälpindex som pekar ut positioner i tokens-index. tagbg-index Index för taggbigram. word-table Tabell med latmannahashning på fil. tagbg-matrix Sökstruktur för taggbigram på fil. 18 Aarflot, sid 31 ff. 19 Aarflot, sid

24 Flexibla ändringar i korpus Flexibla ändringar i korpus Tidigare kunde användaren endast välja mellan att spara eller inte spara de ändringar som föreslås av Granska. Detta kapitel behandlar den lösning jag tagit fram för att användaren enkelt ska kunna lägga till egenformulerade ändringar. Bakgrund och användarkrav Annoteringsverktyget fungerar så att när en sökning utförts enligt den regel som användaren valt, följer det med ett rättningsförslag till varje träff som påträffats i korpus. Rättningsförslaget baseras på den regeldefinition som användaren skrivit, där hon/han angett ett rättningsförslag som ska åtgärda felet i meningen, exempelvis att byta den mot det om substantivet står i neutrum. Användaren kan välja att spara eller inte spara de föreslagna ändringarna. Jag har tagit fram en lösning som möjliggör för användaren att enkelt kunna lägga till egenformulerade ändringar i en viss mening. En träff kan exempelvis härröra sig från en feltaggning, som användaren enkelt ska kunna åtgärda. Om substantivet exempelvis felaktigt står i neutrum, ska inte den bytas mot det, utan taggen på substantivet ändras till utrum. Jag har sökt en lämplig lösning för detta och undersökt vilka förändringar som behöver genomföras för att möjliggöra dessa mer flexibla ändringar. Vilka delar har förändras? Användargränssnittet har förändrats, eftersom det i dagsläget presenterar varje träff med rättningsförslag på en rad, med en kryssruta som markeras om användaren vill spara den föreslagna rättningen. Det fanns inte plats för användaren att skriva in egna rättningar. Överföringsprotokollet har utökats för att bättre stödja införandet av flexibla ändringar som definieras av användarna. Logiklagret har anpassats så att de nya rättningarna kan tas emot och skrivas till en loggfil. Fler ändringar på loggfilen har behövt göras för att möta andra krav, men det tas upp i kapitlet Lagring av användarens rättningar. Ny del av användargränssnittet För att möjliggöra den typ av flexibla ändringar som det finns krav på, krävdes en utökning av användargränssnittet. Min lösning består av ett nytt fönster som öppnas då användaren klickar på en rad i resultatlistan. I fönstret visas hela meningen upp, med ord och tagg. Under meningen finns inmatningsfält där meningen visas upp igen, men där användaren lätt kan ändra de ord och taggar som önskas. Jag valde att göra denna konstruktion där meningen i originalskick visas överst, och därunder en rad där användaren kan göra önskade ändringar, för att underlätta för användaren. Detta ger en enkel överblick över meningen, och användaren kan enkelt jämföra sin redigerade version av meningen med originalversionen innan hon/han sparar sin ändring genom att klicka på Save. Förutom Save finns även knapparna Cancel och Restore. Cancel avbryter redigeringen, stänger fönstret och återgår till huvudfönstret. Restore återställer meningen till originalversionen och slänger alltså de ändringar användaren gjort. Användaren kan på så sätt enkelt ångra sina ändringar och börja om utan att behöva trycka Cancel och åter öppna fönstret. 18

25 Flexibla ändringar i korpus Utökat överföringsprotokoll När användaren tryckt Save skickas ändringen för lagring i användarens loggfil. Hur lagring av användarens ändring sker, beskrivs mer utförligt i kapitlet Lagring av användarens rättningar. Införandet av flexibla ändringar som definieras av användarna, till skillnad från de rättningsförslag som Granska producerar, medför att en ändring i överföringsprotokollet blir önskvärd. Tidigare hade Corrections, som innehåller rättningarna, parametrarna before och after. Detta kommer att ändras till TagChange och WordChange för att lätt kunna särskilja ändringar på ord och tagg. Dessa innehåller i sin tur fälten before och after. Förändringar i logiklagret Logiklagret har utökats med klasser som tar hand om den nya typ av ändringar som kommer med den utökade Correction i överföringsprotokollet. Tidigare skickades rättningarna bara till servern som administrerar användarna, men nu skickas de till logiklagret för att lagras och sedan kunna generera ändringsindex. Mer om det i kapitel Lagring av användarens rättningar. Klasserna savecorrectionshandler och Corrections har tillkommit. Förslag på vidareutveckling Det vore önskvärt att i de rullgardinsmenyer där användaren kan välja tagg på ord, få taggarna sorterade i ordning baserad på sannolikhet för aktuellt ord. I nuläget får användaren söka igenom listan över Granskas 149 taggar för att hitta rätt. Om listan sorterades med de troligaste taggarna för just det ordet överst, skulle det underlätta mycket för användaren. En komplikation är att om användaren ändrar ord, måste en ny tagglista hämtas och beräknas från Granska. Presentationslagret borde utvidgas, så att det är möjligt för användaren att lägga till ord, komma eller punkt. De färdiga rättningsförslag som kommer från Granska kan innehålla sådant, så logiken för att ta hand om nya ord finns redan. Den enda utvidgningen som behövs är ändringar i gränssnittet. Ibland kan fel som Granska hittar bestå i att meningarna avgränsats på fel sätt. De kan i dessa fall vara väldigt användbart att kunna se meningarna före och efter aktuell mening. En sådan utökning skulle vara relativt enkel att åstadkomma. Det vore önskvärt att kunna plocka fram en hel text, gå igenom och göra valda ändringar i texten. I dagsläget bygger funktionaliteten på att användaren först kör en sökfråga och sedan rättar de träffar som frågan genererar. Detta skulle även kunna användas till att plocka fram en hel text med användarens sparade ändringar, så att användaren får se helheten. Man skulle då också enkelt kunna göra så att användaren kan beställa fram texten med eller utan sina ändringar. 19

26 Lagring av användarens rättningar Lagring av användarens rättningar De rättningar som användarna sparar lagras på XML-format i loggfiler. När mitt examensarbete tog vid lagrades alla sparade ändringar, oavsett korpus och användare, i samma loggfil. Jag tog fram en lösning där varje användare kan lagra sina ändringar separat. Tidigare sparades loggfilerna lokalt på servern som hanterar användare utan att användas till något. Huvuduppgiften för mitt examensarbete har varit att implementera sökning där användarnas respektive ändringar införlivats, eller verkar ha införlivats, i korpus. Jag har undersökt var och på vilket sätt ändringarna borde lagras för att underlätta vid implementation av sökning med ändringar. Detta kapitel behandlar lagring av användarens rättningar. Bakgrund och användarkrav Att införa ändringar i korpus innebär att det för användaren verkar som om de sparade ändringarna införts i korpus, eftersom verktyget tar hänsyn till ändringarna vid fortsatt korpusarbete. Det innebär inte att ändringarna införlivas i de faktiska korpusfilerna. Det finns flera skäl till varför man vill undvika detta. Ett är att det skulle bli väldigt ineffektivt att gå in och ändra i stora filer för varje ändring som görs. Ett annat skäl är att detta verktyg är tänkt att användas som en distribuerad applikation där många användare via sina klienter jobbar mot en server som tar hand om allas anrop parallellt. Att låta alla användare införa sina egna ändringar i korpus skulle få många oönskade effekter. Om man använder en korpus som forskningsmaterial vill man inte att textmassan förändrar sig utan att man har kontroll över det. Ytterligare ett skäl är att varje korpus har en ägare som kanske inte vill att korpusen ska kunna ändras av andra. För att kunna ta hänsyn till användarnas respektive ändringar utan att införa dem direkt i korpus krävdes att en parallell struktur byggs upp för ändringarna. Eftersom sökningar sker i ett index som byggts upp utifrån texterna i korpus verkade det lämpligt att bygga upp ett liknande index för ändringarna eftersom samma sökalgoritm då kunde återanvändas. Mer om detta i kapitlet Sökning med ändringar då jag skriver om sökning med ändringar. För närvarande räcker det att veta att någon slags sökstruktur för ändringar byggs upp när användaren väljer att göra sina ändringar sökbara, samt att den lagras på samma ställe i systemet som de vanliga indexfilerna, nämligen på logiksidan. De krav jag genom intervjuer fått in från användare 20 är: Ändringar ska lagras under respektive användares katalog. Ändringsfiler ska kunna slås ihop. Exempelvis kan en användare få en annan användares ändringar, för att enkelt uppdatera en korpus som denne gått igenom och rättat. Användaren ska kunna backa tillbaka och slänga sparade ändringar efter ett visst datum som användaren anger. 20 Intervjuer med Johnny Bigert ( ), Viggo Kann ( och ) och Ola Knutsson ( ). 20

27 Lagring av användarens rättningar Konstruktionsval Detta avsnitt redogör för de konstruktionsval som jag har gjort för att möta användarnas krav. Först tittade jag på vilken struktur som bör användas vid lagringen en loggfil för hela textmassan, en per korpus eller en per text. Sedan valde jag formatet på loggfilen och slutligen hur nya ord ska behandlas i loggfilen. Lagringsstruktur Användarnas loggfiler sparas på logiksidan, eftersom de logiskt hör hemma i det lager där indexering och sökning görs. De sparas där i användarspecifika kataloger, för att möta insamlade krav. Man skulle kunna tänka sig tre olika nivåer för loggfilerna: En stor loggfil för varje användare En loggfil för varje korpus och användare En loggfil för varje text och användare Alternativet att spara alla ändringar i en stor loggfil har som enda fördel att bara en fil behöver öppnas och skrivas till då användaren kört en fråga och vill spara sina rättningar. Å andra sidan är det vanligare att en användare kör sin fråga på en korpus, eller på delar av en korpus 21. Det är mer ovanligt att en användare väljer att plocka ihop texter från olika korpusar till en virtuell korpus, och sedan gör rättningar på den. Rättningarna kommer i de fallen givetvis att sparas på texterna i de olika korpusarna, eftersom den virtuella korpusen bara är en spegling av dem. Valet mellan då två återstående alternativen är inte lika självklart. Att spara ändringarna i en loggfil för varje text, medför att många loggfiler måste öppnas/skapas då ändringarna från en körning på en hel korpus ska sparas. Fördelen med det alternativet är att det underlättar då användare vill distribuera sina rättningar till andra användare detta kan göras på textnivå och inte korpusnivå. Vill man däremot göra det på en hel korpus så kan man kopiera hela den katalog där rättningarna finns. Ytterligare ett argument för att lagra loggfilerna per text är att korpusformatet använder samma uppdelning varje text har en uppsättning filer, vilket jag beskrev under rubrik Lagringsformat för korpusar i Bakgrundskapitlet. Som jag kommer att beskriva i nästa kapitel, Sökning med ändringar, bygger jag förutom en indexstruktur, även upp en korpusstruktur för användarnas ändringar. Detta är en mellanlagring innan jag bygger upp en sökstruktur i form av indexfiler. Att använda samma indelning för loggfil som för korpusformat, kommer därför att underlätta längre fram. Lösningen jag har valt är att alltså spara ändringarna i en loggfil för varje text. Varje användare har följaktligen en katalog med underkataloger för varje korpus, där textspecifika loggfiler kommer att sparas, se Figur Intervju med Ola Knutsson ( ). 21

28 Lagring av användarens rättningar SUC Anna Parole Bosse SLL Carin Figur 15 Lagringsstruktur för användarnas loggfiler med ändringar Lagringsformat Det gamla loggfilsformat som fanns när mitt arbete tog vid hade taggarna correction, user, date, file, id, before och after, se Figur 16. Figur 16 - Utdrag ur loggfil med gammalt format Ihrfors, sid

29 Lagring av användarens rättningar Förändringarna som jag gjort på loggfilsformatet har baserat sig på de behov som finns när rättningarna som skrivits till loggfilen ska omvandlas till indexformat, vilket beskrivs i kapitlet Sökning med ändringar. Jag har behållit taggen correction, som markerar start och slut för en rättning. Taggen user är överflödig nu när varje användare har sina egna loggfiler. Date finns kvar oförändrad, medan id har utökats med ytterligare en nivå, där taggarna sentid och wordid ligger. Figur 17 - Utdrag ur loggfil med nytt format för text aa01med två rättningar Format för nya ord och för borttagna ord När ett ord vid en rättning infogas i texten så har det inget ordid. Det måste ändå i loggfilen tydligt framgå att det är ett nytt ord och var i meningen ordet ska infogas. Innan mitt arbete tog vid så behandlades de fallen så att ordid för ordet innan det ord som ska läggas till skrivs med ett suffix i form av c. 23 Jag arbetar vidare på den linjen. Om ett ord exempelvis ska läggas till mellan aa och aa skrivs aa c i wordid-taggen, se första rättningen i Figur 18. Jag har gjort ett tillägg till den regeln; om ordet ska stå innan första ordet i meningen skrivs istället first i wordid-taggen. När ett ord istället ska tas bort, så behandlas det så att ordets id skrivs i id-taggen, som i normalfallet, och det som markerar att ordet ska tas bort är att after-taggen är tom. Här har jag inte gjort någon ändring. Exempel på hur det ser ut finns i sista rättningen i Figur Ihrfors, sid

30 Lagring av användarens rättningar Figur 18 - Utdrag ur loggfil med det nya formatet. Här syns tre rättningar där ord infogats i de två första Överväganden vid implementationen En strävan efter en låg komplexitetsnivå har präglat implementationen av ändringslagringen. Att distribuera ändringar Ett av de krav som kom fram i intervjuer med användare var att ändringsfiler ska kunna slås ihop. Detta ger en användare möjligheten att överta en annan användares ändringar, och på så sätt enkelt uppdatera en korpus som denne gått igenom och rättat. Det ska också vara möjligt att kombinera ihop sina egna rättningar med en annan användares. Detta är fullt möjligt i denna implementation, men kräver lite manuell hantering användaren måste själv klippa ihop de två loggfilerna. När ändringarna sedan överförs till korpusformat så kommer den rättning med senast datum vara den som gäller för ett ord. Att radera ändringar Ett annat krav var att användaren ska kunna backa tillbaka och slänga sparade ändringar efter ett visst datum. Detta har jag löst så att när användaren ger kommandot Make index, så får användaren i en dialogruta välja om alla ändringar ska med eller bara de innan ett visst datum. Make index är det kommando som gör att de ändringar som finns lagrade i loggfilen överförs till sökindex vilket gör att de blir sökbara. 24

31 Lagring av användarens rättningar Att ändra i flera led Loggfilen kommer att finnas kvar även efter en indexering, och byggs vidare med nya ändringar. Nästa gång användaren indexerar kommer ändringsindex byggas upp på nytt utifrån loggfilen. Denna lösning har främst valts för att den är enkel, men även för att det underlättar då ändringar i flera led genomförs. När en ny rättning på ett ord som redan finns i ändringsindex, eller ett nytt ord i en mening införs, måste dels korpusfiler för ändringarna, dels filerna i ändringsindex uppdateras. I min lösning används samma algoritm för att bygga upp korpusfiler och indexfiler varje gång. Framtida förbättringar Det skulle vara bra med ett verktyg för att kombinera ihop två loggfiler från två olika användare. Man skulle kunna tänka sig att användaren som väljer att kombinera ihop två olika loggfiler får ange en annan prioritetsordning vid konflikt av två ändringar än att senast skapade ändring gäller, t ex att den ena användarens loggfil ska gå före den andres. Ett ännu snyggare alternativ skulle vara om konflikter redovisades för användaren så att denne kunde ta ställning till varje enskild konflikt. Det borde göras möjligt att faktiskt radera ändringar. I dagens lösning raderas ändringarna aldrig, även om användaren väljer att bara indexera fram till ett visst datum. Eftersom loggfilen kommer att finnas kvar även efter en indexering och sedan byggs vidare med nya ändringar kommer de ändringar som användaren valde att inte ta med i en första indexering att komma med i nästa. Detta är en relativt liten utökning. 25

32 Sökning med ändringar Sökning med ändringar Varje användare gör sina egna ändringar i korpus och vid fortsatt arbete ska verktyget ta hänsyn till dessa ändringar. Detta kapitel handlar om hur jag byggt upp en separat indexstruktur för ändringar och gjort om sökalgoritmen så att sökningen tar hänsyn till användarens ändringar. Bakgrund och användarkrav När användaren gjort ändringar i korpus lagras dessa i en loggfil, vilket beskrevs i förra kapitlet. Ändringarna överförs sedan till ett format som är sökbart så att verktyget kan ta hänsyn till dem när användaren fortsätter arbeta med korpusen. Ändringarna införlivas inte direkt i korpus- och indexfilerna. Det finns i huvudsak två skäl till att de bör lagras separat, dels för att alla användare gör sina egna ändringar, men använder samma korpus- och indexfiler, dels för att det rör sig om mycket stora filer och sökstrukturer och det vore inte effektivt att ändra i dem för varje ändring. Ändringarna läggs alltså separat. Detta innebär att ett ändringsindex behövde byggas upp utifrån användarens ändringar och vid sökning användas parallellt med vanliga index. Det har också krävts ändringar i sökalgoritmen så att den använder både originalindex och användarens eget ändringsindex och på så sätt tar hänsyn till användarens införda ändringar. De krav jag genom intervjuer fått in från användare 24 är: Vid fortsatt korpusarbete ska hänsyn tas till användarens ändringar. Vid valt tillfälle ska ändringsfilerna införlivas i korpus genom att användaren ger ett kommando som medför att det utifrån ändringfilerna skapas en sökstruktur för ändringarna som sedan vid fortsatt korpusarbete används parallellt med vanliga indexfilerna. Konstruktionsval Detta avsnitt redogör för de konstruktionsval som jag har gjort för att möta användarnas krav. Först skriver jag om valet hur ändringarna skulle överföras från loggfilsformat till indexformat via vanlig text eller via korpusformat. Sedan beskriver jag hur användaren initierar indexeringen vid vald tidpunkt. Sist beskriver jag lagringsstrukturen. Överföring till indexstruktur Det var klart från början att ändringarna borde överföras till en struktur som liknar den indexstruktur originaltexterna ligger i, eftersom mycket av sökalgoritmen då kunde återanvändas. Det fanns både kod för att överföra texter på korpusformat till indexformat och för att överföra texter från vanligt text till indexformat. Valet stod då mellan att gå från loggfil via vanlig text till indexformat eller från loggfil till korpusformat till indexformat. Jag valde det senare alternativet, och överför först loggfilerna till korpusformat och sedan till indexformat, eftersom det visade sig vara enklare programmeringstekniskt. Ett krav var att användaren ska välja tidpunkt för att indexera sina ändringar. Detta har jag valt att realisera genom att lägga till valet Make index i File i menyraden. När användaren väljer 24 Intervjuer med Johnny Bigert ( ), Viggo Kann ( och ) och Ola Knutsson ( ). 26

33 Sökning med ändringar detta så öppnas en dialogruta där användaren kan välja om alla sparade ändringar ska med, eller bara ändringarna fram till ett visst datum. När användaren gjort sina val skickas kommandot över till logiksidan som då bygger upp ett sökindex baserat på användarens ändringar som ligger sparade i loggfiler. När det gäller lagringsstruktur för ändringskorpus så har jag valt att följa strukturen för orginalkorpus så långt som möjligt. Filerna ligger i en katalog per text, precis som för orginalkorpus. Katalogen ligger på samma ställe som loggfilen, se Figur 19. aa01.wtl. korpusdir Anna SUC Parole aa02.wtl. korpusdir Users Bosse SLL Carin Figur 19 Lagringsstruktur för korpusfilerna med användarnas ändringar Även lagringsstrukturen för själva ändringsindex följer strukturen för originalindex. Filerna ligger i en katalog per korpus och användare, samlade under katalogen userindex, se Figur 20. SUC Anna Parole userindex Bosse SLL Carin Figur 20 Lagringsstruktur för indexfilerna med användarnas ändringar 27

34 Sökning med ändringar Överväganden vid implementationen Överföring av loggfil till korpusformat Konstruktionsvalet att gå via korpusformat till indexformat medförde att jag behövde hitta ett sätt att göra korpusfiler av loggfilerna. Detta löste jag genom att parsa den XML som står i loggfilen så att den omvandlas till en vektor av rättningar. En rättning har typen Correction som har attributen datum, meningsid, ordid, ordändring och taggändring. En ordändring och en taggändring består i sin tur av ett före och ett efter. Detta speglar formatet på XML:en i loggfilen, se Figur 18. Från vektorn med rättningar skrivs sedan informationen till tokens-, taggoch structurefil. Taggbigram Sökindex som beskrivs i bakgrundskapitlet är indelat i två kategorier; ordindex och tagbigramindex. För att kunna bygga upp taggbigramindex måste ändringskorpus innehålla taggarna innan och efter varje ändrad tagg. Första steget när loggfilerna ska omvandlas till korpusfiler är att plocka fram dessa taggar genom att gå tillbaka till orginalkorpus. Detta arbete var ganska omfattande, och tar också relativt lång tid när indexeringen körs. Att skapa nya ordid:n En rättning som systemet föreslår eller en manuell rättning från en användare kan innebära att ord läggs till. Orden i orginalkorpus får iden efter deras position i texten, dvs. de numreras löpande. Detta måste jag komplettera med en lösning för nyskapade ord. Jag har valt att fortsätta den löpande numreringen, så att ett nyskapat ord får nästa lediga nummer. Ordets position i texten kommer inte längre att kunna utläsas av meningsid:t. Eftersom ett av kraven är att olika användares rättningar ska gå att kombinera, så bör varje individuell rättning få ett eget id. Varje nummer kan alltså bara användas till en användares rättning. För att systemet ska veta vilket nästa lediga id är har jag lagt till en tagg i tokensfilen som håller reda på detta. Denna tagg ligger sist och innehåller det sista nyskapat id:t. När ett nytt id ska skapas läser systemet värdet i denna tagg och ökar det med ett. Att skapa nya meningsid:n Liksom det kan bli aktuellt med nya ordid:n så kan det bli det med meningsid:n. I orginalkorpus är meningsid uppbyggt efter första och sista ordid:t i meningen. Detta var tvunget att kompletteras med en lösning för meningar som delas itu eller slås samman. Jag har valt att gå vidare på samma linje ett meningsid kommer att bestå av första och sista ordet i meningen. För att markera att det är ett nyskapat meningsid lägger jag också till ett N i slutet. Hantering av nya ord- och meningsid:n För att hålla reda på var i meningen nyskapade ord ska vara och hur meningar delas och slås samman så har jag skapat en ny slags korpusfil Changes. Formatet syns i Figur 21. Formatet har inte XML-struktur, eftersom sluttaggar saknas. Detta för att formatet ändå är entydigt och lätt kan parsas. Exemplevis framgår det av taggen <S> både att en ny ändring startar och att den förra är slut. 28

35 Sökning med ändringar Figur 21 Exempel på Changes-fil. 29

36 Sökning med ändringar I changesfilen skrivs ändringar i meningens struktur, vilket är om ett ord läggs till ett ord tas bort en mening delas i två två meningar slås samman till en. Om ett ord läggs till skrivs vilket ord som ligger före i meningen och vilket ordid det nya ordet får. Om ordet läggs först i meningen står det First. Eftersom jag fortsätter att ge meningar id efter första och sista ordet i meningen, så kan man av id:t avgöra var meningen delas och vad första respektive sista ordet i meningen är. För meningsändringar anges id på meningen/-arna innan ändring och efter ändring. Changesfilen används sedan rekursivt för att räkna ut hur en originalmening ser ut efter alla ändringar, eller hur en ändrad mening såg ut i orginalkorpus. Effektivitet För att öka effektiviteten har jag skapat ytterligare en korpusfil changed_sents. I den skrivs originalid på de meningar som det finns en ändring i. Genom en uppslagning i den filen kan man vid sökning sedan snabbt utesluta de meningar som inte har en ändring och då bara söka i originalindex. Anpassad sökalgoritm När en användare indexerat sina ändringar och sedan kör en sökfråga så tar systemet hänsyn till ändringarna genom att först söka igenom originalindex på träffar och sedan söka igenom användarens egna ändringsindex. Därefter kombineras träffarna ihop. Om en mening genererar träff i originalindex, men sedan är rättad av användare, så rensas träffen bort från resultatlistan. Förslag på vidareutveckling Annoteringsverktyget kan enkelt utökas så att användaren kan välja om hon/han vill köra sökningen med sina ändringar, eller på originalversionen av texterna. Loggfilen rensas aldrig i dagsläget utan byggs bara vidare. Hela indexeringen görs i ett svep med alla ändringar, man bygger inte vidare på befintliga indexfiler. Det vore därför bra för användaren att kunna spara en gammal version av loggfilen för att kunna backa tillbaka. Överföringsprotokollet är förberett för att kunna indexera bara specifika korpusar, och inte alla. I dagsläget så indexeras dock alla korpusar. För att genomföra detta krävs en utökning av de val användaren får när kommandot Make Index har getts. 30

37 Annoteringar Annoteringar Det är önskvärt att kunna använda detta verktyg för korpusarbete även till annotering av text. Användare vill kunna definiera och använda egna typer av annoteringar. Min uppgift har varit att undersöka vilken funktionalitet som efterfrågas av användare och för att sedan ta fram ett förslag på lösning med funktionalitet för egna annoteringar, men inte att implementera detta lösningsförslag. Bakgrund och användarkrav En annotering är en slags notering. Det kan som jag tidigare beskrivit handla om grammatisk information, när texten är taggad. Taggning av text är alltså en annotering i sig. En annan slags annotering kan vara att märka upp ett eller flera ord med kommentarer, t.ex. fel avstavat eller vanligt förekommande fel för elever med svenska som andraspråk. Jag har tagit fram ett förslag på en utvidgning av verktyget som gör det möjligt för användaren att införa egna typer av annoteringar och sedan använda de typerna till att annotera texten. Förslaget bygger på Granskas regelspråk. Användaren skriver sina egna annoteringsregler, sedan söker verktyget reda på träffar baserat på regeln och föreslår den av användaren definierade annoteringen, precis som vid ett grammatiskt fel i dagens version av verktyget. De krav jag genom intervjuer fått in från användare 25 är: Annoteringar ska kunna läggas till enskilda ord eller del av en mening. Annoteringarna ska kunna visas genom ett knapptryck Visa annoteringar. När annoteringar visas, ska det/de ord som annoteringarna hör till markeras. Användaren ska kunna definiera egna annoteringar. Användaren ska kunna föreslå en annotering till en träff, när regeln skrivs i regelfönstret, precis som man idag kan ge ett rättningsförslag. Användaren som kör regeln får sedan välja att spara annoteringen genom att kryssa i en ruta vid varje träff, liksom för rättningsförslagen. Det ska vara möjligt att lägga till en enskild annotering i det detaljfönster som beskrivs i kapitlet Flexibla ändringar i korpus. Lösningen ska inte göra det möjligt att kunna söka på annoteringar, men det ska vara möjligt att senare göra den utvidgningen. Föreslagna konstrukstionsval Detta avsnitt redogör för de konstruktionsval som jag föreslår för att möta användarnas krav. Jag har tittat på vilken struktur och vilket format som bör användas vid lagringen av dels typerna av annoteringar och dels annoteringarna i sig. Presentation av användarens annoteringar Ett av kraven säger att användaren ska kunna trycka på en knapp Visa annoteringar för att få se användarens lagrade annoteringar i de meningar som finns på skärmen. För att kunna visa annoteringarna, måste de på något sätt skickats från logiklagret, där de lagras, till 25 Intervjuer med Johnny Bigert ( ), Viggo Kann ( och ) och Ola Knutsson ( ). 31

38 Annoteringar presentationslagret. Alternativen som står till buds är att antingen alltid skicka med annoteringsinformationen med varje mening till presentationslagret, eller hämta annoteringsinformationen separat från logiksidan när användaren trycker på knappen Visa annoteringar för de meningar som är aktuella. Jag förordar starkt den senare lösningen, eftersom prestanda vid sökning kommer att påverkas negativt med den förstnämnda lösningen. Eftersom informationen från logiklagret till presentationslagret skickas med XML, så blir varje utökning av protokollet ganska stor. Vinsten med den förstnämnda lösningen att inte behöva vänta ytterligare när man trycker på Visa annoteringar kan inte motivera den ytterligare tid som varje sökfråga kommer ta. Förmodligen kommer användaren inte alltid att vilja se sina annoteringar. Att kunna köra sökfrågor snabbt måste däremot vara högsta prioritet. Därför föreslår jag att överföringsprotokollet utökas med ett kommando där annoteringar på vissa meningar, eller en hel text, efterfrågas. Presentation och redigering av användarens annoteringstyper Användarna ska själva kunna lägga upp sina egna typer av annoteringar, precis som användarna skapar sina egna grammatikregler. I huvudfönstret finns en inmatningsruta där aktuell grammatikregel hela tiden visas och kan redigeras. Eftersom annoteringsreglerna egentligen är en vidareutveckling av grammatikreglerna, där både ett rättningsförslag och ett annoteringsförslag kan finnas med förordar jag att man använder sig av samma ruta även för dessa regler. Innan en annoteringstyp används i en regel, eller i en manuellt tillagd annotering ska den finnas definierad av användaren. Varje användare får på så sätt en lista med sina egna annoteringstyper. Att lägga upp egna typer av annoteringar är inte lika centralt som att skapa nya regler, och veta vilken regel som för tillfället används därför förordar jag en lösning där användaren går in i en meny och väljer att öppna ett mindre fönster som visar en lista över användarens egendefinierade annoteringstyper, och där användaren även kan lägga till, ta bort och redigera annoteringstyper. Presentation och redigering av användarens annoteringar När användaren trycker på knappen Visa annoteringar ska eventuella befintliga annoteringar visas i en egen kolumn i resultatfönstret. Eventuella annoteringsförslag som verktyget föreslår baserat på den regel som använts vid sökningen visas direkt i resultatlistan. Annoteringsförslagen presenteras i en egen kolumn med en kryssruta bredvid sig där användaren anger om annoteringen ska sparas. Detta fungerar precis likadant som för rättningsförslagen. Enligt krav från användare ska det vara möjligt att lägga till egna annoteringar manuellt, och inte baserat på det regelbaserade förslaget som verktyget presenterar. Den smidigaste lösningen av detta krav är att utöka funktionaliteten i det detaljfönster som beskrivs i kapitlet Flexibla ändringar i korpus. I detta fönster finns möjlighet för användaren att lägga till sina egna, manuella ändringar. Detta fönster bör då utökas med fyra fält: ett där typ av annotering väljs i en rullgardinslista, ett fält för fritext till annoteringen och två fält där användaren anger från och till vilket ord som annoteringen gäller. Lagringsstruktur för annoteringar Annoteringar är, liksom användarnas rättningar som beskrivs i kapitlet Lagring av användarens rättningar, användarspecifika. De bör därför också ligga i kataloger som är specifika för varje användare. Jag föreslår att annoteringarna sparas i en fil per text samlade i en katalog per korpus, liksom användarnas rättningar. De kan då sparas i samma struktur som rättningarna, se Figur 22. Anledningen till den uppdelningen är att det är smidigare att jobba med mindre filer. Om alla annoteringar för en korpus sparas i en fil blir den stor och svårhanterlig. När 32

39 Annoteringar annoteringar till fem meningar i en korpus ska hämtas tar det relativt lång tid att söka igenom en stor fil för hela korpusen. Det är snabbare att öppna en fil för varje text och söka fram annoteringarna där, i relativt korta filer. SUC Anna Parole Users Bosse SLL Carin Figur 22 Lagringsstruktur för användarnas filer med annoteringar Lagringsstruktur för annoteringstyper När det gäller att lagra de typer av annoteringar som användaren själv definierar upp så bör de lagras i en fil per användare, eftersom de är användarspecifika. Denna fil skulle, precis som annoteringarna, kunna sparas på logiksidan eller på servern som hanterar användarna, precis som de regler som användaren skapar. Om listan skulle sparas på logiksidan så kommer denna fil att behöva läsas och skickas till presentationslagret då användaren vill skapa annoteringar eller hantera sina annoteringstyper. När annoteringstyperna under körtid en gång skickats från logiklagret, skulle en lista kunna sparas lokalt i presentationslagret under den tiden användaren arbetar med verktyget för att maximera prestanda. Denna kopia av listan används då användaren lägger till nya annoteringar manuellt, skriver en regel med ett annoteringsförslag i sig eller redigerar listan med annoteringstyper. Då användaren redigerar listan med typer av annoteringar, måste dessa ändringar skickas till logiklagret som gör motsvarande ändringar i den aktuella användarens fil med annoteringstyper. Detta förfarande är dock onödigt krångligt, eftersom listan primärt kommer att användas lokalt på användarsidan. Det enda som talar för detta är att ett av kraven från användarna är att lösningen ska vara möjlig att utöka så att användarna kan söka på annoteringar. Detta gör att listan kommer att behövas vid en indexering för att förbereda denna typ av sökning. Detta kan dock lösas genom att listan skickas över tillsammans med indexeringskommandot till logiksidan. Jag förordar alltså att listan sparas på samma sätt som reglerna, dvs. på servern som hanterar användarna. Detta kommer att vara enklast att implementera och vara mest fördelaktigt för verktygets prestanda. 33

40 Annoteringar Lagringsformat för annoteringstyper I Figur 23 syns ett exempel på det format jag föreslår för att spara användardefinierade annoteringstyper. Filen fylls sedan successivt på då användaren definierar upp nya typer av annoteringar. Som jag beskrev under föregående rubrik, skickas listan av annoteringstyper till presentationslagret under inloggningsförfarandet, så att en lokal lista kan visas upp då användaren själv skapar egna enskilda annoteringar i det detaljfönster som beskrivs i kapitlet Flexibla ändringar i korpus. Figur 23 Förslag på filformat för användardefinierade typer av annoteringar Lagringsformat för annoteringar Formatet för att lagra en annotering måste innehålla start- och slutord för annoteringen och vilken typ av annotering det är. Detta finns med i kraven från användarna. Start- och slutord används för att i användargränssnittet visa vilket/vilka ord en annotering hör till. I Figur 24 visas ett förslag på lagringsformat för annoteringar som förutom start-, slutord och typ har plats för en kommentar och ett rättningsförslag. Detta lagringsformat har tagits fram av Johnny Bigert och Jonas Sjöbergh inom CrossCheck-projektet på Nada. 26 Figur 24 Förslag på filformat för användardefinierade annoteringar För att snabba upp hämtning av annoteringar bör ytterligare en fil finnas, med information om vilka texter och meningar som alls har några annoteringar. Förslagsvis använder man sig av en fil per korpus. Ett förslag på hur en sådan fil kan se visas i Figur 25. I denna fil visas alltså vilka meningar som har annoteringar. Filen är sorterad både på textnamn och på meningsid, så att det går snabbt att söka i den. Med detta format är det lätt att se om det finns någon annotering i en text. 26 Bigert och Sjöbergh. 34

41 Annoteringar Figur 25 Förslag på format för fil med information om vilka annoteringar som finns Utökningar vid implementation Detta avsnitt redogör för de förändringar som måste göras i korpusverktyget för att implementera annoteringsfunktionalitet enligt mina förslag Förändringar i presentationslagret En av de förändringar som behöver göras i presentationslagret för att möta användarnas krav är att i det detaljfönster som beskrivs i kapitlet Flexibla ändringar i korpus, göra det möjligt för användaren att själv skapa egna enskilda annoteringar. Ytterligare en förändring är att lägga till en kryssruta i resultatlistan i huvudfönstret, där användaren väljer att spara eller förkasta de förslag på annoteringar som presenteras. Förslagen på annoteringar kommer från sökregeln. I resultatlistan måste också en knapp läggas till som heter Visa annoteringar liknande Visa taggar. När användaren trycker på knappen ska eventuella annoteringar till de träffar som visas hämtas och skrivas ut under meningarna. De ord som annoteringarna hör till ska markeras. Den sista förändringen i presentationslagret är att lägga till en meny i menyraden med namn Annoteringar. I den ska valet Definiera annoteringstyper finnas med. När användaren väljer Definiera annoteringstyper ska en nytt litet fönster öppnas som visar de annoteringstyper som finns, och användaren ska där kunna lägga till nya annoteringstyper. Förändringar i regelspråket Användaren ska kunna ge ett annoteringsförslag i de regler som skrivs, på samma sätt som ett rättningsförslag kan anges i regelspråket. IFigur 26 visas ett exempel på en regel med både ett rättningsförslag och förslag på en annotering som sträcker sig över tre ord där annoteringstyp och en kommentar anges. 35