Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson

En presentation över ämnet: "Requirements and Design Considerations for an Open and General Architecture for Information Refinement Fredrik Olsson"— Presentationens avskrift:

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

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

3 Nyttan av generell och återanvändbar språkteknologimjukvara Undvika att uppfinna hjulet om och om igen. Förkorta vägen från idé till prototyp. Ett steg mot reproducerbara forsknings- resultat.

4 Några utmaningar Variationer mellan och inom språk. Kunskap om: Uppgiften. Användarna. Användarnas situation. Underhåll av språkliga resurser.

5 Mål och frågor (1/2) 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? Definiera en generell och öppen arkitektur för informationsförädling.

6 Mål och frågor (2/2) 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 (1/2) 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.

8 Informationsförädling (2/2) – några tillämpningsområden Nyheter och mobila tjänster (SICS, DSV och room33 AB). Databrytning (SICS, eNiklas AB). Stöd för professionella informationssökare (SICS, Patent- och Registreringsverket). Proteinnamnsigenkänning (SICS, Virtual Genetics Laboratory AB).

9 Mjukvaruplattformar (1/8): TIPSTER DARPA, CIA, DoD, NIST, SPAWAR. 1991-1998. 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.

10 Mjukvaruplattformar (2/8): Eurotra EU-projekt: 12 länder, 18 institutioner, 150 forskare. 1977-1993. 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.

11 Mjukvaruplattformar (3/8) : CLE SRI International, Cambridge University. Engelskt projekt. 1985-1992 (?). 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).

12 Mjukvaruplattformar (4/8): ALEP EU-projekt: IAI, Cap Gemini, SNI, SRI-CRC, Cray Systems, SEMA, BIM. 1991-1995. Mål: plattform för att minska tiden från prototyp till produkt. Möjligt att inkorporera existerande komponenter. Publikt tillgänglig.

13 Mjukvaruplattformar (5/8): Verbmobil Tyskt storprojekt. 31 partners, 168,6 miljoner D-mark, 900+ forskare. 1993-2000. Mål: tal till tal-översättningssystem: tyska, engelska och japanska. Resultatet finns inte publikt tillgängligt.

14 Mjukvaruplattformar (6/8): GATE GATE: University of Sheffield. 1995 – Mål: teoriobunden kommunikations- och kontrollinfrastruktur för språkteknologikomponenter. Bygger på TIPSTER. Fritt tillgänglig.

15 Mjukvaruplattformar (7/8): 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.

16 Mjukvaruplattformar (8/8): 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.

17 En fallstudie – SVENSK (1/3) NUTEK, SICS. 1996-1999. Mål: generell verktygslåda för svenska bestående av återanvändningsbara komponenter. Bygger på GATE.

18 TextCat Tokeniser LexToken Splitter UCP SweCG 2 CLEBrillTagger ParserBox DSPDUP LP-Detect SweCG Indata Utdata

19 En fallstudie – SVENSK (3/3) Utmaningar: Politiska; dela med sig, licenser, dokumentation. Tekniska: integrering, APIer, buggar i svarta lådor, dokumentation. Lingvistiska: domänanpassning, avsaknad av verktyg för lingvistisk avlusning och underhåll.

20 Allmänna observationer (1/2) 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.

21 Allmänna observationer (2/2) Håll arkitekturen öppen. Möjliggör användande av existerande och systemspecifika komponenter. Stöd underhåll av arkiktekturen.

22 Behov av en ny plattform - Kaba Fanns ingen passande plattform för informationsförädling. Full kontroll över koden: Funktionalitet. Distribution/öppenhet.

23 Kravspecifikation för informationsförädling (1/3) 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.

24 Kaba-baserat system Information Användare Kaba-baserat system Kaba-baserat system Information AnvändareMjukvara

25 Kravspecifikation (3/3) - användarkrav 1. Utveckla informationsförädlingssystem. 2. Utvärdera system. 3. Flytta system till ny informationsdomän eller till nytt språk. 4. Dokumentera system. 5. Underhålla system. 6. Skapa lektioner. 7. Hantera data och program.

26 Design av en öppen arkitektur (1/4) 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).

27 Design av en öppen arkitektur (2/4) 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).

28 Design av en öppen arkitektur (3/4) 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).

29 Design av en öppen arkitektur (4/4) 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).

30 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.

31 Nya forskningsfrågor (1/3) 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?

32 Nya forskningsfrågor (2/3) 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?

33 Nya forskningsfrågor (3/3) 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?

34 Exempel på ett Use Case Use Case 7.5: Manage data persistence Goal: To manage data that is persistent across user sessions. Scope: System. Level: User goal. Description: The system will produce intermediate results, e.g., part-of-speech tagged text or documents in which named entities have been marked. Data persistence is necessary for two reasons: sharing intermediate results and error recovery, both of which boil down to not having to redo work already done. Essentially this means that the system could be shut down in an (un)controlled fashion, yet still keep the results of the processing made so far. The implications of data persistence also indicate that a user may work with the same source of information during several sessions while having access to the results from the previous ones.