<?xml version="1.0" standalone="yes"?>
<Paper uid="C90-2014">
  <Title>Lexeme-based Morphology: A Computationally Expensive Approach Intended for a Server-Architecture</Title>
  <Section position="2" start_page="0" end_page="0" type="abstr">
    <SectionTitle>
1. Introduction
</SectionTitle>
    <Paragraph position="0"> In recent years computational morphology has been dominated by the so-called finite-state approach. The discussion about this approach was reportedly started in 1981 by a presentation of Kaplan and Kay at an LSA meeting in New York. it gained momentum after the publication of Koskenniemi's thesis (Koskenniemi 1983), which introduced the widely acknowledged two-level model. This model had several advantages: one of them was that it could be implemented on relatively small machines, i.e. it was extremely economical and effective from a computational point of view. As a result of this, it could be used and tested by a large number of research groups. The original model was modified in different directions in the course of the following years. Bear, for instance, proposed to increase the model's expressiveness by replacing the finite-state framework of the two-level model's lexicon system by a more powerful, unification-based formalism (Bear 86, 88). A similar proposal was conceived by Russell, Pulman, Ritchie, and Black (1986). Kay (1986/87) proposed to increase the formalism's expressiveness in order to make it suitable for nonconcatenative morphology. These and many other efforts also by Koskenniemi himself; see Kataja and Kosken~ niemi (1988) - were mainly directed towards an improvement of the model's capacity to handle different natural languages. An alternative approach was followed in the project which will be described in the following: here, the intention was not to maximize the system's capacity to handle different languages but to improve the original model's properties from the point of view of database theory. There were two reasons for this: firstly, our interest was limited to a restricted set of languages - primarily German, English, French, and Italian. Secondly, we felt that there was a great potential for improvements of the two-level model if it were redesigned on a somewhat 'larger' scale, i.e. for use on an environment of highly powered workstations linked by a local area network, and with design criteria derived fi'om database theory.</Paragraph>
    <Paragraph position="1"> According to our opinion, this latter claim proved to be correct in many respects; during the past few years, a cyclic prototyping process showed that the kind of system resulting fi'om the application of database design criteria had indeed a nmnber of advantages over the original two-level model. Naturally, these advantages had to be paid for, primarily in terms of size and complexity: the system which eventually emerged from this prototyping process, Word Manager. has therefore only remote affinity With the two-level model (as well as with most of the successor models that focussed on increasing the capability of handling different natural languages, for that matter). It is no longer 'small and beautiful', running on practically any personal computer, but complex and above all expensive as far as its memory requirements are concerned. The primary reason for this is that it follows what we like to call the lexeme-based al)proach to computational morphology, which we consider as an alternative to the so-called formative-based approach followed by the two-level model.</Paragraph>
    <Paragraph position="2"> The distinction between these approaches will be the focus of this paper. We will argue that the lexeme-based approach is advantageous in many respects and should therefore be considered as an alternative to the formative-based approach under certain conditions. The argument will proceed as follows: first, we will give an explanation of the terminology chosen for the alternatives. Then, we will proceed with a short description of Word Manager - an exhaustive description will be published in (Domenig 1990). The conclusion will point out the main differences between the two approaches.</Paragraph>
  </Section>
class="xml-element"></Paper>