tceic.com
学霸学习网 这下你爽了
相关文章
当前位置:首页 >> >>

Contents List of Figures List of Tables Index


The KPML documentation

Chapters
Acknowledgements Differences to the hardcopy version Contents List of Figures List of Tables Index Introduction Computational SystemicFunctional Linguistics Installation and Startup Notational conventions in this document The KPML root interface windows The KPML Inspector Window The KPML Development Window The `old-style' KPML interface Resource Verification: Example Sets and Test Suites Maintenance: Resource Patching Resource Organization and Definition Formats Using KPML without the window interface Faster Generation Establishing and using a generation server References Information display modes and corresponding internal flags Data Access Functions used by Inquiry Operator Implementations

next

up

previous

contents

index

Next: Contents

KPML Development Environment Multilingual linguistic resource development and sentence generation
Release 1.0 (September 1996)
Current KPML patch level: 1.0.43 (May 30, 1997).
John Bateman e-mail: j.a.bateman@stir.ac.uk KPML versions up to 1.0 were developed at the: Institut für integrierte Publikations- und Informationssysteme (IPSI) Project KOMET German Centre for Information Technology (GMD) Dolivostr. 15, Darmstadt, Germany. Further development (1.1 and PC-versions) is continuing at the: Department of English Studies University of Stirling Stirling, FK9 4LA, Scotland

The KPML (Komet-Penman Multilingual) development environment is a system for developing and maintaining large-scale sets of multilingual systemicfunctional linguistic descriptions (as originally set out in Bateman et al. (),

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (1 von 11) [11.12.2004 14:15:54]

The KPML documentation

Knowledge representation interface functions About this document ...

Bateman et al. () and Matthiessen et al. ()), and for using such resources for text generation. More generally, the intended purposes of KPML are:
q

q

q

q

q

q q

to offer generation projects large-scale, general linguistic resources which: r are well tested and verified in their coverage, r possess standardized input and output specifications, r and are appropriate for practical generation; to offer generation projects a basic engine for using such resources for generation; to encourage the development of similarly structured resources for languages where they do not already exist, to provide optimal user-support for undertaking such development and refining general resources to specific needs; to minimise the overhead (and cost) of providing texts in multiple languages; to encourage contrastive functional linguistic work; to raise awareness and acceptance of text generation as a useful endeavor.

This document provides complete instructions for using the system for developing and maintaining linguistic resources for natural language generation.

The sources of the current public release of the system can be found in the KPML directory on the IPSI anonymous ftp server. Use is free for academic and research purposes. Users are asked to make available any developed resources for the benefit of others. A linguistic resource development group is currently being formed.

NOTE: this documentation is also available as a hardcopy manual. Minor differences may develop between the two versions; these differences will be added to a special section. In addition, figures and screendumps are generally replaced in this version by their color versions. This has not yet been carried out for all screendumps, but is happening.

q q q q q q

Acknowledgements Differences to the hardcopy version Contents List of Figures List of Tables Index

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (2 von 11) [11.12.2004 14:15:54]

The KPML documentation
q

q

q

q q

Introduction r The purpose of the system r The functionality of the system r Overview of the interface organization r Overview of the documentation r Availability of the system r Known bugs/problems r Troubleshooting Computational Systemic-Functional Linguistics r The linguistic system s Depth and Breadth s Stratal organization s Metafunctions s Functional Regions s Intra-stratal organization: choice and delicacy; structural realization s Inter-stratal organization: interfaces r A generic computational systemic functional system r A specific instantiation: the Penman-style architecture s The generation process: overview s Network traversal s Accessing semantic information s Stopping traversal: bottoming out r Pointers to further information Installation and Startup r Installing the KPML system r Installing the Emacs/Mule-interface r Installing the released linguistic resources r KPML system version maintenance: PATCHES r Making an executable image of the system r KPML resource version maintenance: RESOURCE PATCHES Notational conventions in this document The KPML root interface windows r Introduction r The `new-style' root window: starting up r The root commands: overview r General System Behaviour s Environment Directories s Flags r General Multilingual Operations and Modes r Focusing Operations s Linguistic object focusing s Language focusing

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (3 von 11) [11.12.2004 14:15:54]

The KPML documentation

q

Region focusing r Loading existent linguistic resources s Simple resource set loading s General commands for loading linguistic resources s Loading particular kinds of linguistic objects s Loading modes: overwriting and merging s Loading and the multilingual modes r Resource clearing r Saving and Creating linguistic resources s Simple resource set saving s General commands for saving linguistic resources s Monolingual saving s Contrastive saving s Multilingual saving s Inheriting language definitions s Automatic lexical item acquisition and saving s Creating unconditionalized linguistic resources s Changing the Lisp package of inquiry implementations r Interface suspension, exiting, etc. s Quiting the interface s Suspending the interface s (Re-)Activating the interface s Clearing the interface windows The KPML Inspector Window r Overview of Commands r Graphing systemic networks s Basic graphing options and commands s Quit Resource Grapher s Printgraph s Show examples with collected features s Clear Collected Features s Display Modes s Mail Intention to Work s Producing graphs for inclusion as figures in documents s Mouse activated resource graph options s Showing a full system definition s Showing the realization statements of a feature s Showing the chooser associated with a system s Collecting/Discollecting features s Pruning the displayed graph s Redisplaying a graph s Spawning further graphs
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (4 von 11) [11.12.2004 14:15:54]

The KPML documentation

r

r

r

Graphing regions s Contrastive and multilingual graphing s Monolingual graphing s Contrastive graphing s Multilingual graphing Inspecting individual object definitions s Introduction s Display commands s Print System s Print Chooser s Print Inquiry s Print Inquiry Implementation s Print Lexical Item s Print Concept s Print Relation s Definition displaying and the multilingual modes s Monolingual definition printing s Contrastive definition printing s Multilingual definition printing Object selection according to specified criteria s `Who has' selections s Who has as input s Who has as output s `Who can' selections s Who can lexify s Who can inflectify s Who can classify s Who can insert s Who can order s Who can partition s Who can preselect s Who can ask s Who can identify s Who can pose identifying inquiry s Examples Using Features Direct inspection and information chains s Introduction s Inspection operations on grammatical systems s Printing system definition s Print associated chooser s Graph Grammar starting from system s Inspection operations on grammatical features s Displaying usage of grammatical features
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (5 von 11) [11.12.2004 14:15:55]

The KPML documentation

q

Who has as input s Who has as output s Show path to s Show chooser of feature s Graph from feature s Collect feature s Uncollect feature s Clear collected features s Inspection operations on choosers s Print chooser s Show inquiries of chooser s Systems of chooser s Inspection operations on inquiries s Print inquiry s Print implementation s Who can ask s Who can pose identifying inquiry s Inspection operations on lexical items s Inspection operations on SPL terms s Inspection operations on examples r Overview of information inspection chains The KPML Development Window r Introduction r Window Layout r Overview of commands r Generation: basics s Introduction to generation with KPML s Starting generation s Generation and the multilingual modes s Monolingual generation s Contrastive generation s Semantic defaults and macros s Run-time cautions s Run-time warnings s Running modes s Boundary conditions r Tracing and debugging during generation s Introduction to generation debugging under KPML s Generation tracing modes s Show Constituent Starts s Show System And Inquiry Activity s Show Why System Is Firing
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (6 von 11) [11.12.2004 14:15:55]

The KPML documentation

r

r

r

r

Show Disabled Candidate Systems s Show System Entry Dependencies s Show Preselections s Show Immediate Realizations s Show Lexical Selection s Show Lexical Features s Show Ordering Constraints s Show Ordering Events s Show Ordering Results s Show Associations s Show Inquiry Answer Source s Show entailed inquiry response s Generation process control options s Realize Selectively s Realize until constituent number s Single Step s Enter Debugger on Warnings s Generation result focusing modes s Cumulate System and Inquiry Activity s Update Example Record Fields s Viewing focused results s The cumulative history window commands s Example of use Activating result focusing and tracing for particular linguistic objects s Activation of tracing s Individual system tracing s Individual chooser tracing s Individual inquiry tracing s Clearing tracing selections Graphical representation of systemic network traversal s Traversal and resource graphs s Dynamic traversal tracing Additional generation process control options s Disabling and enabling systems s Pausing on inquiries s Pausing and restarting generation Inspecting the results of generation: Graph Structure s Introduction to structure graphs s Structure Grapher Options s Operations available on structure constituents s Selection expression s Preselections
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (7 von 11) [11.12.2004 14:15:55]

The KPML documentation

q

q

q

Orderings s Lexical constraints s Associations s All structural constraints r Inspecting the results of generation: Operations on the produced strings or textual structure displays r Switching Languages r Summary of generation process information chains r How to debug resources: a sketch of a method The `old-style' KPML interface r Description of the interface `sub-windows' r Basic Old-Style Interface Operations s Clear s Flags s Pause s Quit s Resume s Reset s Show Linguistic Object s Generation Display Modes s Resource Maintenance s Multilingual Operations s Graph Grammar s Graph Sentence Structure s Ready SPL Defaults s Generate Again r Further type-in commands s Abort s Environment Directories s Show Path To s Evaluate Lisp Expression r Various mouse-click triggered commands Static Integrity Checks: Resource maintenance r Background concepts s Static tests during resource loading s Static tests on whole resource set Resource Verification: Example Sets and Test Suites r Example sets and test suites r The example operations s Load Examples s Write Examples s Clear Examples
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (8 von 11) [11.12.2004 14:15:55]

The KPML documentation

q

q

Generate from example SPL s Graph example structure s Display generated string s Show examples with features s Copy examples with new names s Delete some examples s Example runner s Starting the example runner s Levels of detail while example running s Low detail example running s Medium detail example running s High detail example running s Features used in examples survey r Operations on example strings and textually displayed structures s Operations on displayed strings s Show corresponding fundle s Graph corresponding constituent and below s Inspect selection expression s Inspect corresponding semantic term s Partial re-generation s Operations on displayed structures s Graph this constituent and below s Show selection expression s Show corresponding semantic term s Generate again up to but not including this constituent r Full summary of linguistic resource information chains Maintenance: Resource Patching r Introduction r Patching and loading linguistic resources r Patching and saving linguistic resources r Some further consequences of using the patching facility r Modifying linguistic resources r Example record versioning r Acquiring lexical items Resource Organization and Definition Formats r Directory structure and contents r Resource definition formats s Resource definition files s General language property declarations s Morphology style declarations s Standard default environments s Language-font associations
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (9 von 11) [11.12.2004 14:15:55]

The KPML documentation

q

q

Disabling systems s Language variety range declarations s Systems s Realization Statements s Introduction s Basic realization constraints s User-defined realization operators s Morphological realization constraints s Choosers s Inquiries s Lexicons s Examples s Punctuation s Non-systemic system dependencies s Default orderings s Domain concepts and links with the lexicon s SPL macros and defaults r Language variety conditionalization r Requirements for resource definitions s Special inquiries s Special semantic concepts and relations Accessing external information sources r Semantic information from inquiry implementations r External information from the lexicon r Morphological information from external components Using KPML without the window interface r Blackbox operation as a tactical generator r Bookkeeping functions s Switching languages s Establishing network connectivity s Inquiry default initialization s General initialization r Multilingual behaviour flags r Development tools s Linguistic Resource Loading Operations s Generating the example set s Modifying the resources s Saving the resources r Using the mouseable structures for mousing and mark-up s The structure produced s Conditionalization of mouse sensitivity s Specifying additional links in the SPL: annotations
s

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (10 von 11) [11.12.2004 14:15:55]

The KPML documentation

q

q

q q

q q q

Window startup functions Faster Generation r Strictly Monolingual Generation r Knowledge base package reduction r Compilation of inquiry implementations Establishing and using a generation server r Creating a KPML generation server r Creating a KPML client from Lisp r An example of a KPML Lisp client: a WWW-KPML server References Information display modes and corresponding internal flags r More detailed tracing and display modes r Loading and storing modes r Miscellaneous global variables Data Access Functions used by Inquiry Operator Implementations Knowledge representation interface functions About this document ...
r

next

up

previous

contents

index

Next: Contents John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

file:///E:/Web/kpml-darmstadt/The%20KPML%20documentation.htm (11 von 11) [11.12.2004 14:15:55]

Differences to the hardcopy version

next

up

previous

contents

index

Next: Contents

Differences to the hardcopy version
The hardcopy documentation for KPML 1.1 is now available in the documentation ftp directory for KPML 1.0. The functionalities described are available from the patches from 31 January 97 (KPML 1.0.33). The newer documentation is therefore provided there. The online version has not yet been brought up to date with the newer documentation, but can still serve as the first place to look. The new documentation is available as compressed (gzip) postscript from the ftp directory. The currently released version of KPML is still 1.0. To update see the currently available patches. These are detailed on the KPML patch page. John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/diffs.html [11.12.2004 14:16:05]

Notational conventions in this document

next

up

previous

contents

index

Next: The KPML root interface Up: No Title Previous: KPML resource version maintenance:

Notational conventions in this document
In the description of operations available under KPML, we will use the following notation for referring to commands and KPML operations throughout this document. Basic KPML commands are shown as <Load linguistic resources> ; these are generally selected by single mouse-clicks from the appropriate menus. Arguments to such commands are shown in the following font: RANK. These arguments may either be presented as menu options or by typing when prompted in the Command Interaction window. Subcommands reached by further menus of options are shown separated by colons. Several windows offer command menus. Where necessary, the originating window for a command will be given preceding the command. For example, the command to show all grammatical systems using a realization statement of preselection concerning the grammatical function `Thing', which is available in the Inspector window, will be indicated thus:
INSPECTOR:

<Who can ...: ...preselect thing>

This means that the command was given by clicking first on the `Who can...' menu option in the main command menu of the Inspector window (cf. Figure 6.1), then on `...preselect' in the secondary option menu that this brought up, and finally by typing `thing' in at the Command Interaction pane of the Inspector window as prompted. The possible windows from which commands can be issued explicitly are: ROOT, INSPECTOR, DEVELOPMENT, GRAPH, and HISTORY. There are four subtypes of graphing windows: STRUCTURE-GRAPH, RESOURCE-GRAPH, CHOOSER-GRAPH, and DYNAMIC-TRAVERSAL; and two types of history windows: GENERATION-HISTORY and CUMULATIVE-HISTORY. The subtypes will often only be distinguished if the context does not make the intended type of window clear. gif We will also occasionally use `relative' commands, i.e., commands that assume that the user is already in the context of some submenu. These will be specified with a root command `...'; thus the following command description might be used to describe the same command as above, but assuming that we are already in a discussion about the possible options leading on from the <Who can ...> command. <...: ... preselect>
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node36.html (1 von 2) [11.12.2004 14:16:25]

Notational conventions in this document

Finally, there are also often alternative forms of commands that can be given directly by typing within a Command Interaction pane. These will be indicated below by preceding the command name with a colon. Thus, an alternative to the above sequence of mouse clicks is:
INSPECTOR:

<:Who can preselect thing>

This means that the command `Who can preselect' was typed directly. Command completion (up to the next word in the command) is provided during entry by typing a space. Generally, all typed input is terminated by typing a carriage return. Partially typed in or executed commands can be aborted by typing a control-Z. When descriptions of Lisp functions, macros, etc. are given, the notation of Steele Jr. () will be adopted for their usage patterns.

next

up

previous

contents

index

Next: The KPML root interface Up: No Title Previous: KPML resource version maintenance: John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node36.html (2 von 2) [11.12.2004 14:16:25]

Acknowledgements

next

up

previous

contents

index

Next: Contents

Acknowledgements
Many people have contributed during the beta releases (0.1-0.9) leading to the current state of KPML, both in terms of actual code additions/corrections and in terms of critical feedback: particular thanks go to Markus Fischer (ITRI, Brighton) for the original port to CLIM-2, to Cécile Paris and Keith Vander Linden (ITRI, Brighton) for various bug fixes, to Richard Whitney (ISI, Los Angeles) for the code for the Loom 2.1 conversion, to John Wilkinson (Univerisity of Waterloo, Canada) for several speed-ups, to Tony Hartley (ITRI, Brighton), Cécile Paris, Brigitte Grote (FAW, Ulm), Elke Teich (IPSI, Darmstadt), Liesbeth Degand (Université Catholique of Louvaine-la-neuve), Bernhard Hauser (Technische Hochschule, Darmstadt) for providing much feedback throughout the early releases, and to Melina Alexa (IPSI, Darmstadt) and Fabio Rinaldi (University of Udine and IRST, Trento) for test driving the current interface and the documentation. Fabio Rinaldi also receives a special additional vote of thanks for preparing the WWW-versions of this documention! Section 2.1 is adapted from Bateman et al. (). Appendix B, concerning the interface between inquiry implementations and knowledge base, is taken from Bob Kasper's contributions to the Penman documentation. The `old-style' KPML interface (Chapter 8) is an outgrowth of a Penman window interface written by Richard Whitney and Kevin Knight (ISI), which was in turn based on a text planner interface by Vibhu Mittal and Cécile Paris (ISI). The simpler, non-graphical generation debugging tools and grammar tracing facilities build on those of the Penman system--particularly those parts concerned with the grammar. Hence, corresponding parts of this guide are updates of the Nigel Manual (Penman Project, 1989, ISI), originally prepared by Lynn Poulton, Christian Matthiessen and John Bateman. The original beta versions of the KPML interface and resource development environment (0.1-0.5) and its documentation were prepared in the context of a DAAD/British Council cooperation project (DAAD/ARC-313) between GMD/IPSI and ITRI (University of Brighton). The development of the Penman system on which the KPML system builds was supported by the U.S. National Science Foundation Grant IST-8408726, and U.S. Federal Contract numbers MDA903-81-C-0335, MDA90387-C-0641, F49620-84-C-0100, and F49620-87-C-0005. The multilingual extensions to the system have been supported in part by the German Ministry for Research and Technology (BMFT: Project `INTEGRA') and in part by the Australian Research Council. The development of the stratification available in the experimental KPML-E versions of the system for supporting text type (genre) networks and register has been supported by U.S. National Science Foundation Grant IRI-9003087, the European Union Basic Research Action EP-6665 (`Dandelion'), and the German BMFT Project `INTEGRA'.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/ack.html (1 von 2) [11.12.2004 14:16:43]

Acknowledgements

next

up

previous

contents

index

Next: Contents John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/ack.html (2 von 2) [11.12.2004 14:16:43]

Contents

next

up

previous

index

Next: List of Figures Up: No Title Previous: No Title

Contents
q q q q

q

q

q q

List of Figures List of Tables Index Introduction r The purpose of the system r The functionality of the system r Overview of the interface organization r Overview of the documentation r Availability of the system r Known bugs/problems r Troubleshooting Computational Systemic-Functional Linguistics r The linguistic system s Depth and Breadth s Stratal organization s Metafunctions s Functional Regions s Intra-stratal organization: choice and delicacy; structural realization s Inter-stratal organization: interfaces r A generic computational systemic functional system r A specific instantiation: the Penman-style architecture s The generation process: overview s Network traversal s Accessing semantic information s Stopping traversal: bottoming out r Pointers to further information Installation and Startup r Installing the KPML system r Installing the Emacs/Mule-interface r Installing the released linguistic resources r KPML system version maintenance: PATCHES r Making an executable image of the system r KPML resource version maintenance: RESOURCE PATCHES Notational conventions in this document The KPML root interface windows

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (1 von 10) [11.12.2004 14:17:50]

Contents

q

Introduction r The `new-style' root window: starting up r The root commands: overview r General System Behaviour s Environment Directories s Flags r General Multilingual Operations and Modes r Focusing Operations s Linguistic object focusing s Language focusing s Region focusing r Loading existent linguistic resources s Simple resource set loading s General commands for loading linguistic resources s Loading particular kinds of linguistic objects s Loading modes: overwriting and merging s Overwriting mode s Merging mode s Loading and the multilingual modes s Monolingual loading s Contrastive loading s Multilingual loading r Resource clearing r Saving and Creating linguistic resources s Simple resource set saving s General commands for saving linguistic resources s Monolingual saving s Contrastive saving s Multilingual saving s Inheriting language definitions s Automatic lexical item acquisition and saving s Creating unconditionalized linguistic resources s Changing the Lisp package of inquiry implementations r Interface suspension, exiting, etc. s Quiting the interface s Suspending the interface s (Re-)Activating the interface s Clearing the interface windows The KPML Inspector Window r Overview of Commands r Graphing systemic networks
r

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (2 von 10) [11.12.2004 14:17:50]

Contents

r

r

Basic graphing options and commands s Quit Resource Grapher s Printgraph s Show examples with collected features s Clear Collected Features s Display Modes s Content-oriented resource graph options s Layout and hardcopy oriented resource graph options s Continuation options s Mail Intention to Work s Producing graphs for inclusion as figures in documents s Mouse activated resource graph options s Showing a full system definition s Showing the realization statements of a feature s Showing the chooser associated with a system s Collecting/Discollecting features s Pruning the displayed graph s Redisplaying a graph s Spawning further graphs s Graphing regions s Contrastive and multilingual graphing s Monolingual graphing s Contrastive graphing s Multilingual graphing Inspecting individual object definitions s Introduction s Display commands s Print System s Print Chooser s Print Inquiry s Print Inquiry Implementation s Print Lexical Item s Print Concept s Print Relation s Definition displaying and the multilingual modes s Monolingual definition printing s Contrastive definition printing s Multilingual definition printing Object selection according to specified criteria s `Who has' selections s Who has as input
s

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (3 von 10) [11.12.2004 14:17:50]

Contents

r

Who has as output s `Who can' selections s Who can lexify s Who can inflectify s Who can classify s Who can insert s Who can order s Who can partition s Who can preselect s Who can ask s Who can identify s Who can pose identifying inquiry s Examples Using Features Direct inspection and information chains s Introduction s Inspection operations on grammatical systems s Printing system definition s Print associated chooser s Graph Grammar starting from system s Inspection operations on grammatical features s Displaying usage of grammatical features s Who has as input s Who has as output s Show path to s Show chooser of feature s Graph from feature s Collect feature s Uncollect feature s Clear collected features s Inspection operations on choosers s Print chooser s Show inquiries of chooser s Systems of chooser s Inspection operations on inquiries s Print inquiry s Print implementation s Who can ask s Who can pose identifying inquiry s Inspection operations on lexical items s Inspection operations on SPL terms s Inspection operations on examples
s

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (4 von 10) [11.12.2004 14:17:50]

Contents

q

Overview of information inspection chains The KPML Development Window r Introduction r Window Layout r Overview of commands r Generation: basics s Introduction to generation with KPML s Starting generation s Generation and the multilingual modes s Monolingual generation s Contrastive generation s Semantic defaults and macros s Run-time cautions s Run-time warnings s Running modes s Boundary conditions r Tracing and debugging during generation s Introduction to generation debugging under KPML s Generation tracing modes s Show Constituent Starts s Show System And Inquiry Activity s Show Why System Is Firing s Show Disabled Candidate Systems s Show System Entry Dependencies s Show Preselections s Show Immediate Realizations s Show Lexical Selection s Show Lexical Features s Show Ordering Constraints s Show Ordering Events s Show Ordering Results s Show Associations s Show Inquiry Answer Source s Show entailed inquiry response s Generation process control options s Realize Selectively s Realize until constituent number s Single Step s Enter Debugger on Warnings s Generation result focusing modes s Cumulate System and Inquiry Activity
r

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (5 von 10) [11.12.2004 14:17:50]

Contents

q

Update Example Record Fields s Viewing focused results s The cumulative history window commands s Redisplay s Clear history s Display options s Quit s Example of use r Activating result focusing and tracing for particular linguistic objects s Activation of tracing s Individual system tracing s Individual chooser tracing s Individual inquiry tracing s Clearing tracing selections r Graphical representation of systemic network traversal s Traversal and resource graphs s Dynamic traversal tracing r Additional generation process control options s Disabling and enabling systems s Pausing on inquiries s Pausing and restarting generation r Inspecting the results of generation: Graph Structure s Introduction to structure graphs s Structure Grapher Options s Operations available on structure constituents s Selection expression s Preselections s Orderings s Lexical constraints s Associations s All structural constraints r Inspecting the results of generation: Operations on the produced strings or textual structure displays r Switching Languages r Summary of generation process information chains r How to debug resources: a sketch of a method The `old-style' KPML interface r Description of the interface `sub-windows' r Basic Old-Style Interface Operations s Clear s Flags
s

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (6 von 10) [11.12.2004 14:17:50]

Contents

q

q

Pause s Quit s Resume s Reset s Show Linguistic Object s Generation Display Modes s Resource Maintenance s Multilingual Operations s Graph Grammar s Graph Sentence Structure s Ready SPL Defaults s Generate Again r Further type-in commands s Abort s Environment Directories s Show Path To s Evaluate Lisp Expression r Various mouse-click triggered commands Static Integrity Checks: Resource maintenance r Background concepts s Static tests during resource loading s Static tests on whole resource set Resource Verification: Example Sets and Test Suites r Example sets and test suites r The example operations s Load Examples s Write Examples s Clear Examples s Generate from example SPL s Graph example structure s Display generated string s Show examples with features s Copy examples with new names s Delete some examples s Example runner s Starting the example runner s Levels of detail while example running s Low detail example running s Medium detail example running s High detail example running s Features used in examples survey
s

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (7 von 10) [11.12.2004 14:17:50]

Contents

q

q

Operations on example strings and textually displayed structures s Operations on displayed strings s Show corresponding fundle s Graph corresponding constituent and below s Inspect selection expression s Inspect corresponding semantic term s Partial re-generation s Operations on displayed structures s Graph this constituent and below s Show selection expression s Show corresponding semantic term s Generate again up to but not including this constituent r Full summary of linguistic resource information chains Maintenance: Resource Patching r Introduction r Patching and loading linguistic resources r Patching and saving linguistic resources r Some further consequences of using the patching facility r Modifying linguistic resources r Example record versioning r Acquiring lexical items Resource Organization and Definition Formats r Directory structure and contents r Resource definition formats s Resource definition files s General language property declarations s Morphology style declarations s Standard default environments s Language-font associations s Disabling systems s Language variety range declarations s Systems s Realization Statements s Introduction s Basic realization constraints s User-defined realization operators s Morphological realization constraints s Choosers s Inquiries s Lexicons s Examples
r

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (8 von 10) [11.12.2004 14:17:50]

Contents

q

q

q

q

q q

Punctuation s Non-systemic system dependencies s Default orderings s Domain concepts and links with the lexicon s SPL macros and defaults r Language variety conditionalization r Requirements for resource definitions s Special inquiries s Special semantic concepts and relations Accessing external information sources r Semantic information from inquiry implementations r External information from the lexicon r Morphological information from external components Using KPML without the window interface r Blackbox operation as a tactical generator r Bookkeeping functions s Switching languages s Establishing network connectivity s Inquiry default initialization s General initialization r Multilingual behaviour flags r Development tools s Linguistic Resource Loading Operations s Generating the example set s Modifying the resources s Saving the resources r Using the mouseable structures for mousing and mark-up s The structure produced s Conditionalization of mouse sensitivity s Specifying additional links in the SPL: annotations r Window startup functions Faster Generation r Strictly Monolingual Generation r Knowledge base package reduction r Compilation of inquiry implementations Establishing and using a generation server r Creating a KPML generation server r Creating a KPML client from Lisp r An example of a KPML Lisp client: a WWW-KPML server References Information display modes and corresponding internal flags
s

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (9 von 10) [11.12.2004 14:17:50]

Contents

q q q

More detailed tracing and display modes r Loading and storing modes r Miscellaneous global variables Data Access Functions used by Inquiry Operator Implementations Knowledge representation interface functions About this document ...
r

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node1.html (10 von 10) [11.12.2004 14:17:50]

List of Figures

next

up

previous

contents

index

Next: List of Tables Up: No Title Previous: Contents

List of Figures
q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q

Internal KPML components Stratal organization of linguistic resources Constituency and the rank scale: English lexicogrammar Meta-stratal organization of the computational systemic functional account Penman-style architecture for lexicogrammar, semantics, and their interrelationships Further documentation map Example configuration dialogue The KPML root interface Example non-interface trace of generation The KPML inspector window Dependency region (extract) Extract from Dependency region with links to other regions shown Example of EPS figure showing systemic resources Pruned extract from the Dependency region Example of region graphing: the region TAG Example of multilingual (monochrome) graphing Multilingual graphs with and without preservation of grammatical system integrity Graphical display of a chooser Graphical chooser display included in this document as an EPS file Mouse sensitive objects within a textual display Summary of information chain possibilities: resources KPML development environment window Example structural result of generation Generation tracing and result focusing modes Generation History Window Example of using the cumulative generation history Example of graphed chooser showing generation path Example of generation path tracing Successive views of the features selected during network traversal Example of selective traversal tracing by collecting features Example of structure graphing Successive structural snapshots during generation indicating `last' generated node Summary of actualization process information chains Old-style top level interface window The relation of the generation process to example records

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node2.html (1 von 2) [11.12.2004 14:18:12]

List of Figures
q q q q q

q q q q q q q q

q q

Reducing constituent discrimination in example structure graphs Using collected features and example string displays Information chain possibilities: potential and realizations Selective patching according to language Contrastive generation in English and Greek using font associations for Greek pop-up generated result windows Generated structure graph using font associations for Greek Use of Mule for extended character displays Use of Mule for showing grammatical structures filled by Mule-compatible lexeme definitions Example definition of a morphological realization operator Example highly multilingual system Distinct views on a multilingual resource (contrastive) Distinct views on a multilingual resource (multilingual) Example of mouseable structure for the sentence: `The difference has lead to some schizophrenic behavior' Program configuration of the example WWW server Example WWW generation server in use

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node2.html (2 von 2) [11.12.2004 14:18:12]

List of Tables

next

up

previous

contents

index

Next: Index Up: No Title Previous: List of Figures

List of Tables
q q q

Comparison of representation schemes Realization statements and systemic notation Timings for differently configured KPML generation

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node3.html [11.12.2004 14:18:20]

Index

next

up

previous

contents

Next: Prerequisites Up: No Title Previous: List of Tables

Index Root for KPML
...A ...B ...C ...D ...E ...F ...G ...H ...I ...J ...K ...L ...M ...N ...O ...P ...Q ...R ...S ...T ...U ...V ...W ...X ...Y ...Z

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node4.html [11.12.2004 14:18:28]

Introduction

next

up

previous

contents

index

Next: The purpose of the Up: No Title Previous: Prerequisites

Introduction

q q q q q q q

The purpose of the system The functionality of the system Overview of the interface organization Overview of the documentation Availability of the system Known bugs/problems Troubleshooting

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node6.html [11.12.2004 14:18:37]

Computational Systemic-Functional Linguistics

next

up

previous

contents

index

Next: The linguistic system Up: No Title Previous: Troubleshooting

Computational Systemic-Functional Linguistics
This chapter offers a generic overview of computational systemic functional linguistics. It first presents how the linguistic system as a whole is conceived; this is the model for all aspects of the generic system and so is the foundation on which all decisions, including many `implementational' decisions, are made. Following this, it introduces an organization for thinking about the relationship between theory, description, and implementation. This should make it easier to see where one should look for details of particular aspects of the generic system.

q

q q

q

The linguistic system r Depth and Breadth s Stratal organization s Metafunctions s Functional Regions r Intra-stratal organization: choice and delicacy; structural realization r Inter-stratal organization: interfaces A generic computational systemic functional system A specific instantiation: the Penman-style architecture r The generation process: overview s Network traversal s Accessing semantic information s Stopping traversal: bottoming out Pointers to further information

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node14.html [11.12.2004 14:18:47]

The purpose of the system

next

up

previous

contents

index

Next: The functionality of the Up: Introduction Previous: Introduction

The purpose of the system
The KPML (Komet-Penman Multilingual) development environment is a system for developing and maintaining large-scale sets of multilingual systemic-functional linguistic descriptions (as originally set out in Bateman et al. (), Bateman et al. () and Matthiessen et al. ()), and for using such resources for text generation. More generally, the intended purposes of KPML are:
q

q q

q

q q q

to offer generation projects large-scale, general linguistic resources which: r are well tested and verified in their coverage, r possess standardized input and output specifications, r and are appropriate for practical generation; to offer generation projects a basic engine for using such resources for generation; to encourage the development of similarly structured resources for languages where they do not already exist, to provide optimal user-support for undertaking such development and refining general resources to specific needs; to minimise the overhead (and cost) of providing texts in multiple languages; to encourage contrastive functional linguistic work; to raise awareness and acceptance of text generation as a useful endeavor.

A fundamental tenet of the approach followed with KPML is that it is often mistaken to simplify the generation task by simplifying or restricting the linguistic resources employed, just because resource development or coverage is not a primary concern. KPML attempts to simplify the generation task by improving access and handleability of large-scale resources. This should prompt projects to work with large-scale resources, even when the main aims are elsewhere. The benefits of this are that fragmented solutions that do not scale up are more easily avoided, and that proof-of-concept demonstrations can draw on a more realistic strategic generation capability. KPML seeks to offer a stable development and generation environment that can be used for application-near text generation and demonstration.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node7.html [11.12.2004 14:18:54]

The functionality of the system

next

up

previous

contents

index

Next: Overview of the interface Up: Introduction Previous: The purpose of the

The functionality of the system
The KPML development environment provides a convenient platform for the construction and maintenance of multilingual linguistic resources. Interaction with the system is predominantly by combined mouse-click and graphical/textual information presentation. User commands are offered for loading definitions of (multilingual and monolingual) linguistic resources in systemic form, displaying these resources in a variety of ways useful for development and maintenance, performing static integrity checks on the systemic network defined by the resources loaded, and using the resources for generation. It is also possible to use the system as a blackbox tactical generator. The environment takes over and extends the functionality of the Penman text generation system (Mann , Mann & Matthiessen , Penman Project ), going beyond that system in terms of ease of use, development support, and multilingual design. gif The internal components of KPML and their functionality and communication channels are shown in the block diagram in Figure 1.1.

Figure: Internal KPML components Particular points of emphasis of the system include:

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node8.html (1 von 2) [11.12.2004 14:19:05]

The functionality of the system
q

q

q q q q q

q

an integrated view of examples and linguistic resources: resource maintenance is supported by extensive test suites which are interlinked with the resource definitions providing example-based on-line `documentation'; the possibility of combining graphical views of the linguistic resources with particular details of the generation process: generation debugging is graphically driven; a very high degree of modularity in the linguistic resource definitions; very extensive graphical and textual inspection of all aspects of the linguistic resources and their use; automatic resource management, including patch facilities for extending linguistic resources; provision of `fast generation' modes; provision of structured and annotated `string' generation to support hyperlinks and other application specific mouse-driven functionalities; multilinguality throughout.

The view of multilingual resources supported by KPML defines a very fine granularity of language-specific conditionalization. In Bateman et al. () and Bateman et al. () we claim that this organization generalizes substantially beyond all previous approaches to multilinguality. The development environment is also released with sizeable examples of multilingual linguistic resources; the most substantial of these being the English grammar Nigel, originally developed within the Penman project , and the KOMET grammars for German and Dutch. gif The basic units manipulated by the system are grammatical systems, choosers, inquiries, lexical units, punctuation rules, and examples (the latter including Penman-style SPL input specifications: Kasper ). All of these are potentially multilingual in that their contributing elements may be conditionalized to apply in specific languages. Using these object-types as the basic units that the system manages allows KPML to offer fully automatic merging and dynamic extraction of monolingual and contrastive views of those objects. That is, given that a system of a given name is defined as having various forms depending on the language in which it is used, KPML can freely merge such descriptions and subsequently take them apart. As argued in Bateman et al. () and elsewhere, this is a useful approach to managing multilinguality since it constructs multilingual descriptions around the paradigmatic unit rather than the structural: functional equivalences are therefore more likely to be preserved. Building on this functionality, monolingual language descriptions can be freely and automatically merged to produce multilingual specifications and, from these, further monolingual or contrastive resource sets can be automatically extracted. Dynamic contrastive browsing of the resource sets is also supported, as well as contrastive generation and special features for the rapid development of resources for languages not previously handled.

next

up

previous

contents

index

Next: Overview of the interface Up: Introduction Previous: The purpose of the John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node8.html (2 von 2) [11.12.2004 14:19:05]

References

next

up

previous

contents

index

Next: Information display modes and Up: No Title Previous: An example of a

References
Bateman, J. A. (1991), Language as constraint and language as resource: a convergence of metaphors in systemic-functional grammar, Technical report, Gesellschaft für Mathematik und Datenverarbeitung - Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. Written version of paper presented at the International Workshop on Constraintbased Formalisms for Natural Language Generation, November 27-30, 1990, Bad Teinach. Bateman, J. A., Emele, M. & Momma, S. ( 1992), The nondirectional representation of Systemic Functional Grammars and Semantics as Typed Feature Structures, in `Proceedings of COLING-92', Nantes, France. Bateman, J. A., Matthiessen, C. M., Nanri, K. & Zeng, L. (1991a), Multilingual text generation: an architecture based on functional typology, in `International Conference on Current Issues in Computational Linguistics', Penang, Malaysia. Also available as technical report of the department of Linguistics, University of Sydney. Bateman, J. A., Matthiessen, C. M., Nanri, K. & Zeng, L. (1991b), The re-use of linguistic resources across languages in multilingual generation components, in `Proceedings of the 1991 International Joint Conference on Artificial Intelligence, Sydney, Australia', Vol. 2, Morgan Kaufmann Publishers, pp. 966 - 971. Bateman, J. A., Matthiessen, C. M. & Zeng, L. (in preparation), A general architecture for multilingual resources for natural language processing, Technical report, GMD/IPSI, Darmstadt and University of Sydney. Bateman, J. A. & Teich, E. (1995), `Selective information presentation in an integrated publication system: an application of genre-driven text generation', Information Processing and Management: an international journal; Special Issue on Summarizing Text 31(5), 753768. Brachman, R. J. & Schmolze, J. ( 1985), `An overview of the KL-ONE knowledge representation system', Cognitive Science 9(2).

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (1 von 6) [11.12.2004 14:19:37]

References

Brew, C. (1991), `Systemic Classification and its Efficiency', Computational Linguistics 17(4), 375 - 408. Carpenter, B. (1992), The Logic of Typed Feature Structures, Cambridge University Press, Cambridge, England. Degand, L. (1993), Dutch grammar documentation, Technical report, GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. Devlin, K. (1990), Infons and types in an information-based logic, in R. Cooper, K. Mukai & J. Perry, eds, `Situation Theory and its applications', Vol. I, CSLI: Center for the Study of Language and Information, Stanford University, California, pp. 79 - 96. CSLI Lecture Notes Number 22. Emele, M., Heid, U., Momma, S. & Zajac, R. ( 1992), `Interactions between linguistic constraints: Procedural vs. declarative approaches', Machine Translation 6(1). (Special edition on the role of text generation in MT). Finkler, W. & Neumann, G. (1988), MORPHIX: A fast realization of a classification-based approach to morphology, in `Proceedings of the 4th. ?GAI: Wiener Workshop Wissensbasierte Sprachverarbeitung', number 176 in `Informatik Fachberichte', Springer Verlag, Berlin. G?tz, T. & Meurers, W. (1995), Compiling HPSG type constraints into definite clause programs, in `Proceedings of the 33rd. Annual Meeting of the Association for Computational Linguistics'. Halliday, M. A. (1961), `Categories of the theory of grammar', Word 17, 241-292. Reprinted in abbreviated form in Halliday (1976) edited by Gunther R. Kress, pp 52-72. Halliday, M. A. (1976), The English verbal group, in G. R. Kress, ed., `Halliday: system and function in language', Oxford University Press, London. Halliday, M. A. (1978), Language as social semiotic, Edward Arnold, London.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (2 von 6) [11.12.2004 14:19:37]

References

Halliday, M. A. (1985), An Introduction to Functional Grammar, Edward Arnold, London. Henschel, R. (1992), A proposal for merging the english and german upper models, Technical report, GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, West Germany, Darmstadt, Germany. Henschel, R. (1994), Declarative representation and processing of systemic grammars, in C. Martin-Vide, ed., `Current Issues in Mathematical Linguistics', Elsevier Science Publisher B.V., Amsterdam, pp. 363-371. Henschel, R. (1995), Traversing the Labyrinth of Feature Logics for a Declarative Implementation of Large Scale Systemic Grammars, in Suresh Manandhar, ed., `Proceedings of the CLNLP 95'. April 1995, South Queensferry. Kameyama, M., Ochitani, R. & Peters, S. ( 1991), Resolving translation mismatches with information flow, in `Annual Meeting of the Assocation of Computational Linguistics', Association of Computational Linguistics, Berkeley, California, pp. 193-200. Kasper, R. T. (1987), Systemic grammar and functional unification grammar, in J. D. Benson & W. S. Greaves, eds, `Systemic Perspectives on Discourse, Volume 1', Ablex, Norwood, New Jersey. Also available as USC/Information Sciences Institute, Reprint Report ISI/RS-87-179, 1987. Kasper, R. T. (1989), A flexible interface for linking applications to PENMAN's sentence generator, in `Proceedings of the DARPA Workshop on Speech and Natural Language'. Available from USC/Information Sciences Institute, Marina del Rey, CA. Kasper, R. T. & O'Donnell, M. ( 1990), Representing the Nigel grammar and semantics in LOOM, Technical report, USC/Information Sciences Institute, Marina del Rey, California. Kay, M. (1979), Functional grammar, in `Proceedings of the 5th meeting of the Berkeley Linguistics Society', Berkeley Linguistics Society, pp. 142 - 158. Mallery, J. C. (1994), A common lisp hypermedia server, in `Proceedings of the 1st. International Conference on the World-Wide Web', CERN, Geneva.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (3 von 6) [11.12.2004 14:19:37]

References

Mann, W. C. (1983a), `The anatomy of a systemic choice', Discourse Processes . Also available as USC/Information Sciences Institute, Research Report ISI/RR-82-104, 1982. Mann, W. C. (1983b), An overview of the PENMAN text generation system, in `Proceedings of the National Conference on Artificial Intelligence', AAAI, pp. 261-265. Also appears as USC/Information Sciences Institute, RR-83-114. Mann, W. C. (1985), `The anatomy of a systemic choice', Discourse Processes 8(1), 53-74. Also available as ISI/RR-82-104. Mann, W. C. & Matthiessen, C. M. ( 1985), Demonstration of the Nigel text generation computer program, in J. D. Benson & W. S. Greaves, eds, `Systemic Perspectives on Discourse, Volume 1', Ablex, Norwood, New Jersey, pp. 50-83. Matthiessen, C. M. (1984), Choosing tense in English, Technical Report ISI/RR-84-143, USC/Information Sciences Institute, Marina del Rey, CA. Matthiessen, C. M. (1987), Notes on the organization of the environment of a text generation grammar, in G. Kempen, ed., `Natural Language Generation: Recent Advances in Artificial Intelligence, Psychology, and Linguistics', Kluwer Academic Publishers, Boston/Dordrecht. Paper presented at the Third International Workshop on Natural Language Generation, August 1986, Nijmegen, The Netherlands. Matthiessen, C. M. (1995), Lexicogrammatical cartography: English systems, International Language Science Publishers, Tokyo, Taipei and Dallas. Matthiessen, C. M. & Bateman, J. A. ( 1991), Text generation and systemic-functional linguistics: experiences from English and Japanese, Frances Pinter Publishers and St. Martin's Press, London and New York. Matthiessen, C. M., Nanri, K. & Zeng, L. ( 1991), Multilingual resources in text generation: ideational focus, in `Proceedings of the 2nd Japan-Australia Joint Symposium on Natural Language Processing', Kyushu Institute of Technology, Kyushu, Japan. http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (4 von 6) [11.12.2004 14:19:37]

References

Mellish, C. S. (1988), `Implementing systemic classification by unification', Journal of Computational Linguistics 14(1), 40-51. Monachini, M. & Calzolari, N. ( 1994), Synopsis and comparison of morphosyntactic phenomena encoded in lexicons and corpora. a common proposal and applications to European languages, Technical report, Istituto di Linguistica Computazionale. Draft version of EU-LRE Project Eagles deliverable EAG-LSG/IR-T4.6/CSG-T3.2. Nerbonne, J. (1992), `Representing grammar, meaning and knowledge'. (Papers from KITFAST Workshop, Technical University Berlin, October 9th - 11th 1991). Penman Project (1989), PENMAN documentation: the Primer, the User Guide, the Reference Manual, and the Nigel manual, Technical report, USC/Information Sciences Institute, Marina del Rey, California. Pollard, C. & Sag, I. A. (1987), Information-based syntax and semantics: volume 1, Chicago University Press, Chicago. Center for the Study of Language and Information; Lecture Notes Number 13. R?sner, D. & Stede, M. (1994), Generating multilingual documents from a knowledge base: the TECHDOC project, in `Proceedings of the 15th. International Conference on Computational Linguistics (COLING 94)', Vol. I, Kyoto, Japan, pp. 339 - 346. Sefton, P. M. (1990), Making plans for Nigel (or defining interfaces between computational representations of linguistic structure and output systems: Adding intonation, punctuation and typography systems to the PENMAN system), Technical report, Linguistic Department, University of Sydney, Sydney, Australia. Batchelor's Honours Thesis. Steele Jr., G. L. (1990), Common Lisp: the language, (2nd. edition) edn, Digital Press. Teich, E. (1992), Komet: grammar documentation, Technical report, GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, West Germany. Tomita, M. & Carbonell, J. G. ( 1986), Another stride towards knowledge-based machine translation, in `Proceedings of COLING 86', pp. 633-638. 11th. International Conference on Computational Linguistics; Bonn, August.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (5 von 6) [11.12.2004 14:19:37]

References

Uszkoreit, H. (1991), Strategies for adding control information to declarative grammars, in `Proceedings of the 1991 Meeting of the Association for Computational Linguistics', Association for Computational Linguistics, Berkeley, California. Zajac, R. (1992a), `Inheritance and constraint-based grammar formalisms', Computational Linguistics 18(2), 159 - 182. (Special issue on inheritance: 1). Zajac, R. (1992b), Towards computer-aided linguistic engineering, in `Proceedings of COLING-92', Vol. II, pp. 828 - 834. Zeng, L. (1992), ML-Penman: implementation notes, Technical report, GMD/IPSI and University of Sydney. #1#

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node363.html (6 von 6) [11.12.2004 14:19:37]

Overview of the interface organization

next

up

previous

contents

index

Next: Overview of the documentation Up: Introduction Previous: The functionality of the

Overview of the interface organization
The user interface for KPML provides specialized windows for three distinct kinds of work that are typically involved in linguistic resource development and maintenance. These are:
q q q

Loading and saving sets of linguistic resources and determining overall system behavior. Developing, maintaining and debugging sets of resources by generation. Inspecting linguistic resources and objects.

Each of these activities requires different commands and are conceptually separate. The documentation reflects this separation and describes the functionalities offered to support each activity in distinct chapters.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node9.html [11.12.2004 14:19:45]

Overview of the documentation

next

up

previous

contents

index

Next: Availability of the system Up: Introduction Previous: Overview of the interface

Overview of the documentation
This user guide is primarily concerned with enabling a user to use KPML for resource development and multilingual text generation. Particular sections provide details on:
q q

q q q q q

installing and loading the release version of the KPML system (Chapter 3), loading released versions of linguistic resources into the system for inspection or generation (Section 5.7), inspecting the organization of loaded resources (Chapter 6), testing the integrity of resources and using them for generation (Chapters 9 and 10), creating new resources (Section 5.9.1). using the system in blackbox generation mode as a tactical generator (Section 14.1), using the system directly from other Lisp programmes (Section 14.4) and from other processes/machines (Chapter 16).

Finally, although this document assumes a general familiarity with systemic-functional linguistic representations, a brief abstract overview is given in Section 2.1, and a set of pointers to further information is given in Section 2.4.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node10.html [11.12.2004 14:19:55]

Availability of the system

next

up

previous

contents

index

Next: Known bugs/problems Up: Introduction Previous: Overview of the documentation

Availability of the system
KPML is freely available for research purposes; the latest public release can be found on the IPSI ftpserver, ftp.darmstadt.gmd.de, under the directory /pub/komet. The system is written in Common Lisp, using CLOS and CLIM. The resources also assume the presence of the knowledge representation language LOOM, available free from ISI, Los Angeles, for some of their semantic specifications. Use of other knowledge representation systems is straightforward (see Appendix C). Note: the full functionality of KPML is now dependent on Allegro Common Lisp 4.2 or newer with CLIM 2.0 or newer. The system will run with reduced functionality (approximately that of KPML 0.8) on other Common Lisp configurations; in particular with:
q q

Lucid Common Lisp 4.1 with and without CLIM 1 (SunOS 4) Lucid Common Lisp 4.2 with and without CLIM 2 (SunOS 5.3/Solaris 2.3)

Note that due to ongoing code changes that are bringing KPML into accordance with Common Lisp the Language, second edition (Steele Jr. ) and the ANSI standard, KPML is no longer available for any Lisps prior to the versions given above. Moreover, the version for Allegro Common Lisp/CLIM is the only version that is currently being fully supported. gif Standalone versions of the system can be made available for Solaris 2.3 and up.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node11.html [11.12.2004 14:20:03]

Known bugs/problems

next

up

previous

contents

index

Next: Troubleshooting Up: Introduction Previous: Availability of the system

Known bugs/problems
The following are known to be problematic or missing at the time of the present release of KPML.
q

q

The multilingual interaction of stacked SPL default environments from differing languages simultaneously is not yet supported. Since it appears that virtually no one knows that one can use stacked SPL default environments anyway, this is probably not overly problematic at this time. The argument completion facility can be fairly slow if large resource sets have been loaded and the machine being run on is not the fastest.

The following problems can be encountered with non-Allegro use of the system.
q

Some CLIM releases (e.g., Lucid CLIM) produce a header for hardcopy postscript files that may not be directly appropriate for printing. Lucid CLIM produces %! nonconforming %%Creator: CLIM 1.0 %%DocumentFonts: (atend) The first line of this should be simply edited to make it palatable for a printer, e.g.: %!PS-Adobe-2.0 %%Creator: CLIM 1.0 %%DocumentFonts: (atend)

q

q

There are some occasional incompatibilities left in the Lucid CLIM-2 version that can result in the window manager throwing control to the Lisp debugger: the abort option offered in the Lisp listener generally allows one to continue. The entire window interface can freeze under Lucid CLIM-1 (SunOS 4). This behaviour has not been traceable to any particular cause. Use of the system with this somewhat aged configuration is, however, certainly not recommended.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node12.html [11.12.2004 14:20:12]

Troubleshooting

next

up

previous

contents

index

Next: Computational Systemic-Functional Linguistics Up: Introduction Previous: Known bugs/problems

Troubleshooting
If serious errors occur during the loading of Loom, check that Loom has been previously compiled. KPML will not try to compile Loom itself, but loading a noncompiled Loom version will fail. If installation appears to have been completed successfully, but examples do not generate the intended strings, then some component of the lingusitic resources has not been loaded appropriately. There are some systematic failures that can be indicative of particular causes. Most typical is that all SPL inputs result only in nominal phrases being generated: this is usually due to the Upper Model not having been loaded during the configuration phase. If Emacs and Allegro Common Lisp are not being used, then error conditions can cause more than one process to use the originating Lisp listener simultaneously! The user must ensure that the required input makes it way to the appropriate process (e.g., by repeating it until accepted). If the interface is up and running but after selection of some command it stops reacting, then check: 1. that all of the KPML windows are `open' or `expanded'--if a window is `closed' or `iconized', menus dependent on that window will not be brought up until the window is open; 2. that no error condition (e.g., a network or X-server fault) has thrown control back to the calling Lisp process. It is possible that some unfortunately syntactically misformed resource definitions that escape detection on loading can bring the interface to a halt if a request is made to inspect them. Since inspection can only take place in the Inspector window (Chapter 6), it is generally only this window that is affected. Should this occur, there is no available option for continuing, and control-Z from the interface fails to abort, then the Inspector can be restarted by typing at the originating Lisp listener (cf. Section 14.6): (kpml-i::startup-resource-inspector-frame T)

next

up

previous

contents

index

Next: Computational Systemic-Functional Linguistics Up: Introduction Previous: Known bugs/problems

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node13.html (1 von 2) [11.12.2004 14:20:21]

Troubleshooting

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node13.html (2 von 2) [11.12.2004 14:20:21]

The linguistic system

next

up

previous

contents

index

Next: Depth and Breadth Up: Computational Systemic-Functional Linguistics Previous: Computational Systemic-Functional Linguistics

The linguistic system
This generic account of computational systemic-functional linguistic (SFL) systems begins with the structure and organization of the linguistic system. This is crucial for understanding every aspect of the computational system. We also use it below to more finely articulate what levels of description are available to us computationally.

q

q q

Depth and Breadth r Stratal organization r Metafunctions r Functional Regions Intra-stratal organization: choice and delicacy; structural realization Inter-stratal organization: interfaces

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node15.html [11.12.2004 14:20:34]

Depth and Breadth

next

up

previous

contents

index

Next: Stratal organization Up: The linguistic system Previous: The linguistic system

Depth and Breadth
SFL conceives of language as a resource for making and expressing meanings--a potential for making meaning, or `meaning potential' for short. This resource is interpreted (i) as a multi-functional system and (ii) as a multi-stratal system of systems; we describe what this entails for a linguistic account in the following two subsections. We then go on to illustrate how linguistic descriptions are represented in SFL and show how this is particularly suited for use as a resource for uncovering the kinds of information and processes that are necessary for controlling linguistic resources.

q q q

Stratal organization Metafunctions Functional Regions

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node16.html [11.12.2004 14:20:39]

Stratal organization

next

up

previous

contents

index

Next: Metafunctions Up: Depth and Breadth Previous: Depth and Breadth

Stratal organization
The context-embedded system of language as a whole is in SFL organized as a resource for making and exchanging meanings. It is organized in such a way that it can construe the symbolic `gap' between high-level communicative goals in the context of communication and expressions in speech or writing; it construes this `gap' through organization into a series of stratified subsystems -- from the most abstract stratum of semantics to the least abstract level of expression, the resources for expressing the grammar's wordings in writing (graphology) or speech (phonology). Each stratal subsystem is organized in such a way that it can relate to its immediate stratal environment: it is organized as inter-related strategic options available to the next higher stratum. Thus, any given stratum is contextualized by the immediately higher stratum -- the higher stratum provides the functional motivation for the lower one; and the lower one provides the resources to realize the higher stratum. This is crucial in the design of a multilingual system: languages may have a fair amount of functional commonality at one stratum but diverge with respect to the realization at the stratum next below. So far three levels of abstraction in the resources that make up language have received extensive computational treatments -- a higher level that supports processing global to a text, a lower level that supports more local text processing, and an intermediate level that serves as an interface between the former two. These three levels constitute three strata in a stratal theory of language in context such as systemic functional theory or stratificational theory:
q

q

q

the highest stratum -- the semantic environment: higher-level meanings that provide the semantic environment for any text, and the principal means of relating to context; the intermediate stratum -- the semantic interface: the semantic interface resources for relating these higher-level meanings to the grammar; the lowest stratum -- the lexicogrammar: the grammatical resources for wording the meanings, for expressing them lexically and structurally.

We therefore prefer a rather more finely differentiated stratification than that typical in computational linguistics and give full stratal status to the relations defined between semantics and grammar. This is both linguistically necessary and practically useful. Emele et al. () demonstrate that the sheer diversity of interactions between distinct kinds of linguistic information is guaranteed to defeat any staged approach to generation/understanding that successively maps between levels of representation. A highly differentiated scheme of stratification then simplifies inter-stratal mappings and provides maximal support for the necessarily simultaneous resolution of constraints drawn from multiple levels of representation. This becomes increasingly important the further one moves away from toy research prototypes.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node17.html (1 von 2) [11.12.2004 14:20:50]

Stratal organization

next

up

previous

contents

index

Next: Metafunctions Up: Depth and Breadth Previous: Depth and Breadth John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node17.html (2 von 2) [11.12.2004 14:20:50]

Metafunctions

next

up

previous

contents

index

Next: Functional Regions Up: Depth and Breadth Previous: Stratal organization

Metafunctions
All three of these strata are concerned with meaning. This is reflected in their functional organization in various ways. Most generally, this can be seen in the functional diversity of the resources associated with each stratum. SFL traditionally diversifies the functional spectrum into three highly generalized metafunctions, to which any use of language is necessarily simultaneously responsive. They constitute fundamental principles of linguistic organization and are thus embodied in the linguistic system. Each makes its own contribution. The three metafunctions, the ideational, the interpersonal, and the textual, have been described extensively in the SFL literature (e.g., Halliday , Halliday ) but, for present purposes, may be simply glossed as follows.
q

q

q

Ideational: the means we have of representing the world to ourselves; it largely corresponds to what has been termed `propositional content'. It is, as the name suggests, concerned with `ideation'. It provides the speaker with the resources for interpreting and representing `reality'. There are two ideational subtypes, the `experiential' metafunction and the `logical' one. The former is a mode of ideation that construes experience in terms of particular components and subcomponents. It is the mode of organization of, e.g., the TRANSITIVITY structure of the clause (configurations of transitivity functions, such as Actor (she) + Process (gave) + Recipient (to the poor). The latter is a highly generalized mode of ideation that operates in terms of very general relations such as modification. It is the mode of organization for creating complexes of various kinds, such as coordinate and appositional structures, which are chains of interdependent elements (rather than configurations of constituent components). Interpersonal: the range of meaning concerned with the expression of social relationships and speakers' attitudes and evaluations. It provides the speaker with the resources for creating and maintaining interpersonal relations with the listener, e.g., by assigning speech roles such as questioner and (intended) answerer and by intruding into the speech situation by giving or demanding comments on what is being said. These resources are represented in the grammar of the clause as MOOD, MODALITY, and other types of interpersonal assessments. For instance, independent clauses in English are organized into Mood (e.g., he will) + Residue (e.g., leave tomorrow). The Mood element consists of Subject and Finite verbal element and reflects MOOD selections; thus Subject preceding Finite realizes the selection of declarative (he will), whereas Finite before Subject realizes yes-no interrogative (will he). Textual: the resources responsible for making language appropriate to its particular context of use, including resources that support the connectivity and coherence of text. It provides the speaker with the resources for contextualizing the ideational and interpersonal information to be presented. We will see extensive illustrations of the particular resources available below.

These three metafunctional components within lexicogrammar and the semantic interface relate to three functionally distinct bases of support within the highest stratum. The semantic environmental manifestations of the metafunctions are the ideation base, the interaction base, and the text base. We use the term `ideation' base in preference to the traditional `knowledge base' since it makes the functional position, or `address' (i.e., the intersection of the semantic stratum with the ideational metafunction, which we shall write as `semanticsideational') of the base explicit. The interaction base (semanticsinterpersonal) is then concerned, among other things, with the social and epistemic relationship between speaker and listener; it subsumes the notion of `user model'. The text base (semanticstextual) is concerned with, among other things, rhetorical relations, newsworthiness, identifiability and thematic progression in text; it subsumes the notion of `discourse model'. In more detail, the semantic environment of the lexicogrammar is organized into: the ideation base, which is a theory of `reality' -- what one might call a semanticization of the world. gif This is a part of the context that supports `ideation' and hence the ideational component of the lexicogrammar, i.e., a particular interpretation of the world. The phenomena of the world are ranked and are organized into networks -- taxonomies of sequences, process configurations, and simple phenomena. They are interpreted as units with a functional type of structure. For instance, process configurations are configurations of a nuclear process, participants, and circumstances -processes of doing and happening, of sensing, of saying, and of being and having. The interaction base, which is a theory of (symbolic) interaction and role relationships. This is the part of the context that supports linguistic interaction or exchange and hence the interpersonal component of the grammar, i.e., the speaker's assignment of linguistic role-relationships, the speaker's evaluations, attitudes, and so on. In some respects, we can think of the interaction base as different interpersonal colourings superimposed on the ideation base.

q

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node18.html (1 von 2) [11.12.2004 14:21:04]

Metafunctions
q

The text base, which is a theory of information as text. This is the part of the context that supports the presentation of information from the ideation base and the interaction base as text in context.

The contents of the linguistic system are thus cross-classified along two dimensions: stratal `height' and metafunctional `breadth'; this is summarized in Figure 2.1.

Figure: Stratal organization of linguistic resources

next

up

previous

contents

index

Next: Functional Regions Up: Depth and Breadth Previous: Stratal organization John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node18.html (2 von 2) [11.12.2004 14:21:04]

Intra-stratal organization: choice and delicacy; structural realization

next

up

previous

contents

index

Next: Inter-stratal organization: interfaces Up: The linguistic system Previous: Functional Regions

Intra-stratal organization: choice and delicacy; structural realization

All stratal subsystems have the same general principles of organization. Since these principles always reoccur, at all the differing scales, or strata, in the system, we refer to them as fractal principles. The fundamental fractal principle is that of taxonomic choice. This has often been obscured by the fact that different `notations' are usually used for the ideation or knowledge base and for the lexicogrammar -- for example, frame-based inheritance networks such as those found in KL-ONE and the systemic networks of systemic grammar. We emphasize the similarity in the organization because any solution to the problem of integrating multiple languages in the resources that has been worked out for one stratal subsystem has implications for the others. That is, the issue of how to represent commonality and difference in choice is general across the whole system of language in context, including for example, the ideation base and the grammar. To bring out the commonalities, we will first characterize the common organization principle without committing to any particular notational representation for encoding the information in the ideation base or the grammar. Both the ideation base and the grammar are organized as a network of types that form a taxonomic hierarchy (known variously as a concept hierarchy, subsumption lattice or system network). These types are related by Boolean operators: a given type may be a subtype of a single type, a conjunction of other types or a disjunction of other types. For our purposes here, types are distinguished in terms of structural properties: each type may have structural consequences -- a configuration of roles (slots, attributes, functions). Each role may be restricted as to what type can serve that role (value restriction, type, preselection). The table in Table 2.1 summarizes the manifestation of the general organization just sketched in frame-based inheritance networks used for representing `knowledge' and in system networks used for representing lexical and grammatical information.

Table: Comparison of representation schemes We adopt the system network representation as our general representation medium and have extended the notation for multilingual representation--it now captures what is required of a multilingual representation generally. Our selection of multilingual system networks as the basic representational resource mirrors corresponding attempts to use a single formalism, such as typed feature structures (cf. Carpenter ) or `infons' (cf. Devlin ), for all types of linguistic information (as done in, for example, Pollard & Sag (), Zajac (), Kameyama et al. (), Nerbonne () and others). We draw a distinction, however, between the linguistic theoretical level of description (at which systemic networks appear) and the representation theoretical level (at which typed feature structures or infons appear). We present this in more detail below.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node20.html (1 von 3) [11.12.2004 14:21:28]

Intra-stratal organization: choice and delicacy; structural realization

The specification of taxonomically organized choices as a hierarchy of alternative types constitutes a potential. Any type may be instantiated as a token -- an actual concept or an actual grammatical unit such as a clause. In the ideation base of a generation system, tokens are stored as `instantial knowledge' (or assertional knowledge, contrasting with the type of knowledge sometimes called terminological; see, e.g., Brachman & Schmolze () for a standard description) -- particular facts about particular individuals at particular times, etc. In the grammar, tokens are not stored -- they are only created in the process of generation/understanding: particular paths through the taxonomic hierarchy and instantial wordings. That is, the system stores instantial meaning in the ideation base but not in the grammar. gif We can now describe the fractal dimensions of the linguistic theoretical level in more detail. The most important are axis, rank and delicacy. The dimension of axis separates the strategic, taxonomic organization within a stratum as choice -- as represented by system networks -- and the tactic realizations of choices -- as represented in realization statements. The former gives rise to paradigmatic descriptions; the latter to syntagmatic descriptions. Within the lexicogrammatical stratum, for example, axis separates the network of strategic options available for realizing meanings as wordings and the tactic realization of particular options as fragments of structure. Thus, in English, if a clause is `interrogative', there is a further (i.e., more delicate: see below) choice between `wh-interrogative' and `yes/no-interrogative'; these latter two systemic options are realized either by the presence of a Wh-element (indicated by the realization statement [+ Wh]), which is ordered before the Finite-element (the finite part of the verb, i.e., that carrying agreement and tense; realization statement: [Wh Finite]), or by ordering the Subject after the Finite-element [Finite Subject] respectively. Crucially, the realization statements are always given in the context of paradigmatic options such as `wh-interrogative' and `yes/no-interrogative', and the coherence of the paradigmatic organization is given preference over generalizations concerning phrase structure. The paradigmatic orientation is perhaps the central distinctive feature of the architecture overall. The second dimension of intra-stratal organization, delicacy, orders paradigmatic options with respect to one another. This refers to the dependency between systems in a system network; it corresponds to the subsumption partial ordering in a type lattice representation. The more general options provide the context in which more delicate ones are available. Finally, the third dimension, rank, refers to the typical constituency potential of a stratum. In English, clauses consist of groups/phrases, which consist of words, which consist of morphemes; thus, the rank scale of the English lexicogrammar is clause, group/phrase, word, and morpheme. Each higher-ranking unit constitutes the context in which units of the rank below serve (see Figure 2.2). Clause, being the highest-ranking unit, is the most transparent gateway to semantics (cf. Halliday ).

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node20.html (2 von 3) [11.12.2004 14:21:28]

Intra-stratal organization: choice and delicacy; structural realization

Figure: Constituency and the rank scale: English lexicogrammar

next

up

previous

contents

index

Next: Inter-stratal organization: interfaces Up: The linguistic system Previous: Functional Regions John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node20.html (3 von 3) [11.12.2004 14:21:28]

Functional Regions

next

up

previous

contents

index

Next: Intra-stratal organization: choice and Up: Depth and Breadth Previous: Metafunctions

Functional Regions

While the metafunctions provide a general division of linguistic resources, this is not sufficiently fine for usefully manipulating large scale linguistic resources. For this reason, within each metafunction, linguistic resources are further divided into functional regions. A functional region is a subset of the resources that are concerned with a single `semantic/functional' area. A lexicogrammar then typically divides into 30 or more functional regions, each of which is responsible for expressing some particular aspect of the functional distinctions made by the stratum above. Organizing a grammar by `rank' (see below) and `region' then provides an overall `map' of the linguistic system which can be used to focus in on areas of interest. The regions can be seen as a kind of meta-network imposed over the base-level network of linguistic resources. KPML strongly encourages orientation to regions as a basic means of finding one's way about in large-scale resources.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node19.html [11.12.2004 14:21:36]

Inter-stratal organization: interfaces

next

up

previous

contents

index

Next: A generic computational systemic Up: The linguistic system Previous: Intra-stratal organization: choice and

Inter-stratal organization: interfaces

The basic inter-stratal organization employed is still the framework known as chooser and inquiry semantics (Mann ). This can be briefly described as follows. The chooser and inquiry framework for systemic-functional grammar (SFG) arose out of the need to make a text generation system that was modular and re-usable across different contexts and across different computational systems, knowledge representation languages, text planning components, etc. It was necessary to be able to provide semantic control of the grammar component without insisting that a user, or other computational system, be aware of the grammatical distinctions maintained and organized within the grammar. The chooser and inquiry framework provides such a level of semantic control by associating a chooser with each grammatical system in the system network. A chooser is a semantic procedure which knows how to make a purposeful choice among the grammatical features of the system with which it is associated. It makes the choice by asking one or more questions, called inquiries, concerning parameters that, typically, refer to aspects of the meaning, concepts, etc. that need to be expressed. It is the responsibility of the inquiries to obtain the information relevant for the grammatical decision. As far as the grammar and choosers are concerned, therefore, the inquiries represent oracles which can be relied on to motivate grammatical alternations appropriately for the current communicative goals that need to be accomplished. This is a simpler task than directly requiring a selection of grammatical features, since the choosers and inquiries decompose a single selection among minimal grammatical distinctions into a number of selections among minimal semantic distinctions. While the grammatical alternations may not be directly relevant to a component external to the grammar, the semantic distinctions are: this level supplies a situation-independent semantic classification in terms of which a computational system can organize its information for expression in natural language. The meaning of inquiries can be defined in two ways: either an informal natural language description of the semantic discrimination can be given, or an actual process may be implemented which interrogates a knowledge base, text plan, etc. in order to establish the response appropriate for the particular communicative goal being achieved. In general, the inquiries associated with choosers of systems from the different metafunctions in the grammar need to look to different sources for their responses. Ideational inquiries typically examine the knowledge base or domain model of a computational system (i.e., the ideation base); interpersonal inquiries examine a user model, beliefs, attitudes and intentions (i.e., the interaction base); and textual inquiries examine the text plan and text history (i.e., the text base). Matthiessen () describes the relation between the metafunctions and different kinds of `support knowledge' that are required in some detail.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node21.html (1 von 2) [11.12.2004 14:21:43]

Inter-stratal organization: interfaces

One direction of ongoing development is to replace the association of choosers with individual systems by a more general semantic network of inquiries. The arguments for this are presented, with some examples, in Matthiessen & Bateman (). Currently released systems still use the individual chooser packages however.

next

up

previous

contents

index

Next: A generic computational systemic Up: The linguistic system Previous: Intra-stratal organization: choice and John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node21.html (2 von 2) [11.12.2004 14:21:43]

A generic computational systemic functional system

next

up

previous

contents

index

Next: A specific instantiation: the Up: Computational Systemic-Functional Linguistics Previous: Inter-stratal organization: interfaces

A generic computational systemic functional system
We now describe the computational instantiation of sets of linguistic resources of the kind described in the previous section. Just as the linguistic system was organized, the organization of a generic computational functional systemic system is also to be described at a number of levels of abstraction. These levels or, to use Christian Matthiessen's suggestive metaphor, meta-strata, are motivated by a consideration of semiotic systems as a whole but also relate interestingly to modern practises of software engineering. We separate out the following levels:
q

q

q

q

Theory: at this level, the theoretical perspective -- i.e., the particular questions to be asked, the ways of going about answering them, the view of what kind of phenomenon language is, etc. -- is specified. In the present case, we find at this level a statement of what systemic functional linguistics is. Linguistic representation: here, we find: r a representation dimension, where we describe the theoretically motivated representational devices available to us for approaching language. In the present case, the most important linguistic representational device is the systemic network. r a description dimension, where we find concrete linguistic descriptions of actual languages and linguistic phenomena, expressed using the representational resources defined. Note that this meta-stratum involves linguists primarily; there is no necessary connection drawn with computation and the representation adopted is specified only in terms of the theory. Computational representation: here, we find a re-expression of the previous representational information but in terms which are explicitly computational. The aim would be for all information that is expressed at the linguistic representational level to find some corresponding reflex at the computational representational level. This meta-stratum necessary involves computational linguists -- in fact, we would use the existence of this meta-stratum as a definition of what computational linguistics is. Crucially, as with the relation of theory to linguistic representation, there is assumed to be a natural realizational relationship between the meta-strata of linguistic and computational representation. Implementation: here, we pass a `line of arbitrariness' in realization and are concerned with how we make the computational representation run as best we can. There is no need at this level to respect modularities defined and used at the higher meta-strata if they do not contribute to desired run-time behavior.

It is crucial to draw the distinction between the linguistic representation meta-stratum and the computational representation meta-stratum since the two are responsive to quite different concerns. Demonstrations such as those of Mellish () or Carpenter (, pp27-32) that systemic networks are generally `equivalent' to type lattice specifications only hold for the representation theoretical level construal of systemic networks. Such interpretations are, however, underconstraining at the linguistic theoretical level and make no criteria available for distinguishing between systemic networks that represent aspects of language and `arbitrary' networks that appear very unlikely as language descriptions (such as, for example, Brew's () `systemic' network for 3-SAT). The dimensions of organization that find expression in systemic accounts in general, and in KPML in particular, are all to be construed at the linguistic theoretical level, i.e., at the linguistic representation meta-stratum; it remains for future work to define possible realizations of constructs beyond the basic type lattice organization at the representation theoretical level, although some first steps are presented in Kasper & O'Donnell () and Bateman et al. (). For more on the differences between a systemic network and, e.g., the subsumption lattices of HPSG at the linguistic theoretical level, see Bateman (); for further information about the two levels of theoretical representation considered abstractly, see below. The implementational basis of other levels could similarly be changed without affecting the linguistic representation specifications at all; this reflects a further important principle of modularity. Although the Penman system (see Penman Project () and Section 2.3) straddled the lower two meta-strata somewhat uncomfortably, future systemic functional systems will move steadily towards respecting this division and so it makes sense to interpret even current systems in its terms. In particular, current considerations for alternative implementations in terms of typed feature structures (cf., e.g., Bateman et al. , Henschel ) make this division concrete. At present, the grammar definition
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node22.html (1 von 3) [11.12.2004 14:21:53]

A generic computational systemic functional system

notation used in Penman-style architectures can be placed at the computational representation meta-stratum, while the Penman code which interprets these and compiles an internal data structure which is `traversed' as a network, building up internal representations of syntactic descriptions, is best placed at the implementation meta-stratum. We can expect that both the implementation details and the computational representation will change substantially over the next decade, whereas the linguistic representation will probably be extended rather than changed. It is perhaps useful to bear in mind that the meta-strata are to be considered as being related in a realization relationship, just as the strata of the linguistic system. Thus, each meta-stratum contains a complete representation of the linguistic system at the level of abstraction appropriate. A comparison with an idealized view of a generic systemic functional system should clarify the distinctions drawn here. Such a system would consist of:
q q q

q

theory: systemic-functional linguistics in general, linguistic representation: systemic networks used to describe some linguistic phenomena, computational representation: statements made in a typed feature structure formalism compiled automatically from the linguistic representation and capable of being executed according to the the abstract semantics of the formalism, implementation: efficient implementation of the formalism.

This scheme is shown graphically in Figure 2.3. A representation at the computational representation meta-stratum is intended to correspond to Uszkoreit's () `declarative specifications' or to Zajac's (, p830) `executable specifications'. They should also be supportive, therefore, of automatic compilation for specific tasks as done, for example, by the compilation of LFG-like grammars in KBMT (Tomita & Carbonell ) and in the recent flurry of reports on automatic `migration' of HPSG resources into various forms (e.g., G?tz & Meurers ). The main concern is then with the principles of organization of such resources.

Figure: Meta-stratal organization of the computational systemic functional account

next

up

previous

contents

index

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node22.html (2 von 3) [11.12.2004 14:21:53]

A generic computational systemic functional system

Next: A specific instantiation: the Up: Computational Systemic-Functional Linguistics Previous: Inter-stratal organization: interfaces John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node22.html (3 von 3) [11.12.2004 14:21:53]

A specific instantiation: the Penman-style architecture

next

up

previous

contents

index

Next: The generation process: overview Up: Computational Systemic-Functional Linguistics Previous: A generic computational systemic

A specific instantiation: the Penmanstyle architecture
Here we introduce very briefly the Penman-style generation architecture that is also used for the lexicogrammatical and semantic strata supported by KPML. The approach to generation is resource-driven, rather than instance-driven (or data-driven). The organization of the systemic network determines the order in which information is gathered and what information is sought. This is managed via the choosers and inquiries as described above. The architecture is shown in graphical form in Figure 2.4, with the flow of information indicated by broken gray arrows.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node23.html (1 von 3) [11.12.2004 14:22:08]

A specific instantiation: the Penman-style architecture

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node23.html (2 von 3) [11.12.2004 14:22:08]

A specific instantiation: the Penman-style architecture

Figure: Penman-style architecture for lexicogrammar, semantics, and their interrelationships

q

The generation process: overview r Network traversal r Accessing semantic information r Stopping traversal: bottoming out

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node23.html (3 von 3) [11.12.2004 14:22:08]

The generation process: overview

next

up

previous

contents

index

Next: Network traversal Up: A specific instantiation: the Previous: A specific instantiation: the

The generation process: overview

This section provides a very brief overview of the generation process depicted in Figure 2.4. For more details, see Mann & Matthiessen (), Matthiessen & Bateman (). Also described here are some particular details of the basic Penman and KPML style generation strategy.

q q q

Network traversal Accessing semantic information Stopping traversal: bottoming out

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node24.html [11.12.2004 14:22:17]

Network traversal

next

up

previous

contents

index

Next: Accessing semantic information Up: The generation process: overview Previous: The generation process: overview

Network traversal
The generation process in a Penman-style architecture such as KPML is as follows. Generation proceeds in cycles of traversal through the defined systemic network. Each grammatical unit that is generated is created by one cycle through the network. The result of traversing the network is a set of selected grammatical features (the `selection expression') and a corresponding grammatical structure. The grammatical structure is created by resolving all the collected grammatical constraints associated with features of the selection expression. Further cycles (for grammatical subconstituents) are created by constraining a grammatical constituent to require realization involving further features selected from the systemic network. More information about the kinds of grammatical constraints that may be employed is given in Section 12.2.5.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node25.html [11.12.2004 14:22:27]

Accessing semantic information

next

up

previous

contents

index

Next: Stopping traversal: bottoming out Up: The generation process: overview Previous: Network traversal

Accessing semantic information
The features that are chosen during traversal of a network are generally selected by virtue of the semantics to be expressed. This is mediated by the chooser and inquiry framework (developed in Mann ()). Choosers organize inquiries into `decision trees', and inquiries are resonsible for (a) inspecting the semantic specification that is being expressed in order to classify that specification along specific semantic dimensions and (b) providing access to particular portions of the semantic specification for triggering further realization. The connection between grammar and semantics is made via a function association table that relates grammatical functions (i.e., labels for grammatical constituents defined by the grammar) and semantic `hubs' (i.e., labels for portions of the semantics to be expressed). Inquiries typically take grammatical functions as arguments, thus providing access to the associated semantic information in a modular fashion. More information is provided in Section 12.2.7. The usual semantic organization adopted in the Penman-style architecture, and when using KPML, is an Upper Model. All of the KPML resources are defined so that generation is possible with respect to a single Upper Model. This provides the concrete instantiation of the ideation base introduced above. One of the most versions of an upper model is the Generalized Upper Model (version 2.0).

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node26.html [11.12.2004 14:22:34]

Stopping traversal: bottoming out

next

up

previous

contents

index

Next: Pointers to further information Up: The generation process: overview Previous: Accessing semantic information

Stopping traversal: bottoming out
Cycles of generation will continue for all sub-constituents of a grammatical unit until all subconstituents are filled by some specific linguistic substance--typically lexemes or morphemes. Thus, one possible error is an infinite regression caused by underconstraining some grammatical constituent. In KPML there are four main ways by which a grammatical constituent may be sufficiently specified as to receive lexical material as its realization and so not to trigger a further cycle through the grammar: 1. an explicit lexical entry can be selected for realization (with the realization statement: lexify (Section 12.2.5), 2. a set of lexical features can be associated with a grammatical constituent (by means of the classify realization constraint: Section 12.2.5); on completion of a traversal through the grammar, the complete collection of lexical features for a grammatical constituent is used to pick a matching lexical item (i.e., a lexical item whose lexical features unify), 3. an explicit lexicalization on semantic grounds can be asked for by invoking the inquiry termresolve-id. 4. an explicit selection of a morpheme can be made with the morphological realization operators: preselect-substance, preselect-substance-as-stem, or preselect-substance-as-property (Section 12.2.5.4). Note: if a constituent has been classified, then the selection of a lexical item as described in (2) above will not respect any additional information--it is a purely lexicogrammar internal selection. That is, no semantic information or SPL information will be consulted. If the user wants semantic information to be taken into account then option (3) must be taken by including the term-resolve-id inquiry in some chooser that is activated at an appropriate point during generation (cf. Section 12.4.1).

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node27.html [11.12.2004 14:22:43]

Pointers to further information

next

up

previous

contents

index

Next: Installation and Startup Up: Computational Systemic-Functional Linguistics Previous: Stopping traversal: bottoming out

Pointers to further information

We can now describe the documentation available to a user of a generic systemic-functional computational system in terms of which module of the system is described. This can be done not only for each module of linguistic resources, but also for each meta-stratum at which the module exists. Each level of abstraction and each component with each level has distinct documentation corresponding to its differing concerns. Moreover, any additions and modifications to the framework should position themselves explicitly with respect to this organization, since it is only by doing this that the issues and design criteria can be defined. The dangerous tendency of mixing the linguistic and computational meta-strata should be avoided. An overview of the documentation and its assignment to modules is given in Figure 2.5.

Figure: Further documentation map

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node28.html (1 von 3) [11.12.2004 14:23:05]

Pointers to further information

Thus, the following documents together form the basis of a documentation of the generic computational system. gif Document Area 1: systemic theory John Bateman. 1992. ``Systemic Grammar''. Encyclopedia of AI. Christian Matthiessen and M.A.K. Halliday. 1994. ``Systemic Functional Grammar: a first step into the theory''. Document Area 2: ideational semantics John Bateman, Bob Kasper, Johanna Moore and Richard Whitney. 1990. ``A general organization of knowledge for natural language processing: the Penman upper model.'' ISI Penman note. Renate Henschel. 1994. ``Merging the English and German Upper Model.'' Arbeitspapiere der GMD, 848. Sankt Augustin, Germany. Renate Henschel and John Bateman. 1994. ``The merged upper model: a linguistic ontology for German and English''. Proceedings of COLING '94. John Bateman, Renate Henschel and Fabio Rinaldi. 1995. ``Generalized Upper Model 2.0: documentation''. Technical report. GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. URL = http://www.darmstadt.gmd.de/publish/komet/gen-um/newUM.html. Halliday, Michael A.K. and Christian M.I.M. Matthiessen, Construing experience through meaning: a languagebased approach to cognition. Berlin: de Gruyter, to appear. Document area 3: textual semantics John Bateman. 1993. ``Nigel: textual semantics documentation''. Technical report. GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. John Bateman and Christian Matthiessen. ``Uncovering the text base''. In: Keqi Hao, Hermann Bluhme and Renzhi Li (eds.), Proceedings of the International Conference on Texts and Language Research (29-31 March 1989, Xi'an, China), pp3-45, Xi'an Jiaotong University Press, 1993. Christian Matthiessen, ``Interpreting the textual metafunction''. Linguistics Department, University of Sydney. 1992. Document area 4: grammar Christian Matthiessen. 1995. ``Lexicogrammatical Cartography''. Tokyo, Tapei and Dallas: International Language Sciences Publishers. Elke Teich. 1992. ``KOMET grammar of German''. Technical report. GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. Liesbeth Degand. 1993. ``Dutch Grammar Documentation''. Technical report. GMD/Institut für Integrierte Publikations- und Informationssysteme, Darmstadt, Germany. Bernhard Hauser. 1995. ``Multilinguale Textgenerierung am Beispiel des Japanischen''. Technische Hochschule Darmstadt, Diplomarbeit. Document area 5: semantic interface Robert T. Kasper. 1989. ``A flexible interface for linking applications to PENMAN's sentence generator''. Proceedings of the DARPA Workshop on Speech and Natural Language. Document area 6: knowledge representation Bob MacGregor. 1995 ``The LOOM 2.0 Manual''. ISI Technical Report.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node28.html (2 von 3) [11.12.2004 14:23:05]

Pointers to further information

In case of difficulties, the unpublished documents can be sent on request. It is, of course, also possible to focus on particular areas of interest by referring to the overall map of documentation concerns set out in Figure 2.5. The documentation is being steadily extended.

next

up

previous

contents

index

Next: Installation and Startup Up: Computational Systemic-Functional Linguistics Previous: Stopping traversal: bottoming out John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node28.html (3 von 3) [11.12.2004 14:23:05]

Footnotes

...design. The multilingual generation functionality is based on the the multilingual extensions to the Penman system made by Licheng Zeng (University of Sydney) as documented in Zeng (). Other extensions in KPML include provision of an integrated systemic morphology, work on higher levels of text organization, such as genre and register, as well as numerous code improvements and bug fixes. Only those aspects of the system relevant to developing and maintaining multilingual grammatical resources are described in this documentation however; for overviews of other aspects, see, for example, Bateman & Teich (). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...Dutch. For details of these resources, see their respective documentation and descriptions (Matthiessen , Teich , Degand ). .

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (1 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...supported. Thanks to Mick O'Donnell, KPML without the window interface has also been compiled with Allegro PC Common Lisp with minor changes. Interested parties should contact the author. . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (2 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . ...world. As a complement to the notion of a conceptualization, if we take the ideation base to be a meaning base rather than a knowledge base - this is described further in Matthiessen & Bateman (). . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (3 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . ...grammar. This is the basic generalization; we do, of course, store instantial wordings - quotes, proverbs, etc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...system. There are many more documents covering areas such as grammar and semantics; those listed
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (4 von 59) [11.12.2004 14:23:40]

Footnotes

here are those of particular relevance to the linguistic resources currently available computationally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...size=-1>KPML. For some indication of what is involved in using other knowledge representation systems, see Appendix C. . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (5 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . ...found. will not try to compile LOOM itself. Problems will arise if one attempts to continue loading KPML without a compiled version of LOOM being available-loading will fail ungracefully if one attempts to use the source LOOM files without compilation. Note that if the LOOM pathnames and directory structure have not been properly set up, then the compiled version of LOOM may fail to be found and the system may attempt (incorrectly) to use the uncompiled source files. This can fail with unpleasant messages such as: >>Error: The function COPY-EQSLOTS is undefined or similar.
KPML

. . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (6 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . ...system. It is possible to install the system without CLIM being present; see the configuration step below. . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (7 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . ...size=-1>CLOS For newer Lisps, such as Allegro 4.2 and newer, CLOS is already present in the standard Lisp release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...loaded. In order to spare garbage and also for more reliability if a single image of the system is to be used on various machines, it can be advantageous if the compilation and loading phases are carried out separately rather than during a single Lisp session as described here. .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (8 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...ones. Once installed, it is possible for the knowledgeable user to weed out particular patches, but this is not suggested for normal use. . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (9 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . ...clear. KPML-e versions include a fifth graph subtype: GENRE-STRUCTURE-GRAPH; this is not described here. . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (10 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . ...monochrome. Where this is not the case-for example, with the red/blue differentiation used for contrasting multilingual systemic resources according to language when presented graphically (cf. Section 6.2.5)-alternative representation-styles are selected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...used. For Allegro 4.2 or 4.3, for example, see Chapter 14 of the Allegro documentation.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (11 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...readable. Note that this is a destructive operation. Having started up the window interface in demo mode, it is not then possible to revert to non-demo mode. A similar effect can be obtained by changing the allocated fonts-although this requires that particular known fonts are installed and can only work to best effect if the size of some of the window panes is also altered. This is done automatically by using the demo mode. . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (12 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . ...options. Patching is not activated as the default behaviour since it changes the operation of several commands and the user needs to be aware of this-cf. Chapter 11. . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (13 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . ...configured. Note that configuring KPML for a given language (Chapter 3) is no guarantee that resources for that language exist! . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (14 von 59) [11.12.2004 14:23:40]

Footnotes

. ...language. I.e., loading a system of the same name but for another language will have no effect on the status of the existing definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...size=-1>KPML. From Lisp, pushing the values onto the value of the global variable kpml::alllanguages is sufficient. . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (15 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . ...origin. Actually they are interned in the package identified by the value of kpml::*currentlanguage-package*, but in KPML this is always kpml. . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (16 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . ...automatically. Unless the flag kpml-i::*auto-print* is set. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (17 von 59) [11.12.2004 14:23:40]

Footnotes

. . ...bateman@gmd.de. At present, only the most recently activated resource graph determines the region about which a message is sent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...figure There are several utilities for this: it appears that most versions of CLIM do not produce an appropriate bounding box size for figures. . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (18 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . ...list. This behaviour can be changed by means of the flag kpml-i::*show-collecteds* (Section A.3). . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (19 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . ...systems. Definitions can include more than one system possessing a given feature, but all but the last such definition are disabled during loading: cf. Section 7.5.2.4. . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (20 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . ...HREF="node107.html#chooserepseg">6.10. The chooser graphs are the only kinds of graph produced by KPML which are displayed vertically: note that although the display modes options still calls this `vertical spacing' although in this case the effect is more one of changing the horizontal spacing. The EPS example in Figure 6.10 was produced with `vertical' spacing of 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...generated. Regardless of how input. Thus an SPL input specification could be given as an argument to the function say and subsequently regenerated with <Generate Again>.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (21 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...command. The displayed versions of the generated strings are in fact produced with the example record operation <Display Generated String> (Section 10.2.5.1). The mouse-sensitive structure can therefore be fine-tuned to differing granularities-it need not be a direct representation of the syntactic structure. KPML uses the same structure for this presentation as the `rich mouseable structure' that can be passed back to applications for further processing (e.g., adding hyperlinks, defining their own mouse sensitivity, etc.). Section 14.5 describes these facilities in detail. . . . . .

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (22 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . ...generation. All warnings can be suppressed by setting the flag *demo-mode* to true: not recommended for everyday use! . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (23 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . ...mode. This mode played a more important role in the early days of the Penman system before the inquiry interface and semantic representations had become stable. It is still potentially useful for getting to understand in detail how the architecture works and the kind of modularities that it achieves. A detailed example of a mock-up deimplemented generation traversal is given by Mann & Matthiessen (). . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (24 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . ...`off'. The internal symbol names for these flags are listed in Appendix A below; this enables them to be used to control the amount of information that is given during generation when the window interface is not being used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...entered. From this one can determine the effect on system entry that the system dependencies, defined in the global variable system-dependencies, have. These system dependencies are
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (25 von 59) [11.12.2004 14:23:40]

Footnotes

responsible for helping to decide which of several apparently equally eligible systems should be entered. Relying on particular orders is therefore possible, although not recommended. The forms for defining such dependencies are described in Section 12.2.11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...augmentation. Note that since KPML does not attempt to provide a semantically complete internal representation of the subsumption lattice entailed by the systemic network (this is still beyond the practical capabilities of available feature logic implementations: cf. (Henschel )), it approximates full paths by tracing backwards (i.e., rightwards in the systemic network) until a feature participates in a disjunctive entry condition. Guidance is then given for preselections through such entry condition: see Section 12.2.7. . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (26 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . ...hand. It appears currently not possible to give a nil setting once a number has been given; as a workaround, the number zero can be given. This has the same effect as nil since traversal cycle counting starts from 1 and so a cycle number zero is never found. . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (27 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . . . . . . . . . . . . ...graph. Note that this particular chooser definition contains an oddity: the `notprecede' option for precede-q that does not lead anywhere; this can be ignored here. . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (28 von 59) [11.12.2004 14:23:40]

Footnotes

. . . . . . . ...window. Note that displaying a chooser graphically when only some of its inquiries have been traced and the flag `show generation paths' is set can lead to an incorrect graph. This can be avoided by tracing the chooser rather than inquiries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...size=-1>TENSE. The linguistic details and motivations for this treatment of tense are based on (Halliday ) and
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (29 von 59) [11.12.2004 14:23:40]

Footnotes

are given in Matthiessen (). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...right. This orientation can be changed, see the options below; it is, however, probably the most suitable for systemic functional structures due to the long functional labels that constituents receive. . . . . . . .

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (30 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . ...release. It is also possible to graph individual constituents from a generated structure. This is managed however via the example record and the facilities offered there for structure graphing: cf. Sections 10.2.5 and 10.3. . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (31 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . ...facilities. Slightly more than was available in KPML 0.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (32 von 59) [11.12.2004 14:23:41]

Footnotes

. ...follows. Minor differences in the positioning and ordering of the options can occur as the menu is dynamically constructed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...loaded. With the present release, this test is probably best run only when single language varieties are loaded. . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (33 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . ...HREF="node274.html#exrename">10.2.7), Only available from the Development window under KPML 0.9. . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (34 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . ...`failing'. This does not, therefore, include Lisp errors. If resources are so misformed that Lisp errors occur, then the example runner enters the Lisp debugger as usual and example running is suspended. . . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (35 von 59) [11.12.2004 14:23:41]

Footnotes

. . . ...grow. When more than one generated string is produced for an example, only the first of these appears in the example runner file. This restriction does not apply to the :complete detail file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...therefore: Note that the function structure information appearing is not ideal if this file is to be read into Lisp for automatic processing since some care is necessary to avoid reader errors. . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (36 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . ...NAME=3324> . This is equivalent to issuing an explicit in-language command at the Lisp listener (cf. Section 12.2.1). The effects of the in-language command can be overridden by a subsequent in-language or by calling the function (clear-region-and-languagedefaults). . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (37 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . ...Emacs/Mule. Note: the mode of interaction provided in the Penman interface whereby SPL specifications could be edited from a stand-alone Penman process by starting a new editor-process for each edit is not supported. . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (38 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . ...required. The version of Nigel released as a KPML-resource set does, however, include systemic resources for morphology. This provides a more flexible and transparent representation of the linguistic resources at word and morpheme rank, but increases the generation time a little since further cycles through the grammar are required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (39 von 59) [11.12.2004 14:23:41]

Footnotes

...networks. In older resources-for example, the Nigel grammar and resources created from this resourcethe lexical features and the grammatical features belong to disjoint symbol spaces and so require a mapping from one to the other. This is being gradually changed as time permits (see the linguistic resource descriptions accompanying those resources). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...HREF="node271.html#grexstruct">10.2.5). Setting the global flag *global-font-switching* to true will cause all information displayed in the inspector and development windows to be effected however. Such global font changes take effect when an appropriate <Set Language> is issued. . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (40 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . ...Mule. GNU Mule is the Emacs-extension permitting editing with many different character fonts, including Japanese, Chinese, Vietnamese, Thai, Arabic, Russian, etc. . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (41 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . ...enforced. Note that this is an additional realization operator over those defined in Penman-style resources; reports of experience with its use would be appreciated. . . . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (42 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . ...`preselect'. Although one difference is that use of inflectify allows use of the lexicon to check for idiomatic realizations of features: i.e., irregular forms. Theoretically there is no reason why this should not apply to higher ranks for idioms in general, but this is not currently supported in KPML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...HREF="node317.html#rsnotation">12.1. The notation actually extends the standard somewhat, since not all the realization statements supported here are standard.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (43 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...explicitly. For early experiments in this direction, see, for example, Sefton (). . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (44 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . ...user. That this is called :english is a hangover from the Penman system; it will be changed to :gloss in the near future. . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (45 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . ...not. This is a hangover from the Penman system, it will probably be generalized somewhat sometime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...available. In such cases, the logical form is also, of course, preserved.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (46 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...multilingual). There are some exceptions in the structure slots that are merged: information that is purely bookkeeping for generation is not merged. . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (47 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . ...model'. For alternative, more flexible, models of relating domain to upper model concepts, see, e.g., Bateman & Teich (). . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (48 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . ...generator. Both the SPL macro and default facilities were written by Bob Kasper for the Penman system. This is taken on virtually unchanged in KPML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...are:
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (49 von 59) [11.12.2004 14:23:41]

Footnotes

These are mostly maintained in lists internal to KPML so customization would also be straightforward if they are not to be defined in the upper model adopted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...argument An inquiry defined as taking a parameter of type Function provides such objects appropriately (see Section 12.2.7). . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (50 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . ...access. In fact, for the very lazy, lexical-feature-present-in-association-p assumes as default for its :yes case, a symbol identical to the feature sought (given as second parameter), and for its :no case, a symbol constructed by prefixing either the yes case, or if this is also missing, the second parameter, with the string held in the variable *defaultnegation-prefix* (which is in turn by default the string ``NON''). . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (51 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . ...author. The relevant KPML/Penman internal function for this is realize-classify. This function is called whenever a constituent has had lexical constraints specified for it in terms of `classifications', i.e., preselections of lexical features. It returns information specifying a lexical item that is appropriate for the constraints specified. If, however, a lexical item has already been selected on semantic grounds (by use of the term-resolve-id inquiry), then that is accepted without further investigation. . . . . . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (52 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . ...say. Note, this is a generalization of the Penman functions say and express. It takes several additional keyword parameters and returns results that are not available from the corresponding Penman functions. Code relying on these features is not interchangeable with the Penman system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...HREF="node351.html#mouseablestructureeg">14.1.
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (53 von 59) [11.12.2004 14:23:41]

Footnotes

Each printable constituent object also has a unique identifier (under the slot :id); these have been ommited from the figure to save space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...are: The knowledge-base package reduction methods, as well as several internal speed-ups, were worked out by John Wilkinson (University of Waterloo, Canada). . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (54 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . ...time This is the time excluding, for example, any swapping, garbage collection, KPML once-only set up activities (such as establishing network connectivity), and Loom classifications. . . . . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (55 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . ...to: Franz strongly recommend that safety never be set to zero for their Allegro Common Lisp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (56 von 59) [11.12.2004 14:23:41]

Footnotes

...individually. A CORBA-compliant protocol is being considered. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...itself. The reader might wonder as to why there is an inconsistency in the naming; some of the flags have names of the from *...*, most do not. This is a relic of the old Penman code still underlying much of KPML. The flags with stars are in areas that have been reworked more recently. . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (57 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . . . . . . . . . . . ...redefined. There are two additional functions used in the old Penman experimental nominal phrase planner; this code is not normally used. The functions are: kb-relations and kbidentifier. . . . . . . . . . . . . . . . .
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (58 von 59) [11.12.2004 14:23:41]

Footnotes

. . . . . . . . . . . . . . John Bateman - GMD/IPSI - Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/footnode.html (59 von 59) [11.12.2004 14:23:41]

The KPML root interface windows

next

up

previous

contents

index

Next: Introduction Up: No Title Previous: Notational conventions in this

The KPML root interface windows

q q q q

q q

q

q q

Introduction The `new-style' root window: starting up The root commands: overview General System Behaviour r Environment Directories r Flags General Multilingual Operations and Modes Focusing Operations r Linguistic object focusing r Language focusing r Region focusing Loading existent linguistic resources r Simple resource set loading r General commands for loading linguistic resources s Loading particular kinds of linguistic objects s Loading modes: overwriting and merging s Overwriting mode s Merging mode s Loading and the multilingual modes s Monolingual loading s Contrastive loading s Multilingual loading Resource clearing Saving and Creating linguistic resources r Simple resource set saving r General commands for saving linguistic resources s Monolingual saving s Contrastive saving s Multilingual saving

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node37.html (1 von 2) [11.12.2004 14:24:04]

The KPML root interface windows

q

Inheriting language definitions r Automatic lexical item acquisition and saving r Creating unconditionalized linguistic resources r Changing the Lisp package of inquiry implementations Interface suspension, exiting, etc. r Quiting the interface r Suspending the interface r (Re-)Activating the interface r Clearing the interface windows
r

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node37.html (2 von 2) [11.12.2004 14:24:04]

Introduction

next

up

previous

contents

index

Next: The `new-style' root window: Up: The KPML root interface Previous: The KPML root interface

Introduction
It is assumed that most interaction between the user of the develoment environment and the KPML system will be via the window interface. If this is not so, or if CLIM is not available, see Chapter 14 for information about interacting with the system without the interface. Two styles of window interface are provided: the `new' and the `old'. The old-style is that familiar to users of the Penman system or KPML 0.8 and before; it is described in Chapter 8. Selection of style (when available) can only be done during the KPML load up and configuration phase. The rationale for the new-style interface is to provide both the quickest access to the information necessary for debugging and maintenance and the ability to maintain that information on screen at all times and in combination with other necessary information. Also provided are more graphical tools for inspecting the results and process of generation. The new-style interface uses color-differentiation extensively for presenting various kinds of information in combination; use of KPML is therefore recommended on color screens, although, of course, the differentiation will still be visible in monochrome. gif The recommended way of using KPML is as a subprocess to GNU Emacs; Emacs should be entered in the normal way, and KPML started in an external process Common Lisp buffer. Instructions for starting such a buffer can probably be found in the documentation of the Lisp system being used. gif Using some of the extensions to Emacs--such as the GNU Mule system--offers here a variety of further possibilities (cf. Section 12.2.2.3). However, it is also, of course, possible to use KPML directly without Emacs being present. The KPML system uses the original calling Lisp window for outputting results of commands that are not intended for interactive use. Error conditions that arise and which are not caught by KPML may also occasionally result in control being thrown back to the calling Lisp process. In this event, a restart of the KPML interface (usually one of the presented options for continuing from the error) will suffice for continuing work. For these reasons, it is recommended that the user sets up the screen so that the calling Lisp listener (either an Emacs buffer or an interaction shell) can also be seen somewhere in the background while working with KPML. Such error conditions will generally only arise if the user is developing resources and the definitions are seriously incomplete, or if the window system is disturbed in some way extrinsic to KPML (e.g., by network problems, color palette problems, etc.). Note: if Emacs and Allegro Common Lisp are not being used, then error conditions can cause more than one process to use the originating Lisp listener simultaneously! The user must ensure
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node38.html (1 von 2) [11.12.2004 14:25:46]

Introduction

that the required input makes it way to the appropriate process (e.g., by repeating it until accepted). Commands are given either by selecting from menus or by being typed within interaction panes. Generally, all typed input is terminated by typing a carriage return. Partially typed in or executed commands can be aborted by typing a control-Z. The new-style interface also provides argument completion. Control-? produces a list of possible completions of the string already given; control-/ produces a list of all possible completions where the string given occurs as a substring. Commands and arguments being input can be edited using the normal input line editing commands (control-f: forwards a character, control-b: backwards a character, control-e to end of line, control-a to beginning of line, etc.). The remainder of this chapter describes the `new' style root interface window. Chapters 6 and 7 then describe the other two main windows of the new style interface: the Inspector window window and the Development window respectively.

next

up

previous

contents

index

Next: The `new-style' root window: Up: The KPML root interface Previous: The KPML root interface John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node38.html (2 von 2) [11.12.2004 14:25:46]

The `new-style' root window: starting up

next

up

previous

contents

index

Next: The root commands: overview Up: The KPML root interface Previous: Introduction

The `new-style' root window: starting up
Once the KPML system has been loaded, and as long as it has been configured so as to include the newstyle window interface (see Chapter 3), the interface can be started by calling the Lisp function kpmli::startup from the selected Lisp listener (i.e., either an Emacs Common Lisp buffer or a shell). The function takes several optional keyword arguments as indicated by the following. [function] When non-nil :reset indicates that any existing instances of a KPML window interface are to be replaced. :demo, when non-nil, brings up the window interface in demonstration mode: here the size of fonts in windows are made very much larger so that they can be easily seen at some distance from the screen or during overhead projection--many of the window and screen images shown in this documentation were made using the KPML demonstration window mode in order to make them more readable. gif The straightforward call to: (kpml-i::startup) is equivalent to the call: (kpml-i::startup :reset T :demo nil) Images made with the make-kpml-image function (cf. Section 3.1) will automatically bring up the window interface with default parameters when executed. The first action of the startup function is to ask the user whether the interface is to be brought up in monochrome or in colour. Restarts of the window interface can change their selection here as the user requires. For example, many of the screendumps reproduced in this document were made in monochrome mode since these can look better when printed in black-and-white. If no linguistic resources are present on startup, the root window alone will be brought up. If linguistic resources have been loaded, then the Inspector and Development windows described in Chapters 6 and 7 respectively will also be started automatically.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node39.html (1 von 2) [11.12.2004 14:26:05]

The `new-style' root window: starting up

next

up

previous

contents

index

Next: The root commands: overview Up: The KPML root interface Previous: Introduction John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node39.html (2 von 2) [11.12.2004 14:26:05]

The root commands: overview

next

up

previous

contents

index

Next: General System Behaviour Up: The KPML root interface Previous: The `new-style' root window:

The root commands: overview
The root window provides commands for those operations that generally precede or follow working with a set of linguistic resources--such as loading and saving linguistic resources--as well as for selecting between general system behaviour options. The root interface window is shown in Figure 5.1.

Figure: The KPML root interface The root window consists of 5 panes stacked vertically. From top to bottom these are: the root command menu, the root interaction pane, the root messages pane, the <Launch Development Windows> command button, and the documentation line. Most, but not all, available commands are shown in the command menu. There are also several additional commands that can be typed directly in the middle interaction pane or selected by mouse-click from the completion menu when
http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node40.html (1 von 2) [11.12.2004 14:26:18]

The root commands: overview

available (as shown in the documentation line). These latter are less frequently required commands. The prompt shown in the interaction pane includes an indication of the current language; in the example in the figure, this can be seen to be English. Once resources have been loaded and the system flags have been set as desired, the development and inspection windows can be started by clicking on the <Launch Development Windows> button. This brings up the two windows described in the following two chapters. Finally, the documentation line shows at all times the options available by clicking the mouse buttons. Options are shown when applicable for the left (L) button, the middle (M) button, and the right (R) button. In the figure, there is only one option available: clicking right would bring up the complete list of commands possible for input at the interaction pane. Clicking on one of these would then insert it as if typed. To activate it, the user must then type a return. The root commands group into the following categories. Both those commands available directly via the menu and those that need to be entered at the interaction pane are listed here, differentiated according to the notational conventions given in Chapter 4.
q q

q

q

q

General system behaviour (<Flags> and < Environment Directories>). System behaviour particularly concerned with the multilinguality of loaded or stored linguistic resources (<Multilingual Behaviour Modes> and <Set Default Language> ). System behaviour during loading or saving particularly concerned with which types of linguistic object are to be affected (<Focusing Operations> ). Resource input/output: including linguistic resource sets as a whole (<Load Linguistic Resource>, <Store Linguistic Resource>, <Create New Language>), lexicons (<Load Lexicon Files>, <:Write Lexicon Files>, <:Clear Lexicons>), and clearing of any loaded systemic linguistic resources (<Clear Systemic Networks>). Exit, suspension/activation and clearing of window interface panes (<Quit>, <:Suspend>, <:Activate>, and <:Clear Windows>).

The following sections describe these command groups in detail.

next

up

previous

contents

index

Next: General System Behaviour Up: The KPML root interface Previous: The `new-style' root window: John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node40.html (2 von 2) [11.12.2004 14:26:18]

General System Behaviour

next

up

previous

contents

index

Next: Environment Directories Up: The KPML root interface Previous: The root commands: overview

General System Behaviour

q q

Environment Directories Flags

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node41.html [11.12.2004 14:26:29]

Environment Directories

next

up

previous

contents

index

Next: Flags Up: General System Behaviour Previous: General System Behaviour

Environment Directories

The <Environment Directories> command brings up a menu for setting/inspecting the environmental file directories that the KPML system uses for various kinds of information access and display. The directories currently maintained here are:
q q

q

q

Root of resources: the directory under which all linguistic resources hang (cf. Section 12.1). Hardcopy directory: the directory where postscript versions of graphed information are written when called for--for example, when graphing systemic networks (Section 6.2.1.2), structures (Section 7.9 and 10.2.5), or choosers (Section 6.3.2.2). Merging results directory: the directory that records the actions taken when resources are being merged during loading rather than overwritten when the most verbose tracing flags are set (see Section 5.7.2.2). Example runner results directory: the directory where the results of attempting to generate selected sets of loaded examples (see Chapter 9) are recorded.

Changing the root directory, for example, is one simple way of creating resources in a new userspecific location--this would be of particular use if different users or developing different resources but using the same installation of KPML. The starting value for the root directory is that given in the KPML configuration phase. The starting values for the other directories is /tmp.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node42.html [11.12.2004 14:26:36]

Flags

next

up

previous

contents

index

Next: General Multilingual Operations and Up: General System Behaviour Previous: Environment Directories

Flags

The command <Flags> brings up a menu containing flags that control general display characteristics of the KPML system. These flags activate or disable:
q

q

q

q

q

q

display of generated constituency structure: when this flag is set successful generation processes display not only a generated string but also a representation of the grammatical structure underlying that string. The structure is mouse sensitive and can be used for seeking information concerning the generation process. Figure 7.2 shows an example (cf. Section 10.3.2). schematic constituency display in generated strings: when set, generated strings are displayed with internal syntactic bracketting enabling selective mouse selection of grammatical constituents (cf. Section 10.3.1). The first output string in Figure 7.1 is an example of the use of this mode. restriction of examples offered for generation according to language: when set, the menus of pre-stored examples for generation are restricted only to show those examples defined for the current language (cf. Section 7.4.2). automatic acquisition of new lexical items: when set, any new lexical items generated on-thefly during generation are added to a list of `new lexemes'. These can then be written out to lexicon files following a session (cf. Section 5.9.4). example running results recording to various levels of detail: resource maintenance is generally performed by running test suites. This flag sets the degree of detail in the logs of such test suite runs (cf. Section 10.2.9). use of various pop-up windows for showing generation results or for inspecting linguistic objects. In particular, generated strings, selection expressions (i.e., paths of features selected while traversing the systemic networks), and choosers can either be presented in the relevant development or inspector window information panes, or separately in their own pop-up windows. The default behaviour is that selection expressions and choosers are shown in their own windows and generated strings are shown in the development window.

next

up

previous

contents

index

Next: General Multilingual Operations and Up: General System Behaviour Previous: Environment Directories

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node43.html (1 von 2) [11.12.2004 14:26:42]

Flags

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node43.html (2 von 2) [11.12.2004 14:26:42]

General Multilingual Operations and Modes

next

up

previous

contents

index

Next: Focusing Operations Up: The KPML root interface Previous: Flags

General Multilingual Operations and Modes

This section describes the options and effects available under the commands <Multilingual Behaviour Modes> and <Set Default Language> . KPML provides some general modes and settings for multilingual operations that apply in some form to almost all operations that the system offers--i.e., to loading, saving, graphing, printing, and generating. These modes extend the flexibility and ease of use of the system particularly when multilingual operations are being performed with any frequency. All types of multilingual operations on resources can be carried out in three modes:
q

q

q

monolingual mode, where a single monolingual view of a, possibly multilingual, resource is taken, contrastive mode, where several, usually monolingual, views of a multilingual resource are taken `side by side', or in parallel, multilingual mode, where a single multilingual view is taken of some selection of languages (possibly all) drawn from a multilingual resource.

Here, a monolingual resource is understood as one which contains information only about one language variety (whether or not this is indicated by single in-language declarations (Section 12.2.1) or by appropriate conditionalization within linguistic unit definitions (Section 12.3)), and a multilingual resource is understood as one which contains information about at least two language varieties. The modes can be set by selecting the command <Multilingual Behavior Modes> ; this brings up a menu of possibilities. The precise consequences of each of the three modes when combined with a given multilingual operation type is set out in the individual sections below. The default behavior on starting up a newly installed instance of KPML is always `monolingual' in all cases. In addition, the multilingual modes menu includes options for setting whether linguistic resources are merged during loading (see Section 5.7.2.2.2) or not, and for setting whether linguistic resources are by default cleared before the loading of a new resource set begins. The defaults are that no merging occurs

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node44.html (1 von 2) [11.12.2004 14:26:51]

General Multilingual Operations and Modes

and that resources are cleared. As described in the chapter concerning definition formats (Chapter 12), definitions of linguistic objects for loading can contain explicit language conditionalizations. They need not do so, however, in which case the language specification for a linguistic object is taken either from a declaration at the beginning of the file containing the definition or, if no such declaration is present, from the currently known set of languages for which KPML is configured. This behaviour is sometimes not what is required--for example, if a definitions from some resource file are being edited and the changes are being immediately evaluated as typically the case when using KPML combined with Emacs, then these definitions will often not contain language conditionalizations because they are relying on the declaration at the beginning of the file. Evaluating the definitions could then place the definition in the wrong language partitions. The <Set Default Language> provides a solution to this problem by setting up a default set of languages for all evaluation contexts where no explicit language conditionalization is given. This is described in more detail in the chapter on resource patching (Chapter 11).

next

up

previous

contents

index

Next: Focusing Operations Up: The KPML root interface Previous: Flags John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node44.html (2 von 2) [11.12.2004 14:26:51]

Focusing Operations

next

up

previous

contents

index

Next: Linguistic object focusing Up: The KPML root interface Previous: General Multilingual Operations and

Focusing Operations

This section describes the options and effects available under the command <Focusing Operations> .

q q q

Linguistic object focusing Language focusing Region focusing

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node45.html [11.12.2004 14:27:08]

Linguistic object focusing

next

up

previous

contents

index

Next: Language focusing Up: Focusing Operations Previous: Focusing Operations

Linguistic object focusing

Whereas the default behaviour of the loading and saving operations <Load Linguistic Resource> and <Store Linguistic Resource> is that all linguistic resources of a given language or languages be loaded or saved, this can be more finely controlled by focusing on the types of linguistic object that are of interest. The command <Focusing Operations: Focus on selected linguistic objects> brings up a menu of the kinds of linguistic objects known to the system. This list contains the following items:
q q q q q q q q q q q q q

:systems :choosers :inquiries :default-orderings :punctuation :lexemes :examples :inquiry-implementations :inquiry-defaults :domains :properties :resource-patches :kpml-lg-specific-patches

All or any of these items may be selected. Subsequent loading or saving operations will then concern only the linguistic objects of the types selected. The command <Focusing Operations: Release linguistic object focus> undoes the effect of object focusing, by setting the default list of object considered back to the full set. The full set consists of all the linguistic objects except the two patch options. gif

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node46.html [11.12.2004 14:27:14]

Language focusing

next

up

previous

contents

index

Next: Region focusing Up: Focusing Operations Previous: Linguistic object focusing

Language focusing

When one is working with some subset of the languages for which resources are available, it is possible to fix attention to that subset so as to avoid repetitive queries (during, for example, contrastive saving, graphing, generation, etc.) as to which languages are required. The command <Focusing Operations: Focus on selected languages> brings up a menu of the languages that are known to the system. The user should then select some subset (or all) of the languages offered. These then become the languages that are used in any contrastive or multilingual operations without further user queries. The effect of language focusing is removed by the command < Focusing Operations: Release language focus>. Giving this command when no languages are focused has no effect.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node47.html [11.12.2004 14:27:18]

Region focusing

next

up

previous

contents

index

Next: Loading existent linguistic resources Up: Focusing Operations Previous: Language focusing

Region focusing

Region focusing provides a finer selection of particular functional regions (cf. Section 2.1.1.3) within languages. When a set of regions is focused, then only these regions will be effected by loading and saving operations. Region focusing works entirely analogously to language focusing.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node48.html [11.12.2004 14:27:22]

Loading existent linguistic resources

next

up

previous

contents

index

Next: Simple resource set loading Up: The KPML root interface Previous: Region focusing

Loading existent linguistic resources
Loading refers to the reading of resource definitions (according to the specifications set out in Chapter 12) maintained in files into the KPML system. The assumed directory organization of these resource files is as described in Section 12.1. Normally, the first operation that will be done when starting up KPML will be to load some set of resources. The default startup loading behavior is monolingual behavior.

q q

Simple resource set loading General commands for loading linguistic resources r Loading particular kinds of linguistic objects r Loading modes: overwriting and merging s Overwriting mode s Merging mode r Loading and the multilingual modes s Monolingual loading s Contrastive loading s Multilingual loading

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node49.html [11.12.2004 14:27:26]

Simple resource set loading

next

up

previous

contents

index

Next: General commands for loading Up: Loading existent linguistic resources Previous: Loading existent linguistic resources

Simple resource set loading
Once KPML is installed, loaded, and running, the first operation that typically needs to be performed is to load some already existing set of linguistic resources. The resources desired need also to have been installed and made accessible to KPML. KPML can access resources when the directory in which the resources are kept has been placed in the global variable *root-of-resources*. This can either be done during installation of KPML (see Section 3.3), or at any time by issuing the command <Environment Directories> (see Section 5.4.1). Following this, the simplest way to load a set of linguistic resources is with the command: <Load Linguistic Resources> The languages offered will be those for which KPML has been configured. gif . This command will then cause all available resources for the designated resource set to be loaded. This includes the grammar definition (systems, choosers, and inquiries), any lexica that are defined for the resource set, any examples that are defined for the resource set, punctuation rules, and SPL-defaults/macros for the language variety; for descriptions of all these resource types, see Chapter 12. Note that explicit language conditionalization given in an input specification always takes precedence over any default assumptions or options. That is, if a resource set is called :english, but contains explicit conditionalizations for :german, then it is these explicit conditionalizations that prevail. Resource set loading relies on the resources having the organization and internal form also described in Chapter 12. This organization is automatically created and conformed to by any of the KPML commands for saving linguistic resources (Section 5.9.1). If the resource set is complete (as any of the standardly released resource sets will be), it is then possible to generate with the loaded resources--either from the provided examples or from new semantic specifications given by the user. Generation of an example sentence provided in the resource set is started by the command DEVELOPMENT:<Generate Sentence EG-n> where EG-n is an example name selected from an offered menu. The first time that a sentence is generated, it will probably be the case that some internal bookkeeping is triggered; this does not then occur again until new resources are loaded. For the details of the generation process see Section 7.4, and for test suite maintenance Chapter 10.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node50.html (1 von 2) [11.12.2004 14:27:42]

Simple resource set loading

next

up

previous

contents

index

Next: General commands for loading Up: Loading existent linguistic resources Previous: Loading existent linguistic resources John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node50.html (2 von 2) [11.12.2004 14:27:42]

General commands for loading linguistic resources

next

up

previous

contents

index

Next: Loading particular kinds of Up: Loading existent linguistic resources Previous: Simple resource set loading

General commands for loading linguistic resources
While the above loading command usage is often sufficient for using KPML, the system provides considerably more functionality for loading linguistic resource sets.

q q

q

Loading particular kinds of linguistic objects Loading modes: overwriting and merging r Overwriting mode r Merging mode Loading and the multilingual modes r Monolingual loading r Contrastive loading r Multilingual loading

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node51.html [11.12.2004 14:27:52]

Loading particular kinds of linguistic objects

next

up

previous

contents

index

Next: Loading modes: overwriting and Up: General commands for loading Previous: General commands for loading

Loading particular kinds of linguistic objects
It is possible to indicate exactly what kinds of linguistic objects are to be loaded from any resource set by issuing the command < Multilingual Behaviour Modes: Focus on selected linguistic objects> (Section 5.6.1). When some subset of linguistic objects are focused, any load operation initiated before the focused object set is released is automatically restricted to just those objects that are focused. Therefore, if a grammar, for example, that of French, was to be kept intact, and it was simply required to load an updated version of, for example, the punctuation rules for that language, then this could be achieved with the following command sequence (making use also of the language focusing commands mentioned in Sections 5.6.2) issued from the ROOT KPML window interface. <Multilingual Behaviour Modes: Focus on selected language French> <...: Focus on selected linguistic objects punctuation> <Load linguistic resources> <Multilingual Behaviour Modes: Release Object Focusing> Note that the command DEVELOPMENT:<Operations on examples: Load examples> is also available for loading examples (Section 10.2.1). This allows the user to select a given example set from the Example directory of the current language, should not all the available example sets be required. Example sets offered in the menu consist of those files with extension .spl or .ex in the appropriate language directory.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node52.html [11.12.2004 14:27:57]

Loading modes: overwriting and merging

next

up

previous

contents

index

Next: Overwriting mode Up: General commands for loading Previous: Loading particular kinds of

Loading modes: overwriting and merging

Two loading modes are provided: overwriting and merging.

q q

Overwriting mode Merging mode

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node53.html [11.12.2004 14:28:01]

Overwriting mode

next

up

previous

contents

index

Next: Merging mode Up: Loading modes: overwriting and Previous: Loading modes: overwriting and Overwriting mode

When systems, choosers, inquiries, examples and lexical items are loaded for which definitions of identically named entities already exist, these previous definitions are fully replaced by the new ones. No trace of the older ones will survive. When a newly defined entity has a smaller language scope than the entity replaced, then a warning to this effect is given since it means that the previous language resources relying on the old definition may no longer be complete. Similarly, for punctuation rules, nonsystemic dependencies, and inquiry implementations, the newly loaded resources for a language will replace all existing definitions for any language. Although potentially deleterious for the loaded versions of existing resources, this option can be sensibly used for working on new language development without regard for previous resources. Subsequently, merging can be undertaken using the merging mode for reimporting the debugged resources into the general multilingual potential.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node54.html [11.12.2004 14:28:05]

Merging mode

next

up

previous

contents

index

Next: Loading and the multilingual Up: Loading modes: overwriting and Previous: Overwriting mode Merging mode

When systems, choosers, inquires, examples and lexical items are loaded for which definitions of identically named entities already exist, these previous definitions are merged with the new definitions. The result is a multilingual entity which is equivalent to a set of monolingual definitions. The entity can then be used or inspected from the perspective of any of the languages for which KPML is configured. Similarly, for punctuation rules, nonsystemic dependencies, and inquiry implementations, the new definitions are added to existing definitions (replacing only any such definitions already existing for the newly loaded language), and definitions of other languages are not affected.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node55.html [11.12.2004 14:28:09]

Loading and the multilingual modes

next

up

previous

contents

index

Next: Monolingual loading Up: General commands for loading Previous: Merging mode

Loading and the multilingual modes
The multilingual modes (Section 5.5) intersect with loading to produce the following behaviors.

q q q

Monolingual loading Contrastive loading Multilingual loading

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node56.html [11.12.2004 14:28:12]

Monolingual loading

next

up

previous

contents

index

Next: Contrastive loading Up: Loading and the multilingual Previous: Loading and the multilingual Monolingual loading

When the monolingual mode for loading is activated, a resource set from a single identified language variety is loaded. For example, issuing a <Load linguistic resources> command prompts for a single language and the resources found under the corresponding directory will be loaded. Monolingual loading takes place in overwriting mode; that is, any new definitions possessing the same name as existing definitions cause the existing definitions to be overwritten--regardless of whether this causes information to be lost by removing definitions relevant for other languages! That is, if there is an existing definition of a grammatical system PROCESS-TYPE that is relevant for the languages English, German and Japanese, and a new system of the same name is loaded monolingually for German, then the previously accessible views of English and Japanese will be lost. If a new system of the same name is loaded monolingually for, for example, Dutch, then the previous views of English, German and Japanese will all be lost. This behavior comes closest to that of the Penman system when loading new definitions.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node57.html [11.12.2004 14:28:16]

Contrastive loading

next

up

previous

contents

index

Next: Multilingual loading Up: Loading and the multilingual Previous: Monolingual loading Contrastive loading

When the contrastive mode for loading is activated, resource sets from several identified language varieties are loaded. For example, issuing a <Load linguistic resources> command in this case prompts not for one but for several languages: resources found under each of the corresponding directories will then be loaded. The order of loading is not specified and should not be significant. Also, although it will generally be the case that the individual resource sets are monolingual, this need not be the case and is not enforced. Contrastive loading provides a convenient way of loading an entire set of distinct resources in one go. Although resources are cleared before loading commences--as in the case with monolingual loading-contrastive loading takes place in merging mode. Here, for any of the selected languages, definitions sharing names with existing definitions will be merged with the views of the existing definitions that correspond to languages distinct to the one currently being loaded. Indeed, with this option, overwrite mode would make little sense since it would usually make it the case that information would be lost when each additional resource set were loaded. Thus, asking for contrastive loading of, for example, English, German and French results in a single three-language multilingual resource consisting of the merged monolingual descriptions of each of those languages. Note that, since the resources loaded are cleared prior to a contrastive load, asking for the contrastive loading of a single language is equivalent to monolingual loading. In order to load a single language into the KPML system in merging mode, this mode has to be selected explicitly. This can be done under the <Multilingual Behaviour Modes> command described in Section 5.5. Then, using the example for monolingual loading outlined above: in the first case the definitions for English and Japanese will be maintained and only that for German will be replaced; in the second case, all of the information is maintained, the incoming definition for Dutch is simply merged with the existing definitions for English, German and Japanese resulting in a definition for PROCESS-TYPE that allows four distinct language views. This could be of use in successive testing of resources. Note also that when a system has been disabled for some language during previous loading, then that status remains unchanged unless the system is explicitly reloaded for that language. gif Similarly, if a linguistic object belongs to a patch, then that patch status remains unchanged when linguistic objects of the same name but from other languages and possibly of different patch status are loaded.

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node58.html (1 von 2) [11.12.2004 14:28:21]

Contrastive loading

next

up

previous

contents

index

Next: Multilingual loading Up: Loading and the multilingual Previous: Monolingual loading John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node58.html (2 von 2) [11.12.2004 14:28:21]

Multilingual loading

next

up

previous

contents

index

Next: Resource clearing Up: Loading and the multilingual Previous: Contrastive loading Multilingual loading When the multilingual mode for loading is activated, a single multilingual resource set from a specified directory is loaded into the KPML system. The normal behavior during multilingual loading is that loading proceeds in merge mode; i.e., new definitions replace old definitions just for those languages which are common between the new and the existing resources. If potential `interference' with existing resources is to be ruled out, then those resources should first be cleared. The directory used for loading multilingual resources can be inspected and set using the < Environment Directories> command (Section 5.4.1). The multilingual loading option is quite powerful. It makes it possible for a multilingual grammar for, for example, English, German and Dutch developed by one research group to be merged directly with another multilingual grammar for, say, Japanese, Chinese and Thai developed by a distinct research group. The result is then in this case a single six-language multilingual resource from which contrastive views can be extracted as required--for example by inspecting (Chapter 6) or saving (Section 5.9.1) operations. An alternative way of producing the same result would be for each group to extract three monolingual resource sets (contrastive saving, see below) and then to load the resulting six descriptions contrastively. The multilingual option is, however, much faster since the necessary merging operations have already been carried out in the multilingually written files. Note: there is no guarantee that an `optimal', or even a `canonical', merged form is created in any of the options involving merges. All that is guaranteed is functional equivalence of the resources created. The language varieties used as conditionalizations in a multilingual resource set should all be made known to the system before loading; that is, if the resource set uses conditionalizations for :french, :japanese, and :dutch, then these values must be declared as expected language varieties to gif Multilingual resources created with KPML will standardly include a declaration of the KPML. languages they include (cf. Section 12.2.3).

next

up

previous

contents

index

Next: Resource clearing Up: Loading and the multilingual Previous: Contrastive loading John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node59.html [11.12.2004 14:28:26]

Resource clearing

next

up

previous

contents

index

Next: Saving and Creating linguistic Up: The KPML root interface Previous: Multilingual loading

Resource clearing
If it is necessary to clear already loaded resources before loading new resource sets, this can be carried out by the <Clear Systemic Network> command. This clears all systemic networks and their corresponding choosers and inquiries. Language and region focusing have no effect here. The command <:Clear Lexicons> similarly clears all lexical items defined; while the command DEVELOPMENT:<Example Operations: Clear Examples> clears all example definitions.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node60.html [11.12.2004 14:28:30]

Saving and Creating linguistic resources

next

up

previous

contents

index

Next: Simple resource set saving Up: The KPML root interface Previous: Resource clearing

Saving and Creating linguistic resources

q q

q q q q

Simple resource set saving General commands for saving linguistic resources r Monolingual saving r Contrastive saving r Multilingual saving Inheriting language definitions Automatic lexical item acquisition and saving Creating unconditionalized linguistic resources Changing the Lisp package of inquiry implementations

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node61.html [11.12.2004 14:28:34]

Simple resource set saving

next

up

previous

contents

index

Next: General commands for saving Up: Saving and Creating linguistic Previous: Saving and Creating linguistic

Simple resource set saving

Saving is the operation of exporting the resource definitions held at any time in the KPML system to sets of external files. Saving is the normal operation to be performed after working on the resources or after creating new resources. Saving can be carried out in any of the three multilingual operation modes (Section 5.5). The default startup saving behavior is monolingual saving. All information concerning systems, choosers and inquiries that is known to the system will be saved to their respective regions, regardless of any originating file structure used in loading that information. In contrast, lexicons and examples are saved back into a directory structure isomorphic to their originating definitions although not necessary in the same directory. All requests for saving linguistic resources initiated with the <Store linguistic resources> command obey any constraints that may have been set under language, region, and linguistic object focusing as described above. The following additional commands provide specialized saving commands:
q

q

Lexicon File> - this will pick out the lexical items defined in an identified file and write these and these only back to that file. DEVELOPMENT:<Example Operations: Write Examples> - this will write out the current examples as defined (cf. Section 10.2.2).

ROOT:<:Write

Note that the saving commands never clear their target directories before saving: the user should therefore exercise care that old and new definitions are not mixed involuntarily. To aid this, the save menu contains an additional flag asking whether a new directory is to be created (regardless of the existence of a previous directory for the language variety at issue) or not. When a new directory is to be created and there is already an existing directory of the same name for that language variety, then the existing directory is copied into a backup directory. The name of the backup directory is the same as the original with the date of creation of the new directory appended.

next

up

previous

contents

index

Next: General commands for saving Up: Saving and Creating linguistic Previous: Saving and Creating linguistic

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node62.html (1 von 2) [11.12.2004 14:28:38]

Simple resource set saving

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node62.html (2 von 2) [11.12.2004 14:28:38]

General commands for saving linguistic resources

next

up

previous

contents

index

Next: Monolingual saving Up: Saving and Creating linguistic Previous: Simple resource set saving

General commands for saving linguistic resources

q q q

Monolingual saving Contrastive saving Multilingual saving

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node63.html [11.12.2004 14:28:43]

Monolingual saving

next

up

previous

contents

index

Next: Contrastive saving Up: General commands for saving Previous: General commands for saving

Monolingual saving

In monolingual saving mode, the user is prompted for a single language selected from those for which KPML is currently configured. A single set of monolingual resources for that language will then be written to files in a directory corresponding to the name of the language variety. The directory will be located underneath the *root-of-resources* directory as specified during KPML initialization (Chapter 3) or as subsequently modified by the <Environment Directories> command (Section 5.4.1). For example, if KPML is working with a loaded multilingual resource including views for English and German, issuing a monolingual Store linguistic resources command for German will write out a set of files (three for each functional region, providing the systems, choosers, and inquiries, plus ordering and punctuation information: see Chapter 12) under a directory called GERMAN. All of the resource files will be conditionalized exclusively for the single language German. Resource sets of this kind can then naturally be reloaded separately at any time using the monolingual <Load linguistic resources> command, or as a contributor to a multilingual set using the contrastive load option.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node64.html [11.12.2004 14:28:47]

Contrastive saving

next

up

previous

contents

index

Next: Multilingual saving Up: General commands for saving Previous: Monolingual saving

Contrastive saving
In contrastive saving mode, the user is prompted for a set of languages selected from those for which KPML is currently configured. The system then performs a monolingual save for each of these languages. For example, issuing a contrastive <Store linguistic resources> command for English and German results in two directories (called ENGLISH and GERMAN respectively) being written, each containing a complete monolingual conditionalized set of resource definitions. Resource sets of this kind can then naturally be reloaded in their entirety at any time using the contrastive <Load linguistic resources> command, or as single languages using the monolingual load option. Note that monolingual conditionalized resource sets are explicitly marked as being relevant for a given language. This contrasts with monolingual resource sets which have no language affiliation: see Section 5.9.5.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node65.html [11.12.2004 14:28:52]

Multilingual saving

next

up

previous

contents

index

Next: Inheriting language definitions Up: General commands for saving Previous: Contrastive saving

Multilingual saving

When the multilingual mode for loading is activated, a single multilingual resource set is written to a specified directory. The user is prompted for the languages (which can be any subset of the set of languages for which KPML is configured at that time) to be included in that resource set. The resource set contains the appropriate language specific conditionalizations to enable the individual language views to be recovered when required. For example, if KPML is configured for English, German, Dutch, French and Japanese, then issuing a multilingual <Store linguistic resources> for English, Dutch and Japanese will result in a single threeway multilingual resource set being written to the specified directory. The directory used for saving multilingual resources can be inspected and set using the <Environment Directories> command (Section 5.4.1). Multilingual resource sets of this kind can be reloaded at any time using the multilingual <Load linguistic resources> command.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node66.html [11.12.2004 14:28:56]

Inheriting language definitions

next

up

previous

contents

index

Next: Automatic lexical item acquisition Up: Saving and Creating linguistic Previous: Multilingual saving

Inheriting language definitions

KPML provides one way of creating linguistic resources: a resource set is constructed that is the exact copy of some existing linguistic resources apart from the language conditionalization being altered to refer to some new language. This is triggered by the <Create New Language> command. This command brings up a menu dialogue which asks the name of the new language variety to be created and the existing language variety from which it is to be created. Following the operation a complete new set of resources for the new language variety based on the definitions of the selected old language is written under the current root of resources, and this language is added to the list of available languages. If the original resource set was complete, then it should be possible to issue a load linguistic resource command on the new language and obtain the same generation results as were obtained with the originating language. This command can be used as the first stage of creating resources for a new language. The command is fully sensitive to region and linguistic object focusing. Note that, as always, only systemic resources are included in this saving operation: i.e., only systems, choosers, inquiries, punctuation, and default orderings. Other definitions (domains, etc.) have to be prepared separately.

John Bateman -- GMD/IPSI -- Darmstadt, Germany mail to bateman@gmd.de

http://www.darmstadt.gmd.de/publish/komet/kpml-1-doc/node67.html [11.12.2004 14:29:01]

Automatic lexical item acquisition and saving

next

up

previous

contents

index

Next: Creating unconditionalized linguistic resources Up: Saving and Creating linguistic Previous: Inheriting language definitions

Automatic lexical item acquisition and saving

When the ROOT:<Flags> option `automatic acquisition of new lexical items' is set, any undefined lexical items mentioned in :lex or :name s

推荐相关:

table of contents & list of figures and tables_图文.ppt

table of contents & list of figures and tables_英语学习_外语学习_教育专区... or attached materials introduced without any titles or explicit indexing/...

Scaffolding 支架理论_图文.pdf

Contents List of figures List of tables About the authors Preface Acknowledgements ix ix x xi xvii Introduction Why scaffold literacy learning? The scaffold...

TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES LI....pdf

TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES LIST OF ABBREVIATIONS AND ACRONYMS ii隐藏>> Augmented Sorting of Recovered Wood Waste Using Stain and ...

Contents List of Figures vii List of Tables ix.pdf

Contents List of Figures vii List of Tables ix_专业资料。Contents List of...For the ports between Index Control and Data Retrieve, the communication ...

unit 4 table and figure精讲_图文.ppt

Medical English Writing 医学英语写作第四章 表格与插图(Table and Figure) 授课单位:外语教研部 授课教师:高晓平 Content 1 2 统计表与统计图 Lead-in 表图的...

Contents List of Figures ix List of Tables xi.pdf

Contents List of Figures ix List of Tables xiContents List of Figures ix List of Tables xi隐藏>> ADVANCES IN SPECIFICATION AND DESIGN LANGUAGES FOR ...

Contents List of Figures vii List of Tables ix List....pdf

Contents List of Figures vii List of Tables ix List of Algorithms x ...a corpus of 424 web services from SALCentral.org, a web service index. ...

CONTENTS LIST OF TABLES AND FIGURES 4 Chapter 1 THE PROBLEM ....pdf

CONTENTS LIST OF TABLES AND FIGURES 4 Chapter 1 THE PROBLEM AND ITS SETTING_专业资料。CONTENTS LIST OF TABLES AND FIGURES 4 Chapter 1 THE PROBLEM AND ...

Lists of Definitions, Figures, Symbols, and Tables ....pdf

Contents List of Figures... 暂无评价 108页 免费 List of Figures iii ... Figures, Symbols, and Tables 311 List of Tables Table 1 Overview of ...

Table of Contents Table of Contents ii List of Tables ii.pdf

Program Institute for Research in Construction National Research Council Canada Table of Contents Table of Contents List of Tables List of Figures Nomenclature...

...in Collaboration Contents List of Figures_免费下....pdf

List of Tables and Figur... 79页 免费 Contents List of Figures... ...By adopting automatic indexing, file://G:\kchang\publications\publication25....

unit 4 table and figure剖析_图文.ppt

Medical English Writing 医学英语写作第四章 表格与插图(Table and Figure) 授课单位:外语教研部 授课教师:高晓平 Content 1 2 统计表与统计图 Lead-in 表图的...

如何制作论文中的Table和Figures.doc

如何制作论文中的TableFigures_其它_工作范文_实用文档。论文书写 TABLE FIGURE... 5页 1下载券 TABLE OFCONTENTS List ... 暂无评价 30页 免费 ...

What is the table of figures about A.The poc_答案_百度高考.doc

本题是细节题,较为容易。在对话一开始,女士即指出: ...this table of figures about the pocket money children in Britain get,因此本题答案就是[A]。...

Contents List of Tables vii.pdf

Contents List of Figures... 暂无评价 148页 免费 ii Table of Contents Ack... 暂无评价 160页 免费 CONTENTS LIST OF TABLES.... 暂无评价 23页 免费 ...

TABLE of CONTENTS ACKNOWLEDGEMENT 3 LIST OF TABLES ....pdf

Almashary 12/1426 1/2006 TABLE of CONTENTS ACKNOWLEDGEMENT LIST OF TABLES LIST OF FIGURES SUMARRY (English) SUMMARY (Arabic) 1. 2. 3. 4. LITERATURE ...

Contents List of Tables................................pdf

2005 c Copyright by Patrick Christopher Frey 2005 Contents List of Tables ..... . . . 72 vi List of Figures 2.1 2.2 3.1 MonAtar, CUPID and ...

TABLE OF CONTENTS LIST OF TABLES.......................pdf

01, 2005 TABLE OF CONTENTS LIST OF TABLES . . . . . . . . . . .... . . . LIST OF FIGURES vii . . . . . . . . . . . . . . ...

TABLE OF CONTENTS LIST OF TABLES.......................pdf

Date Approved: August 18, 2005 TABLE OF CONTENTS LIST OF TABLES . .... . . . . Figure 41 The gap from capacity for a randomly punctured ...

Contents Organization iii List of Speakers iv List ....pdf

Contents List of Tables ... 暂无评价 65页 免费 Contents List of Symbols... 暂无评价 108页 免费 Contents List of Figures... 暂无评价 67页 免费 ...

网站首页 | 网站地图
All rights reserved Powered by 学霸学习网 www.tceic.com
copyright ©right 2010-2021。
文档资料库内容来自网络,如有侵犯请联系客服。zhit325@126.com