Tabu. Jaargang 20

(1990)– [tijdschrift] Tabu– rechtenstatus

Nieuwe bouwstenen voor gebruikers-interfaces
Jan de Vuyst en Bert Bos

0 Samenvatting

Door bepaalde ontwikkelingen in de automatisering worden steeds hogere eisen gesteld aan interactieve gebruikers-interfaces. Twee typen interfaces treden daarbij op de voorgrond: grafische en natuurlijke taal interfaces. Bij het ontwerpen van dergelijke interfaces bestaan echter twee knelpunten, namelijk de noodzaak rekening te houden met een grote variatie in invoer en met de daaruit voortvloeiende administratie. Behalve aan randvoorwaarden als efficiëntie en geheugenbeheer wordt in dit artikel aandacht besteed aan een methode om de genoemde administratie te automatiseren en los te koppelen van zowel de vorm als de funktionaliteit van interfaces; hierdoor wordt het ontwerpen en implementeren van interfaces aanzienlijk eenvoudiger. Tenslotte wordt, op grond van de verschillende soorten toepassingen van beide typen interfaces gepleit voor een integratie: de natuurlijke taal interface kan worden geformuleerd als een object binnen de object-georiënteerde grafische interface.

1 Inleiding

Door verschillende ontwikkelingen in de automatisering is de rol van de interactieve gebruikers-interfaces steeds belangrijker geworden. Drie ontwikkelingen liggen daaraan met name ten grondslag: ten eerste de toenemende complexiteit van de data die moeten worden ingevoerd, ten tweede de toename van computergebruik door ‘leken’ en ten derde de zich ontwikkelende telematica, waardoor steeds grotere aantallen mensen zich steeds verder van de computercentra bevinden.

Na een korte beschouwing van elk van deze ontwikkelingen in het gebruik van computers wordt vervolgens in paragraaf 3 ingegaan op de vereisten die men aan interfaces mag stellen en meer in het bijzonder op de natuurlijke taal interfaces (paragraaf 4) en grafische interfaces (paragraaf 5) In paragraaf 6 wordt kort besproken waarom intergratie van beide soorten interfaces wenselijk is, en hoe dat mogelijk is, waarna paragraaf 7 met een aantal conclusies afsluit.

2 Computer-gebruik

2.1 Complexe gegevens

De complexiteit van de in te voeren gegevens is de laatste jaren drastisch toegenomen Die complexiteit is moeilijk in getallen uit te drukken, maar het is wel duidelijk dat bijvoorbeeld een database-query taal een stuk ingewikkelder is dan een spelling-checker. Naarmate computerprogramma's ingewikkelder problemen kunnen oplossen, wordt het specificeren van die problemen in computer-taal moeilijker. Er is niet langer één manier van gegevensinvoer geschikt voor alle applicaties. Het is noodzakelijk dat de computer zelf hulp biedt bij het correct invoeren.

2.2 Nieuwe gebruikers

Steeds meer mensen willen (of moeten) met computers werken en natuurlijk willen die mensen ook gebruik kunnen maken van alle mogelijkheden die het apparaat biedt. Over het algemeen zullen ze niet in staat zijn een cursus te volgen voor elk programma en bovendien gebruiken ze de meeste mogelijkheden waarschijnlijk zo infrequent dat ze er ook nooit werkelijk ervaring mee krijgen. Zo ziet men allerlei programma's op de markt verschijnen die afgestemd zijn op ongetrainde gebruikers. Een voorbeeld zijn de adviessystemen, een nieuwe ontwikkeling in het spoor van de expertsystemen. Expertsystemen zijn bedoeld als gereedschap voor een beperkte groep gebruikers met verstand van zaken, adviessystemen voor een veel grotere groep mensen die informatie of advies willen over iets waar ze geen verstand van hebben. Voorbeelden van adviessystemen zijn stads-informatiesystemen als in Maastricht, Will-writer (een Amerikaans systeem voor advies aan mensen die een testament willen maken), of programma's voor computer-ondersteund onderwijs.

2.3 Technische ontwikkelingen

De ontwikkelingen in de telematica zorgen er voor dat steeds meer mensen gebruik kunnen maken van informatie en programma's die fysiek gezien ver weg zijn. Via de telefoon en de televisiekabel komen voortdurend nieuwe diensten beschikbaar. Hulp in de vorm van menselijke adviseurs wordt echter niet meegeleverd. De mogelijkheden die geboden worden moeten toegankelijk zijn voor een zeer grote en weinig homogene groep gebruikers. Het interface wordt haast belangrijker dan de geboden dienst zelf, want mensen nemen wel genoegen met magere antwoorden, maar niet met een systeem waarin ze vastlopen. Het programma kan geen enkele vooronderstelling maken over de gebruiker, behalve dat die gebruiker mogelijkerwijs nooit eerder met een

computer heeft gewerkt en misschien zelfs nu nog niet beseft dat hij/zij eigenlijk met een computer communiceert. Een postorderbedrijf dat zijn klanten via de kabel laat bladeren in de on-line catalogus kan wel instructies rondzenden, maar is niet in staat een adviseur te sturen naar elke huiskamer waar een gebruiker vast komt te zitten.

3 Adequate interfaces

De traditionele manieren om een programma te laten doen wat de gebruiker wil, zijn de commando-taal en het menu-systeem. Het nadeel van commando-talen zoals database query talen (bijvoorbeeld SQL) en macro-talen (bijvoorbeeld TeX) is, dat ze niet geschikt zijn voor leken. Elke taal moet eerst geleerd worden en daarvoor is tijd nodig en vaak ook begeleiding. Bovendien vergeet men een taal snel als die een tijd niet wordt gebruikt. Menu's vangen dat probleem op (de gebruiker hoeft weinig of niets te leren of te onthouden) maar ze zijn niet geschikt voor complexe invoer, omdat de gebruiker in de veelheid van keuzes snel verdwaalt.

Twee andere typen interfaces zijn veelbelovend: natuurlijke taal interfaces (NLI) en grafische gebruikersinterfaces (GUI). Het idee achter taalinterfaces is dat de gebruiker, zonder hulp, in zijn/haar eigen taal al efficiënt kan communiceren; de computer zou zich daaraan moeten aanpassen, in plaats van de mens aan de computer. De grafische systemen proberen met behulp van plaatjes, tekst en menu's het beeld te benaderen dat de gebruiker van een bepaald probleem heeft. Vaak kunnen de acties van de gebruiker beperkt blijven tot het intypen van enkele woorden en verder het aanwijzen van plaatjes en menukeuzes met behulp van een muis of gewoon met een vinger.

De knelpunten bij het vervaardigen van interfaces liggen op een drietal verschillende terreinen. In de eerste plaats moet het interface, gezien het ‘directe’ contact met de gebruiker, in een acceptabel tempo werken: efficiëntie is een belangrijke randvoorwaarde. In de tweede plaats moet het interface geen al te zware eisen aan de apparatuur stellen. Dit lijkt in tegenspraak met het eerste knelpunt: een snel en krachtig systeem stelt immers hoge eisen aan bijvoorbeeld geheugenomvang en/of schermresolutie van de machine waarop het moet draaien. Anderzijds is het juist de popularisering van de computer die steeds hogere eisen aan de prestatie van interfaces stelt, en die popularisering speelt zich niet af in de hoek van de zware werkstations. Een tweede randvoorwaarde is dus dat het interface op een personal computer moet kunnen draaien. Dat, in samenhang met de randvoorwaarde van de efficiëntie, stelt hoge eisen aan onder meer het geheugenbeheer en de schermsturing. Het derde, en grootste, probleem is de complexiteit van de software, die bij de bestaande systemen vaak gesteld is in één van de traditionele hogere programmeertalen. Dergelijke programmeertalen werken met concepten die ver afstaan van de elementen waaruit een

grafisch systeem of een taal-interface bestaan. In feite vergt een interface een bijbehorende hoge taal die overeenkomt met het type bewerking dat het interface moet uitvoeren: de taal-interface moet grammaticaregels in taalkundige notatie kunnen accepteren en een grafische interface moet objecten zoals ‘window’ rechtstreeks kunnen accepteren.

4 Natuurlijke taal interfaces

4.1 Parsing

Alle natuurlijke taal-verwerking veronderstelt ten minste kennis van taal en kennis van het domein waarover wordt gesproken of geschreven in die taal. Als een natuurlijke taal interface voor algemene doeleinden moet kunnen worden ingezet heeft het interface ook algemene ‘kennis van de wereld’ nodig. Die algemene kennis is één van de hardnekkigste problemen in het vakgebied van de kennisrepresentatie en in de praktijk wordt de kennis dan ook beperkt tot specifieke domeinkennis. Die kennis is nodig voor het juist interpreteren van door het interface geanalyseerde invoer en zal sterk verschillen per applicatie. Dergelijke kennisrepresentatie valt dan ook buiten het bestek van dit artikel (zie daarvoor De Vuyst 1987, 1989 en verwijzingen daarin).

De taalkundige kennis van een taalverwerkend systeem is opgeslagen in een grammatica, die wordt verwerkt door een parser. ‘Parsing’ in engere zin is het in relevante elementen uitsplitsen van invoer, en in ruimere zin het proces dat een tekst in een of andere taal met behulp van een grammatica omzet in een andere vorm, bijvoorbeeld in een database query of een opdracht aan een expert-systeem. Tot de taak van de parser behoort ook de controle of de invoer wel voldoet aan de grammatica en de afhandeling van fouten als gevolg van ongrammaticale teksten. In de context van computer-programma's wordt de semantiek van de invoer gelijkgesteld aan de gegenereerde structuur. Parsing is derhalve één van de cruciale processen in een taalverwerkend systeem.

Eind jaren vijftig werd parsing nog gezien als een noodzakelijk kwaad ten behoeve van het automatisch vertalen van teksten van de ene taal naar de andere. Er werd tamelijk ad hoc gewerkt. In de jaren zestig concentreerde men zich op contextvrije (CF-) grammatica's en de daarop gebaseerde parsers. Door kritiek van taalkundigen, die CF-grammatica's ontoereikend achtten voor met name de correcte associatie van semantiek met de tekst, verslapte de aandacht voor deze klasse van grammatica's. In het midden van de jaren zestig verschijnen dan twee soorten parsers: een groep gebaseerd op modellen uit de transformationele taalkunde (TG-parsers) en de zogenaamde Augmented Transition Network parsers (ATN's). De TG-parsers behoren tot de meest moeizame parsers in de geschiedenis van de natuurlijke-taalverwerking. (cf. Petrick, zelf een TG-onderzoeker, in Shapiro

1987, pagina 693: ‘The [TG-parsers] are usually mechanisms of some kind that produce structures of the type thought to be correct at some time by the advocates of some variant of TG.’). ATN's hebben sinds het begin van de jaren zeventig een prominente rol gespeeld. Een deel van hun populariteit zal ongetwijfeld te danken zijn aan het relatieve gemak waarmee ze kunnen worden geïmplementeerd. ATN's lenen zich overigens voor een aantal verschillende parse-methoden; de belangrijkste zijn recursive descent, leftcorner parsing en chart-parsing. Die flexibiliteit geeft al meteen hun zwakte aan: ATN's zijn te primitief. De ontwerper van een parser die zijn/haar programma schrijft als een ATN moet te veel denken in termen van een machine met een geheugen en een programma-verloop in plaats van in termen van grammaticaregels. Het is niet altijd makkelijk een bepaalde regel uit een grammatica te vertalen naar een ATN.

In de jaren tachtig kan men een aantal ontwikkelingen in de techniek van het parsen van natuurlijke taal onderscheiden. Algemeen is er hernieuwde aandacht voor phrase-structure grammatica's met onder andere feature-grammatica's, opnieuw gebaseerd op contextvrije grammatica's. Een aantal bezwaren tegen CF-grammatica's uit de jaren zestig is inmiddels weerlegd. Of de nieuwe vormen van CF-grammatica's inderdaad resultaten zullen gaan opleveren is nog moeilijk te zeggen.

Dat laatste heeft mede tot gevolg dat het hele terrein van parsing van natuurlijke taal zich momenteel in een aantal verschillende richtingen ontwikkelt. Er is een theoretische strijd over ‘puur’ syntactisch parsen op basis van taalkundige systemen als Generalized Phrase Structure Grammar, Unification Grammar of Logical Form Grammar, waarbij zaken als equivalentie van grammatica's, efficiëntie van algoritmes en wiskundige eigenschappen van complexe categorieën (verzamelingen features) een rol spelen (zie Reyle & Rohrer 1988). Daarnaast is er een toenemend aantal theorieën waarbij men probeert af te zien van syntactische analyse: parsing opnieuw als een ‘noodzakelijk kwaad’ dus. Deze theorieën proberen de structurele analyse te laten leiden door conceptuele begrippen. Voorbeelden zijn de (al wat oudere) case-grammar, de (misleidend getitelde) ‘semantische grammatica’ gebaseerd op ATN-technieken, de expectation-driven parser (onder andere op TG gebaseerd) en de word expert parser, waarin conceptuele beschrijvingen nauw zijn verbonden aan individuele woorden uit het lexicon. Als basis voor een implementatie van deze systemen is onder andere de techniek van het blackboard ontwikkeld, prominent toegepast in HEARSAY (zie Penny Nii 1989). Een ander instrument is de chart-parser die een eigen ‘programmeertaal’ definiërt speciaal voor het schrijven van parsers (bijvoorbeeld de taal PATR, zie hieronder en ook Shieber 1986 en Gazdar & Mellish 1989).

Concluderend kan men stellen dat parsing wezenlijk is voor de verwerking van natuurlijke taal, maar dat er een aanzienlijk aantal praktische problemen moet worden opgelost voordat de ontwerper van een natuurlijke taal interface een juist werkende parser ter beschikking heeft. Gezien de aandacht die uit moet gaan naar de complexiteit/eenvoud van de invoer lijkt de

chart parser een veelbelovende techniek te bieden. Een parser doorloopt een zin op zoek naar de structuur ervan. Op verschillende momenten moet de parser beslissen welke regel uit de grammatica van toepassing is. Hij kiest als hypothese één van de regels en gaat vervolgens de hypothese testen. Een chart-parser slaat op een efficiënte manier tussenresultaten op, om te voorkomen dat bepaalde vormen van redundantie en ambiguïteit in de grammatica tot dubbel werk leiden. Een chart is een datastructuur waarin de parser geanalyseerde delen van de invoer, maar ook onafgemaakte of mislukte ontledingen op kan slaan. Met de verzamelde gegevens kan de parser voorkomen dat een bepaalde hypothese over de structuur van een zin(sdeel) ooit tweemaal wordt getest.

Een zogenaamde deterministische parser kan altijd direct de juiste regel kiezen op grond van het volgende woord in de zin. Een non-deterministische parser zal eerst een (onbekende) hoeveelheid werk moeten doen voordat duidelijk is of een bepaalde hypothese over de structuur van de zin correct is. Voorbeelden van deterministische parsers zijn recursive descent of LL-parsers en LR-parsers (zie Winograd 1983 en Aho, Sethi & Ullman 1988).

Een chart-parser verwerkt non-deterministische grammatica's zo efficiënt mogelijk. Uiteraard zorgt de administratie van de chart voor een zekere overhead en een chart-parser kan daarom niet de efficiëntie halen van deterministische parsers. Maar grammatica's voor natuurlijke taal zijn over het algemeen niet of nauwelijks deterministisch te maken en de chartparser kan een polynomiale complexiteit garanderen waar andere methoden zoals backtracking of pseudo-parallellie al gauw exponentieel groeienGa naar eind1.

4.2 PATR en unificatie

Beschouw de twee zinnen

(1)	Pak de schroevedraaier met de lange steel.
(2)	Pak de schroevedraaier met de linker hand.

De ‘juiste’ interpretatie is, dat het zinsdeel vanaf met in (1) een nadere aanduiding is van de schroevedraaier (welke schroevedraaier?), terwijl datzelfde zinsdeel in (2) iets zegt over de manier van pakken (hoe? of waarmee?). De interpretatie berust op eigenschappen van de woorden schroeve-draaier, steel en hand. Dit soort afhankelijkheden moet in de grammatica uit te drukken zijn. Een geschikte notatie daarvoor is PATR. De PATR-notatie voor (context-vrije, phrase structure) grammatica's is de laatste jaren op weg de lingua franca van de natuurlijke taalverwerking te worden. Voorbeeld van een PATR-notatie (Gazdar & Mellish 1989)Ga naar eind2:

(3)	Rule
	S --> NP VP
	<S cat> = s
	<NP cat> = np
	<VP cat> = vp
	<NP num> = <VP num>

Alle terminals en non-terminals in PATR hebben (beter gezegd: bestaan uit) een verzameling attributen of features (cat en num in bovenstaand voorbeeld). Door de regels uit de grammatica toe te passen op de woorden uit de invoer, worden de attributen die nog geen waarde hebben ingevuld. Attributen die al een waarde hebben dienen om te worden vergeleken met de overeenkomstige attributen van de woorden. Zo wordt getest of de regel van toepassing is. Als we bijvoorbeeld de regel toepassen op de zin Piet loopt met de woorden

Word	Word
‘Piet’	‘loopt’
<cat> = n	<cat> = v
<num> = sg	<num> = sg

dan blijkt dat Piet past op de terminal N, waardoor het attribuut cat van N de waarde ‘n’ (van noun) krijgt en het attribuut num de waarde ‘sg’ (van singular). Op dezelfde manier past loopt op V en op beide samen is regel (3) van toepassing; de cat van S wordt daardoor ‘s’ en de attributen van N en V worden getest.

De volgorde waarin waarden aan attributen wordt toegekend is afhankelijk van de methode die de parser toepast, maar die methode heeft geen invloed op de uitkomst, hoogstens op de efficiëntie. Dit proces, waarbij sommige attributen een waarde krijgen en andere worden vergeleken, zonder dat van te voren wordt vermeld wat nu precies met welke attributen gebeurt, heet unificatie. Over het algemeen kan de parser niet van te voren weten welke attributen in een bepaalde situatie een waarde krijgen en welke gebruikt moeten worden om hypotheses te testen. Bovendien kunnen de attributen in PATR willekeurig complexe structuren bevatten. De attributen gedragen zich als de variabelen in Prolog (Clocksin & Mellish 1984), maar dankzij de chart hoeft de parser geen backtracking te gebruiken.

De PATR-notatie voor grammatica's is overzichtelijk en tegelijk dankzij de unificatie toch zeer krachtig. Een chartparser die PATR-grammatica's kan lezen is daarom een goede basis voor een NLI.

5 Grafische interfaces

Het tweede type interface dat in dit artikel nadere aandacht krijgt is de grafische gebruikers-interface (GUI). Grafische gebruikers-interfaces zijn er nu zo'n jaar of tien. De pioniers waren Rank-Xerox Corporation met de programmeertaal Smalltalk (1976) en de Xerox Star computer (1981) en het team van Niklaus Wirth aan de Technische Hochschule in Zürich met de Lilith computer (1977). De laatste jaren neemt het gebruik explosief toe met het beschikbaar komen van steeds meer computers die krachtig genoeg zijn voor het intensieve rekenwerk dat achter de schermen in een grafisch systeem moet plaatsvinden.

Programma's die een grafisch interface hebben zijn typisch erg groot en complex, omdat het bijhouden van het (bitmapped) scherm en het reageren op alle mogelijke invoer veel werk vergt. Om het werk te vereenvoudigen zijn langzamerhand verzamelingen algoritmes en complete subroutine-bibliotheken ontstaan (bijvoorbeeld X Windows) die vaak ook te koop zijn (bijvoorbeeld Microsoft Windows). Bij al deze systemen blijft het echter zo, dat de ontwerper moet werken met een programmeertaal die in eerste instantie gericht is op het verwerken van eenvoudige objecten als getallen en letters.

Talen die gebruik maken van object oriented technieken zijn beter in staat de complexe structuren te behandelen die nodig zijn voor grafische systemen. In talen als Smalltalk (Goldberg 1983) worden data en procedures niet meer los van elkaar gezien, maar wordt uitgegaan van objecten die worden gedefiniëerd door de data die ze kunnen bevatten en de veranderingen die die data kunnen ondergaan. In een grafisch programma kan bijvoorbeeld een pictogram of icon een object zijn: het bevat informatie over de vorm van het pictogram en tevens informatie over de veranderingen die daarin mogelijk zijn (andere kleur, andere positie op het scherm, etcetera). Deze manier van ontwerpen sluit beter aan bij het beeld dat de gebruiker van het uiteindelijke interface heeft: een verzameling objecten op het scherm die hij/zij elk afzonderlijk kan manipuleren.

Naarmate de problemen van het ontwerpen van grafische interfaces beter worden begrepen en naarmate er meer mensen nodig zijn die deze interfaces kunnen ontwerpen, groeit de behoefte aan aparte instrumenten voor de specificatie van interfaces. Zoals PATR de mogelijkheid biedt om een parser te schrijven zonder gebruik te maken van een algemene programmeertaal, zo is er ook behoefte aan een instrument om interfaces te specificeren zonder daarvoor subroutines aan een applicatie-programma toe te moeten voegen. Een voorbeeld van zo'n tool is ‘Hypertalk’, een interface- en batch-taal op de Macintosh computer.

Om de vorm en de funktionaliteit te kunnen loskoppelen van de implementatie van grafische interfaces, is speciaal GIST (Gebruikers-Interface-Specificatie-Taal; Bos 1990) ontwikkeld. Voorbeeld van een GIST-notatie:

Description:	een lichtblauwe window
Name:	‘lb window’
Type:	window
Colour:	0.5 0.5 1.0
Size:	80 25
Text:	‘De Lichtblauwe Window’
Actions:
initialize:	‘b-1’ open.
‘x’:	self ‘stop nu’.
‘stop nu’:	self close, * ‘exit’.

Description:	de stop-knop
Name:	‘b-1’
Type:	button
Border:	1 + 1
Colour:	0 0 0
Size:	19 1.1
Text:	‘stop dit voorbeeld’
Actions:
mouse-up:	self select, ∧ ‘stop nu’.

Het bovenstaand voorbeeld beschrijft een window met de titel ‘De Lichtblauwe Window’ met daarin een button met de tekst ‘stop dit voorbeeld’. Uit de beschrijving van de funktionaliteit onder Actions blijkt onder andere dat de button reageert op de muis door de opdracht ‘stop nu’ naar boven door te geven. De window reageert daarop door zichzelf te sluiten en de opdracht ‘exit’ door te geven aan de applicaties die achter het interface schuil gaan. De GIST-interpreter zorgt voor de noodzakelijke administratie en de correcte vertaling van acties van de gebruiker naar opdrachten aan het interface. Deze opzet maakt het makkelijk een interface te geven aan een programma dat er nog geen heeft. Met name blijkt het een groot voordeel dat een interface eenvoudig kan worden veranderd, zonder dat die verandering gevolgen heeft voor de applicatieprogramma's. Door zijn opzet hoort GIST tot de familie der object oriented programmeertalen. De objecten zijn windows, pictogrammen, menu's en dergelijke, maar ook editors en (natuurlijke-taal-) parsers zijn objecten in een interface volgens GIST.

6 Integratie

De beide typen gebruikers-interfaces die we bespraken in dit artikel hebben elk hun eigen kenmerkende toepassingen en beperkingen. Zo zal men een natuurlijke taal interface goed kunnen inzetten voor het raadplegen van een gegevensbestand: eventuele ambiguïteiten in de invoer leiden hoogstens

tot niet gevraagde maar wel met de vraag samenhangende informatie. Voor het bijwerken van gegevens echter is een dergelijke ambiguïteit onacceptabel. Een grafisch interface is zeer geschikt om de gebruiker- in staat te stellen verschillende objecten te manoeuvreren, maar niet alle gebruikers zullen een dergelijke veelheid aan mogelijkheden op prijs stellen en willen liever geconfronteerd worden met één vraag en één type invoer. Overigens lenen ook niet alle televisieschermen zich voor grafische interfaces. Het probleem is natuurlijk dat dezelfde gebruiker tijdens hetzelfde applicatieprogramma verschillende vormen van interfacing nodig kan hebben. Op het ene moment wil de gebruiker zicht hebben op bijvoorbeeld verschillende delen van een programma, en kunnen derhalve windows van pas komen. Op een volgend moment moet een gegevensbestand geraadpleegd worden of hulp gevraagd worden, en zou een natuurlijke taal het voor de hand liggende communicatiemiddel zijn. Gezien de aard van de besproken interfaces sluit de één de ander echter niet uit: de natuurlijke taal interface kan uitstekend worden opgenomen als één van de objecten in de grafische interface. Op een gevraagd, of door het interface geschikt geacht, moment opent een window naar de natuurlijke taal interface. Voor bepaalde applicaties of zelfs bepaalde gebruikers kan dat het enige window zijn. In andere gevallen zijn ook verschillende andere objecten beschikbaar, waardoor beide typen interfaces maximaal effectief kunnen worden ingezet.

7 Conclusie

De toenemende complexiteit van gegevens voor invoer, de toenemende aantallen relatief naïve gebruikers en de toenemende mogelijkheden die de techniek te bieden heeft stellen alle samen steeds hogere eisen aan (gebruikers-)interfaces. Maar interfaces zijn in de gebruikelijke hogere programmeertalen moeilijk te ontwerpen en te implementeren. Voor twee veelbelovende typen interfaces, natuurlijke taal interfaces en grafische interfaces, is daarom gezocht naar mogelijkheden om ontwerp en implementatie fundamenteel te vereenvoudigen. De notaties PATR en GIST blijken daartoe de geschikte middelen te leveren, en tegelijkertijd toe te laten dat de twee typen interfaces geïntegreerd kunnen worden in één (object georiënteerde) interface-omgeving, waardoor typerende voordelen van elk soort interface effectief gecombineerd kunnen worden.

Bibliografie

Aho, A., R. Sethi & J.D. Ullman (1988), Compilers, principles, techniques and tools. Addison-Wesley. Reading, Mass.

Bos, G. (1990). ‘GIST; Gebruikers-Interface-Specificatie-Taal’ interne publicatie, Vakgroep Alfa-informatica, RUG

Gazdar, G. & C. Mellish (1986), Natural Language Processing in Prolog. Addison-Wesley. Workingham, England.

Goldberg, A. (1983), Smalltalk-80: the language and its implementation. Addison-Wesley. Reading, Mass.

Penny Nii, H. (1989), ‘Blackboard Systems’. Barr, Cohen & Feigenbaum (refd.) Handbook of Artificial Intelligence, Vol. TV, Addison-Wesley. Reading, Mass.

Reyle, U. & C. Rohrer, (red.) (1988), Natural Language Parsing and Linguistic Theories. Reidel. Dordrecht

Shieber, Stuart M. (1986), An introduction to unification-based approaches to grammar. Chicago University Press. Chicago.

Shapiro, S.C., (red.) (1987), Encyclopedia of Artificial Intelligence. Wiley and Sons. New York.

Vey Mestdagh, C.N.J. & G. Bos, (1989), ‘A and not A = true, juridisch systeem voor het verwerken van tegenstrijdige aannames en afleidingen’, Kennissystemen jrg.3 nr.4 (april 1989) pp.8-11.

Vuyst, J. de (1987), ‘Taalkunde en kunstmatige intelligentie: kennisrepresentatie’ TABU Bulletin voor Taalwetenschap 17 (4) pp. 164-183

Vuyst, J. de (1989) ‘Technieken voor kennisrepresentatie’ TABU Bulletin voor Taalwetenschap 18 (1) pp. 31-43

Winograd, T. (1983), Language as a cognitive proces, volume 1: syntax, Addison-Wesley. Reading, Mass.

Wirth, N. (1981), ‘The personal computer Lilith’. Institut für Informatik, Report 40, ETH Zürich.

eind1: De auteurs zijn werkzaam bij de vakgroep Alfa-informatica van de Rijksuniversiteit Groningen
Polynomiale complexiteit betekent dat de parser rekentijd nodig heeft die lineair is met een zekere macht van n, het aantal woorden in de zin. Met een goede structuur voor de chart kan O(n³) worden bereikt. Dit betekent dat de tijd die de parser nodig heeft proportioneel is met de derde macht van het aantal woorden in een zin. Exponentieel wil zeggen dat de tijd afhangt van eⁿ en dat is voor niet te kleine n groter dan welke macht dan ook.

eind2: Legenda: Een zin (Sentence) bestaat uit (-->) een nominaal deel (Nominal Phrase) en een werkwoordelijk deel (Verb Phrase); cat is een afkorting van category, en num van number (enkelvoud/meervoud).

Vorige Volgende

Nieuwe bouwstenen voor gebruikers-interfaces Jan de Vuyst en Bert Bos