IGoR som GoDiS för restaurangbranschen

Transkript

1 IGoR som GoDiS för restaurangbranschen Henrik Bertilsson, Christine Lundell, Andreas Wallentin Datalingvistikprogrammet Göteborgs universitet {cl0hbert, cl0clund, Abstract I dagens datoriserade värld tycker många att det borde finnas smidigare och bättre sätt att föra en bra dialog med datorn Var ligger skillnaderna i att föra en dialog med en människa och att föra en dialog med en dator? Då detta är ett problem som alla dialogsystem har, valde vi att lägga vikten på att göra en applikation till ett befintligt system, i detta fall GoDiS Vad vi går igenom är en överblick av de olika komponenter som måste finnas i ett informationssökande system Dessutom visar vi vår egen applikation, IGoR, som vi har gjort med utgångspunkt av en resebyråapplikation 1 Inledning 11 Introduktion Interaktion mellan människor och datorer har under senare år, till mångas glädje, blivit verklighet för både datorkunniga och nybörjare Ett exempel på detta är SJ:s talstyrda tågupplysning Att kunna föra en riktig dialog med datorn; att konversera och kunna få svar på frågor eller hjälp att boka resor är något som engagerat forskningen I detta arbete presenteras ett dialogsystem, GoDiS, och vår egen dialogapplikation, IGoR, en informationsguide om restauranger 12 Tidigare forskning Dialogsystem är något som utvecklats i takt med AIforskning, det vill säga forskning rörande artificiell intelligens Att kunna föra en naturlig dialog med datorn är en av grundpelarna inom denna vetenskap Vid institutionen för lingvistik vid Göteborgs universitet, som är framstående när det gäller forskning kring dialogsystem, har ett verktyg för utveckling av dialogsystem tagits fram, TrindiKit GoDiS (Gothenburg Dialogue System), är det system, vars uppbyggnad vi tittat närmare på Det som vi har utgått ifrån är en turistbyråapplikation Denna version innehåller varken taligenkänning eller talsyntes, men det finns dock stora möjligheter att bygga in sådana moduler 13 Problemformulering och problembakgrund Alla dialogsystems gemensamma problem har att göra med förståelse av naturligt språk: hur skall man få datorn att förstå vad användaren vill ha sagt och hur skall det kopplas ihop med det som datorn vill ha svar på? Hur skall datorn hålla ordning på vad användaren redan har sagt och vad den måste fråga? För att kunna få ett fungerande dialogsystem måste datorn kunna matcha input på ett korrekt sätt mot databasen, vilket kan vara problematiskt eftersom användaren inte skall behöva anpassa sitt språk alltför mycket till datorn Systemet skall kunna känna igen ett så naturligt språk som möjligt, dessutom skall användaren kunna ge mer information åt gången än systemet frågar efter: precis så som sker i en dialog mellan två människor Dessa överlapp skall förstås av datorn och användaren skall inte behöva säga samma sak två gånger: Försäljare: Vad kan jag stå till tjänst med? Kund: Jag vill boka en flygresa till Paris Försäljare: Varifrån vill du flyga? Kund: Jag vill flyga från Göteborg 1:a oktober och flyga hem den 14:e oktober Kunden svarar på försäljarens fråga, dessutom ger han ytterligare information Naturliga dialogers överlapp är det centrala problemet när det gäller dialogsystem Jämför ovanstående med SJ:s dialogsystem: SJ: Varifrån och vart vill du åka? Anv: Jag vill åka från Göteborg till Karlskrona i morgon klockan 12 SJ: Du vill åka från Göteborg till Kramfors Stämmer det? Anv: Nej SJ: Du vill åka från Göteborg till Karlskrona Stämmer det? Anv: Ja SJ: Ungefär hur dags vill du åka? Anv: I morgon klockan Syfte och frågeställning Vårt syfte med detta projekt är att få en inblick i hur ett dialogsystem är uppbyggt Hur kommer det sig att datorn kan förstå vad användaren säger, när språket tillåter oss att formulera uttryck på så många olika sätt? Och vad skiljer egentligen dialogsystem utvecklande i TrindiKit från andra system, som tex SJ:s dialogsystem? Dessutom vill vi ge andra med viss datalingvistisk bakgrund en liten inblick i hur ett dialogsystem fungerar rent tekniskt 15 Metod och Materialbeskrivning Till en början ägnade vi oss åt litteraturstudier Förutom genomläsning av TrindiKit-manualen och GoDiS-koden har vi läst artiklar skrivna av forskare på området Det finns åtskilliga skrifter som på senare år skrivits inom området dialogsystem, bla av dem som har varit med och utvecklat TrindiKit Professor Robin Cooper vid institutionen för datalingvistik, Göteborgs universitet, har skrivit ett antal skrifter inom området, som är hans specialområde Dialogsystem som GoDiS har använt sig av TrindiKit TrindiKit är ett verktyg för att bygga och experimentera med DME (eng dialogue move engines) och IS (eng information state) Vi har utgått från GoDiS applikation i

2 resebyråmiljö och gjort om koden på de ställen som behövts för att vår applikation skall fungera Till vår hjälp har vi haft Stina Ericsson vid institutionen för lingvistik, som har besvarat våra frågor om GoDiS 2 Huvuddel 21 Presentation av uppsatsen I denna uppsats kommer vi först att presentera TrindiKit, det verktyg som ligger till grund för dialogsystemet GoDiS Därefter följer en presentation av GoDiS, den dialogapplikation som vi har utgått ifrån i vår egen dialogapplikation IGoR Där tar vi upp de viktigaste delarna i en dialogapplikation, IS och DME Vi går också in djupare i de viktigaste filerna för vår applikation: databasen, lexikonet och domänen, och ger exempel därifrån Därefter följer motsvarande information om IGoR, samt hur vi utvecklade IGoR från GoDiS och hur resultatet blev Vi presenterar även en testkörning av en exempeldialog i IGoR Slutligen följer en diskussion och en sammanfattning, där vi i diskussionen bland annat tar upp resultat och problem 22 TrindiKit TrindiKit är ett verktyg utvecklat i Trindiprojektet för att bygga och experimentera med IS och DME Trindi påbörjades för att täcka (en del av) det växande behovet av interaktionsmöjligheter med maskiner/datorer, oavsett om användaren använder naturligt språk eller en begränsad vokabulär Utöver att TrindiKit föreslår ett generellt upplägg för hur systemet ska se ut, så har det specifika krav på hur man måste definiera IS, DME, uppdateringsregler och algoritmer tillhörande systemet Dessutom tillhandahåller TrindiKit enkla moduler för input/output samt moduler för tolkning och generering av strängar 23 GoDiS 231 Introduktion till GoDiS Den applikation av GoDiS som vi har tittat närmare på är dialogsystemet i resebyråmiljö Systemet skildrar en informationssökande dialog, där användaren vill ha en prisuppgift på en resa Datorn skall fråga och få svar på vart och varifrån man vill resa, hur man vill resa, vilken klass man vill resa i, vilken månad man vill resa och om man vill resa tur och retur Systemet är uppbyggt så att datorn både kan ställa frågorna i tur och ordning och matcha användarens input med respektive oställd fråga Då slipper man ett system som, likt SJ:s system, inte kan behandla fler än ett svar åt gången Tre filer är grundläggande för varje område, de så kallade RIV: domänfilen, databasfilen och lexikonfilen I domänfilen anges vad datorn skall fråga och i vilken ordning Dessutom definieras konceptkunskap om den aktuella domänen, tex att Paris är ett resmål, Frankrike ett land, flygplan ett transportmedel, oktober en månad och så vidare När systemet har fått svar på alla frågor beräknas det totala priset för den aktuella resan i databasfilen I lexikonfilen finns datorns outputsträngar och godkända svar på direkta frågor eller ren information Dessutom finns synsets definierade, det vill säga synonymy sets, ord som har ungefär samma betydelse, eller som skall parsas till samma begrepp, tex med flyg, plan, flygplan, flyga menar användare att han vill resa med flygplan, då slipper datorn ställa frågan om hur användaren vill resa, om den inte redan har gjort det 232 Total Information State (TIS) TIS, som man skulle kunna kalla dialogsystemets hjärna, består av IS, MIV (Module Interface Variables) och RIV (Resource Interface Variables) som programmet kommer åt genom olika villkor och operationer TIS specificeras genom att ge typdeklationer för TISvariablerna, detta ger specifika krav på vilka villkor och operationer som är tillgängliga 2321 Information State (IS) Information State, eller informationstillstånd, är ett sätt att förklara dialogers uppbyggnad och är baserat på Jonathan Ginzburgs QUD (Questions Under Discussion) QUD är en stack som innehåller de aktuella frågorna, antingen frågor som systemet har ställt eller oställda frågor som användaren har svarat på Det viktiga är att identifiera den relevanta informationen i dialoger, hur den uppdateras och hur dessa uppdateringsprocesser är kontrollerade Informationstillstånd i en dialog representerar informationen som är nödvändig för att skilja just denna dialog från andra dialoger, uppdateringsregler lägger till information från tidigare händelser i dialogen och motiverar framtida händelser Det är viktigt att skilja informationstillståndstillämpningar på dialogmodeller från andra, strukturella dialogtillståndstillämpningar Informationstillstånd består av både statiska och dynamiska komponenter Statiska komponenter är sådana som inte förväntas förändras under dialogens gång, till exempel domänkunskap och kunskap om dialogkonventioner De dynamiska komponenterna är uppdelade i privat och delad information (också dessa begrepp från Ginzburg) Privat information är bland annat systemets egna trosuppfattningar och handlingar som systemet skall utföra i dialogen Gemensam information är delade trosuppfattningar, QUD:en och LU (latest dialogue move performed) Dessa moment krävs för att kunna följa de inblandades agerande i informationssökande dialoger Informationstillstånd är ett begrepp som används både för komponenterna i den teoretiska inriktningen till dialogmodellering och i den specifika systemmodulen

3 som tillåter inspektion och uppdatering av det aktuella tillståndet Nedan ett exempel på ett IS från GoDiS, mitt i en pågående dialog PRIVATE, systemets hjärna består av: AGENDA systemets nästa fråga, PLAN vilka frågor som skall ställas eller besvaras, BEL privat information och TMP en kopia av hela SHARED, det vill säga så som den såg ut innan förra yttrandet SHARED innehåller information som har fastställts av systemet och användaren under konversationen, COM sådant som båda parter vet, i detta fall att användaren vill ha en prisuppgift på en resa till Paris med flyg, QUD - frågor som är ställda, men ännu inte besvarade och LU information om senaste talare och senaste händelse Grundläggande informationstillstånd i GoDiS: Systemet: Hej och välkommen till resebyrån! Anv Flyg till Paris Systemet flyttar frågor från PLAN till QUD, frågor: hur användaren vill resa och vart användaren vill resa Sedan ställer systemet nästa fråga ur PLAN, till exempel när användaren vill resa 233 Dialogue Move Engine (DME) Huvudfunktionen hos en DME (ung motor för dialoghändelser) är att uppdatera informationstillstånd baserat på händelser som har skett eller kommer att ske DME:n består av två moduler, en uppdateringsmodul och en selektionsmodul, dessa använder sig sedan kontrollmodulen (controlpl) av Dessa två DME-moduler innehåller funktioner som integrerar observerade dialoghändelser och väljer nya händelser En DME består av en beskrivning av: a) hur IS ser ut b) vilka händelser i dialogen (DM) som finns c) hur DM är tillämpade till IS d) en samling uppdateringsregler på IS e) en uppdateringsalgoritm 234 Resource Interface Variables (RIV) Resource Interface Variables består av variabler som systemet får från modulerna databas, domän och lexikon 2322 Accommodation Accommodation kallas presuppositionell information i yttranden Typexemplet är om någon säger att kungen av Frankrike är flintskallig, så kan man ta för givet, via accommodation, att det verkligen finns en kung av Frankrike Den typ av accommodation som används i dialogsystem som GoDiS är något annorlunda definierad I dialogsystem handlar accommodation om vilka antaganden som deltagarna i en dialog gör angående vilka frågor som för tillfället diskuteras, det vill säga QUD (Questions Under Discussion) I GoDiS används question accommodation och task accommodation Question accommodation innebär att användaren kan svara på oställda, relevanta frågor När användaren svarar på en oställd fråga, tas denna fråga från PLAN och hamnar på QUD:en Till detta finns det uppdateringsregler i DME:n Dessa uppdateringsregler kan utföra flera olika sorters accommodations när den förväntade strukturen inte finns på QUD:en eller PLAN Förutom question accommodation finns det även task accommodation Detta innebär att om användaren anger ett svar, men PLAN är tom, så söker systemet i domänresurserna efter en task och PLAN med en matchande fråga Exempel på question accommodation i en informationssökande dialog: 2341 Lexikon I lexikonet samlas de delar som i huvudsak rör dialogen mellan systemet och användaren; vilka frågor som kan ställas och vilka svar som kan uppfattas För systemet (GoDiS) används predikatet output_form/2 (med två argument) som innehåller formella yttranden och frågor som gör ett försök att få dialogen att låta mer mänsklig Första argumentet i predikatet står som en betydelsemarkör (move) för det andra argumentet, som är en fras i form av en sträng: ex 1 output_form(move, phrase ) Samma princip gäller även för de frågor som ska ställas för att dialogen (eller målen) ska kunna uppfyllas (annars kan dialogen förefalla händelselös) I detta fall ska svaret lagras för att senare kunna uppfylla de önskningar som talaren söker efter En sådan fråga kan se ut som följande: ex 2 output_form(ask(x^(topic(x))),"phrase") X är variabeln som motsvarar det svar som användaren ger på ämnet (topic) som datorn ställer i form av en fråga (ask) som realiseras i en fras För att yttranden ska kunna ges måste talaren ge ett svar (eller flera) eller ett kommando som enligt applikationen förväntas vara korrekt Dessa av datorn förväntade svar ingår i predikatet input_form/2: ex3 input_form( [phrase], move )

4 Ordningen på argumenten är omvänd jämfört med output_form/2; första argumentet är en lista med svaret som ges, andra argumentet är betydelsemarkören för det första Om man ser på ex3 så ser man att det går att ge elliptiska svar, det vill säga, korta och koncisa svar, men tanken är ju att användaren också ska kunna ge en fullständig mening som svar När ett svar ges i form av en mening måste man se vilket/vilka som är huvudord i satsen för att kunna utvinna den information som behövs För att lösa detta problem kan man se vad som följer huvudordet: ex 4 input_form( [x Y], answer( topic( Z ) ) ):- lexsem(y, Z), Av exemplet ovan kan man utläsa att om x (huvudordet) kommer före Y i en mening så ska ett svar, Z, tillhörande ämnet ges, men endast om Y är ett lexem För att se om svaret är relevant så måste lexemet som tagits emot analyseras För att göra detta används lexsem/2 (från ursprunglig GoDiS-kod) som är ett av villkoren i ovanstående exempel ex 5 lexsem( Word,Concept ):- synset( Words, Concept ), member( Word, Words ) Predikatet tar ett ord och ger tillbaka ett koncept om det är så att ordet är medlem i en lista med synonymer till ett defaultvärde För att detta ska kunna förverkligas så används synset/2: ex 6 synset( [ [syn 1 ],,[syn n ] ], default ) Om man följer ex4-6 så ser man förloppet av en händelse som utspelats i en dialog Om ett svar på en fråga ges så analyseras meningen genom en sökning efter huvudordet i svaret Är det ordet som följer huvudordet ett lexsem så ges det som svar till det godkända ämnet Det kommer mer konkreta exempel under presentationen av IGoR, vår dialogapplikation 2342 Databas I databasen preciseras de fakta som behövs för att tex beräkna priset på en resa 2343 Domän Domänen är kunskapsdelen i dialogsystemet Här finns predikat som analyserar relevansen av de svar som ges, planer över frågeordning, samt ett antal småpredikat En plan är ett schema (i form av en lista) över de mål som ska uppfyllas och ser ut som följande: plan( plan_info, [findout( X1^(topic( X1))),, quit]) Om inte alla delmål, det vill säga alla frågor som ska besvaras, har uppfyllts, så kommer frågorna (målen) i den ordning som skrivs i predikatet plan/2 Vidare i planen, för att applikationen ska avslutas eller starta om, så kan man använda kommandon som quit, forget med flera som mål För att kunna ta reda på om svaren som ges av användaren är relevanta, och inte vara av "God dag yxskaft"-typen, så följs målen av planen av predikatet relevant_answer/2 som, utan att vara för ingående, jämför det svar som ges med de predikat som motsvarar det förväntade svaret: relevant_answer( X^( topic( X ) ), A ) :- 24 IGoR 241 Introduktion till IGoR IGoR, Informationsguide om restauranger, heter den dialogapplikation som vi har gjort med utgångspunkt från GoDiS Med IGoR skall man kunna föra en dialog för att få fram förslag på restaurang(-er) i Göteborg, efter vad användaren vill ha att äta och hur mycket han vill betala Liksom med GoDiS är det stora problemet att få datorn att förstå vad användaren menar i dialogen, oavsett om man svarar direkt på en fråga eller ger mer information på en gång När alla frågor besvarats får användaren ett förslag på restauranger som motsvarar önskemålen som ställts De moduler som är viktigast för dialogen är lexikonet, databasen och domänen I de tre finner man all information om vad det innebär att vara restaurang 242 RIV 2421 Lexikon I lexikonet samlas, som redan sagt, de delar som i huvudsak rör dialogen mellan systemet och användare ex1 output_form( quit, "Tack för besöket och välkommen åter") ex2 output_form( ask(x^(what(x))), "Vilken typ av mat vill du äta?" ) X är variabeln som motsvarar det svar som man förväntas ge i form av en siffra eller ett adjektiv (mycket, lite) ex3 input_form( [hejdå], quit ) - Jag vill äta musslor När ett svar blir en mening får man se till vilket som är det tyngsta ordet i satsen som rör frågan, vilket i detta fall är äta och ordet som följer efter Realisering av svaret i ett predikat ser då ut som följande: ex4 input_form( [äta S], answer( what( C ) ) ) :- lexsem( S, C ), foodtype( C ) För att se om det som önskas äta kan ätas och finns hos de restauranger som används för sökningen, måste en begränsning av område ske; den mat som användaren

5 önskar måste tillhöra den mattyp som restaurangerna har som specialitet För att göra detta används lexsem/2 (från ursprunglig GoDiS-kod), som tar den önskade måltiden (musslor) och ger den mattyp som måltiden tillhör: ex 5 lexsem( Word, Concept ):- synset( Words, Concept ), member( Word, Words ) För att detta ska kunna förverkligas så tillämpas synset/2, som består av en lista med synonymer och en mattyp: ex 6 synset( [ ['kräftor'],[musslor],[krabba], ], skaldjur ) Finns maten med i listan så ges mattypen (i detta fall skaldjur) som andra argument i lexsemregeln, vilket gör att mattypen skickas vidare till ett predikat som heter foodtype/1, som kommer att nämnas i följande avsnitt 2422 Databas I databasen finns ett antal restauranger (40 stycken) i ett predikat restaurant/4 som innehåller den information som ska matchas med tidigare input (önskemålen från användaren) och ge namn och ett medianpris på måltiden till användaren: restaurant(namn, mattyp, medianpris, prisklass) restaurant( Sjömagasinet, skaldjur, 325, jättedyrt ) Det som matchas är mattyp och prisklass, och det som ges är namn på restaurangen och vilket medianpris en måltid kan kosta Att medianpris används är först och främst för att det skulle ta alldeles för lång tid att skriva in exakta menyer för varje restaurang, dessutom fanns informationen om samtliga restauranger som finns i databasen tillgängliga på GPs hemsida (se källförteckning) För att kunna ge användaren ett svar motsvarande önskemålen, samlas nödvändig information in och ges ut i form av en lista i db/1 db([ what(food), maxpay(price), restaurants(list)] ):- restaurant(_,food,_,price), findall( [Rest-Price1], restaurant(rest,food,price1,price),list) 2423 Domän Domänen är kunskapsdelen i dialogapplikationen Här finns predikat som analyserar relevansen av de svar som ges, planer över frågeordning, samt ett antal småpredikat som visar vilka mattyper och prisklasser som finns En plan är ett schema (i form av en lista) över de mål som ska uppfyllas och ser ut som följande: plan( food_info, [findout(x1^(what(x1))), findout(x2^(maxpay(x2))), consultdb(x3^(restaurants(x3))), forget, exec(top)] ) Om inte alla delmål, det vill säga alla frågor som ska besvaras, har uppfyllts, så kommer frågorna (målen) i den ordning som skrivs i predikatet plan Vidare i planen, för att applikationen ska avslutas eller starta om, så kan man använda kommandon som quit, forget med flera som mål Eftersom versionen av GoDiS (i skrivande stund) inte stödjer tolkning av siffror, och siffror är ju bra om man ska ge ett pris som man är villig att betala för maten, så använder vi oss istället av adjektiv från jättebilligt till jättedyrt (och däremellan) för att benämna prisklasser Dessa finnes i predikatet pay/1: pay('jättebilligt') pay('jättedyrt') I lexikonet finns även synsets för liknande betydelser, som tex lite, svindyrt, superbilligt mm, så att man inte måste veta exakt vad man ska skriva Vidare så finns även i domänen ett predikat foodtype/1 som innehåller de mattyper som finns i restaurangdatabasen: foodtype(franskt) foodtype(internationellt) Dessa har också tilldelade synsets i lexikonet, eftersom det inte kan vara lätt att veta vilka exakta specialiteter restauranger har: skulle man veta detta så är ju applikationen inte av intresse 243 Testkörning Nedan följer ett urdrag ur en testkörning av IGoR, uppdaterings- och selektionsreglerna syns inte, enbart informationstillstånden - Jag vill äta ostron och priset kvittar! : latest_speaker = usr : latest_moves = { answer(what(skaldjur)), answer(jättedyrt) } : program_state = run : lexicon = lexicon_restaurant : domain = domain_restaurant : database = database_restaurant : is = private = agenda = < > : plan=[raise(_20559^task(_20559)), findout([task(food_info)]) ] : bel = { } : tmp = com = { } : moves= assocset([(greet,true)]) : shared = com = { }

6 : moves = assocset([(greet,true)]) : output = 'Tack för besöket!' : latest_speaker = usr : latest_moves = { } : next_moves = { quit } : program_state = run : lexicon = lexicon_restaurant : domain = domain_restaurant : database = database_restaurant : is = private = agenda = < quit > : plan = [ ] : bel={restaurants([[sjömagasinet-325]]) } : tmp = com = { } : moves = assocset([(greet,true)]) : shared = com = { maxpay(jättedyrt), what(skaldjur), task(food_info) } : lu = speaker = usr moves= assocset([( answer(jättedyrt),true), (answer(what(skaldjur)),true)]) IGOR> Tack för besöket! : latest_speaker = sys : latest_moves = { } : program_state = quit : lexicon = lexicon_restaurant : domain = domain_restaurant : database = database_restaurant : is = private = agenda = < > : plan = [ ] : bel={restaurants([[sjömagasinet-325]]) } : tmp= com= {maxpay(jättedyrt), what(skaldjur), task(food_info) } : moves = assocset([(quit,true)]) shared = com= {maxpay(jättedyrt), what(skaldjur), task(food_info) } : moves = assocset([(quit,true)]) Tyvärr lyckades vi inte få vår dialogapplikation att ge ett svar till användaren Man kan dock se att systemet fungerar, för vi får en lista i IS med restauranger som passar in på användarens önskemål När vi provkörde GoDiS-applikationen i resebyråmiljö, så fick vi inte heller någon prisuppgift på en resa Därför drar vi slutsatsen att det inte är någon fungerade version av GoDiS som man kan ladda ner från TrindiKits hemsida 25 Diskussion Tanken var att kunna föra en naturlig dialog med datorn för att få fram förslag på restauranger som motsvarade de kriterier som vi gav på mattyp och prisklass I stort sett lyckades detta bra, då informationssökningen med "accommodation" (överlappning) fungerade som det var tänkt De predikat som anpassades till vår applikation fungerade också utan problem Vissa problem låg dock i hur TrindiKit var implementerat, tex att man som användare inte kunde skriva in siffror för det belopp som man kunde tänka sig att betala Vidare var RIV-modulerna, enligt vår uppfattning, väldigt ostrukturerade Ett exempel är att modul X anropar ett predikat i modul Y, som i sin tur hänvisar till motsvarande predikat i modul X Anledningen till detta kan vara att det är flera personer som är inblandade i implementeringen av GoDiS Dessutom kan det vara så att den version som finns för nedladdning inte är tillräckligt komplett Detta gjorde att systemet inte kunde ge någon respons på de fakta som samlats in Från början var det tänkt att vi skulle kunna köra IGoR med ett webbgränssnitt, men de nödvändiga filerna för installation av detta, som skulle finnas i den nedladdade TrindiKitfilen, saknades Slutprodukten blev alltså en körbar men ej komplett restaurangguide Detta inte på grund av tidsbrist eller brist på kompetens från vår sida, utan snarare brister i de versioner som vi hade tillgång till 3 Sammanfattning I vår uppsats har vi visat vilka problem man kan stöta på när man utvecklar en applikation till ett dialogsystem I vårt arbete har vi behandlat ett dialogsystem som har gjorts med hjälp av verktyget TrindiKit Vi har redovisat hur vi har gått till väga när vi gjort om en dialogapplikation i ett befintligt dialogsystem, GoDiS, så att den skulle passa vårt arbete, IGoR Vi har gått in djupare på de viktigaste filerna och visat de ändringar som var väsentliga för IGoR I testkörningen ger vi ett kort exempel på hur informationstillstånd, IS, kan se ut i ett dialogsystem I diskussionen tar vi upp problem som vi stött på under arbetets gång och kommentarer till dessa 4 Källförteckning Cooper, R, 1997 Information States, Attitudes and Dialogue Larsson, S, Cooper, R, Accommodation and reaccomodation in dialogue Larsson, S, Cooper, R, 1998 Dialogue moves and information states Larsson, S, Grönqvist L, Berman, A, Ljunglöf, P, Bos, J, Traum, D, 2000 TrindiKit 20 Manual revised version Larsson, S, Traum, D, 2000 Information state and dialogue management in the TRINDI Dialogue Move Engine Toolkit Natural Language Engineering, 6, 3-4 sept, Larsson, S, 2001 GoDiS ESSLLI, Helsingfors, 21 aug Ljunglöf, Peter, 2000 Formalizing the Dialogue Move Engine Poster presentation at the Götalogworkshop on semantics and pragmatics of dialogue, GBG, jun

7 wwwgpse wwwlingguse/projekt/trindi/trindikit/abouthtml Tack till Stina Ericsson, institutionen för lingvistik, GU