in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Designing for human-computer communication - Sime M.E.

Sime M.E. Designing for human-computer communication - Academic Press, 1983. - 350 p.
ISBN 0-12-64-3820-X
Download (direct link): desingforhumancomputer1983.djvu
Previous << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 141 >> Next

What does the “non-procedural revolution” have to do with natural language programming? The current capabilities of systems like INTELLECT are subsets of the functionality of the existing nonprocedural systems. There was a time when the non-procedural systems were limited to only database query and simple report generation. The original non-procedural system, MARK IV, fits this description. The natural language technology, at least as embodied in INTELLECT, completely encompasses this capability today. In the meantime, of course, the newer non-procedural systems have gone beyond query and simple reporting to data input, hierarchical structures and more complex reporting. This new set of capabilities has already been proven sufficient to cope with a wide variety of intricate data processing applications. The immediate goals for the development of the INTELLECT system are to allow a larger amount of this new functionality to be expressed in natural language instead of a formal language. In as much as this is possible, INTELLECT will allow “natural language programming” for these same applications that are currently amenable to non-procedural programming.
It may not be necessary or even desirable to express all the nonprocedural functions in natural language. For example, high volume data input may be best specified by a for mal language, since the frequency of the alteration of the input format is very low compared to the frequency of its use. The general trend I .am predicting is first, that non-procedural languages will continue to grow both in capability and in widespread acceptance; and secondly, that natural language technology will track this development. Within this scenario I think we can expect to see a substantial amount of “natural language programming” in the not-too-distant future.
j Advantages of natural language programming
|V. Conclusion
It is all too easy to look at the complexity and intricacy of dealing with natural language and become overwhelmed. It is truly a difficult problem that will require many more years of research to solve, if it is ever completely solved. But we should not be so overwhelmed that we become pessimistic about the feasibility of all natural language applications. In this chapter we have tried to show that there is, in fact, good reason to be optimistic about the future of natural language processing. Having just cleared the first important hurdle, database query, this is not the time to despair, but the time to consider the implications of this new technology and plan new ways to take advantage of it in the design of future systems. The use of natural language will set new standards for the easy use of computers.
4. TEIRESIAS: experiments in communicating with a knowledge-based system
Massachusetts Institute of Technology, Cambridge, Massachusetts, USA
I. Introduction
In this chapter we view communicating with computer s in the light of three motivations:
knowledge acquisition.
Transparency is a measure of a program’s comprehensibility. A “black box”, all of whose internal workings are hidden, is the least transparent type of system. We examine some mechanisms that allow a user to “look” inside the machinery of a program to discover both what it is doing and why. This sort of capability offers advantages in terms of both user-acceptance (people ar e far more likely to accept what they can understand), and possible educational benefit (they may learn from seeing how the program works).
Debugging is of course an inevitable part of constructing a program, and most debugging tools have been designed by programmers for their own use. But what would a debugging tool look like if it were designed instead for use by the user community? We consider here the design and implementation of a facility that allows non-programmers to track down the source of a certain class of bugs in an application program.
Having discover ed a bug, it would of course be nice to have a facility that allowed the user to correct it. Our concept of knowledge acquisition includes
DESIGNING FOR HUMAN-COMPUTER COMMUNICATION Copyright © 1983 by Academic Press London
ISBN 0 12 643820 X All rights of reproduction in any form reserved
the idea of giving the user a mechanism for adding to (or modifying) the program’s store of information in order to improve its performance.
In this chapter we examine the mechanics of setting up communication facilities to achieve these goals. We examine the kinds of communication that are necessary and describe in some detail the machinery we have implemented to make such communication possible.
II. Background
This work has been done in the context of efforts to design and implement a computer-based consultation system. The system is intended to supply near expert-level advice on difficult cognitive problems, and is designed to interact with two classes of user: (a) naive users who are acquainted with the domain of application but are not necessarily skilled in it, and who are requesting advice or instruction; and (b) experts using the system in order to challenge it, uncover weaknesses, and correct those problems by augmenting or revising the system’s knowledge about the domain.
Previous << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 141 >> Next