The “Whiteboard” Architecture: A Way to Integrate Heterogeneous Components of NLP Systems

THE "WHITEBOARD" ARCHITECTURE: A WAY TO INTEGRATE HETEROGENEOUS COMPONENTS OF NLP SYSTEMS Christian Boitet Mark Scligman GETA, IMAG (UJF & CNRS), 150 rue de la Chimie, BP 53 38041 Grenoble Cedex 9, Fr,'mce Christian .Boitet@imag. fr NI'R Interpreting Teleconununicafions Research Labs 2-2 ltikari-dai, Seika-cho, Somku-gun Kyoto 619-02, Japan seligman@it i. atr. co. jp ABSTRACT We present a new softw,'u'e architecture for NLP systems made of heterogeneous components, and demonstrate an architectural prototype we have built at ATR iu the context of Speech Translation. KEYWORDS: Distributed NLP systems, Software architectures, Whiteboard. INTRODUCTION Speech translation systems must integrate components handling speech recognition, machine translation and speech synthesis. Speech recognition often uses special hardware. More components may be added in the future, for task understanding, multimodal interaction, etc. In more traditional NLP systems, such ,'cq MT systems for written texts, there is also a trend towards distributing various tasks on various machines. Sequential ,architectures [10, 11] offer ,an easy solntion, but lead to loss of information and lack of robustness. On the other hand, reports on experimenls with blackboard architectures [16, 13, 20] show they also have problems. We ,are exploring an intermediate architecture, in which components are integrated under a coordinator, may be written in various programming languages, may use their own data structures and algorithms, and may run in parallel on different machines. The coordinator maintains in a whiteboard an image of the input and output data structures of each component, at a suitable level of detail. The whitehoard fosters reuse of partial results and avoids wasteful recomputation. Each component process is encapsulated in a manager, which transforms it inlo a server, commuuicating with external clients (including the coordinator) via a system of mailboxes. Managers handle the conversions between internal (server) and external (client) data formats. This protocol enhances modularity and clarity, because one needs to to explicitly and completely declare fl~e appearance of the partial results of the components on the whileboard. Managers may also make batch components appear :is incremental components by delivering outputs in a piecewise fashion, thus taking a first step towards systems simulating simultaneous translation. We have prc~luced a rudimentary architectural prototype, KASUGA, to demonstrate the above ideas. In fl~e first section, our four main guidelines ,are detailed: (1) record overall progress of components in a whiteboard; (2) let a coordinator schedule the work of components; (3) encapsnlate components in managers; and (4) use the managers to simulate Incremental Processing. In the second section, some high-level aspects of the KASUGA prototype ,are first described, and a simple demonstration is discnssed, in which incremental speech translation is simulated. Lower-level details are then giveu on some internal aspects. I. TIlE WII1TEBOARD ARCHITECTURE 1. Record overall progress in a whitelmard The whiteboard ,architecture is inspired by the chart architecture of the MIND system [8] and later systems or formalisms for NLP [1, 5], as well as by the blackbo~u'd architecture, first introduced in HEARSAY-II [6, 13] for speech recognition, llowever, there is a significant difference: tile components do not …

Content truncated to 500 words