Dialogsystem i andraspråksinlärning GoDiS-applikationer i prototyper för webbaserad CALL

Transkript

1 Dialogsystem i andraspråksinlärning GoDiS-applikationer i prototyper för webbaserad CALL

2 2

3 Tack! Stort tack till Josefin Bergenholtz för ett mycket givande och intressant samarbete. Jag vill även tacka min handledare Staffan Larsson för all tid och engagemang samt David Hjelm och Jacob Hallenborg för hjälp med GoDiS och tillhörande webinterface. 3

4 Sammanfattning I detta arbete genomförs ett samarbete mellan mig, Christina Nienhardt, och Josefin Bergenholtz för att utveckla tre prototyper för webbaserad CALL (Computer Assisted Language Learning). Prototyperna innehåller dialogapplikationer utvecklade med hjälp av GoDiS (Gothenburg Dialogue System). Prototyperna är tänkta att användas av vuxna som har svenska som andraspråk. Från andraspråksinlärning används interaktionshypotesen samt ett ramverk för tasks (uppgifter) och från datalingvistiken används GoDiS. Konversationsdraget recast är i andraspråksinlärningssammanhang feedback som uppmärksammar felaktigheterna utan att uttalat anmärka att något är fel eller uttalat rätta till ett fel. Recast implementeras som en feedback i två av prototyperna varav en prototyp innehåller en syntaktisk kontroll som avgör om recast ska ges eller inte. Prototyperna har testats och utvärderats genom att dialoger loggades vid testerna, enkät fylldes i av testpersonerna samt testpersonernas tal och interaktionen med datorn filmades och senare transkriberades. Resultatet visar att de applikationer som byggts med GoDiS och används i prototyperna till stor del har passat bra för detta ändamål. Det visar även att delar ur de teorier som har tagits hänsyn till ur andraspråksinlärningen har bekräftats och varit till stor hjälp under såväl utveckling som test. 4

5 1. INLEDNING, SYFTE OCH DISPOSITION SYFTE DISPOSITION BAKGRUND ANDRASPRÅKSINLÄRNING Input & Interaktionshypotesen Tasks i andraspråksinlärning, Ellis ramverk IKT & LÄRANDE CALL Övningar i CALL Inlärningsteorier : andraspråksinlärning och CALL LINGUA2:SVENSKA DIALOGSYSTEM TrindiKit GoDiS En applikation byggd på GoDiS Webinterface TIDIGARE FORSKNING OM DIALOGSYSTEM & CALL L2Tutor En Busca de Esmeraldas METOD UTGÅNGSPUNKTER En modell som utgångspunkt Vem är Mathilda? RECASTS SOM FEEDBACK I GODIS DEFINITION AV EN DOMÄN UTIFRÅN ELLIS RAMVERK DIALOGER SOM SYSTEMET SKA KLARA IMPLEMENTATION LEXIKON DIALOGPLANER DATABASER RECASTS & SYNTAKTISK KONTROLL WEBINTERFACE OCH WEBBSIDOR RESULTAT, TEST OCH UTVÄRDERING EXEMPEL PÅ GENOMFÖRDA DIALOGER PRESENTATION AV PROTOTYPERNA I BILDER TEST OCH UTVÄRDERING Enkätsvaren Loggade dialoger och transkriberingar SLUTSATSER, DISKUSSION OCH FRAMTIDA ARBETE FRAMTIDA ARBETE REFERENSER APPENDIX A LOGGADE DIALOGER APPENDIX B ENKÄT OCH ENKÄTSVAR

6 1. Inledning, syfte och disposition Datalingvistik är ett tvärvetenskapligt ämne som kombinerar språkvetenskap och datavetenskap. Tillämpningar av datalingvistik finns inom t.ex. ordbehandling, kommunikationsteknologi, hjälpmedel för språkhandikappade samt datorstödd undervisning. Datorstödd undervisning inom språkinlärning kallas CALL (Computer Assisted Language Learning). Det finns en ständig strävan mot att människan genom sitt naturliga språk ska kunna konversera med datoriserade system och dialogsystem är ett datalingvistiskt tillämpningsområde som växer i takt med att teknologin utvecklas. För mig är datorstödd språkundervisning och dialogsystem de intressantare områdena inom datalingvistik och jag har därför valt att göra mitt examensarbete med inriktning på dialogsystem i andraspråksinlärning. På dialoglabs hemsida vid Göteborgs Universitet beskrivs dialogsystem på följande sätt: Dialogsystem är datorprogram som möjliggör interaktion med (eller via) datorer med hjälp av naturliga språk såsom svenska, engelska, japanska etc. Med dialogsystem avses normalt system som klarar längre dialoger, inte bara en fråga följd av ett svar. Både talad och skriven dialog är relevant, liksom kombinationer av skriven/talad dialog och mer traditionell grafikbaserad människa-datorinteraktion (multimodalitet). ( Detta arbete kommer främst röra sig inom området dialogsystem men det rör sig även inom områdena IKT och Lärande (Informations och Kommunikationsteknologi och Lärande) och andraspråksinlärning, samt CALL. IKT och Lärande är ett område som utifrån teorier om lärande, arbetar med modeller för utveckling och design av teknologier och verktyg för lärande, så som virtuella lärandemiljöer eller utbildningsplattformar. Centralt är samspelet mellan teknologi, individ, grupp och verksamhet. Det behandlar även hur olika syn på lärande samverkar med tekniken, arbetsformer och innehållet i det som ska läras och hur man kan skapa förutsättningar för att människor ska lära sig. Användandet av datorn som verktyg vid språkinlärning, CALL, kan ses som en del av IKT och Lärande. CALL är även ett område där det finns många datalingvistiska tillämpningar och dialogsystem inom språkinlärning kan ses som en sorts CALL tillämpning. Datalingvistik, dialogsystem, IKT och Lärande samt andraspråksinlärning har ett gemensamt område i CALL (se fig 1 här nedan). 6

7 Fig. 1: En bild för att illustrera hur de olika disciplinerna går in i varandra och har ett gemensamt område området CALL. Detta arbete rör sig inom den del som är gråmarkerad. CALL : Computer Assisted Language Learning IKT & L: IKT och Lärande ASI : Andraspråksinlärning DS: Dialogsystem DL : Datalingvistik Enligt Borin (2003) kan man inom datalingvistiken bidra till utveckling inom CALL-området genom att samarbeta med språklärare för att utveckla CALL-tillämpningar. I detta arbete möts disciplinerna IKT och Lärande och datalingvistik i form av ett samarbete mellan Josefin Bergenholtz magisterstudent vid IKT och Lärande och mig, Christina Nienhardt, magisterstudent i datalingvistik. Samarbetets resultat är en praktisk tillämpning och utvärdering samt två separata uppsatser, en utifrån ett datalingvistiskt perspektiv och en utifrån ett IKT och Lärandeperspektiv 1. Ett samarbete av detta slaget kräver dock även ett övergripande fokus. 1.1 Syfte Syftet med detta magisterarbete är att genom litteraturstudier undersöka områdena dialogsystem, IKT & Lärande, andraspråksinlärning och CALL samt att i ett samarbete med Josefin Bergenholtz implementera och utvärdera webbaserade prototyper. Prototyperna kan ses som CALL-tillämpningar och ska innehålla dialogsystem och användas av vuxna som lär sig svenska som andraspråk. Tanken är att andraspråksinlärning och datalingvistik ska kombineras. Från andraspråksinlärning används interaktionshypotesen samt task based language learning och från datalingvistik en anpassning av GoDiS (Gothenburg Dialogue System). Prototyperna kan ses som ett komplement till Lingua2:svenskas 2 webbkurs. Lingua2:svenska är utvecklat inom ett EU-projekt (se mer avsnitt 2.4). Lingua2:svenskas webbkurs är för vuxna distansstudenter som vill lära sig svenska som andraspråk. Prototyperna i detta arbete vänder sig till samma målgrupp som Lingua2:svenska. En stor del av arbetet är test och utvärdering där data från enkäter och tester med användare ur målgruppen bearbetas. 1 Josefin Bergenholtz uppsats :

8 1.2 Disposition För att ge en övergripande förståelse för de områden arbetet rör sig inom presenteras de först i kapitlet Bakgrund. Den praktiska delen av arbetet beskrivs i form av utgångspunkt, metod, kod och utvärdering. Slutligen finns avsnittet Slutsatser och diskussion samt förslag på framtida arbete. Bakgrund: Arbetets områden samt tidigare forskning. Metod och utvärdering: Implementera samt testa och utvärdera tre prototyper Slutsatser och diskussion samt framtida arbete. Fig. 2 : Uppsatsens disposition 8

9 2. Bakgrund Bakgrunden består av litteraturstudier inom dialogsystem, IKT och Lärande samt andraspråksinlärning och CALL. Här redovisas de begrepp som är viktiga för arbetet med den praktiska delen. Även Lingua2:svenska beskrivs samt två exempel på tidigare forskning som berör de områden som detta arbete rör sig inom. 2.1 Andraspråksinlärning Enligt Fox (1991) tar lingvistiken hjälp från andra områden som kommunikationsstudier, pedagogik, psykologi och sociologi för att studera andraspråksinlärning. Att göra detta, skriver Fox fortsatt, kallas oftast tillämpad lingvistik och handlar om en stor del av vad som påverkar språket och språkinlärningen. Det var under 70-talet som forskningen började koncentrera sig på hur man tillägnar sig ett andra språk. Rod Ellis (1997) menar att det är det skillnad på att lära sig sitt förstaspråk och att lära sig ett andra språk. Då man ska lära sig ett andra språk finns modersmålet att utgå ifrån och detta medför en medvetenhet om hur ett språk fungerar. Kunskaperna om sin omgivning kommer till nytta i tolkning och förståelse av den input, de yttranden, man utsätts för samt vad som kan observeras i omgivningen. Det finns en medvetenhet om vilka strategier som kan använda då språkkunskaperna inte räcker till. Ellis (1997) beskriver externa och interna faktorer. Externa faktorer kan t.ex. vara det sociala sammanhanget som andraspråksinläraren befinner sig i och även vilken sorts input man får och av vilken kvalitet inputen är dvs. de delar av språket som man tar del av. De interna faktorer som påverkar andraspråksinlärning är kognitiva processer, kunskapen om omgivningen och erfarenheter om hur språk fungerar Input & Interaktionshypotesen Forskning om input och interaktion i andraspråksinlärning baseras på att konversation inte bara är till för att öva det man redan lärt sig utan att man även genom konversation tillägnar sig ny kunskap. Rod Ellis (2003) beskriver inputhypotesen som lades fram av Krashen Den innebär att förstålig input är nödvändig när man ska tillägna sig ett andraspråk. Om inputen är aningen svårare än den nivå man ligger på blir resultatet att man lär sig nya lingvistiska former. Hur man erfar språket, ses som å ena sidan en källa av input där interna lärprocesser kan arbeta och andra sidan som en möjlighet att testa strukturella hypoteser genom output. Mitchell & Myes (1998) skriver om Michael Long som till viss del bygger vidare på den empiriska traditionen av forskning inom andraspråksinlärning inspirerad av Krashens input hypotes. Long menar att för att förstå hur viktigt det är med input bör man lägga vikt på att studera de interaktioner den lärande genomför. Longs teori kallas interaktionshypotesen. 9

10 Long har genom studier kommit fram till att när de som lär sig ett andra språk för en konversation med någon som har det språket som modersmål genomförs fyra olika sorters konversationsdrag: 1. Comprehension check - försäkra sig om att ens eget yttrande har blivit förstått. 2. Clarification request - den man konverserar med ska klargöra vad han/hon menar. 3. Confirmation check - Här vill man stämma av för att försäkra sig om att man själv har förstått rätt. 4. Recast - Man upprepar det yttrande som den man konverserar med har yttrat sist. T.ex. modersmålstalaren upprepar ett yttrande som andraspråkstalaren uttalat fel och säger det korrekt istället för fel, inte för att man fokuserar på formen, utan för att kommunikationen ska gå smidigare. Detta görs ofta omedvetet. Sådana här upprepanden kallas recasts och kan ge den som lär sig ett andraspråk feedback som uppmärksammar felaktigheterna utan att uttalat anmärka att något är fel eller uttalat rätta till ett fel. Det kan sägas vara en form av implicit negativ feedback. I en senare version av interaktionshypotesen beskriver Long input som blivit modifierad med hjälp av interaktion. Han menar att detta fungerar bra för att tillägna sig ett andra språk när det hjälper den som lär sig att uppmärksamma lingvistisk form i input och när den lingvistiska formen ligger inom inlärarens kapacitet att förstå språket. Språkinlärning främjas, enligt interaktionshypotesen, när modifiering av input och output sker i syfte att förstå. Den implicit negativa feedback som kan förekomma i andraspråksinlärning, inklusive recasts, som uppmärksammar andraspråksinläraren på de felaktigheter som de själva producerar bidrar till att språkinlärningen främjas. Endast sådant som är positiv feedback, inte skapar något problem, bidrar inte till att man lär sig nya saker Tasks i andraspråksinlärning, Ellis ramverk Tasks, uppgifter, är något som används i forskning såväl som i undervisningssituationer när det gäller andraspråksinlärning. Studier som genomförts på konversationer mellan de som lär sig ett andraspråk och de som har det språket som modersmål har visat vilka övningar som stödjer meningsskapande både i och utanför klassrummet. Ett exempel på sådana övningar är uppgifter där båda konversationsparter har kontroll över nödvändig information till skillnad mot flytande diskussioner, mer öppna diskussioner. Enligt Ellis (2003), kan uppgifter vara fokuserade eller ofokuserade. En fokuserad uppgift har som mål att ge övning i en specifik lingvistisk form. En ofokuserad uppgift är inte uppbyggd med inriktning på någon specifik lingvistisk form men kan däremot ge möjlighet att välja mellan olika lingvistiska former. Oavsett om en uppgift är fokuserad eller ofokuserad är de olika designvalen för skapandet av en uppgift viktiga. Andraspråksinlärningsapproachen task based language learning som Ellis (2003) ramverk beskriver nedan (se fig 3) ger steg för steg möjligheten att definiera den språkövning, uppgift, man vill bygga. 10

11 Ellis ramverk: Design drag Förklaring 1 Mål Det övergripande målet för uppgiften. 2 Input Verbal eller icke-verbal information som ingår i uppgiften t.ex. bilder, bilder, text. 3 Förutsättningar Det sätt informationen är presenterad på, eller hur den är ämnad att användas. 4 Procedur Den metod som man bör använda för att genomföra uppgiften. 5 Önskat resultat: Produkt Process Den del som är resultatet när man genomfört uppgiften. Kan vara antingen öppen, dvs. flera olika resultat godkänns, eller den kan vara stängd, dvs. det finns endast ett rätt resultat. Kan ses som en produkt, t.ex. en ifylld tabell, en ritad bild. Den lingvistiska eller kognitiva process som uppgiften är tänkt att stödja. Fig. 3: Ett ramverk som beskriver tasks från Ellis (2003) 2.2 IKT & Lärande IKT & lärande behandlar frågor om hur man kan utnyttja den nya teknologin i lärandesammanhang på bästa sätt. Utvecklingen pekar mer och mer mot att e-learning och flexibelt lärande används för att utveckla människors lärande i olika verksamheter och som verktyg i det livslånga lärandet. Det livslånga lärandet är vad individer lär sig genom hela livet och i en mångfald av kontexter. Flexibelt lärande innebär att stor hänsyn tas till den enskilda eleven, dess önskemål och förutsättningar. Eleven sätts i centrum och har möjlighet att välja tid, plats, tempo och form för studierna. Organisationerna förändrar sin pedagogik, organisation och teknik för att möta elevens behov. E-learning kan översättas som elektronsikt lärande. Det innebär att man i utbildningssammanhang använder nätverk och elektroniska utbildningsplattformar för distribution av kurser och läromedel. Enligt Eriksson, Hultén & Zettergren (2000) handlar e-learning om samverkan av tre huvudmiljöer: 1. Individens egna studier och reflektioner. 2. Diskussion i grupp för tolkning och bedömning. 3. Användning av informationsteknologi som tar sikte på interaktiva möjligheter mellan de personer som ingår i utbildningen. Med diskussion i grupp för tolkning och bedömning menas främst sådana diskussioner som kan föras online på Internet i en interaktiv lärmiljö, diskussionsforum. 2.3 CALL CALL står för Computer Assisted Language Learning och behandlar datorns användning inom språkinlärning. CALL innefattar forskningsområdena psykologi, datavetenskap, lingvistik och pedagogik. CALL-program används främst för allsidig främmandespråksinlärning respektive läs- och skrivinlärning på modersmålet. 11

12 Enligt Lars Borin (2002) lever de två disciplinerna datalingvistik och CALL ganska åtskilt fast de egentligen kan tyckas vara två discipliner som bör ha ett starkt samarbete. Borin skriver vidare att mycket av den forskning som blivit gjord inom CALL, främst i norden, kan härröras från AI (Artificiell Intelligens) och inte från datalingvistiken. Anledningen till att CALL och datalingvistik saknar ett närmare samarbete tror Borin beror på olika kulturer, missförstånd om varandras discipliner samt språkinlärningsideologin. Datalingvistiken kommer från datavetenskapen, CALL kommer från språkinlärning och tillämpad lingvistik vilket gör att man har skilda bakgrunder. Uppfattningen man får, enligt Borin, är att datalingvistik och CALL tillsammans inte är ett erkänt forskningsområde. Det man kan hitta är arbeten utförda av enskilda forskare som har tillräckligt starkt intresse för att kombinera dessa områdena. Borin tror inte att lösningen är att den lingvist som ska kommunicera med en programmerare bör ha djupare kunskap om hur programmet funkar. Inte heller att det team som ska utveckla CALL måste bestå av en lingvist och en programmerare. Lösningen finns enligt Borin till stor del i hur man lär ut datalingvistik där han pekar på att kombinationen av områdena datalingvistik och CALL är viktig. Inom datalingvistiken kan man, enligt Borin (2003) bidra till utvecklingen av CALL på följande sätt: Genom att tillsammans med språklärare utforma och förverkliga bra CALLtillämpningar. Genom att utvärdera CALL-tillämpningar Genom att skapa och förbättra verktyg för att utveckla och utvärdera sådana tillämpningar. Genom att göra en realistisk bedömning av (1) om en viss funktion är möjlig att uppnå, och (2) ungefär vad det i såfall skulle kosta att uppnå den. En viktig del av en realistisk bedömning bör rimligen också vara att ta ställning till frågan om det överhuvudtaget är motiverat att använda ett CALL-system i det aktuella fallet; bara för att man använder datorn för att göra en sak, är det inte alltid bäst att man faktiskt gör det. Chapelle (2001) presenterar två visioner för området CALL. Den ena visionen är Underwoods vision for intelligent language teaching från 1989 som menar att det ideala CALLprogrammet bör byggas genom en kombination av hypermedia, artificiell intelligens, datalingvistik och språkigenkänningsteknologi. Detta skulle, enligt visionen, ge språkinläraren chans att ganska fritt röra sig i en virtuell värld och interagera med intelligenta agenter. Den andra visionen som Chapelle (2001) tar upp är en vision från Kurzweil som säger att vid år 2009 kommer man att kunna lära sig läsa, räkna etc. lika bra med hjälp av interaktiv mjukvara som med hjälp av en riktig lärare. Visionen säger också att språkteknologi kommer vara mycket utvecklat och lättillgängligt. Chapelle (2001) ställer sig kritisk till dessa visioner och frågar sig var denna avancerade teknologin ska komma ifrån då man ännu idag inte ser någon större användning av sådan teknologi. Chaplle skriver att det är en utmaning att ta till vara på de möjligheter som den snabba utvecklingen av teknologin medför på samma gång som man även tar hänsyn till språkinlärning. In other words, success in technologies such as speech recognition is not equivalent to success in technologies for second language learning (Chappelle 2001, sid. 12). Utvecklingen av teknologin innebär, enligt Chapelle, inte automatiskt en chans att bygga ideala CALL-program. Hon menar att man bör rikta in sig på teorier inom andraspråksinlärning för att utveckla CALL. 12

13 Chapelle (2001) skriver att man kan utvärdera CALL bl.a. genom att jämföra de som använder CALL-tillämpningen med andra grupper, låta användare fylla i en enkät, transkribera interaktioner samt intervjua Övningar i CALL De vanligast förkommande övningarna i en CALL-tillämpning är enligt Gimeno-Sanz & Davies (2003) : Flervalsfrågor: Användaren får en fråga och har ett antal svar att välja på. Den feedback användaren får kan vara allt från bara rätt eller fel till vidare ledtrådar, mer information. Dessa övningar kan innehålla både ljud och bild. Detta är den vanligaste typen av övningar men den tillåter dock inte att användaren producerar eget språk. Öppen input: Användaren skriver in text, som t.ex. kan vara svar på en fråga. Texten analyseras sedan på olika sätt, meningar kan tex. parsas för att genomföra stavningskoll eller grammatikkoll. Fylla i: Här ges till exempel meningar där ord saknas som ska fyllas i. Antingen är övningen byggd så att användaren fritt kan skriva in ett ord, eller så får användaren ett antal ord att välja på. Språklab och andra språkaktiviteter: Användaren kan spela in sin egen röst. Övningarna kan variera från att gälla enstaka ord till att gälla meningar eller dialoger. Dialogerna kallas även simulerade konversationer. Dessa dialoger är ofta uppbyggda så att de följer olika spår beroende på vilket val användaren gör Inlärningsteorier : andraspråksinlärning och CALL Vilken inlärningsteori som gäller skiftar och man kan se en utveckling från den behavioristiska teorin till den i dagsläget mest framträdande sociokulturella teorin. Uppfattningen om hur man lär sig språk påverkas av vilken inlärningsteori man anser vara den bästa. Detta påverkar även utvecklingen av CALL-tillämpnigar. I följande kapitel ges en överblick om sambandet mellan den gällande synen på inlärning och hur man använder datorn, CALL-tillämpningar. Warshauer & Healey (1998) menar att man kan urskilja tre olika stadier i utvecklingen av datorers användande i andraspråksinlärning: behavioristisk CALL, kommunikativ CALL och integrerad CALL. Behaviorismen har sitt ursprung i Ivan Pavlovs arbeten. Den grundar sig på en empiristisk inlärningssyn vilket det innebär att lärande ses som grundat i de fysiska erfarenheter en individ gör. Pavlov studerade de betingade reflexerna som uppkommer och hur man kan kontrollera dem. Detta utvecklade senare den amerikanske psykologen B.F.Skinner. Han forskade om hur individer upprepar beteenden och hur det förstärks genom positiv belöning (förstärkningsprincipen). Kunskapen byggs på bit efter bit för att till slut bilda en helhet. CAI (Computer Assisted Instruction) grundar sig på en behavioristisk kunskapssyn. Pedagogens roll är att skaffa sig kunskaper, hitta effektiva sätt att dela kunskapen och sen 13

14 kontrollera att eleven har lärt sig. Dessa applikationer kännetecknas av drill- och övningsprogram som (har) används i skolorna. Behavioristisk CALL grundar sig på denna kunskapssyn och var aktuell på och 70talet. Den kognitiva teorin kännetecknas av att man skiljer på kropp och intellekt och att hjärnan och dess processer kan studeras för sig. Medan behaviorismen är empirisk och studerar människors beteende undersöker inom den kognitiva teorin mentala processer. Man jämför hjärnan med en processor och pratar om att människor inhämtar information, lagrar, söker och bearbetar information i minnet, har en uppsättning minnessystem. I ITS (Intelligent Tutoring Systems) avspeglar sig den kognitiva kunskapssynen. ITS liknar CAI men innehåller mer interaktivitet och kan anpassas till individen. Kommunikativ CALL uppstår i samband med den kognitiva inlärningsteorin. I kommunikativ CALL fokuserar man på elevens möjligheter att använda sig av språket och produktion av eget språk uppmuntras. Den sociokulturella teorin kopplas ihop med den ryske psykologen Vygotsky. Detta perspektiv betonar, enligt Säljö (2000), att lärandet sker i en kulturell kontext och att människan lär sig i ett samspel med andra genom att få tillgång till andras erfarenheter och uppfattningar. En grundläggande princip för hur lärande kan beskrivas i ett sociokulturellt perspektiv är förmågan att se något nytt som ett exempel på en variant av något redan bekant. Enligt Koschmann (1996) är CSCL (Computer Supported Cooperative Learning) den teori som innebär en sociokulturell syn på lärande som deltagare i sociala praktiker där datorn används som ett multimedialt verktyg för lärande i grupp. Enligt Koschman fokuserar CSCL på det sociala lärandet och på lärprocessen, istället för på resultatet. Man utgår från den enskilde individens interaktion med datorn som verktyg för sitt lärande, tillsammans med andra människor. Lärandet uppstår genom socialt deltagande. Deltagandet kan vara både synkront och asynkront. Integrerad CALL baseras på den sociokulturella teorin. Det som utmärker integrerad CALL är strävan efter att engagera eleverna i autentiska situationer. Teknologin bör vara integrerad i språkinlärningsprocessen tillsammans inlärningsprocessen för att lära sig skriva, läsa, lyssna och tala. 2.4 Lingua2:Svenska I följande kapitel beskrivs Lingua2:svenska, en del av EU-projektet Lingua2 3. Lingua2 är en del av i EU:s utbildningssatsning Socrates som involverar runt 30 länder. Målen för Lingua2 är : Hjälpa till att lyfta fram standarder i språkundervisning och språkinlärning genom att se till att det finns språkundervisningsmaterial och verktyg för att fastställa de språkliga kunskaperna. Uppmuntra utvecklingen av nytt material och en bredare spridning av redan existerande metoder som har en bra tillämpning och ger ett Europeiskt mervärde

15 Målsättningen i Lingua2:svenskas projekt är att skapa en distanskurs i svenska som främmande språk - via Internet med IKT som pedagogiskt hjälpmedel. Kursen riktar sig främst till universitetsstuderande i Frankrike, Tyskland, England, Belgien, Nederländerna och Sverige. I Sverige är kursen också öppen för utländska vuxenstuderande, andra än universitetsstuderande. Kursen är en nybörjarkurs i svenska, indelad i flexibla moduler om ett visst antal timmar per modul, för att lätt kunna passa in i respektive lands undervisningssystem. I kursen ingår tandemlearning, direkt och personlig kontakt och kommunikation på nätet mellan de utländska studenterna som lär sig svenska i de olika länderna och svenska studenter i Sverige som lär sig främmande språk, samt blivande lärare i svenska som andraspråk. Syftet är framför allt. språk- och kulturutbyte. Tandemlearning är ett begrepp som står för att man har kontakt med en person som har det språk du lär dig som modersmål. I kontakten med den personen lär man sig genom att öva tal eller diskutera svårigheter. Detta kan ske genom att träffas personligen eller genom att t. ex. skicka . Lingua2:svenska har utvecklats av en sammanslutning av flera Europeiska institutioner. Det startade i september 2001 och det är tänkt att sträcka sig tidsmässigt till mars Projektets slutprodukt är ett kurspaket bestående av en studiehandledning på svenska, franska, engelska, tyska och nederländska, texter med ordlistor, språkliga övningar med och utan facit, uttalsoch grammatikmaterial, insändningsuppgifter, ett tandemprogram, en CD och informationsbroschyrer på de olika språken. Kursen utnyttjar konferenssystem, ljudfiler, språkmelodikurvor, synkron ljudkommunikation, mm. Webbkursen är baserad på mycket kommunikation och interaktion mellan studenter-lärare och studenter-studenter. Samarbetsuppgifter ingår och "besök i verkligheten. Mål för Lingua2:svenska: bevara det svenska språket studera oberoende av tid och rum utökad studiemöjlighet kommunikation, interaktion, tandem och multimedia är nyckelorden ge studenten en aktiv och deltagande roll. genom samarbete bidra till införandet av webbaserad språkinlärning och språkundervisning i Europa Inlärningsmål för Lingua2:svenska: få grundläggande kunskaper skriftlig och muntlig svenska kunna förstå skrift och tal i svenska på en grundläggande nivå kunna uttrycka sig skriftligt och muntligt i svenska på en grundläggande nivå samt ha förståelse för olika regler i det svenska språket. tandem ska öka förståelse för språket och kulturen Anledningarna till att vi önskade utgå från Lingua2:svenska var att vuxenstuderande som lär sig svenska på nybörjarnivå är en målgrupp som inte det inte finns så mycket CALL material utvecklat för. En annan anledning är att de prototyper som vi implementerat kan utgöra ett bra komplement som skulle kunna innebära en variation i de övningar som förkommer i webbkursen. 15

16 2.5 Dialogsystem Dialogsystem är, som beskrivits i inledningen, program som möjliggör att med naturligt tal konversera med en dator. Det är fortfarande ett relativt nytt forskningsområde. Enligt McTear (2002) finns det olika sorters system som använder sig av mänskligt tal: Röst diktering : ger en transkription av vad användaren säger till systemet Kommando och kontroll: olika kommandon kan genomföras med hjälp av tal, kommandon som kan ersätta mus och tangentkommandon på datorn Dialogsystem med tal: en mer avancerad applikation. Här finns ett gränssnitt mellan användaren och systemet som möjliggör tal med systemet på ett relativt naturligt sätt. Detta område innehåller således stora områden inom språkteknologi : taligenkänning, talsyntes, språkbehandling, dialoghantering. McTear skriver om dialogsystem med tal dvs. sådana program som gör det möjligt för användare att genom tal interagera med applikationer som i grunden t.ex. kan bygga på databaser eller expertsystem. McTear menar att dialogsystem med tal är till för att ge gränssnitt mellan en användare och en datorbaserad applikation... the main purpose of a spoken dialogue system is to provide an interface between a user and a computer-based application such as database expert systems (McTear, 2002 sid. 3) McTear skriver att grunden till dialogsystem ligger i den forskning kring Artificiell Intelligens menad att utveckla ett konversationsgränssnitt, som började på 1950-talet. På senare tid har utvecklingen inom bl.a. talteknologi medfört och gjort den mer tillgänglig. Detta har resulterat i att telekommunikations- och mjukvaruutvecklarföretag har fått upp ögonen för området. Det senaste är röstportaler där man via ett talgränssnitt kan prata med systemet med hjälp av en telefon. På senare tid utvecklas allt fler plattformar och verktyg ämnade för att utveckla dialogsystem. Utvecklingen går från fråga-svar till konversation Dialogsystem klarar oftast, enligt McTear, begränsade domäner som t.ex. frågor om flygresor. Han menar fortsatt att man kan klassificera dialogsystem i termer av olika kontrollstrategier. Kontrollstrategi innebär hur systemet kontrollerar dialogen med användaren. McTear presenterar tre olika typer av kontroll av dialogen: 1. Finit-state-baserade system 2. Formulärbaserade system 3. Agentbaserade system Här följer en beskrivning av de tre olika typerna: Finit-state-baserade system Dialogen består av förutbestämda steg. Systemet har kontrollen och promptar användaren att svara. Yttranden, ord eller fraser känns igen eller förkastas. Varje yttrande som känns igen leder till att dialogen går vidare. 16

17 Exempel Finit-state-baserade system: System: What is your destination? User: London System: Was that London? User: yes System: What day do you want to travel? User: Friday System: Was that Sunday? User: No System: What day do you want to travel? (McTear, 2002, sid 4) Grammatik och ordlista som krävs specificeras i förväg och resulterar i en mer begränsad taligenkänning. Användarens input är begränsad till de förutbestämda orden, fraserna. Detta gör att det är svårt att rätta sådant som inte känns igen, samt att användaren inte har någon chans att bryta in och leda in dialogen på annat område. Enligt McTear skulle det behövas en komponent som kan klara av mer naturligt tal och en del där man kan se vilken information systemet fått och vad som saknas. En verifikation kan även läggas sist i dialogen, som ett kvitto på att systemet fått den information systemet efterfrågar och att dialogen nått sitt slut. Formulärbaserade system Här ställs frågor till användaren utifrån ett formulär där det saknas information. Det leder till att man t.ex. kan genomföra en uppgift som att ge tågtabellsinformation. I detta fall är dialogens flöde inte helt förutbestämt utan det är beroende av innehållet i användarens input och den info som system måste plocka ut. Systemet kan klara av att mer än just efterfrågad info finns med i användarens yttrande. Exempel Formulärbaserade system: System: What is your destination? User: London on Friday around 10 in the morning System: I have the following connection (McTear, 2003, sid 4) VoiceXML är ett exempel på ett programspråk för att bygga formulärbaserade dialogsystem. Som ett tillägg till formulärstrategin erbjuder VoiceXML en mekanism som kan triggas då en användare inte svarar, svarar fel eller frågar efter hjälp. VoiceXML baseras på XML (extensible Mark-up Language) som är en standard för storskalig elektronisk publicering samt utbyte av data via webben. VoiceXML kan hantera applikationer med talbaserat gränssnitt och har medfört att det blivit lättare att skapa enkla applikationer / dialoger mellan människa och system. Agentbaserade system Agentbaserade system använder komplexa konversationer för att lösa en uppgift. De klarar även av mixed initiative d.v.s. att användaren byter samtalsämne, t.ex. ställer en fråga om något annat. McTear skriver att konversationen är mer som ett samarbete, konversationen ses som interaktion mellan två agenter. Det är mer jämlikt och båda agenterna har egna tankar och handlar utifrån sina egna mål. Sådana system använder sig av sofistikerade språkhanteringskomponenter. 17

18 Exempel Agentbaserade system : User: I m looking for a job in the Calais area. Are there any servers? System: No, there aren t any employment servers for Calais. However, there is an employment server for Pas-de Calais and an employment server for Lille. Are you interested in one of these? TrindiKit TrindiKit utvecklades inom EU-projektet Trindi (Task Oriented Instructional Dialogue) (Larson & Traum, 2000) och använder sig av en informationstillståndsapproach till dialogsystem. TrindiKit är inget dialogsystem i sig men kan ses som en verktygslåda för att utveckla dialogsystem där man kan experimentera med informationstillstånd. När man ska bygga en dialogsystemapplikation med hjälp av TrindiKit börjar man formulera en dialogteori som innehåller IS (Informationstillstånd), dialogdrag och uppdateringsregler. Efter det lägger man till moduler. Därpå följer implementation av genre-specifika ISkomponenter, dialogdrag och regler. Till sist lägger man till resurser som är specifika för just den applikationen (se illustration i fig. 4 nedan). resurser applikation genre-specifik teori genre-specifikt system dialogteori grundläggande system informationstillståndsapproach TrindiKit Fig. 4 : Från TrindiKit till applikation GoDiS GoDiS är ett dialogsystem som man kan lägga till resurser till för att utveckla applikationer. I denna uppsats används dialogsystemet GoDiS för att bygga applikationer tänkta att användas i prototyper för webbaserad CALL. I följande kapitel förklaras GoDiS och GoDiSkomponenter samt de dialogfenomen som hanteras i GoDiS. 18

19 GoDiS står för Gothenburg Dialogue System och är ett dialogsystem som är utvecklat med TrindiKit. Det är från början ett domänoberoende dialogsystem. Grunden i teorin bakom GoDiS finns i Jonathan Ginzburgs teori om dialogsemantik där Dialogue Gameboard (DGB) (Larsson 2002) är en del av teorin. Ginzburgs DGB kan i korthet beskrivas som den information man delar i en dialog. Informationen kan uppdelas i de fakta man gemensamt har kunskap om, de frågor som man diskuterar - QUD (Question Under Discussion) - och information om det senaste yttrandet dialogen. GoDiS har frågebaserad dialoghantering som utgångspunkt. Frågebaserad dialoghantering kan sägas vara en blandning mellan formulärbaserade och agentbaserade system dvs. dialogen följer ett fråga-svara mönster men kan också hantera mer eller mindre information samt även subdialoger. Man har även haft som övergripande mål med GoDiS att det ska vara lätt att anpassa till nya domäner. Nedan beskrivs GoDiS-komponenterna dialogplaner, informationstillstånd och dialogdrag. Dialogplaner Dialogerna skapade med hjälp av GoDiS måste inte följa ett speciellt mönster utan följer istället en plan med olika handlingar. Dialogsystemet ställer frågor och ger feedback för att föra planen framåt men användaren kan välja vid vilket tillfälle han/hon vill besvara eller ställa en fråga. I planer används plankomponenterna findout/1, raise/1 och respond/1. findout(q) gör att systemet tar reda på svaret på q men om systemet redan vet svaret på q så ställs ingen fråga. Predikatet raise(q) ställer också frågan q men ställer inte frågan på nytt om inget svar ges. Då respond(q) anropas ger systemet ett svar på frågan q. Informationstillståndet IS (informationstillståndet) i GoDiS består av en gemensam del och en privat del. För en översikt av IS se den något förenklade figuren av IS nedan (fig 5). Den gemensamma delen (SHARED) innehåller det som etableras under konversationens gång, information man gemensamt kommit fram till. Den privata delen (PRIVATE) innehåller den kunskap som systemet vet om men inte användaren t.ex. databasinnehåll och dialogplaner. På agendan (AGENDA) finns de handlingar systemet planerar att utföra i nästa drag. AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) COM : set( Prop ) QUD : stackset( Question ) SHARED : LU: SPEAKER: Speaker MOVES: OpenQueue( Move ) Fig. 5 : En privat och en gemensam del i GoDiS IS Dialogdrag Dialogdragen i systemet används för att generera yttranden. Dialogdrag kan sägas vara abstrakta beskrivningar av yttranden. Vilket dialogdrag som används avgörs genom att informationstillståndet uppdateras med hjälp av uppdateringsregler. När användaren hälsar 19

20 används dialogdraget greet. Det finns även drag för quit som kan avgöra om användaren skriver eller säger t.ex. hej då. Dialogdragen ask och answer är centrala för frågebaserad dialoghantering då de hanterar frågor och svar. Vid ett tomt yttrande från användaren används systemets no_move och ingen uppdatering sker. Senast ställda fråga från systemet upprepas då. Nedan följer beskrivning av dialogfenomenen ackommodering, multipla uppgifter, informationsdelning samt feedback och grounding. Ackommodering Det finns ackommodering (anpassning) i GoDiS. Detta innebär att systemet kan ta emot mer information än vad som efterfrågas vid det specifika tillfället och då även ge feedback på den extra informationen samt lägga till den som hanterad. Fråge-ackommodering innebär att yttranden matchas mot dialogplanen och om ett yttrande svarar på en fråga ur planen som inte är aktuell just då anges den ändå som besvarad. GoDiS har även uppgiftsackommodering. Detta innebär att systemet matchar användarens yttrande mot frågor i möjliga planer i domänen även om ingen uppgift har etablerats. Multipla uppgifter och informationsdelning Två dialogfenomen som hanteras av GoDiS är multipla uppgifter och informationsdelning. Multipla uppgifter innebär att kunna göra flera saker på en gång dvs. systemet kan hantera subdialoger genom att olika dialogplaner hanteras samtidigt. Informationsdelning innebär att information kan delas mellan uppgifter. Informationsdelningen görs genom att frågor kan delas av olika planer dvs. har man svarat på en frågan innan kommer den inte att ställas igen om den finns med i den nya planen. Feedback, grounding och taligenkänningspoäng Positiv feedback i en dialog uttrycker acceptans, förståelse, perception och kontakt. Negativ feedback innebär oftast att man inte har förstått något. Grounding avser den interaktiva process som går ut på att försäkra sig om att man förstår och accepterar varandras yttranden. Det kan även användas i problematiska situationer där ett yttrande inte förstås. Termen ICM (Interactive Communication Management) är det som används I GoDiS för att uttrycka feedback och grounding. Notationen för icm som implementerats i GoDiS är icm:l*p{:args:} där L står för Action Level, P står för Polarity och Args står för argument (Larson 2002, sid 101). Nedan förklaras detta närmare. Action level står för följande: - con: kontakt, tex. Are you there?. - per: perception, tex. I didn t hear anything from you, I heard you say to Paris. - sem: semantisk förståelse, tex. I don t understand, To Paris. - und: pragmatisk förståelse, tex. I don t quite understand, You want to know about price - acc: accpeterande / reaktion, tex. Sorry I can t answer questions about connecting flights, Okay. Polarity står för; - neg: negativ - int: interrogativ (frågande) - pos: positiv 20

21 Exempel på icm: - icm:con*neg (kontakt, negativ) = I didn t hear anything from you. - icm:per*pos (perception, positive) = I heard to Paris. - icm:sem*neg (semantisk förståelse, negative) = I don t understand. - icm:und*pos (pragmatisk förståelse, positiv) = To Paris. - icm:acc*neg (accepterande, negativ) = Sorry, Paris is not a valid destination city. - icm:acc*pos (accepterande, positiv) = Okay Det finns även icm som hanterar när system ställer en fråga på nytt och när det ska ladda en plan på nytt. Då en fråga som ställts innan men inte fått svar då ställs igen används t.ex. icm:reraise:q - Returning to the issue of. Ett siffervärde som kallas score används för att simulera kvalitén på användarens tal då man testar dialogsystemet text-till-text. Detta gör att man kan testa olika sorters feedback som systemet kan ge om kvalitén på användarens tal är dålig och systemet eventuellt måste ange att det ej förstått. Beroende på detta värde, taligenkänningspoäng, ges olika sorters feedback. Det finns tre olika intervall som resulterar i olika polariteter (neg, int, pos) ju högre poängen är. Se exempel på positiv och interrogativ feedback på taligenkänningspoäng här nedan. Är poängen 0.9 eller lägre ges det positiv feedback: - Användarens yttrande har 0.76 poäng : price information please. - Systemet använder icm:und:*pos:usr*issue(?a.price(a)) och ger positive feedback: Okay. You want to know about price. Lets see. How do you want to travel? Är poängen 0.7 eller lägre ges det interrogative feedback: - Användarens yttrande har 0.65 poäng : price information please - Systemet använder icm:und:*int:usr*issue(?a.price(a)) och ger interrogativ feedback: You want to know about price, is that correct? En applikation byggd på GoDiS I detta avsnitt ges en inblick i de olika delarna i en applikation byggd med hjälp av GoDiS. Först presenteras grundkomponenter och därpå följer information om de resurser en applikation kan ha, exempel på dialogplaner och till sist exempel på hur informationstillståndet uppdateras. En applikation byggt med hjälp av GoDiS (som in sin tur bygger på TrindiKit) består av fem grundkomponenter. 1. Det totala informationstillståndet (TIS) : Delas upp i tre olika variabelgrupper. Informationstillstånd (IS): information som är nödvändig för att skilja den aktuella dialogen från andra dialoger. I TrindiKit finns definitioner av abstrakta datatyper som man kan använda för att definiera ett systems informationstillståndstyp. De används exempelvis för resultatet av utförandet av ett dialogdrag, samt för att avgränsa en mängd av nu möjliga drag. Modulinterface: modulinterfacevariabler är gränssnitt mellan moduler. I GoDiS är dessa variabler : input, latest speaker, latest moves, program state, next moves och output. Resursinterface : gränssnitt mot externa resurser, GoDiS databaser, lexikon och domänkunskap. 21

22 2. Dialogdragsmotorn (DME): Kärnan i systemet. De moduler som tillhör DME har till uppgift att uppdatera informationstillståndet baserat på observerade dialogdrag samt att välja de drag som ska utföras av systemet. Modulerna har full tillgång till TIS. Det finnas två moduler, en för att uppdatera IS och en som väljer nästa drag för systemet. De två modulerna är update, som uppdaterar informationstillståndet, och select, som väljer nästa dialogdrag. 3. Kontrollmodulen : Bestämmer vilka moduler som ska anropas vid vilket tillfälle. 4. Övriga moduler : Används i GoDiS för att tolka information från användaren och även ge yttranden till användaren. 5. Resurser: Det finns tre resurser som man kopplar till GoDiS då man utvecklar en applikation: lexikon, domän och databas. De olika domäner som dialogsystemet ska ha kunskap om behöver anges och detta gör man genom att ange t ex planer, lexikon och databas. I avsnittet här nedan redovisas resurserna för en applikation byggd med hjälp av GoDiS. Resurser för en applikation När man bygger en applikation med hjälp av GoDiS behöver man, som nämns ovan, resurserna lexikon, domän och databas. Här följer en beskrivning av dessa resurser samt viktiga predikat. Lexikon : Viktiga predikat är input_form/2, output_form/2 och yn_answer/1. Input_form(+Phrase, -Move) används av tolkningsmodulen en sträng stoppas in och man får ut motsvarande dialogdrag. Output_form(-Phrase, +Move) används av genereringsmodulen för att omvandla ett drag till en sträng. Yn_answer(?A) definierar svar på ja/nej frågor. Domän: Har tre viktiga funktioner: relevant_to_task/3, relevant_answer/2, plan/2 och default/1. Med relevant_to_task(+moves, -Task, -Plan) kan man stoppa in en lista av dialogdrag och få ut matchande plan och uppgift. Regeln används vid ackommodering, d.v.s. när systemet tolkar ett yttrande från användaren som svar på en ännu icke ställd fråga. Ackommodering används också för att klargöra vilken uppgift systemet ska utföra. Relevant_answer(?Query, + Answer) hitta den matchande frågan till ett svar från användaren. Relevant_answer används också för att kolla om ett svar är relevant för en fråga. Om en fråga ställs har systemet som mål att besvara den med en plan som hittas med hjälp av predikatet plan(+goal, -Plan). Detta anrop ger planen som för till målet. Default/1 bestämmer vilka defaultantaganden som får göras om ett svar är relevant för flera frågor. Exempel är default(x^(to(x))) som betyder att om man säger en ort ska den som default tolkas som en destination. Databas: I databasen finns ett viktigt predikat, consultdb/3. Med consultdb(+proplist, +Question, -Answer) kan man stoppa in en lista på kända fakta och en fråga, och få ut ett svar bestående av en proposition, alternativt ett felmeddelande 22

23 control DME input interpret updat e select generate output TIS DATABASE LEXICON DOMAIN database lexicon domain knowledge Fig. 6 : En bild på GoDiS arkitektur För att förklara bilden ovan ytterligare kan man i korthet beskriva vad som händer då dialogsystemet tolkar användarens yttrande: när användaren skriver något eller säger något hämtar inputmodulen in yttrandet till tolkningsmodulen (interpret) och yttrandet omvandlas till dialogdrag. Uppdateringsmodulen uppdaterar informationstillståndet utifrån dragen och systemets nästa drag väljs i selectmodulen. Det drag som ska utföras omvandlas till ett yttrande i genereringsmodulen. Outputmodulen skriver ut yttrandet till användaren. Dialogplaner för en applikation GoDiS har anpassats till en resebyråapplikation på engelska där man kan föra konversationer om resvägar och priser. I planen för resebyråapplikationen finns ett antal frågor som ska besvaras för att systemet tillslut ska ange ett pris. I exempel 1 nedan visas att predikatet findout/1 används, liksom raise/1 och consultdb/1. Frågor systemet ska ställa till användaren handlar om destination, transportmedel och datum etc. Exempel 1: findout(?x.dest-city(x)) findout(?x.depart-city(x)) findout(?x.transport(x)) findout(?x.dept-month(x)) findout(?x.dept-day(x)) raise({?class(economy),?class(business)} consultdb(?x.price(x)) 23

24 I exempel 2 ser ni en plan för frågor om visum. Denna planen hanteras som en subdialog där information om dest_city delas med föregående plan. Då i exempel 2 är hanterad återgår systemet till föregående plan i exempel 1. Exempel 2 : findout(?x.dest-city(x)) findout(?x.citizenship(x)) Nedan visas ett exempel på en dialog som använder sig av planerna beskrivna ovan. Subdialogen om visum finns med (hantering av multipla uppgifter) men även om systemet klarar informationsdelning sker det ingen sådan i denna dialogen då användaren inte angivit dest_city innan användaren frågar om visum. (S = system, A = användare); S> Welcome to the travel agency! A> price information S> ( ) Lets see. How do you want to travel? A> by flight S> ( ) What city do you want to go to? A> paris S> ( ) What city do you want to go from? A> do I need a visa? S> ( ) Lets see. What country are you from? A> sweden S> Okay. Yes, you need a Visa. S> Returning to the issue of price. Let s see. What city do you want to go from? Man kan även se att icm används i dialogen då systemet ger svar som Okay och Returning to the issue of. Informationstillståndet Nedan följer ett exempel på en del av en dialog med förklaring av hur IS uppdateras för resebyråapplikationen. För att ge en bättre överblick visas den förenklade bilden av IS som tidigare presenterats i fig 5. Q är av datatypen stack och står för question. PLAN är dialogplanen, även den av datatypen stack : AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) COM : set( Prop ) QUD : stackset( Question ) SHARED : LU: SPEAKER: Speaker MOVES: OpenQueue( Move ) Fig. 7 : en bild av IS som stöd för texen nedan 24

25 (S = system, A = användare); A> Price information please frågan om pris triggar planen Om användaren frågar Q, pushas Q på QUD och även respond(q) på AGENDA Om respond(q) i AGENDA och PLAN är tom, hitta planen för Q och lägga till i PLAN Om findout(q) är först i PLAN, fråga Q S> Where do you want to go? A> Paris Om LU/MOVES innehåller answer(a) och A är relevant svar på Q, lägg till P=Q[A] på SHARED.COM Om P i SHARED.COM och Q högst upp i QUD och P svarar på Q, gör en pop på QUD Om P i SHARED.COM och P svarar på Q och findout(q) i PLAN, gör en pop på PLAN När användaren skriver/säger svaret Paris så tolkas det som answer(to(paris)). Om to(paris) är ett relevant svar på den fråga som ligger överst på QUD så tas frågan bort och IS uppdateras med den nya informationen. Hade även information om att användaren vill åka med flygplan angivits, t.ex. To Paris by plane hade systemet fått svar på två frågor samtidigt. Detta kallas, som tidigare nämnts, ackommodering och betyder att användaren kan svara på frågor som ännu inte ställts. Systemet ser yttranden som svar på frågor som ligger på QUD. Om systemet tolkar yttrandet som ett svar på en fråga som inte finns på QUD letar systemet upp frågan och lägger den på QUD Webinterface Tillhörande TrindiKit finns ett webinterface som gör det möjligt att testa dialogsystemet med hjälp av en webbläsare. Webinterfacet består av två delar en Java Applet där dialogen förs text-till-text och en dynamisk webbsida där de genomförda dialogerna loggas tillsammans med dialogdragen. Det finns en inbyggd score-funktion som kan användas för att simulera kvalitén på användarens tal med hjälp av ett siffervärde (se även info om score i avsnitt 2.5.2). Java Appleten är kopplad till den SICStus process som skapas när dialogsystemet startas. Utseendet på Java Appleten kan till viss del ändras genom att modifiera olika parametrar i den HTML-kod som tillhör appleten. De olika parametrarna som man kan ändra är följande: Parameter Typ Beskrivning Default värde red, green, blue int, Färgvärden (RGB) 192, 192, 292 User, system string Yttrandeprefix i textarean U:, S: text, score, restart string Text på labels och buttons Text, Score, Restart noscore any Om det finns ett värde visas ingen scorebutton eller label inte definierad Fig. 8 : Parametrar som kan ändras i den Java Applet som är kopplad till dialogsystemet Så här kan den Java Applet som man för dialogen i se ut (se fig 9 nedan). I denna applet har följande parametrar anpassats: färg = ljusblå, yttrandeprefix = M för systemet, restart = starta om dialog, noscore = true (dvs. ingen taligenkänningspoäng kan anges). 25

26 Fig. 9 : Java Applet som ingår i webinterface 2.6 Tidigare forskning om dialogsystem & CALL Vad har gjorts tidigare som eventuellt liknar det som är gjort i detta arbete? I följande kapitel beskrivs två olika arbeten som exempel på arbeten som rör sig inom samma områden som detta arbete. I L2Tutor beskrivs ett dialogsystem för andraspråksinlärning och i En Busca de Esmeraldas beskrivs ett Internetbaserat CALL-system som är tänkt att främja kommunikation och interaktion andraspråksinlärare emellan L2Tutor Price, McGalla och Bunt (1999) vid universitet i Saskatchewan beskriver i sitt paper L2tutor: A Mixed-Initiative Dialogue System for Improving Fluency systemet L2tutor, en CALL-implementation innehållande ett dialogsystem för personer med engelska som andraspråk. Det beskrivs som ett system där tanken är att man ska få chans att utveckla sitt ordförråd, grammatikkunskaper samt få mer flyt i talet. Uppgiften man får i L2tutor är att beställa mat på en restaurang andraspråkstalaren beställer mat av en servitör. L2tutors underliggande struktur bygger på nyckelord, olika scenarion i en restaurang och det är ett system där dialogen är mixed-initiativ, d.v.s. initiativet att föra dialogen framåt kan tas av både användaren och systemet. Dialogen förs tex-till-text. Exempel på en bitar ur en konversation med L2tutor, S är systemet och A är användaren: S: Would you like something to drink? A: Can I have a soft-drink please S: Okay. S: What kind of a soft-drink would you like? We only have cola, sprite, orange-crush, and root-beer. A: I'll have ginger ale Exempel på mixed initiativ: S: Where would you like to be seated? S: Smoking or non-smoking? A: could I have a coffee? Where is your bathroom? S: The washroom's down the hall. S: Coffee? No problem. S: Smoking or non-smoking? Något som kallas PDA, Post Dialogue Analysis, ingår och där är analysen anpassad till personer som har franska som modersmål och olika fel rapporteras t.ex. substantiv följt av ett adjektiv eller felstavning samt en förklaring och ett rätt alternativ. En liten parser med en begränsad grammatik används för att analysera, se exempel nedan. 26

27 Error Type Input Sample Error Message Explanation Spelling Mistakes Noun Followed By An Adjective Cofee please. I would like a cola large. The correct spelling of cofee is coffee. The adjective large followed the noun cola When unfamiliar with the vocabulary of the second language, the learner may spell words incorrectly. A language transfer error. Fig. 10 : PDA analyserar och redovisar ett begränsat antal fel hos en person med franska som modersmål. Tester av systemet L2Tutor har visat att detta tillåter robusta och autentiska konversationer med användarna. Men inget test har gjorts för att se om de önskade målen, utveckla sitt ordförråd, grammtikkunskaper samt få mer flyt i talet, uppnås genom att använda systemet. Författarna hävdar att just begränsningen till en specifik uppgift, task, är nödvändig för att L2tutor ska fungera som en CALL-implementation En Busca de Esmeraldas Marta Gonzales-Lloret (2003) vid universitetet i Hawai har utvecklat En Busca de Esmeraldas, en CALL-tillämpning på Internet som är baserad på andraspråksinlärningsprinciper från Doughty & Long, Long och Chapelle. Gonzales-Lloret (2003) skriver att det inte är meningen att mäta förståelse eller lärande. Istället vill hon presentera ett exempel på en CALL uppgift byggd för att främja interaktion mellan andraspråksinlärningsstudenter och undersöka vilken sorts interaktion som förekom. Många som lär sig ett andraspråk, speciellt de som lär sig ett andraspråk som inte är så vanligt kanske inte har så många tillfällen att interagera med sådana som har språket som modersmål. Därför, enligt Gonzales-Lloret, kan det vara bra att använda sig av samarbete mellan två andraspråksinlärare och att det eventuellt kan ersätta en interaktion mellan en andraspråksinlärare och en som har språket som modersmål. "En Busca de Esmeraldas" är en aktivitet på Internet i två delar : sök efter en karta och sök sedan efter emeralderna. Det består av en 3D-simulation i form av 23 webbsidor innehållande bilder, audiofiler, filmer. Detta skapar tillsammans en värld där studenterna kan navigera tillsammans. Genom en rad uppgifter skall man nå ett mål. Uppgifterna är ordnade i en följd som kan främja inlärande med hjälp av samarbete. Studenterna ska interagera med varandra medans de jobbar ihop mot ett gemensamt mål. Gonzales-Lloret (2003) har utgått från Ten Methodological Principles (TMP) som Long föreslagit och som anpassats av by Doughty. 27

28 Fig. 11 : De tio punkterna som Gonzales-Lloret utgått ifrån En av punkterna är provide negative feedback. En Busca de Esmeraldas ger två möjligheter till negative feedback 1. feedback som ges av en annan student under tiden då uppgifter genomförs och man kommunicerar med varandra för att förstå 2. feedback från läraren som en respons på studentens skrivna output som skickas via . I första fallet kan det vara svårt att kontrollera om det är negative feedback eftersom det inte går att kontrollera studenternas interaktion när de jobbar ihop. Men då läraren deltar med sin feedback rekommenderas negative feedback. 12 studenter med spanska som andraspråk testade systemet. När studenterna genomförde uppgifterna spelades deras tal in. Senare transkriberades 4 stycken inspelningar. Studenterna fick även fylla i en enkät. Gonzales-Lloret skriver sammanfattningsvis om resultatet som visar att studenterna kommunicerade med varandra i syfte att förstå uppgiften och komma fram mot målet. Denna interaktion andraspråksinlärare emellan är ett sätt att skapa förståelse. En andraspråksinlärare kan vara en, om än något begränsad, källa till modifierad input. Dock inte lika bra som en modersmålstalare hade varit. Som fortsatt arbete anger Gonzales-Lloret att studenter som inte hade samma första språk skulle få jobba ihop och då skulle de tvingas att använda mer omformuleringar, repetition etc. 28

29 3. Metod För att testa hur ett samarbete med utgångspunkt i både andraspråksinlärning och datalingvistik kan se ut utvecklas tre webbaserade prototyper innehållande dialogsystem och utvärderas. Prototyperna är även ett förslag på ett tillägg till det befintliga webbmaterial som har utvecklats inom projektet Lingua2:svenska. Lingua2:svenskas målgrupp är även tilltänkt målgrupp för våra tre prototyper. Den praktiska delen har genomförts i samarbete med Josefin Bergenholtz. Delar av språkpedagogiken och datalingvistiken kombinerades och implementerades. Tidigt bestämdes att arbetsprocessen måste vara iterativ och att utvärderingen bör bidra till vidareutveckling. Jag har implementerat dialogsystemen och kopplat dem till webinterface. Jag har även anpassat webinterfacet samt gjort en liten Flashanimation samt översatt stödtexterna för de klara prototyperna till tyska. Josefin har byggt SQL databaser med php-kopplingar samt implementerat JavaScript. I metodkapitlet presenteras arbetet med att utveckla de tre prototyperna. I genomförandet av det praktiska arbetet har vi följt en arbetsmetod som är en kombination av en metod för utveckling av andraspråkinlärningsövningar och en metod för utveckling av dialogsystem. Vi har använt Rod Ellis ramverk för task based language learning för att definiera uppgifter. Utifrån dessa uppgifter har vi skapat domäner och sedan anpassat GoDiS till dessa domänerna. Till detta har vi lagt en stor del av tiden på webbdesign och webbprogrammerande för att få fungerande prototyper. Vi har utvecklat tre olika prototyper. Den första handlar om studenter, den andra om recept och den tredje om att boka en biokväll. Följande åtta steg har ingått i metoden för utvecklandet av prototyperna. Se även en illustration av arbetets gång här nedan. 1. Definiera en domän utifrån Ellis ramverk 2. Hitta på dialoger som systemet ska klara 3. Implementation av lexikon. 4. Implementation av dialogplaner. 5. Implementera databas. 6. Koppla systemet till webinterface, skapa webbsidor 7. Testa själv, debugga, fixa till 8. Testa på naiva användare Definiera en ny domän utifrån Ellis ramverk. Gå tillbaka och modifiera. GoDiS implementera en ny domän Bygg webbsida : GoDiS webinterface Ordlista Fill-the-gap sida Databaskopplingar med PHP, etc. Testa och utvärdera. Fig. 12 : Arbetet är iterativt, efter test görs vissa modifieringar. 29

30 3.1 Utgångspunkter Utgångspunkterna för vårat arbete med prototyperna finns inom datalingvistik och andraspråksinlärning. Från andraspråksinlärning har vi tagit fasta på den feedback som fås genom recasts och det ramverk som Ellis utvecklat för att skapa uppifter. Vi vill även använda interaktionshypotesen som menar att språkinlärning främjas när modifiering av input och output sker i syfte att förstå. Inom datalingvistik har vi med oss den resurs som GoDiS utgör och hur informationstillståndsapproachen används för att modellera dialoger. Då Lingua2:svenskas webbaserade kurs ses som en bas för prototyperna är tillgänglighet på webben också en viktigt utgångspunkt En modell som utgångspunkt En modell arbetades fram för att ha som utgångspunkt när vi utvecklar prototyperna. Modellen bygger på interaktionshypotesen och task-based-language-learning. Med modellen vill vi visa hur vi tänker oss de olika interaktionerna - se fig. 13 nedan. elev / användare A uppgiftens input E B dialogsystemet uppgiftens resultat D resurser lärare D pågående iteration iteration endast en gång Fig. 13 : En modell över den interaktion vi tänker oss för prototyperna. A Uppgiftens input består av uppgiftens kontext, instruktioner samt annan information användaren kan tänkas behöva t.ex. formulär att fylla i, bilder eller ljudfiler. B Eleven för en dialog med dialogsystemet för att få eller ge information (enligt de instruktioner som finns givna). C Eleven interagerar med de resurser som finns ordlista, fraslista, bilder, ljudfiler eller annat som kan stödja ändringar av t.ex. semantisk eller lingvistisk form. D När eleven har gjort klart sin uppgift kan han/hon välja att skicka resultatet med hjälp av ett webbaserat formulär till sin lärare. Uppgiftens resultat består t.ex. av det eleven fyllt i tomma fält och den genomförda dialogen mellan elev och dialogsystem. 30

31 E Läraren ger eleven feedback på resultatet och på den genomförda dialogen. Eleven kan svara på den feedback som ges och på så sätt fortsätta konversationen med läraren om det önskas Vem är Mathilda? Levy (1997) presenterar the tutor tool framework som ger möjlighet att dela in CALL-tillämpningar i olika kategorier utifrån att titta på vilken roll datorn är tänkt att ha. När datorn anges rollen som lärare, tutor, får den, enligt Levy, en funktion som utvärderar och kontrollerar användaren. Men när datorn istället är ett verktyg, tool, är den mer neutral och inte tänkt att eventuellt ersätta en lärare. När man skapar dialogsystem med hjälp av TrindiKit och GoDiS anges det som viktigt att dialogsystemet klart kan uppfattas som ett system och inte som en verklig person. I detta fallet har vi frångått detta genom att vi har gett dialogsystemet namnet Mathilda samt skapat en bild av henne som en del av prototypens utseende. Mathilda är tänkt att var en jämlik konversationspartner och inte en lärare. Mathilda har svenska som modersmål och kan därför ge visst stöd till användarna som har svenska som andraspråk. 3.2 Recasts som feedback i GoDiS Förutom den feedback som redan finns inbyggt i GoDiS så har det i detta arbete även implementerats feedback i form av recasts. Recast är enligt Long ett konversationsdrag i andraspråksinlärningssammanhang som ger feedback som uppmärksammar felaktigheterna utan att uttalat anmärka att något är fel eller uttalat rätta till ett fel. I dett fallet betyder det att användarens yttrande upprepas av systemet. Feedback i form av recasts har implmenterats i två olika former. I en av prototyperna ges det alltid en recast medan det i en annan endast ges då användarens yttrande är syntaktiskt felaktigt eller om användaren inte skriver en hel mening utan bara nyckelord. Se exempel nedan på när feedback i form av recasts alltid ges och när det ges endast vid syntaktiskt fel recast är understruket; Exempel 1 alltid recast: Användare : Vad heter Maria i efternamn? Systemet : Vad heter Maria i efternamn? Maria heter Svensson i efternamn. Exempel 2 recast vid syntaktiskt fel: Korrekt inget recast; Användare: Hur mycket ströbröd behövs? Systemet: Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölken. Felaktig recast ges; Användare: Hur mycket dl av ströbröd behöver jag? Systemet: Hur många deciliter ströbröd behövs? Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölken. Recat ges även vid nyckelord; Användare: ströbröd Systemet: Hur många deciliter ströbröd behövs? Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölken. Se vidare om kodningen och modifieringen av GoDiS för att bygga den syntaktiska kontrollen i avsnitt

32 3.3 Definition av en domän utifrån Ellis ramverk Här är ett exempel på hur vi skapade uppgifter utifrån Ellis ramverk. Användning av Ellis ramverk ger en väl definierad presentation av själva uppgiften samtidigt som det ger möjlighet att begränsa sig till en specifik domän vilket är viktigt för dialogsystemet. Utifrån Ellis ramverk definierar vi tre stycken uppgifter, se exempel på definitionen av uppgiften för Recept Köttbuller nedan. Design 1 Mål Det övergripande målet för uppgiften. 2 Input Verbal eller icke-verbal information som ingår i uppgiften t.ex. bilder, bilder, text. 3 Förutsättningar Det sätt informationen är presenterad på, eller hur den är ämnad att användas. 4 Procedur Den metod som man bör använda för att genomföra uppgiften. 5 Önskat resultat: Produkt Den del som är resultatet när man genomfört uppgiften. Kan vara antingen öppen, d.v.s. flera olika resultat godkänns, eller den kan vara stängd, d.v.s. det finns endast ett rätt resultat. Kan ses som en produkt, tex. en ifylld tabell, en ritad bild. Process Den lingvistiska eller kognitiva process som uppgiften är tänkt att stödja. Förklaring En ofokuserad uppgift. Ger tillfälle för användning av frågor som : Hur många? / Hur mycket.? På webbsidan : instruktioner om hur man genomför uppgiften (både på svenska och på engelska). Ett recept där det fattas information. Systemet har information som användaren vill åt. Aktiviteten är en tvåvägs process (elev - dator), men informationen som ska delas har bara systemet kunskap om. Användaren läser uppgiftens instruktioner. Han/hon startar dialogen genom att klicka på Mathilda (en animerad bild av en tjej). Användaren skriver sina yttranden i textform och klickar på en svara-knapp. Dialogsystemet tar hand om användarens yttrande och ger den respons den är programmerad att göra. Användaren kan när som helst välja att modifiera sitt yttrande genom att använda ord- och fraslistan eller genom att använda en mouse-over funktion som visar en översättning av det svenska ordet. Ett färdigt recept som man kan skriva ut om man vill. Den genomförda dialogen att granska själv, skriva ut och / eller skicka till sin lärare. Användaren förväntas producera egna meningar på svenska för att genomföra uppgiften. Det antas att användaren väljer att ändra input eller output för att genomföra uppgiften. Användningen av recasts antas ge implicit negative feedback och stödja språkinlärningen. Fig. 14 : En definition av uppgiften för Recept Köttbullar utifrån Ellis ramverk för task based language learning. 32

33 3.4 Dialoger som systemet ska klara Vi hittade på dialoger som vi ville att systemet skulle klara. Se exempelvis en dialog för prototypen Recept Köttbullar. System : Hej! Nu kan du börja fråga mig frågor om köttbullsreceptet. Användare : Hur mycket blandfärs ska jag ha i köttbullarna? System : Du behöver ett halvt kilo blandfärs. Användare : Hur många ägg behöver jag? System : Hur många ägg du behöver. Vi ska se Du behöver bara ett ägg. Användare : Hur mycket ströbröd behöver jag? System : Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölk Användare : Hur många lökar behöver jag? System : Du ska ha en lök. Det räcker med en liten. Löken ska hackas. Användare : och hur mycket mjölk? System : Två deciliter mjölk. Användare : Ok. Tack ska du ha System : Det var så lite så. Lycka till med köttbullarna! Hej då! Fig. 15 : Exempel på en påhittad dialog 33

34 4. Implementation I följande kapitel förklaras olika delar ur implementationen av applikationerna. Kod från de tre olika prototyperna redovisas tillsammans med förklarande text. Först beskrivs implementation av lexikon, sedan dialogplaner och därefter databaserna. Sist beskrivs implementationen av syntaktisk kontroll. 4.1 Lexikon Här presenteras olika dialogdrag som har implementerats i lexikon-resursen. Även semantiska sorter tas upp. Mathildas hälsningsfras, dialogdraget greet, ser liknande ut i de tre prototyperna. Här är dialogdraget greet för prototypen Studenter i Sverige : output_form(greet, ['- Hej, jag heter Mathilda. Maria, Dirk, Jane och herr Valldosera är alla studenter i Sverige. Vissa uppgifter om dem fattas i formuläret till höger. Din uppgift är att fråga mig och fylla i det som fattas.'] ). Mathildas svar ges med predikatet output_form/2. Här är output_form/2 svar på frågan vad heter XXX i efternamn? i prototypen Studenter i Sverige. I prototypen Studenter i Sverige ges alltid en recast som feedback vilken då redan ar definierad i output_form (se även recast som feeback med hjälp av syntaktisk kontroll i avsnitt 4.4). output_form(answer(efternamn(efter)),x):- hela_namnet(for, Efter), X = ['Vad heter',for,'i efternamn?',for,'heter',efter,'i efternamn.']. Ovan används predikatet hela_namnet/2 som anger både för- och efternamn. Detta predikat implementerades i databasen (se mer i avsnitt 4.3) och är egentligen en genväg inte helt i enlighet med hur GoDiS bör anpassas då man bygger en applikation. När ett yttrande inte förstås av Mathilda i prototypen Studenter i Sverige används icm. output_form(icm:und*neg, ['Nu förstod jag inte riktigt.'] ). När användaren yttrar något används input_form/2. Här nedan ser du den input_form/2 som används i prototypen Studenter i Sverige när användaren frågar efter efternamn. input_form([efternamn],ask(x^efternamn(x))). I predikatet sem_sort/2 anges den semantiska sorten. Den semantiska sorten är definierad i en separat fil som även används av domänkunskapsresursen. Semantisk sort gör det möjligt att skilja på när något är meningsfullt eller inte. Att Maria är av den semantiska sorten namn kan vara meningsfullt vid ett tillfälle men inte i nästa. Här nedan visas exempel på de olika semantiska tillhörigheterna som anges i prototypen Studenter i Sverige. De andra prototypernas semantiska uppbyggnad ser liknande ut. sem_sort( C, top ):- sem_sort( C, namn ); sem_sort( C, studie); sem_sort('maria', namn ). sem_sort(ekonomi, studie). 34

35 I prototypen Biokväll är planen längre (se 4.2) och Mathilda ställer frågor till användaren. De olika frågorna Mathilda ställer beror på var i planen man befinner sig. Här är de frågor som finns i output_form/2 som ställs enligt planen för Biokväll. output_form(ask(a^(vilken_dag(a))),['vilken dag passar dig bäst?']). output_form(ask(b^(film(b))),['vilken film vill du se?']). output_form(ask(c^(regissor(c))), ['Vem är det som har regisserat den filmen?']). output_form(ask(d^(anledning(d))), ['Vad ska du göra på måndag eftersom du inte kan då?']). I prototypen Biokväll kan användaren kan starta en subdialog genom att fråga Mathilda om vilken film hon vill se eller vilken dag hon kan gå på bio. input_form([film,vill,du],ask(filmen)). input_form([dag,passar,dig],ask(dag)). Användarens frågor som startar en subdialog är i detta fallet implementerat med hjälp av input_form/2 (se ovan) men kan även implementeras som wh-frågor. När dialogen Biokväll är genomförd får man ett slutligt svar, som ett kvitto på att man är klar. Svaret är den output_form som används för planen boka: output_form(answer(boka(x)),['det låter bra. Då går vi på bio på',x,'. Glöm inte att skriva upp det i din kalender!']). Synset/2 anger en definition på vad något är. Flera olika uttryck kan betyda samma sak. När användaren anger endast Jan som regissör antar systemet att det är Jan Troell. synset([['jan Troell'],[jan,troell],[jan],[troell]],'Jan Troell'). Användaren kan ange olika namn på sin inbokade yogakväll: synset([[yoga],[yoga-kurs],[yogakurs]],yoga). 4.2 Dialogplaner Här beskrivs hur de olika dialogplanerna ser ut. Planerna för att ta hand om användarens yttrande i prototypen Studenter i Sverige är relativt enkla. I planen för frågor om efternamn nedan triggas frågan om förnamn genom findout om man inte har med förnamn i yttrandet. Slutligen konsulteras databasen för att hitta rätt efternamn: plan(x^efternamn(x), [findout(x1^(namn(x1))), consultdb(x2^(efternamn(x2)))]). I prototypen Recept köttbullar ser planerna ut på följande sätt. När man frågar efter antalet ägg konsulteras databasen. plan(x^agg(x), [consultdb(x2^(agg(x2)))]). 35

36 Biokväll har en längre plan. Här kommer användaren få en del frågor av Mathilda innan dialogen avslutas med att användaren och Mathilda har bokat in en kväll då de ska på bio. Planen kan sägas planera vilken dag som ska bokas. Då det från början i prototypen har angetts att användaren inte kan gå på bio på måndag och Mathilda frågar om det passar på måndag säger användaren nej. Då vill Mathilda veta anledningen till varför användaren inte kan, vilken annan dag han/hon kan, vilken film han/hon vill se och vem som har regisserat filmen. Slutligen anger Mathilda, som ett kvitto på att de ska gå på bio, att de ses den dag de bestämt. plan(x^boka(x), [findout(x1^(anledning(x1))), findout(x2^(vilken_dag(x2))), findout(x3^(film(x3))), findout(x4^(regissor(x4))), consultdb(x5^(boka(x5)))]). 4.3 Databaser Följande avsnitt beskriver databaserna för de tre olika prototyperna. Informationen i databasen i prototypen Studenter i Sverige ser ut så här: post([namn('dirk'),efternamn('weber')]). Vissa hjälppredikat har lagts till i databasen för "Studenter i Sverige". Dessa predikat exporteras av databasen (genom att inkluderas predikatlistan i module/2) vilket gör att databasfilen även kan laddas in i lexikonresursen. Detta är en genväg som fungerar i detta fall eftersom databasen är en statisk databas men det är något som vid en vidareutveckling bör förändras. Se exempel nedan på predikat som har lagts till i databasen för Studenter i Sverige för att inkluderas i module. hela_namnet(xs,ys):- post([namn(xs), efternamn(ys)]). :- module(database_student,[consultdb/3, consultdbx/3, validdbquery/2, validdbparameter/1,hela_namnet/2,namn_alder/2,namn_kurs/2,namn_stad/2,namn_ fornamn/2,namn_telefon/2,namn_national/2,namn_modersmal/2]). I databasen är informationen för Recept Köttbullar inte så omfattande. Här nedan ges exempel på att man anger antal ägg: post([agg(ett)]). I databasen för Biokväll finns inlägg för varje veckodag. Till exempel - har användaren svarat fredag på vilken dag han/hon kan gå på bio så bokas fredagen genom att Mathilda svarar vi ses på fredag. post([anledning(_),vilken_dag(fredag),film('utvandrarna'),regissor(_), boka(fredag)]). 36

37 4.4 Recasts & syntaktisk kontroll Recasts som feedback ges i de två prototyperna Studenter i Sverige och Recept Köttbullar. I Studenter i Sverige ges det alltid recast som feedback, det är inkluderat i svaret från systemet. I Recept Köttbullar ges endast en recast då användarens yttrande inte är syntaktiskt korrekt eller om endast nyckelord används. Den syntaktiska kontrollen som görs på användarens yttrande bygger på det stöd som finns för taligenkänningspoäng (se avsnitt 2.5.2). Poäng 1.0 används i den syntaktiska kontrollen för att ange om ett yttrande är syntaktiskt korrekt och poäng 0.8 används för att ange att ett yttrande är syntaktiskt inkorrekt eller om endast nyckelord används. Om användaren använder många ägg anges poängen 1.0 för dialogdraget ask och det ses som syntaktiskt korrekt. input_form(['många','ägg'],(ask(x^agg(x)),1.0)). Om användaren bara använder ägg, som ett nyckelord, eller använder tex. mycket ägg är poängen 0.8 och det anses syntaktiskt felaktigt: input_form(['ägg'],(ask(x^agg(x)),0.8)). När användarens yttrande är syntaktiskt korrekt anges följande svar: output_form(answer(agg(x)),['vi ska se... du behöver bara',x,'ägg.']). Två olika sorters lösningar på hur recast ska ges implementerades. I båda används icm:pos*und för att ge recasts. I den ena ges både recast och svar som ett feedbackdrag (icm). I den andra ges recast som ett feedbackdrag och svaret (answer) ges som ett separat drag När användarens yttrande är syntaktiskt felaktigt ges en recast genom att icm används. När användaren exempelvis skriver hur mycket ägg behövs? används icm enligt nedan: icm:pos*und:issue(x^agg(x)) I det första fallet ger då yttrandet i output_form både recast samt svar på frågan. Här användes issue istället för answer i output_form: output_form(icm:und*pos:issue(x^agg(x)),['hur många ägg behövs? Du behöver ett ägg'])." 4 Detta medför dock att GoDiS fortfarande anser frågan obesvarad, och systemet ger därför svaret en gång till i nästkommande yttrande 4 Koden ser inte ut exakt såhär, men funktionen är densamma. Vissa ändringar har gjorts för att öka åskådligheten i exemplet. 37

38 I den andra lösningen som testades användes istället både icm- och answer-drag. I output_form för feedback anges recast, och i output_form för answer anges svaret. output_form(icm:und*pos:issue(x^agg(x)),['hur många ägg behövs?']). 5 output_form(answer(x^agg(x)),['du behöver ett ägg']). För att den syntaktiska kontrollen ska fungera har en ny tolkningsmodul byggts. Score har lagts till i de predikat som tolkningsmodulen innehåller. Score anger det siffervärde som avgör om det ska ges en recast eller inte. Tolkningsmodulen (interpret) döps till interpret_syntaxascore och variabeln Score läggs till i predikatet interpret, recognize_moves samt även i predikatet wordlist2moves (se pilarna): interpret :- check_conditions([ is_set(input), $input = Str, $lexicon = Lexicon ]), recognize_moves( Lexicon, Str, MoveList, Score ), type( latest_moves, LMType ), MoveStruct =.. [LMType,MoveList], ( MoveList = [] -> Moves = failed; Moves = MoveStruct ), apply_updates([ set( latest_speaker, usr ), set( latest_moves, Moves ), score := Score]). recognize_moves( _, "", [no_move],1.0). recognize_moves( Lexicon, Str, Moves, Score ) :- string2wordlist( Str, WordList ), wordlist2moves( Lexicon, WordList, Moves0, Score ), remove_duplicates( Moves0, Moves ). wordlist2moves( _, [], [],_Score). wordlist2moves( Lexicon, Sentence, AllMoves, Score ):- append( Phrase, Rest, Sentence ), check_condition( Lexicon :: input_form( Phrase, (NewMoves,Score))), \+ longer_phrase( Lexicon, Sentence, Phrase),!, wordlist2moves( Lexicon, Rest, RestMoves, Score ), add_to_list( RestMoves, NewMoves, AllMoves ). wordlist2moves( Lexicon, [_ Sentence], Moves, Score ):- wordlist2moves( Lexicon, Sentence, Moves, Score ). För prototypen Recept Köttbullar som använder sig av den syntaktiska kollen behöver man ange att denna nya tolkningsmodul ska användas då man kopplar dialogsystemet till webinterfacet se mer i nästkommande kapitel. 5 Koden ser inte ut exakt såhär, men funktionen är densamma. Vissa ändringar har gjorts för att öka åskådligheten i exemplet 38

39 4.5 Webinterface och webbsidor Arbetet med webbsidorna innebar att bygga sidor innehållande information som skulle passa uppgiften samt koppla GoDiS till webinterfacet. Ord- och fraslistor har skapats av Josefin Bergenholtz med PHP och SQL, formulär har skapats med PHP och SQL och mouseover funktioner med JavaScript. Webbsidornas färger och annan layout valdes för att passa med Lingua2:svenskas webbkurs. En stor del av arbetet med webbsidorna innebar att skapa sidor på stödspråken engelska och tyska. Egentligen ska stödspråket vara det modersmål som användaren har men i våra prototyper är valen av stödspråk begränsade till engelska och tyska. Josefin skapade de delar som innehåller PHP, SQL och JavaScript. Jag implementerade Java Appleten, gjorde den flashanimering som föreställer Mathilda samt översatte text till tyska. För att webinterfacet ska kunna köras mot den Sicstusprocess som dialogsystemen drar igång på servern anger man i koden för dialogapplikationen vilka moduler som skall användas genom att definiera predikatet selected_modules/1 på följande sätt: selected_modules([input : input_textscore_socket, interpret : interpret_simple, update : update, select : select, generate : generate_simple, output : output_simpletext_socket]). För den prototyp som använder den syntaktiska kollen, Recept Köttbullar, anger man interpret_syntaxscore istället för interpret_simple. 39

40 5. Resultat, test och utvärdering Resultatet av det praktiska arbetet presenteras i avsnitt 5.1 & 5.2 genom att visa exempel på delar av genomförda dialoger samt genom att visa utseendet på prototypernas webbsidor i bilder. Tester och utvärdering beskrivs i avsnitt Exempel på genomförda dialoger Här följer en kort presentation av delar från genomförda dialoger från de tre applikationerna och vad som utmärker dem. Man kan även se exempel på de olika sorters feedback som finns. Delarna ur de dialoger som presenteras är genomförda dialoger, inte påhittade. För varje applikation ges två exempel. Studenter i Sverige I Studenter i Sverige har man som uppgift att ta reda på saker om olika studenter. Man frågar systemet och får svar. Vid varje svar från systemet ges även den korrekta frågan som en recast. Studenter i Sverige har ingen syntaktisk kontroll. Om man frågat om en viss student och sedan inte anger dess namn i nästa fråga antas av systemet att man fortfarande vill ha information om just den studenten. Då systemet inte förstår användarens yttrande ges feedback. För att visa hur uppgiften kan se ut presenteras här nedan två exempel. Det första visar en användare som skriver meningar och det andra en användare som skriver mestadels nyckelord. Mathilda är dialogsystemet. Exempel 1, Studenter i Sverige : Mathilda: Hej, jag heter Mathilda. Maria, Dirk, Jane och herr Valldosera är alla studenter i Sverige. Vissa uppgifter om dem fattas i formuläret till höger. Din uppgift är att fråga mig och fylla i det som fattas. Användare: Vad är marias efternamn? Mathilda: Vad heter Maria i efternamn? Maria heter Svensson i efternamn. Användare: Hur gammal är Dirk? Mathilda: Hur gammal är Dirk? Dirk är 30 år. Användare: Vad heter Valldosera i förnamn? Mathilda: Vad heter Valldosera i förnamn? Valldosera heter Jordi i förnamn. Exempel 2, Studenter i Sverige : Mathilda: - Hej, jag heter Mathilda. Maria, Dirk, Jane och herr Valldosera är alla studenter i Sverige. Vissa uppgifter om dem fattas i formuläret till höger. Din uppgift är att fråga mig och fylla i det som fattas. Användare: efternamn Mathilda: Nu ska vi se... Vem av studenterna frågar du om, kan du ge mig ett namn? Användare: maria Mathilda: Vad heter Maria i efternamn? Maria heter Svensson i efternamn. Användare: kurs Mathilda: Vilken kurs läser Maria? Maria studerar ekonomi. Användare: jane Mathilda: Nu förstod jag inte riktigt. Ställ en ny fråga om efternamn, kurs, telefonnummer, stad, nationalitet, förnamn, modersmål eller ålder. Användare: stad Mathilda: Är det Jane du frågar om? Användare: ja Mathilda: Var bor Jane? Jane bor i Göteborg. Användare: nationalitet Mathilda: Vilken nationalitet har Jane? Jane är engelsk. 40

41 Recept - Köttbullar I Recept Köttbullar ska man komplettera ett recept där viss information om ingredienser och instruktioner saknas. Man får även här fråga systemet efter information. I denna applikationen finns en syntaktisk kontroll som avgör hur svaret ska se ut. Skriver man en syntaktiskt felaktig fråga eller bara ett nyckelord får man den korrekta frågan i svaret. För att visa hur uppgiften kan se ut presenteras här nedan två exempel på genomförda dialoger. I den första dialogen anges frågor från användaren som innehåller syntaktiskt korrekta formuleringar och inga extra frågor ställs. I den andra dialogen används ibland endast nyckelord och ibland en felaktig syntaktisk formulering. Exempel 1, Recept Köttbullar : Mathilda: Hej, jag heter Mathilda. Jag tycker att du ska prova svenska köttbullar. Vissa uppgifter fattas i receptet till höger. Du kan fråga mig och fylla i det som fattas. Användare: hur mycket blandfärs behöver jag? Mathilda: Det behövs ett halvt kilo blandfärs. Användare: hur många ägg behövs det? Mathilda: Vi ska se... du behöver bara ett ägg. Användare: hur mycket ströbröd behövs det? Mathilda: Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölken. Användare: hur mycket mjölk behövs det? Mathilda: Det behövs två deciliter mjölk. Användare: hur många lökar behövs det? Mathilda: Det behövs en lök. Det räcker med en liten. Löken ska hackas. Användare: vad ska jag blanda med ströbrödet i bunke? Mathilda: Du ska blanda mjölken och ströbrödet. Exempel 2, Recept Köttbullar : Mathilda: - Hej, jag heter Mathilda. Jag tycker att du ska prova svenska köttbullar. Vissa uppgifter fattas i receptet till höger. Du kan fråga mig och fylla i det som fattas. Användare: hur många blandfärs Mathilda: Hur mycket blandfärs behövs? Det behövs ett halvt kilo blandfärs. Användare: ägg Mathilda: Hur många ägg behövs? Du behöver ett ägg. Användare: ströbröd Mathilda: Hur många deciliter ströbröd behövs? Du ska ha en halv deciliter ströbröd. Ströbrödet ska blandas med mjölken. Användare: mjölk Mathilda: Hur mycket mjölk behövs? Det behövs två deciliter mjölk. Användare: lök? Mathilda: Hur mycket lök behövs? Det behövs en lök. Det räcker med en liten. Löken ska hackas. Användare: blanda Mathilda: Du ska blanda mjölken och ströbrödet. Biokväll I Biokväll ska man boka en bioträff med Mathilda. I denna applikationen får man frågor och kan även ställa frågor. Användaren har sin kalender på webbsidan där det är angivet vilka dagar han/hon kan eller inte kan gå på bio. Det presenteras även en lista med tillgängliga filmer och information om dem på webbsidan. I denna dialogen är det systemet som ställer frågor och för dialogen framåt, men även användaren har chans att ställa frågor subdialoger 41

42 För att visa hur dialogen kan se ut presenteras här nedan två exempel på genomförda dialoger. Den första dialogen ger användaren all information på en gång och dialogsystemet använder sig av ackommodering för att förstå allt och ge ett svar. I den andra dialogen förs en längre konversation där det förekommer subdialoger. Mathilda är dialogsystemet. Exempel 1, Biokväll : Mathilda : Hej jag heter Mathilda. Det ska bli roligt att gå på bio med dig. Din egen kalender och listan med filmer hittar du till höger. Kan du gå på bio på måndag? Användare : nej, men vi kan gå på onsdag. Jag vill se Pelle Erövraren som Bille August regiserat Mathilda : Det låter bra. Då går vi på bio på onsdag. Glöm inte att skriva upp det i din kalender! Exempel 2, Biokväll : Mathilda : Hej jag heter Mathilda. Det ska bli roligt att gå på bio med dig. Din egen kalender och listan med filmer hittar du till höger. Kan du gå på bio på måndag? Användare : Det kan jag inte, jag ska sitta barnvakt Mathilda : Nu ska vi se... Vilken dag passar dig bäst? Användare : Jag kan onsdag, torsdag och fredag. Mathilda : På onsdag ska jag på middag och på fredag ska jag på fest. Mathilda : Nu ska vi se... Vilken dag passar dig bäst? Användare : det blir kanske torsdag då. Mathilda : Vilken film vill du se? Användare : jag vet inte, vilken film tror du är bäst? Mathilda : Jag vet faktiskt inte...vilken skulle du helst se? Användare : jag vet inte Mathilda : Okej. Så. Vilken film vill du se? Användare : jag vill nog helst se utvandrarna. Mathilda : Vem är det som har regisserat den filmen? Användare : troell Mathilda : Det låter bra. Då går vi på bio på torsdag. Glöm inte att skriva upp det i din kalender! Användare : nejdå, hej då! Mathilda : Bra, vi ses. Hej då! 42

43 5.2 Presentation av prototyperna i bilder Här presenteras prototypen Recept Köttbullar för att visa hur webbsidorna ser ut. Webbsidorna består av en startsida, sidan med JavaApplet och uppgiften på samt sidor med resultat och enkät. De andra två prototyperna har samma upplägg. Startsidan där man kan välja vilket stödspråk man önskar samt läsa om uppgifterna. Fig. 16 : Startsidan Infoknapp Java applet där dialogen förs med text-till-text. Klickar man på info ges en pop-up ruta med info. Om dialogsystemet skulle låsa sig kan man starta om det på knappen starta om dialogen. Möjlighet att start om dialogen ges med hjälp av knappen Starta om dialogen. Fig. 17 : Java Applet 43

44 Ordlista Fig. 18 : Hela webbsidan Mouse over funktion ger dig översättning. En bild över hela webbsidan. Till vänster för man dialogen och till höger fyller man i det som fattas. Nedan till vänster finns ordlistan. För man musen över ett ord får man översättningen på det stödspråk man valt. När man är klar trycker man på jag är klar. När man är klar Pop-up fönster med info på stödspråket om hur protoypen är tänkt at fungera. Fig. 19 : Info pop up med instruktioner 44