The Design of the Kernel Architecture for the Eurotra Software

THE DESIGN OF THE KERNEL ARCHITECTURE FOR THE EUROTRA* SOFTWARE R.L. Johnson**, U.M.I.S.T., P.O. Box 88, Manchester M60 IQD, U.K. S. Krauwer, Rijksuniversiteit, Trans 14, 3512 JK Utrecht, Holland M.A. RUsher, ISSCO, University of Geneva, 1211 Geneve 4, Switzerland G.B. Varile, Commission of the European Conm~unities, P.O. Box 1907, Luxembourg ABSTRACT Starting from the assumption that machine translation (MT) should be based on theoretically sound grounds, we argue that, given the state of the art, the only viable solution for the designer of software tools for MT, is to provide the linguists building the MT system with a generator of highly specialized, problem oriented systems. We propose that such theory sensitive systems be generated automatically by supplying a set of definitions to a kernel software, of which we give an informal description in the paper. We give a formal functional definition of its architecture and briefly explain how a prototype system was built. I. INTRODUCTION A. Specialized vs generic software tools for MT Developing the software for a specific task or class of tasks requires that one knows the structure of the tasks involved. In the case of Machine Translation (MT) this structure is not a priori known. Yet it has been envisaged in the planning of the Eurotra project that the software development takes place before a general MT theory is present. This approach has both advantages and disadvantages. It is an advantage that the presence of a software framework will provide a formal language for expressing the MT theory, either explicitly or implicitly. On the other hand this places a heavy responsibility on the shoulders of the software designers, since they will have to provide a language without knowing what this language will have to express. We are grateful to the Commission of the European Communities for continuing support for the Eurotra Machine Translation project and for permission to publish this paper; and also to our colleagues in Eurotra for many interesting and stimulating discussions. ** order not significant There are several ways open to the software designer. One would be to create a framework that is sufficiently general to sccomodate any theory. This is not very attractive, not only because this could trivially be achieved by selecting any existing programming language, but also because this would not be of any help for the people doing the linguistic work. Another, equally unattractive alternative would be to produce a very specific and specialized formalism and offer this to the linguistic community. Unfortunately there is no way to decide in a sensible way in which directions this formalism should be specialized, and hence it would be a mere accident if the device would turn out to be adequate. What is worse, the user of the formalism would spend a considerable amount of his time trying to overcome its deficiencies. In other words, the difficulties that face the designer of such a software system is that it is the user of the system, in our case the linguist, who knows the …

Content truncated to 500 words