<?xml version="1.0" standalone="yes"?>
<Paper uid="W99-0803">
  <Title>Autosegmental Phonology in Pronunciation</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 What kind of interactivity?
</SectionTitle>
    <Paragraph position="0"> The second kind of question to be asked is: Why the Web? Interactive training tools are not limited to the Web; they have been distributed on floppy disk for over two decades, and on CD-ROM for over a decade. In phonetics, interactive operational models have a long history: audio I/O, visualisations as oscillogrammes, spectrogrammes, pitch traces and so on, have been leading models for multi-media in teacher training and speech therapy education since the 1970s. So why the Web? The answers are relatively straightfbrward: null  accessing the Web is (all but) universal (modulo minor implementation differences) in many ways: platform independent, exists in every office and many houles, ...</Paragraph>
    <Paragraph position="1"> The tools describe here embody three different approaches to the dependence of students on teachers with regard to the provision  of materials: 1. Server-side applications, realised with  standard CGI scripts: practically unlimited functionality, with arbitrary programming facilities in the background, but with inaccessible source code.</Paragraph>
    <Paragraph position="2"> 2. Compiled client-side applications, realised with Java: practically unlimited functionality, particularly with respect to graphical user interfaces, typically with inaccessible source code.</Paragraph>
    <Paragraph position="3"> 3. Interpreted client-side applications, realised with JavaScript: limited functionality with respect to graphical user interfaces, functionality limited to text manipulation and manipulation of HTML attributes (including CGI preprocessing), typically with immediately accessible code.</Paragraph>
    <Paragraph position="4"> From the formal point of view, these programming environments are equally suitable. From the (professional) programming point of view, the object oriented programming style of Java is often the preferred, homogeneous environment, though it is hard to relate it to other styles. CGI provides an interface for arbitrary programming languages, and scripting languages are highly relevant to linguistic tasks, particularly modern varieties such as perl, with respect to corpus tagging and lexicon processing, or Tcl to the visualisation of formal models or speech transformations. JavaScript is a pure client-side application, and has a number of practical advantages which outweigh many of its limitations: JavaScript is interpreted, not compiled, and the code is immediately available for inspection by the user; despite its sireplicity, it permits arbitrarily complex textual and numerical manipulation and basic window management; like other scripting languages, Javascript is not designed for modular programme development or library deployment, but is best restricted to small applications of the kind used in introductory work. There is another issue of interactivity at a very general level: in software development, perhaps less in the professional environment than in the training of non-professionals to understand what is 'going on under the bonnet', or to produce small custom applications: the open software, shared code philosophy. In the world 'outside' salaries are obviously dependent on measurable product output, and intellectual property right (IPR) regulations for shareware, licences and purchase are there to enable people to make a legitimate living from software development, given the prevailing structures of our society.</Paragraph>
    <Paragraph position="5"> As far as teaching is concerned, the debate mainly affects programmes with medium functionality such as basic speech editors or morphological analysers, often commercial, with products which can be produced in principle on a 'hidden' budget by a small group of advanced computer science or engineering students (hence the problem). Obviously, it is easy for those with in stable educational institutions to insist that software is common property; indeed it may be said to be their duty to provide such software, particularly in the small and medium functionality range.</Paragraph>
    <Paragraph position="6"> Finally, it is essential to consider design issues for interactive teaching systems, an area which has a long history in teaching methodology, going back to the programmed learning and language lab concepts of the 1960s, and is very controversial (and beyond the scope of the present paper). We suggest that the discussion can be generalised via the notion of TM space introduced above to conventional software engineering considerations: requirements spec~ifieation (e.g. specification of loca-tion in TM space by topic, course and student type), system design (e.g. control structures, navigation, windowing, partition of material, use of graphics, audio etc.), implementation (e.g. server-side vs. client side), verification (e.g. 'subjective', by users; 'objective', in course context).</Paragraph>
    <Paragraph position="7"> Only a small amount of literature is available on teaching tools; however, cf. (HH1999) {br speech applications, and the following for applications in phonetics and phonology (CB1998a), (CBG1999), English linguistics (CBG1997), and multimedia communication (G1997). The following sections will discuss a number of practical model-based applications: a basic database environment; an interpreter for deterministic finite automata; a development environment for phonotactic and orthographic processing; a testbed and scratchpad for introducing the DATR lexical representation language. The languages used are JavaScript (JS) for client-side applications, and Prolog (P) or C (C) for server-side CGI applications.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Database query interface
</SectionTitle>
    <Paragraph position="0"> generator Database methodology is an essential part of computational linguistic training; traditionally, UNIX ASCII databases have been at the core of many NLP lexical databases, though large scale applications require a professional DBMS. The example shown in Figure 1 shows a distinctive feature matrix (Jakobson and Halle consonant matrix) as a database relation, with a query designed to access phonological 'natural classes'; any lexical database relation can be implemented, of course. In  this JavaScript application with on-the-fly query interface generation the following functionality is provided: i. Input and query of single database relations. null 2. Frame structure, with a control frame and a display/interaction frame which is allocated to on-the-fly or pre-stored database information.</Paragraph>
    <Paragraph position="1"> 3. The control frame permits selection of: (a) a file containing a pre-compiled database in JavaScript notation, (b) on-the-fly generation of a query interface from the first record of the database, which contains the names of the fields/attributes/flolumns, (c) on-the-fly generation of tabular representation of the database, (d) input of databases in tabular form.</Paragraph>
    <Paragraph position="2"> 4. Query interface with selection of arbi- null JavaScript data structure: a one-dimensional array, with a presentation parameter for construction of the on-the-fly query interface.</Paragraph>
    <Paragraph position="3"> Typical applications include basic dictionaries, simple multillingual dictionaries, representation of feature structures as a database relation with selection of natural classes by means of an appropriate conjunction of query attributes and values.</Paragraph>
    <Paragraph position="4"> Tasks range from user-oriented activities such as the construction of 'flat' databases, or of feature matrices, to the analysis of the code, and the addition of further input modalities. Advanced tasks include the analysis of the code, addition of character coding conventions, addition of further database features.</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 DFSA interpreter
</SectionTitle>
    <Paragraph position="0"> There are many contexts in computational linguistics, natural language processing and spoken language technology in which devices based on finite state automata are used; for example, tokenisation, morphological analysis and lemmatisation, shallow parsing, syllable parsing, prosodic modelling, plain and hidden markov models. A standard component of courses in these disciplines is concerned with formal languages and automata theory. The basic form of finite state automaton is the deterministic finite state automaton (DFSA), whose vocabulary is epsilon-free and which has no more than one transition with a given label from any state. There are several equivalent representation converttions for DFSAs, such as a full transition matrix (Vocabulary x StateSet) with target states as entries; or sparse matrix representation as a relation, i.e. a set of triples constituting a subset of the Cartesian product StateSet x Stateset x Vocabulary; or transition network representation.</Paragraph>
    <Paragraph position="1"> The interface currently uses the full matrix representation, and permits the entry of arbitrary automata into a fixed size matrix. The example shown illustrates the language a'b, but symbols consisting of an arbitrary number of characters, e.g. natural language examples, may be used. A state-sequence trace, and detailed online help explanations, as well as task suggestions of varying degrees of difficulty are Fil~ l~clil Vlsw GO Wlrxlow Help I DFSAi~p~t:Ij~.. I-~ I~deg~l -~'~ Q~. ~abs~ ~ Q, set ot fia~l ~tatea Q: finite sC/~ o |~t~t~ D: umsi~ l+ancc+tion D Rom Q ~d g to Q, D: Q,V</Paragraph>
    <Paragraph position="3"/>
  </Section>
  <Section position="6" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5 Phonological NDFSA
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
development environment
</SectionTitle>
      <Paragraph position="0"> Phonology and prosody were the first areas in which finite state technologies were shown to be linguistically adequate and computationally efficient, in the 1970s; a close second was morphological alternations in the 1980s (CB1998a). The goal of this application is to demonstrate the use of finite state techniques in computational linguistics, particularly in the area of phonotactic and allophonic description for computational phonology. However, the tool does not contain any level specific information and can therefore be used also to demonstrate finite state descriptions of orthographic information. In this CGI application, implemented in Prolog (see (CBG1999)), the following functionality  is provided: 1. Display/Alter/Add to the current (nondeterministic) FSA descriptions.</Paragraph>
      <Paragraph position="1"> 2. Generate the combinations described in the FSA.</Paragraph>
      <Paragraph position="2"> 3. Compare two FSA descriptions.</Paragraph>
      <Paragraph position="3"> 4. Parse a string using an FSA description.</Paragraph>
      <Paragraph position="4">  Typical applications of this tool include descriptions of phonological well-formedness of syllable models for various languages. Tasks range from testing and evaluating to parsing phonological (or orthographic) FSA descriptions. More advanced tasks include extension of the current toolbox functionality to cater for feature-based descriptions.</Paragraph>
    </Section>
  </Section>
  <Section position="7" start_page="0" end_page="0" type="metho">
    <SectionTitle>
6 Zdatr testbed and scratchpad
</SectionTitle>
    <Paragraph position="0"> DATR is a well-known theoretically well-founded and practically oriented lexicon representation language. It also has a high ratio of implementations to applications, and, until relatively recently, a low degree of standardisation between implementations. In order to create a platform independent demonstration and practice environment, a CGI interface was created. The engine was intended to be a Sicstus Prolog application; Sicstus turned out to be non-CGI-compatible at the time (1995), so a UNIX shell version of DATR (mud, minimal UNIX DATR) was implemented using a combination of UNIX text stream processing tools, mainly awk. This  was later replaced by Zdatr Vl.n, and will shortly be replaced by Zdatr V2.0 (implemented by Grigoriy Strokin, Moscow State University). The Zdatr software is widely used in the teaching of lexicography, lexicology, and lexicon theory (Ginpress).</Paragraph>
    <Paragraph position="1"> Two interikces are driven by Zdatr: The testbed which permits interactions with previously defined and integrated DATR theories (CBG1999), and the scratchpad (shown in Figure 3), with which queries can be written and tested. The scratchpad permits the entry of short theories and queries, and the testbed has the following functionality:  1. viewing of DATR theories; 2. selection of manual, declared (#show and #hide) and pre-listed queries; 3. selection of output properties (trace, atom spacing).</Paragraph>
    <Paragraph position="2"> 4. a function for automatically integrating  new theories sent by email (not documented for external use).</Paragraph>
    <Paragraph position="3"> Sample DATR theories which are available include a detailed model of compositionality in English compound nouns (Gibbon), an application for developing alternative feature or autosegmental phonological representations (Carson-Berndsen), and a number of algorithm illustrations (bubble sort, shift register machine) for more theoretical purposes.</Paragraph>
  </Section>
class="xml-element"></Paper>