Presentation laddar. Vänta.

Presentation laddar. Vänta.

Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson fredriko@sics.se Jag kommer att.

Liknande presentationer


En presentation över ämnet: "Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson fredriko@sics.se Jag kommer att."— Presentationens avskrift:

1 Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson Jag kommer att prata på svenska. några av er är här för att ni tror att ni måste vara det. andra är säker här för att de tror att de vill. en del av er ser mer nervösa ut än jag känner mig. jag vet inte om det är ett direkt bra tecken. ni får gärna ställa frågor som för presentationen framåt, typ, vad betyder egentligen den där förkortningen. ni får gärna vänta till efter presentationen med frågor av typen "vad är forskning för dig". jag ska nu på fy§rtio minuter presentera licen som på ungefär 140 sidor pressar in fyra års arbete. som ni kan förstå kommer jag inte att kunna gå in på detaljer som jag egentligen skulle vilja gå in på. den tid jag har arbetat på sics, de senaste fyra åren, har mer eller mindre handlat om två saker; återanvändning av programvara för språkteknologi och informationsåtkomst och -förädling. den här licen handlar om snittet mellan de två områdena.

2 Innehåll Introduktion Informationsförädling
Några viktiga mjukvaruplattformar En fallstudie – SVENSK Allmänna observationer Kravspecifikation och design av en öppen arkitektur för informationsförädling Slutsatser

3 Nyttan av generell och återanvändbar språkteknologimjukvara
Undvika uppfinna hjulet om och om igen Förkorta vägen från idé till prototyp Ett steg mot reproducerbarhet av forskningsresultat OBS: återanvändbarhet hos språkteknologiprogramvara innebär också generalitet: för att mjukvara ska kunna vara återanvändbar måste den också vara generell eftersom det är väldigt sällan en programvara är tänkt att användas helt oförändrad i en ny tillämpning. Ibland kommer jag att säga generell när jag menar återanvändbar och tvärt om.

4 Några utmaningar Variationer mellan och inom språk
Kunskap om uppgiften, användarna och deras situation Det finns många många utmaningar och det här arbete syftar inte till att hitta alla utmaningar; bara de mest uppenbara.

5 Mål och frågor Definiera en generell och öppen arkitektur för informationsförädling. Q-1: Hur beskriva en mängd relaterade språkteknologiuppgifter som är liten nog att försöka göra generell mjukvara för, och som samtidigt är stor nog för att rättfärdiga det merarbete som konstruerandet av sådan mjukvara medför? Min ansats: begränsa typen av uppgifter du ämnar lösa för att på så sätt fokusera konstruktionen av generell mjukvara för de uppgifterna till något som är skäligt i termer av resurser och funktionalitet.

6 Mål och frågor (forts.) Q-2: Hur kan mängden relaterade uppgifter beskrivas i termer av krav som en tänkt användare kan ha? Q-3: Hur kan kravspecifikationen implementeras, dvs. hur ska en mjukvara som svarar mot kraven designas?

7 Informationsförädling
Med informationsförädling menas den arbetsprocess i vilken text hanteras i syfte att komma åt de delar av innehållet som är relevant sett från ett visst perspektiv. Informationsförädling handlar om text. Vi har kontakter med en mängd företag och organisationer och vi har märkt att deras textuella informationshanteringsbehov i stort handlar om samma saker; de är samtliga professionella (med allt vad det innebär av krav på tillgänglighet och kontroll) och de har behov av hjälp inom väldefinierade områden med mer eller mindre väldefinierade uppgifter. Arbetsprocess: uppgift eller situation över en viss tid. Komma åt (access): handlar om att tillhandahålla verktyg och metoder för att ge hög och lätt tillgänglighet till information som användaren behöver. Relevans: relevans knyter ihop informationsbehov, sökprocess och textuellt innehåll. Exakt vad relevans är är det ingen som kan förklara, men det är onekligen så att människor lätt oxh snabbt kan avgöra om en text är relevant för henne eller inte. Perspektiv: genom att betrakta texter som något mer än bara påsar av ord, dvs. genom att inse att de har struktur kan man tala om olika perspektiv på text. T.ex. Läser en läkare FASS annorlunda än sjukpensionären eftersom de har olika kunskaper och olika mål med att läsa FASS. Exempel på tekniker: Informationsextraktion Informationsåtkomst summering

8 Informationsförädling – några tillämpningsområden
Texter och mobila tjänster. SICS, DSV och room33 AB. Data mining. SICS, eNiklas AB. Stöd för professionella informationssökare. SICS, Patent- och Registreringsverket. Proteinnamnsigenkänning. SICS, Virtual Genetics Laboratory AB. För att visa några nyttor av informationsförädling. Vi har en massa andra kompisar också. KIB, HD, Observer, Telia, Speedy Tomato, It’s Alive, Svensk Byggtjänst, Ericsson Research...

9 Mjukvaruplattformar: TIPSTER
DARPA, CIA, DoD, NIST, SPAWAR. Mål: effektiv och billig dokumenthantering. Objektorienterad databasarkitektur: Dokument och samlingar av dokument. Annoteringar, spann och attribut. Specifikationen publikt tillgänglig. Ingen har gjort en fullständig implementation. På de kommande åtta ljusbilderna går jag igenom de mest slående egenskaperna hos några av de system och projekt som har haft mest inverkan på hur språkteknologisystem konstrueras idag. Listan är alls inte fullständig! TIPSTER har haft stor inverkan på hur många valt att hantera eller inte hantera textuell information. TIPSTER-gruppen fick slut på pengar. Det är antagligen ogörligt att implementera hela TIPSTER-specifikationen. Men det är ganska många som har tagit inspiration av TIPSTER.

10 Mjukvaruplattformar: Eurotra
EU-projekt: 12 länder, 18 institutioner, 150 forskare. Mål 1: förindustriell prototyp av transferbaserad maskinöversättning för nio språk. Mål 2: förbättra forskningsklimatet och kompetensen i datorlingvistik i europa. Delar av arbetet finns tillgängligt. Det anses att lite för lite arbete lades ner på systemkonstruktion. 9 språk innebär 72 transfersystem. Gruppen kom överens om ett antal generella designprinciper; varje transfersystem var tvunget att vara enkelt. Detta innebar att analys- och genereringsfaserna blev komlexa i motsvarande grad. Frågor på systemkonstruktionsnivå såsom denna är intressanta: Fanns det någon annan möjlig approach? Interlingua skulle ha reducerat antalet ”transfersystem”/gränssnitt till 9. Den stora svårigheten med Eurotra var förmodligen att det aldrig konvergerade mot ett system. Eurotra uppfyllde det andra målet.

11 Mjukvaruplattformar: CLE
SRI International, Cambridge University. Engelskt projekt. (?). Mål: domänoberoende system för att omvandla engelska till formell representation. Inte publikt tillgänglig: ”You don’t give away a one million Pound program” (SRI:s forskningschef). Modulär design som skickar den formella representationen av indata mellan sig. Kunde anpassas till andra språk än engelska. Det sägs ingenting om hurvida man kan använda existerande komponenter i CLE eller om allt måste utvecklas specifikt för CLE.

12 Mjukvaruplattformar: ALEP
ALEP: EU-projekt. IAI, Cap Gemini, SNI, SRI-CRC, Cray Systems, SEMA, BIM. Mål: plattform för att minska tiden från prototyp till produkt. Möjligt att inkorporera existerande komponenter. Publikt tillgänglig. Byggde på erfarenheter från Eurotra (?) Tanken var att ALEP skulle vara öppen, grundläggande och lågpris. Svårarbetad. Riktad till experter. Krävde att man använde en viss formalism.

13 Mjukvaruplattformar: Verbmobil
Tyskt storprojekt. 31 partners, 168,6 miljoner D-mark, 900+ forskare. Mål: tal till tal-översättningssystem: tyska, engelska och japanska. Resultatet finns inte publikt tillgängligt. Två ansatser till kommunikationslösning mellan komponenter: Fleragentarkitektur. Men till slut handlade det om 69 komponenter och 2380 interface och det var för många. Black-board-arkitektur istället. 198 svarta tavlor för modulerna i Verbmobil att utväxla information genom.

14 Mjukvaruplattformar: GATE
GATE: University of Sheffield. 1995 – Mål: teoriobunden kommunikations- och kontrollinfrastruktur för språkteknologikomponenter. Bygger på TIPSTER. Fritt tillgänglig. Kräver inte att man följer en viss formalism. Stöder integrering av data och algoritmiska resurser, det ansågs som någonting nytt att det inte bara var data som skulle återanvändas.

15 Mjukvaruplattformar: DARPA Communicator
DARPA, MITRE, AT&T Labs, MIT, IBM, NIST. Bygger på MIT’s Galaxy II. Mål 1: nästa generations multimodala gränssnitt till distribuerad information. Mål 2: en arkitektur för alla där det är lätt att anpassa och utvärdera moduler. Fritt tillgänglig. Projektet pågår och jag är inte säker på när det startade. Kanske 98? Med distribuerad information menar de sådan som finns tillgänglig i olika källor och behöver kombineras på något sätt. Alla tycker inte att DARPA Communicator är riktigt bra: ”We’ve spent most of our time the last year trying to make our stuff follow Communicator standards rather than on doing research” (NASA-forskare). Uttalat mål att påverka standardbildningar inom området.

16 Mjukvaruplattformar: ATLAS
NIST, MITRE, LDC. Mål: generell arkitektur för att annotera lingvistisk data med tillhörande verktyg. Påminner om TIPSTER. Fritt tillgänglig: bjuder in alla att vara med. Architecture and Tools for Linguistic Analysis Systems (ATLAS). Främst för tal. Vet inte när det startade eller när det är tänkt att sluta.

17 En fallstudie - SVENSK NUTEK, SICS. 1996-1999.
Mål: generell verktygslåda för svenska bestående av återanvändningsbara komponenter. Bygger på GATE. Jag, Björn och Micke. Forskning och utbildning. Tanken var att SVENSK skulle vara fritt tillgänglig för svenska intressenter. Bygger på GATE. ALEP, som var ett alternativ, var inte tillräckligt lätt att handha. Här förkastades också alternativet att bygga en egen plattform, jag var inte inblandad i det beslutet Här tillbringade jag mycket tid: Mycket kodning och tid: exjobb + 2 år heltid för min del.

18 TextCat Splitter UCP DSP DUP SweCG Tokeniser LexToken SweCG2CLE
BrillTagger Språkidentifiering: van Noord’s textcat. Tokenisering: En tokeniserare för svenska (Olsson 98) En tokeniserare för lexikaliserade fraser (Hassel och Johansson 00) En igenkännare för komplexa lexikaliserade fraser (Lindberg 99, Hassel och Johansson 00) En meningsavgränsare för svenska (Olsson 98) Ordklasstaggning och morfologisk analys En svensk version av Brill-taggaren (Prytz 97) Tvånivåmorfologi och begränsningsgrammatik från Lingsoft (Karlsson 92) (Koskenniemi 83) Uppsala Chart Processor (Sågvall Hein 81) Grammatiska resurser: Deep-level unification-based processor (Gambäck 97) Domain-specific processor (Sunnehall 96) ParserBox (Gambäck m.fl. 94) Summa sumarum, en hel del komponenter, som inte alltid är utvecklade för SVENSK och integrering i första hand. Många olika programmeringsspråk och register. DSP DUP LP-Detect ParserBox

19 En fallstudie - SVENSK Utmaningar:
Politiska; dela med sig, licenser, dokumentation Tekniska: integrering, inga APIer, buggar i svarta lådor Lingvistiska: domänanpassning, avsaknad av verktyg för lingvistisk avlusning Politiska. Få forskare och andra att dela med sig av sina skapelser. Svårt också att få dem att dokumentera och börja integrera sina program; det ska de kanske inte heller, det är väl inte deras jobb. Kommersiella intressen ett problem; licenser, spridning av resultat. Tekniska. Integrering av komponenter skrivna i olika språk gör det hela mer beroende av plattformen; alla komponenter måste ju bli tillgodosedda i termer av virtuell maskin, kompilator, och vad det nu kan vara. API kommer att vara i centrum eftersom man måste lita på att man kan ha ett konsistent sätt, som inte ändras över programvaruversioner, att komma åt funktionalitet i de olika modulerna. Dokumentation. Rätta buggar. Lingvistiska. Domänanpassning av komponenter är svårt om det inte finns verktyg för det. Buggrättning.

20 Allmänna observationer
Hög tid att utvecklare kombinerar kunskap från språkteknologiområdet med traditionell mjukvaruutveckling. En arkitektur bör vara generell m.a.p. en klass av uppgifter, inte ett helt forskningsfält. Olika typer av användare kan ha olika krav. Fokusera på tillämpningsområdet. Håll arkitekturen öppen. Möjliggör användande av existerande och systemspecifika komponenter. Stöd underhåll av arkiktekturen. Den här listningen bygger på erfarenheterna med SVENSK och det jag har läst i litteraturen, dvs. det som beskrevs under ”Några viktiga mjukvaruplattformar” tidigare. Listningen kan tyckas vara självklar, men det är den inte.

21 Behov av en ny plattform - Kaba
Fanns ingen passande för informationsförädling Full kontroll över koden Funktionalitet Distribution/öppenhet Varför inte använda nån annan existerande plattform? Utöver det som står på ljusbilden: Bygga Kaba ser jag som en utbildningsgrej; hur ska jag kunna vara viktig om plattformar och arkitekturer utan att ha byggt en själv. När vi började med Kaba (1999) fanns inte någon tillräcklig flexibel plattform att tillgå. GATE fanns inte tillgänglig i Java, som vi ville använda: GATE 1.5 var implementerad i Tcl/Tk, C och C++ och Sheffield höll just på med att ta fram en Java-version. Hade vi använt GATE 1.5 så hade vi varit fast och varit tvugna att göra om en massa kodning när Javaversionen väl kom. Kaba kommer inte att vara en fix mängd verktyg för att skapa färdiga produkter.

22 Kravspecifikation för informationsförädling
Användare: datorlingvist/programmerare Kaba ett verktyg för utvecklare av informationsförädlingssystem Tillåta integrering av existerande och specialgjorda komponenter Bygga på öppna standarder Favoriserar ingen speciell lingvistisk teori I fortsättningen skiljer vi mellan Kaba och Kaba-baserade system. Tänkt användare är en datorlingvist med programmeringskunskaper, eller en grupp människor med motsvarande kunskaper. Projektbegränsningar. Bygga på öppna standarder. Förutsätter att ordklasstaggning och annan grundläggande lingvistisk analys redan har gjorts när texterna läses in i Kaba. Kaba ska fungera under Linux, sedan andra OS. Programmeringsspråket ska vara välkänt och använt, typ Java.

23 Information Kaba-baserat system Användare Information Kaba-baserat
Mjukvara Information Kaba-baserat system Användare Tänkta omgivningar för ett Kaba-baserat system. Mjukvara

24 Kravspecifikation - användarkrav
Utveckla informationsförädlingssystem Utvärdera system Flytta system till ny informationsdomän eller till nytt språk Dokumentera system Underhålla system Skapa lektioner Hantera data och program Kravspecifikation. Kraven handlar om vad man ska kunna göra, inte hur man gör det Hur man gör är frågan för designfasen. Use cases kan beskrivas som det som händer när olika aktörer, mänskliga eller inte, interagerar med ett system. Omfånget av ett UC kan vara strategic scope eller system scope. Här: bara systemnivå. Nivån på ett UC kan vara summary goal, user goal eller sub-function. Här: bara summeringsmål och användarmål. Här är de sju övergripande kraven som ställs på Kaba: det är det här en utvecklare som ska använda Kaba vill göra. Sammanlagt 30 use cases på olika nivåer för Kaba. Kapitel 6, sidan 71 – 92.

25 Design av en öppen arkitektur
Hantering av data Metadata för komponenter (UC 7.1). In- och utdata (UC 7.3, 7.4). Intern representation av annoterad text (UC 7.6). Databeständighet (UC 7.5). Designen handlar om hur kravspecifikationen kan implementeras. Use cases behandlas inte alltid ett och ett i designfasen; de klumpas ihop efter problemen de adresserar samt sättet på vilka de kan lösas. Metadata: bläddra i samlingar av komponenter, fungerar som indikatorer på begränsningar i funktionalitet, automatisk invokering av moduler. Metadata bör beskriva bl.a. Vad en modul kräver respektive producerar. Metadata och data om text kan representeras på samma sätt i Kaba. In- och utdata: Kaba förutsätter att indata är analyserat, f.n. M.h.a Conexors FDG. Indata konverteras från FDG-format till ett mellanliggande SGML-format innan det läses in i Kaba. Det interna formatet ska också kunna konverteras till SGML och sparas. Från detta ska man sen kunna producera det format som krävs: XML, HTML, PostScript, ... Intern representation: ska medge snabb åtkomst av godtycklig del av data. Ska vara minnessnålt. Kaba använder en delmängd av TIPSTER: single span annotations, inte samlingar av dokument, eller ha attribut och föräldrar för dokument. Databeständighet: ska stöda multipla sessioner. Enklaste sättet är att låta beständig data lagras på samma format som in- och utdata.

26 Design av en öppen arkitektur
Interaktion med andra Kaba-baserat system används av annan mjukvara (UC 1.1.1). Kaba-baserat system använder externa komponenter (UC 7.7.3). Kaba-baserat system interagerar med människor (UC 1.2.1, 1.2.2, 1.2.3). Distribuerad processning (UC 1.1.3, 7.7.1). Dokumentation och lektioner (UC 1.1.4, 4, 6, 7.2). Interaktion 1: kräver ett eller flera begränsade och väldefinierade Kaba APIer, t.ex. Publikt tillgängliga metoder i Javaklasser. Interaktion 2: viktigt att externa komponenter ser likadana ut från Kabas vy, därför måste externa komponenter kläs in i kod som definierar APIerna, för att abstrahera bort från t.ex. Kommandoradsargumenten hos en ordklasstaggare. Interaktion 3: det svåraste fallet att generalisera över. Lösningarna i varje enskilt Kaba-baserat system måste vara specifika, men Kaba kan fås att underlätta arbetet med gränssnitt genom att ge väldefinierade krokar till t.ex. Java Swing. Distribuerad: ett kaba-baserat system kan ta hjälp av funktionalitet som finns utspritt över t.ex. Internet genom att använda sockets eller SOAP. Dokumentation: här är det svårt att ge programmatiskt stöd eftersom man inte på förhand vet vad som ska konstrueras m.h.a. Kaba (jmfr. Gränssnitt mot människor). Däremot kan man ge riktlinjer, exempel och kanske ett dokumentformat som kan användas (typ Javadoc, LaTeX, DocBook, HTML).

27 Design av en öppen arkitektur
Skapa interna (systemspecifika) komponenter (UC 7.8.1). Använda interna komponenter (UC 7.8.3). Underhåll av system Underhåll av externa komponenter (UC 1.1.2, 7.7.2). Underhåll av interna komponenter (UC 7.8.2). Underhåll av hela system (UC 5). Skapa interna: CPSL-regler kompileras till Java-kod. Ett eller flera regelpaket kan kombineras till program. Kommer också att kunna tillverkas m.h.a. Maskininlärning som genererar CPSL-regler. Det senare är inte ett löst problem. Forskningsfråga senare i pratet. Använda interna: när CPSL-reglerna blivit Javakod måste det Kaba-baserade systemet veta var det ska hitta regelpaketet. Underhåll 1: underhåll av externa komponenter är för Kaba samma sak som underhåll av APIet genom vilket Kaba-baserade system kommunicerar med den externa komponenten. Allt hänger på externa komponenten och dess tillverkare; automatisk nedladdning och uppgradering, visuella verktyg för att underhålla grammatikor, osv. Underhåll 2: grafiska gränssnitt för att hantera CPSL-regler. Underhåll 3: involverar också hantering av hela systems dokumentation och mjukvarudependenser osv. Kan uppnås genom direktiv och exempel på hur dokumentation kan integreras i systemet m.m.

28 Design av en öppen arkitektur
Stöd för att flytta Kaba-baserade system mellan olika informationsdomäner (UC 3). Stöd för utvärdering av system (UC 2). Flytta: att flytta system mellan informationsdomäner är inte en baggis. Maskininlärning och människoinblandning kommer att behövas; den förra för att minska graden av den senare (som är dyr). Forskningsfråga senare i pratet. Utvärdering: genom att tillhandahålla lingvistiskt annoterad data som kan fungera som ett facit, eller genom att tillhandahålla verktyg som arbetar på sådana facit för att räkna ut ett och annat. Detta är inte ett löst problem. Forskningsfråga senare i pratet.

29 Slutsatser Syftet med generella verktyg är gott, men genomförandet är problematiskt och inte alltid berättigat. Användbara generella verktyg kräver begränsningar! Informationsförädling bra begränsning Kravspecifikation och designförslag kan synliggöra nya forskningsfrågor Att skapa generell och återanvänbar mjukvara för språkteknologi handlar till mångt och mycket om att tillhandahålla lösningar för uppgifter som ofta behöver lösas, ofta är dessa av administrativ natur, t.ex. Att läsa och skriva data till och från filer, att koppla ihop ett eller flera program över ett nätverk, och att tillhandahålla väldefinierade APIer för att andra ska kunna återanvända sådana resurser. De rent lingvistiska tillämpningarna stöds inte i samma utsträckning, på sin höjd verkar stödet kunna ta formen av rutiner och verktyg för datainsamling (lexikon, trädbanker) och väldigt sällan som ren data, t.ex. Lexikon. Antalet användarkrav för en generell och öppen arkitektur för informationsförädling är inte orimligt stort. Några av kraven befinner sig i forskningsfronten, men flertalet går att uppfylla med befintliga tekniker.

30 Nya forskningsfrågor - övergripande
När en hypotes om informationsförädling har implementerats i ett system, är det möjligt att använda samma system, eller delar av det, för att testa en annan hypotes? När är det bättre att bygga ett helt nytt system än att återanvända ett existerande? Med grund av egna intressen och vad som dök upp som olösta problem i designförslaget ställer jag mig följande framtida forskningsfrågor. De här har att göra med hur Kaba ska kunna utvecklas till att vara mer generell inom sitt område, dvs. informationsförädling. Min tanke är att dessa frågor ska ligga till grund för min avhandling.

31 Nya forskningsfrågor - systemnivå
Vilka metoder är användbara för att samla och annotera data i syfte att träna och utvärdera komponenter för informationsförädling? Vilka maskininlärningsmetoder är lämpliga för vilka informationsförädlingsuppgifter?

32 Nya forskningsfrågor – bortom systemet
Givet att ett informationsförädlingssystem ska konstrueras och att det är tänkt att användas och kanske t.o.m. definieras av användare som inte är experter; vilka metoder finns det för att fånga slutanvändarnas informationsbehov?


Ladda ner ppt "Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson fredriko@sics.se Jag kommer att."

Liknande presentationer


Google-annonser