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

Communicating with Databases in Natural Language - Wallace M.

Wallace M. Communicating with Databases in Natural Language - Ellis Horwood Limited, 1985. - 170 p.
Download (direct link): comumunicatingwthisdatabase1985.djvu
Previous << 1 .. 40 41 42 43 44 45 < 46 > 47 48 49 50 51 52 .. 59 >> Next

The second major extension is to program the NL front end to use language as a way of achieving a conversational goal (satisfying the user’s requirements) rather than simply to understand questions and statements Such a front end takes the user’s natural language query as a starting point in a chain of reasoning
which attempts to assess what the usei really meant and what he might have asked had he known a bit more about the database.
Finally, there is an obvious need to connect an NL front end to a range of software to enhance the man—machine inteiface and to augment the database access component.
For user input the extra software will enable the user to point to objects as well as naming them Natural language may well be used to augment menu systems for certain applications. In the longer term NL front ends may be integrated with voice recognition software to produce a single module which will “understand”, at some level, spoken language
Foi user output, NL systems such as INTELLECT aiealieady being integrated with graphics packages. Thus instead of results being output as a table they can be expiessed as a pie chart 01 histogiam Of course natural language generation is a necessary part of an NL front end, but in current systems the NL output is very simple. Surprisingly NL input and NL generation are really quite distinct tasks and it is possible that separate NL generation packages will be giafted onto NL front ends in the futuie
Foi database access a number of enhancements can be made by utilising othei software. The most immediate application is for statistical processing of the data, (INTELLECT again offers an interface to such packages, indicated in the natural language input by a single keyword which indicates the required processing). In the longer term the database access component will be augmented by a reasoning system which will be able to deduce answers from the given data. (In a current laboratory system this component deduces the distance between two ships from their current positions, and works out how long it will take them to rendezvous from their respective cruising speeds.)
Current natural language systems run on centralised database systems maintained by a support team An end user of a natural language front end uses standard terminals through which he generally has to log in to the operating system and call up the NL enquiry system, before starting to use natural language.
Clearly the near futuie will see terminals directly connected to specific programs, and NL enquiry will be a prime candidate. Thus the terminal in the personnel manager’s office will automatically connect to an NL front end for the personnel database as soon as he switches on and types his password.
Another development already in hand is to put an NL front end onto an intelligent terminal, so that the NL analysis is done at the terminal and only the database calls are passed up the line to the mainframe computer. An important prerequisite for this type of facility is that the NL system must be able to make sensible guesses at the meaning of unknown words Such words are likely to represent data values occurring in the database, but it would be impossible to store all such words in a vocabulary on the terminal, and inappropriate to send a
special seaich command to the mainframe to confirm the appearance in the database of each unknown word.
The final development will be the introduction of complete natural language database systems which will run on a microcomputer These will be used for personal databases created, updated and maintained by the end user. Surprisingly, perhaps, these are in many ways easier to build than natural language front ends
because the database structures are designed to support the exact meaning
representations generated by the NL analyser.
The systems cunently in existence (e.g. [48]) work on binary relations and allow the user to define new relations by a simple dialogue
Q “Create the attribute : colour”
A “The attribute colour has been added”
Q “Individuals: white, blue, black, grey”
A “The following individuals have been added: white blue black grey”
When a manager has a personal NL database system on his own microcomputer, he will be able to add information to the database using natural language. Although entered randomly the system will be able to retrieve the data sorted and correlated in any way he wants by merely expressing his requirements in his natural language.
Appendix 1
A pilot implementation
This book has described the architectuie of a natural language enquiry system. The development of the design was continually checked by programming, and the practical result was a pilot QPROC system that implemented most of the designed features. The pilot system lacked:
(1) any implementation of context,
(2) comparisons, other than “=”.
However, it served well to demonstrate the possibilities of QPROC and was adapted to three databases: an expanded version of the election database, the COPSE database and an archery database designed by W, Pitkin, The system was written completely in the PROLOG language, and it included four modules.
Previous << 1 .. 40 41 42 43 44 45 < 46 > 47 48 49 50 51 52 .. 59 >> Next