next previous contents
Next: A KBAS for technical Up: Case study: KBAS-TW Previous: Case study: KBAS-TW

General overview

Today, more technical documentation has to be produced and translated in a shorter time because of the massive increase in technological developments and innovations. The knowledge about a product in the form of complete and reliable information (general information, user manual, reference manual, etc.) has to come with the product, otherwise the product will have have no real chance on the market. From a consumer's point of view, a bad product manual counts as a serious shortcoming of the product. Product documentation and user manuals often do not fulfill the basic requirements of user-oriented presentation and information reliability. This is due to professional, organisational and technological weaknesses in the production process of the documentation. Better results in the production of this type of knowledge are required. Technical documentation becomes a better knowledge and information product if more know-how is invested in its production.

Currently, no tool assists the technical writer or the translatorgif in a coherent way during all document development stages and, in particular, at the level of a document's domain of discourse. To some extent, recent developments in the field of terminological knowledge bases may support the technical author in this respect (cf. (Meyer92) and (Schutz93)), however, functionalities of content related operations still remain poor. One estimate of current tools in the field of desktop publishing is that they are effective for only 20 of consumer instructions and 8 of manuals (cf.for example (Hofmann92)). Today, the computer-assisted organisation of technical documentation and translation as an integral part of the documentation process is still in its infancy. There is a need for tools that permit the technical writer to acquire, store, up-date, edit, etc., product and document related information and knowledge. Thus, a better tool is needed: a workbench for technical writers which integrates different tools into a documentation environment.

We have to make a distinction between technical writing and general text editing. Professional writing is quite rich in its methodological knowledge; by the mere effect of routine and professional competence, professional writers dispose of more ready-made methods, rules and patterns than non-professionals. The task-related knowledge of a technical writer may be formalisable, but often is only implicit. This means that, in order to design and specify a workbench for technical documentation, an analysis of the tasks of a technical writer has to be done; as far as we know, such an analysis has not been done until now (cf.below).

We have to bear in mind that different kinds of knowledge are involved in these tasks. Knowledge-based systems (KBSs) are powerful means to manage heterogeneous types of knowledge. Normally, a KBS supports and solves a task in a domain where knowledge can be represented in a compiled expression that is efficient for the task. In our scenario, we have the problem of separating domain knowledge from knowledge about various tasks. However, these types of knowledge are heavily interrelated. For example, acquisition, explanation and validation tasks can be seen as general tasks, but they rely on domain-specific knowledge which may then trigger the tasks in specific ways. Thus, the user should have the possibility to tailor a knowledge base to his specific needs.

Certainly, there are difficulties for such a KBS to reach an industrial stage. Problems occur because, in practice, substitutions are similar but not identical. It is necessary to configure automatically a KBS to have clones of the initial KBS. These systems act like a knowledge configurator that is used by the user himself to tailor the KBS to his specific needs. In such a case the user is an expert. The user and the knowledge based assistant system (KBAS) may profit from each other. The man-machine interaction for acquiring and refining knowledge extends the role of expert systems to expert supporting systems. On top of all this, knowledge is volatile and evolves as projects evolve. Thus, the KBAS will not be a `single-use' system. It will be used for maintenance and updating in an endless process of knowledge acquisition.

In a company, knowledge is accumulated over many years and it may not be available in any form directly tractable by computational means. Thus, the recovery of this knowledge is a task of extreme importance. It is becoming increasingly urgent to share knowledge sources among applications that can use them in different ways. A natural approach considers that the central repository would be managed with various tools, each applicable to and manipulating some part of the knowledge and information stored within the repository.


next up previous contents
Next: A KBAS for technical Up: Case study: KBAS-TW Previous: Case study: KBAS-TW

ceditor@tnos.ilc.pi.cnr.it