Vi presenterar trasor (Reference Architecture for Generation Systems) ramverk: en specifikation av en abstrakt Natural Language Generation (NLG) systemarkitektur för att stödja delning, återanvändning, jämförelse och utvärdering av NLG-teknik. Vi hävdar att bevisen från en undersökning av de faktiska NLG-systemen kräver en annan tonvikt i ett referensförslag än den som setts i liknande initiativ inom informationsutvinning och multimediagränssnitt. Vi inför själva ramverket, särskilt den datamodell på två nivåer som gör det möjligt för oss att stödja de komplexa datakraven för NLG-system på ett flexibelt och konsekvent sätt, och beskriva våra insatser för att validera ramverket genom en rad genomföranden. I detta dokument beskrivs ett försök att ange en referensarkitektur för genereringssystem för naturligt språk. Fältet Natural Language Generation (NLG) kännetecknas av en mängd olika teoretiska metoder, som har effekten av att splittra samhället och minska bandbredden i kommunikationen. Tekniken är tillräckligt mogen för att kommersiella tillämpningar ska vara nära, och ändå är det relativt sällsynt att NLG-programvara och data återanvänds mellan olika forskare. Projektet "Reference Architecture for Generation Systems" (Reference Architecture for Generation Systems) syftar till att utnyttja den underförstådda överenskommelse som finns inom området och fokusera diskussionen på de verkliga punkterna av teoretisk oenighet med hjälp av en "standard" vokabulär och referenspunkt. Därför syftade trasor till att göra det lättare att: • skapa återanvändbara dataresurser (t.ex. representativa ingångar till algoritmer, korpora av genererade texter tillsammans med deras underliggande representationer); • kommunicera data mellan NLG-programmoduler skrivna vid olika tidpunkter och med olika antaganden, och därmed tillåta återanvändning av sådana moduler; • tillåta att moduler (eller åtminstone deras ingångar och utgångar) definieras på ett relativt formellt sätt, så att deras omfattning och begränsningar kan förstås bättre. På så sätt bör utvecklingen av tillämpningsorienterade system underlättas, standardgränssnitt och dataset kan uppstå, idéer och programvara kan lättare återanvändas, forskare kan realistiskt specialisera sig på särskilda områden och jämförande utvärdering av system och komponenter kan bli möjlig. För förståelsen av naturligt språk har det gjorts betydande framsteg i utvecklingen av "arkitekter" och "infrastrukturer" för att stödja utveckling, standardisering och utvärdering av tillämpningar. Till exempel, grindarkitekturen [Cunningham et al., 1996, Bontcheva et al., 2004 ger en svit av användbara programvarumoduler, faciliteter för gränssnitt nya moduler vars input och utdata passar den underliggande modellen och tjänster för att hjälpa corpus förvaltning, statistisk analys och visualisering av resultat. trasor försöker starta processen för naturlig språkgeneration genom att definiera en "arkitektur" för generationssystem. Vi ser nedan att det finns intressanta skäl till varför detta har visat sig vara ganska annorlunda från grinden. Vi anser dock inte att den nuvarande tekniken sätter någon i position att säga vad den "rätta" NLG-arkitekturen är: det finns helt enkelt för lite kunskap om NLG-processen och för mycket variation i målen att skapa NLG-system. För tidig standardisering skulle skada området och hämma den teoretiska mångfalden. Och ändå definierar trasor en arkitektur. Vi löser denna uppenbara motsägelse på följande sätt: • Vi inriktar oss specifikt på end-to-end-genereringssystem, främst för att system som dessa måste ta itu med alla aspekter av generationsprocessen. Dessutom, en studie av Reiter [Reiter, 1994], diskuteras vidare nedan, föreslog att det finns vissa allmängiltighet som finns i sådana system. Vi gör inga anspråk på andra typer av system, även om det verkar troligt att många aspekter av diskussionen här skulle vara relevanta för ett bredare spektrum av system. • Vi definierar arkitekturen på ett särskilt flexibelt sätt (som beskrivs i avsnitt 3 nedan). Detta innebär att människor kan "köpa in" trasor i varierande utsträckning. Naturligtvis ökar möjligheten till delning när man köper mer, men det är inte ett "allt eller inget" beslut (se avsnitt 5). • Vi använder termen referensarkitektur för att hänvisa till trasor för att betona det faktum att det inte är en föreslagen standard. Förekomsten av en väl specificerad referenspunkt kan vara värdefull inte bara för konstruktörer av nya system, utan också som en jämförelsepunkt för befintliga system, och även som ett fokus för diskussionen om sina egna brister. I nästa avsnitt diskuterar vi befintliga idéer om arkitekturer för NLG och hur vårt föreslagna ramverk kan jämföras med liknande initiativ på andra områden. Vi fortsätter sedan att diskutera de viktigaste inslagen i själva ramen, följt av några av de konkreta genomföranden som har utvecklats inom ramen. Vi sammanfattar genom att diskutera hur man kan använda trasor som det är nu. Slutligen diskuterar vi de viktigaste bidrag som detta arbete har gett, tittar på några av de områden som det ännu inte tar upp och anger möjliga framtida riktlinjer för trasinitiativet. Ytterligare detaljer om specifikationerna för trasor och den programvara som vi distribuerar kan erhållas från vår webbplats på http://crc.open.ac.uk/projects/rags. Generella arkitekturer för NLG Många olika övergripande arkitekturer har föreslagits för NLG-system [De Smedt et al., 1996], vilket återspeglar utbudet av olika tillämpningar och de olika motiven för att bygga system. Hoppas att det kunde finnas en enda väl specificerad arkitektur som skulle vara lämplig för många system höjdes när Reiter [Reiter, 1994] föreslog att många end-to-end programorienterade NLG-system följde samma arkitektoniska modell: en enkel trestegs pipeline som därför kunde ses som en de facto-standard eller "consensus"-arkitektur. Reiter och Dale [Reiter och Dale, 2000] uppdaterade och lade till ytterligare detaljer till detta förslag i sin NLG lärobok. Den övergripande strukturen för deras modell visas i figur 1. Den första stora uppgiften för trasprojektet, som genomfördes 1998, var en omfattande undersökning av tillämpade NLG-system för att validera detta förslag till "consensus"-arkitektur 1. Vi identifierade 19 system 2 som uppfyllde kriterierna för att vara end-to-end tillämpningsorienterade NLG-system, och försökte korrelera deras publicerade beskrivningar med den föreslagna konsensusmodellen. De första slutsatserna var uppmuntrande: även om dessa system hade något från två till sju namngivna moduler, kunde så gott som hela systemet ses som en rörledningsarkitektur där alla modulerna motsvarade en, del av en eller flera av de tre "consensus"-modulerna (det huvudsakliga undantaget för denna modell var Komet - för mer detaljer, se Cahill och Reape [Cahill och Reape, 1998] (2000)) formulering använder något annorlunda terminologi, som vi också använder här, men för våra syften är annars inte helt annorlunda. 2 De system som undersöktes var: Alethgen [Coch och David, 1994] ; Ana [Kukich, 1988] ; Caption Generation System [Mittal et al., 1998] ; Drafter [Paris et al., 1995] ; Drafter2 [Scott et al., 1998] ; Exclass [Caldwell och Korelsky, 1994] ; FoG [Goldberg et al., 1994] ; Ghostwriter [Marchant et al., 1996] ; GIST [Power and Cavallotto, 1996] ; Gossip [Kittredge och Polguére, 1991] ; HealthDoc [Hirst et al., 1997] ; Joyce [Rambow, 1990] ; Komet [Teich och Bateman, 1994] ; LFS [Iordanskaja et al., 1992] ; ModellExplaher [Lavoie et al., 1996] ; Patent Claim Expert [Sheremetyeva et al., 1996] ; Plan [MKepalme m., 1994] ; Provb. Fullständiga detaljer och diskussioner om undersökningen och erhållna resultat finns i Paiva [Paiva, 1998] och Cahill och Reape [Cahill och Reape, 1998 ]. 3 de exemplifieras i någon detalj, och effektivt föreskrivs att vara komplett och av specifika typer (även om vissa variationer är tillåtna i innehållet i en textspecifikation). Detta innebär att det nästan inte finns någon flexibilitet när det gäller tilldelning av uppgifter på lägre nivå (t.ex. retorisk strukturering, lexikalt val) till moduler -om detta föreslås som en "konsensus"-arkitektur, då skulle man förvänta sig att se alla system utföra var och en av dessa uppgifter inom samma modul. Det andra steget i trasan undersökning försökte bekräfta denna aspekt av modellen också, en svårare uppgift eftersom inte alla system beskrivs i tillräckligt detial för att göra tydliga bedömningar. De uppgifter som lågnivågenerationen beaktade för denna analys var: Lexikalisering: Valet av innehållsord som ska visas i den slutliga utdatatexten. Kombinationen av flera strukturer (t.ex. meningar) till en enda, mer komplex struktur. Retorisk strukturering: Fastställandet av retoriska relationer och deras omfattning. Planering av det material som ska ingå i referensuttrycken (inklusive pronominationsbeslutet). Valet av linjär ordning av textens element. Indelning av information i meningar och punkter. Centrering/salience/tema: Spårning av textens salience-relaterade egenskaper inom en diskurs. Denna uppsättning utgör inte en uttömmande uppdelning av NLG i komponenter, utan representerar de uppgifter som oftast identifieras som oberoende funktioner inom NLG-systemen. För att validera "consensusmodellen" på denna nivå tilldelade vi var och en av dessa uppgifter till modulen i den konsensusmodell där den uppstod. Figur 2 är en grafisk representation av resultaten av denna övning 3. För varje system och uppgift finns det tre positioner som kan skuggas, vilket indikerar att uppgiften utförs (delvis eller helt) inom motsvarande modul (med beställningen Document Planner, Microplanner och Surface Realiser). Till exempel, i GhostWriter, utförs aggregering i Microplanner och salience beaktas i både Document Planner och Microplanner. För referens har vi inkluderat Reiter och Dale modellen som den sista raden i tabellen, även om det inte specificerats i detalj vid tidpunkten för undersökningen. För att modellen ska kunna valideras på denna nivå av granularitet förväntar vi oss att de flesta av systemen följer samma mönster som denna sista rad. Det framgår tydligt av diagrammet att de inte gör det. Det råder god enighet om att retorisk strukturering förekommer i dokumentplaneraren, men nästan lika stark oenighet om att segmentering förekommer i Microplanner - de flesta system gör det i dokumentplaneraren. De flesta uppgifter verkar kunna visas i någon modul, eller över två moduler, och Lexikalisering verkar ganska ofta ske i två olika faser. Även om en sådan övning alltid bara är en approximation, är budskapet i figur 2 inte i de särskilda detaljerna utan i den betydande mängd mångfald som anges. Denna mångfald tyder på att även om Reiter och Dale modellen kan ha fångat några högnivåintuitioner om organisationen av NLG-system, är den alltför begränsad för att fungera som grund för en formellt definierad funktionell arkitektur som återspeglar hela utbudet av tillämpade NLG-system. Sammanfattningsvis var våra slutsatser om konsensusmodellens giltighet: 3 Denna siffra är en återpresentation av de två tabellerna i Cahill och Reape (Cahill och Reape, 1998). Där en uppgift utfördes genom användarintervention, inte alls utförd eller där dess placering var oklar, har vi utelämnat den, men vi har inkluderat placeringar markerade som osäkra i de ursprungliga tabellerna. Många av de undersökta systemen hävdade eller verkade följa trestegsmodellen, men det var inte möjligt att tilldela detaljerade funktionella beskrivningar till de tre moduler som var kompatibla med alla, eller ens de flesta, system. 2. Utgångspunkten är följande: Många av systemen hade gemensamma funktionella undermoduler (t.ex. "avseende uttrycksgenerering"), men ordern om utförande av dessa undermoduler, och deras tilldelning till de tre stegen bildade inte ett enda övergripande konsekvent mönster. 3. Vad är det som händer? Det fanns ingen enkel definition av datagränssnitten mellan de föreslagna samförståndsmodulerna, eller ens de lägre funktionella modulerna, i de system som undersöktes – de flesta system manipulerade data på flera språknivåer på ganska komplicerade sätt, och "snapshots" av data vid de putativa gränssnitten avslöjade inte några starka mönster av vad som var och vad som inte var direkt i olika system. Även om deras föreslagna "konsensusmodell" representerar en viktig observation om fältet, är Reiters och Dales särskilda ståndpunkt om definitionen och tidpunkten för modulerna, liksom deras antaganden om hur datatyperna samlas i gränssnitten, även om exempel på god NLG-systemdesign, alltför restriktiva för det allmänna fallet. För att vara till nytta skulle trasornas arkitektur behöva inta en mer flexibel ståndpunkt i dessa frågor. När vi tänkte efter kanske slutsatserna i vår undersökning inte var så förvånande. I grund och botten kan NLG-uppgiften betraktas som ett samtidigt problem med begränsad tillfredsställelse som inbegriper kunskaper på flera språknivåer [De Smedt et al., 1996]. Forskare som föreslår nya arkitekturer och sökmetoder för NLG har hävdat att effektiv generering av optimala texter inte kan uppnås genom att göra val i förutbestämd ordning (till exempel Danlos [Danlos, 1984], Wanner och Hovy [Wanner och Hovy, 1996] ; Mellish et al. (Mellish et al., 1998)............................................................................................................ Detta talar mot att det finns en optimal pipeline eller skiktad strategi som finns i mycket nuvarande NL förståelse arbete. Större komplexitet i datainteraktionen och större variation i bearbetningsordningen kan förväntas, vilket gör uppgiften att utveckla en referensarkitektur mer utmanande. Undersökningen visade dock att det var tillräckligt vanligt för att motivera sökandet efter gemensamma principer, så länge kravet på en exakt arkitekturspecifikation ersattes av strävan efter en mer allmän ram för utveckling av NLG-system. Ett sådant ramverk skulle fortfarande kunna utgöra en grund för samverkan mellan forskare som är överens om grundläggande antaganden om sina systemarkitekturer och datastrukturer – det skulle inte tvinga fram en särskild uppfattning (som en fullständig referensarkitektur skulle ha), men det skulle ge ett gemensamt språk för att uttrycka och utforska ett överenskommet perspektiv. Den resulterande ramen för trasor avlastar kravet på "architectural" till en punkt där det är tillräckligt inkluderande av faktiska system för att vara relevanta, men ändå tillräckligt restriktivt för att vara användbart. Vi uppnådde detta genom att karakterisera på en ganska abstrakt nivå de datatyper, funktionella moduler och protokoll för att manipulera och kommunicera data som de flesta modulära NLG-system verkar förkroppsliga. De viktigaste komponenterna i förslaget om trasor är följande: • En specifikation på hög nivå av de viktiga (språkliga) datatyper som NLG-systemen manipulerar internt. Här används abstrakta typdefinitioner för att ge en formell karakterisering oberoende av någon särskild genomförandestrategi. • Ett referensgenomförande på låg nivå som specificerar detaljerna i en datamodell som är tillräckligt flexibel för att stödja NLG-system. Detta genomförande ("Objects and Arrows Model") karakteriserar formellt uppsättningen rättsliga data representationer som en uppsättning maskinskrivna riktade grafer, • en exakt XML-specifikation för datatyperna, vilket ger en standard "off-line" representation för lagring och kommunikation av data mellan komponenter, • en allmän bild av hur bearbetningsmoduler kan interagera och kombinera för att göra ett komplett NLG-system, med hjälp av dataformat "nativ" till sina särskilda programmeringsspråk som är trogna de modeller på hög och låg nivå och utnyttja överenskomna momentiationer av högnivådatatyper, • flera urvalsimplementationer för att visa hur utvecklingen av en rad konkreta arkitekturer kan uppnås. I figur 3 sammanfattas trasans struktur och hur den är avsedd att användas. Olika processmoduler manipulerar trasor data med hjälp av format som är infödda till deras specifika programmeringsspråk (de kan naturligtvis manipulera andra typer av data, men trasor säger ingenting om hur det kan kommuniceras mellan dem). Dessa format ger implementationer av abstrakta typdefinitioner och är också i överensstämmelse med modellen "objekt och pilar", genom vilken de ärver en standard XML serialisering. Två kommunicerande moduler måste komma överens om en omedelbar bild av de abstrakta datatyperna och kan sedan definiera sina gränssnitt och utbyta data antingen i ett överenskommet inhemskt format eller via XML offline representation. Frikopplingen av det abstrakta från de mer konkreta aspekterna av referensarkitekturen resulterar i en "ram" för utveckling av NLG-system som gör det möjligt för många möjliga betongarkitekturer - för att bygga en verklig NLG-arkitektur måste ytterligare beslut om process- och dataflöde fattas. Detta är ett av de sätt som trasorna arkitektur är ovanligt flexibel. Den resulterande modellen liknar på vissa sätt portarkitekturen för information extraktionssystem [Cunningham et al., 1996, Bontcheva et al., 2004. Båda ger hjälp med att bygga en tillämpning av modulära komponenter som tillhandahålls från andra håll, och är helt obundet till faktiska bearbetningsstrategier som används 1. I grinden uppnås datakommunikation genom inkrementell notering av de texter som analyseras, så de implicita datatyperna är starkt baserade i textelement; eftersom NLG naturligtvis inte börjar med en text, behöver trasor en mer abstrakt NLG-orienterad repertoar av datatyper och -representationer, med mindre beroende av en enda gemensam referenspunkt. trasor innebär således att man intar en starkare teoretisk hållning och försöker göra ett väsentligt uttalande men inte alienera alternativa metoder. 2. Gate är en konkret plattform för allmän implementering, med specifika bibliotek och gränssnitt för applikationsutveckling, med fokus på högkvalitativt stöd för verksamhet på låg nivå. trasor är en ram för att specificera genomförandet (plus vissa urvalsgenomföranden), mer engagerat funktionellt, men mindre engagerat genomförande. Både trasor och grindar stöder byggandet av modulsystem och den jämförande utvärderingen av systemkomponenter, men deras omfattning skiljer sig åt. trasor stöder specifikationen av en komponentuppgift och den standardiserade representationen av önskade ingångar och utgångar. Gate gör detta också (med en enklare datamodell), men ger också mycket mer direkt stöd för genomförandet. Porten har varit mycket framgångsrik. I en ny användarundersökning 4, ungefär hälften av dem som svarade använde systemet aktivt i forskning, programutveckling eller undervisning, vilket tyder på en fortsatt betydande och hälsosam användarbas. Denna framgång uppmuntrar oss att hoppas att något liknande kommer att vara möjligt för NLG. Men framgången med porten bygger på en befintlig underliggande datamodell, tipser arkitektur. En sådan modell finns ännu inte för NLG, så ett viktigt bidrag av trasor är försöket att specificera en. En annan användbar jämförelsepunkt är "standardreferensmodellen" för intelligenta multimediapresentationssystem Vi drar slutsatsen att alla dessa referensförslag, även om de har liknande avsikter och struktur, har en subtilt annorlunda tyngdpunkt. Vi kan särskilja arkitekturer efter ett antal dimensioner. En arkitektur kan vara abstrakt (med stöd för utformning och specifikation) eller konkret (med stöd för faktiska genomförandemekanismer). Det kan vara normativt (svårt att ange vad som är möjligt) eller flexibelt (som tillåter en rad olika typer av genomförande). Det kan vara inriktat på funktionell specifikation (precisera modulerna och deras interaktioner) eller dataspecifikation (precisera data som utbyts mellan eller hålls av moduler). Slutligen kan den vara uppgiftsorienterad (fokuserad på ett smalt spektrum av system med en väldefinierad uppgift) eller generisk (öppen, med avseende på vad systemen är för). Figur 4 visar informellt hur trasor, grindar och impps modellen relaterar till dessa dimensioner. Kärnan i trasramverket är en redogörelse för de data som NLG-system manipulerar: trasornas "datamodell". Denna modell är en beskrivning på två nivåer av NLG-datastrukturer: högnivåmodellen delar in NLG-data i sex grundläggande typer med olika språkliga roller, och specificerar hur de relaterar till varandra; lågnivåmodellen anger formellt vilka datastater som kan kommuniceras mellan NLG-moduler i samband med den föränderliga specifikationen av en text. Lågnivåmodellen utgör också grunden för en enhetlig representation och överföring av data mellan moduler. En användare av trasor ram kan "köpa in" ramen (och befintligt arbete använder den) i varierande grad. De kan till exempel välja om de vill: • representera (vissa av) sina data på sätt som är kompatibla med datamodellen för trasor, • använda särskilda momentiationer av de abstrakta typer som redan används, • implementera moduler med funktionalitet som anges i uppsättningen exempel trasor moduler, eller kompatibel med andra befintliga arbeten, • organisera sina moduler på standard sätt som uppstår från tidigare arbete, eventuellt med hjälp av trasa applikationskomponenter. Den grundläggande ramen för trasor är främst inriktad på den första av dessa, vilket ger en fast grund för fastställandet av överenskomna strategier för andra aspekter när ramen används. Ramverket för trasor stöder sex grundläggande datatyper: Conceptual, Retorical, Document, Semantic, Syntaktic och Citat. Av dessa är Syntaktik och Citat beroende av målspråket och Conceptual kommer ofta att vara oberoende av det. För de andra tre intar vi ingen ståndpunkt om språkberoende, även om vi misstänker att endast (delar av) den semantiska nivån kan vara språkoberoende. NLG system byggs under antagande många olika teorier om syntax, semantik, diskurs, etc. Det skulle vara omöjligt för trasor att producera en allmänt accepterad fullständig definition av representationer på någon av dessa nivåer eftersom det finns så mycket teoretisk mångfald. I stället definierar trasor de olika representationsnivåerna främst i termer av abstrakta typdefinitioner som anger de komponenter som dessa representationer förväntas ingå i. Här använder vi standardnotation från set-teori för att karakterisera datans väsentliga struktur, oberoende av ett visst genomförande (ett gemensamt tillvägagångssätt inom teoretisk datavetenskap, även om det inte används i stor utsträckning inom beräkningslingvistik). Den notation som används i våra definitioner förklaras utförligt i trasans referenshandbok [Cahill et al., 2001b], och presenteras kortfattat här. Således, till exempel: (från avsnitt 3.1.2 nedan) definierar en RhetRep (RhetRep) som består av en RhetRel (rhetorisk relation) och en RhetRepSeq (följd av RhetReps) för barnen. Den senare definieras i sig själv i form av en sekvens av ett eller flera element, som var och en är en RhetLeaf eller en RhetRep. De abstrakta typdefinitionerna "bottom out" i primitiva typer, som anges på följande sätt: RhetRel P rimitives trasor har inget mer att säga om typen RhetRel, som är uppsättningen av retoriska relationer. Forskarna uppmanas att omedelbart påbörja denna uppsättning så som de anser lämpligt i enlighet med vilken teoretisk ståndpunkt de vill inta. Det vill säga, trasor specificerar inte undertyper av primitiva typer, förutom att erkänna att de kan existera. Olika implementationer kan göra olika antaganden om undertyper av primitiva typer, även om mest effektiva återanvändning av kod eller data kommer att vara möjligt mellan forskare som håller med. Alla definitioner av trasor datatyper är alltså parameteriserade via dessa primitiva typer - de definierar det övergripande formatet för en uppsättning strukturer men anger inte den exakta uppsättning av värden som kan visas på bladen av dessa strukturer. Användare av trasor dataset eller moduler måste ange hur de primitiva typerna är ögonblickliga samt hur de använder abstrakta typer. Utöver de abstrakta typdefinitionerna ger vi också informella exempel på representationerna i notationer som tyder på faktiska genomförandemöjligheter 5. 5 trasor stöder inga specifika noteringar förutom XML-utväxlingsformatet som beskrivs i avsnitt 3.4. Det är viktigt att inse att det på sätt och vis inte finns något särskilt nytt i följande förslag. De är avsiktligt förankrade i befintlig praxis och bygger på ingående studier av befintliga teorier. Betydelsen av trasor modellen kommer från den explicita artikuleringen av de distinkta nivåerna av representation och deras form. Vi anser inte att NLG-system alltid är uttryckliga om arten av deras representationer (t.ex., om något är semantiskt eller syntaktiskt), och problem uppstår om detta görs dåligt. Konceptuella representationer inkapslar hänvisningar till data "utanför" NLG-systemet - vanligtvis information som tillhandahålls som generatorns ingång. Detta är inte semantiska framställningar: de kan inte ha någon enkel koppling till språkliga beslut och de antas inte vara skapade eller förändrade av NLG-systemet. För begreppsmässiga representationer finns det en enda primitiv typ KBId ("kunskapsbasidentifierare"). trasor anger hur ett NLG-system kan förhöra sådana data för att ta reda på om omvärlden, med hjälp av funktioner som: Även om konceptuella enheter kanske inte har någon enkel språklig tolkning, de ändå måste vara relaterade till språkliga begrepp för att ett NLG-system kan hantera dem. Detta är anledningen till att ovanstående funktioner uttrycks i termer av semantiska predikat, roller, etc., snarare än en separat konceptuell vokabulär. Trasor API för KBIds är mycket nära det abstrakta gränssnittet mellan penmansystemet [Mann, 1983] och dess kunskapsbas, och det kan genomföras via en Upper Model [Bateman, 1990]. Specifikationen för detta API är också kompatibel med åsikten att ett NLG-systems interaktion med en extern kunskapskälla bör ske genom ett kontrollerat gränssnitt som ger ett visst skydd mot brister och oegentligheter i de underliggande uppgifterna [Reiter och Robertson, 1999]. Reiter och Dale [Reiter och Dale, 2000] diskuterar elementen i en domänmodell i termer av enheter, attribut, relationer och klasser (i en hierarkisk taxonomi). Ovanstående API tillåter enkel förfrågan av en sådan domän (förutsatt att relationer återställs). Reiter och Dale skiljer sig dock från trasor när det gäller att hävda att predikat, roller etc. är faktiskt en del av domänen, snarare än en del av en språkorienterad syn på domänen. I allmänhet kan principer för innehållsbestämning i NLG vara mycket domänberoende, och därför kan en ram som trasor säga lite om dem. Vissa aspekter av innehållsbestämning är dock involverade i genomförandet av KBId s. Retoriska representationer definierar hur satser (i trasor, SemReps -se avsnitt 3.1.4) i en text är relaterade. Till exempel, den första meningen i texten i Figur 5, "Blow din näsa, så att det är klart", genereras av rikedomssystemet [Cahill et al., 2001a], kan anses bestå av två förslag: snyt näsan och näsan är klar, sammankopplad med en relation som MOTIVATION.  Således en retorisk representation (RhetRep) är ett träd vars inre noder är märkta med relationer (RhetRel), och vars blad är atomretoriska noder (RhetLeaf, som, som vi kommer att se i avsnitt 3.2, kan till exempel betraktas som pekare till konceptuellt eller semantiskt innehåll). Ett exempel på en enkel retorisk representation visas informellt i figur 6. Här finns en enda RhetRep som innehåller en sekvens av två RhetLeaf s (associerad med semantiskt innehåll, som inte är strikt en del av RhetRep själv). RhetRel för RhetRep har subtypen MOTIVATION, ett teorispecifikt samband. Betydelsen av underträdens positioner specificeras inte för trasornas representation i allmänhet, eftersom den är teorispecifik. Teorispecifika definitioner av relationer specificerar därför döttrarnas roll. Till exempel, ett genomförande av retorisk strukturteori [Mann och Thompson, 1988] skulle behöva specificera att, till exempel, den första dottern till MOTIVATION relationen är "nucleus" och den andra "satelliten", om relationen istället CONTRAST, skulle det ange att den andra var en annan "nukleus". Likaså, ett genomförande baserat på diskursen teorin om Moser och Moore [Moser och Moore, 1996] skulle behöva specificera att till exempel, den första dottern av MOTIVATION är "kärnan" och den andra "bidrag", men att döttrar i en CAUSE relation hade ingen sådan beteckning. 11 MOTIVERING
Det finns också ett motsvarande arbete REF som utmanar denna nedbrytning.
A Reference Architecture for Natural Language Generation Systems
{'venue': 'NATURAL LANGUAGE ENGINEERING', 'journal': None, 'mag_field_of_study': ['Computer Science']}