Download (direct link):
sentence (Meaning) -> noun_phiase(X, VP, Meaning), verb _phrase(X,VP).
(Terms with a capital — “Meaning”, “X”, “VP” — are variable.)
In our example, “a man lives”, the noun-phiase ultimately yields the following result:
noun_phiase(X, lives(X), (exists(X): man(X)&lives(X))).
The trouble with such an analysis is that the meaning of the noun-phiase has become involved with the meaning of the whole sentence. We cannot extract the meaning of the noun-phrase for purposes of ISA anaphora Thus with such a translator we could not use the context to deal with a follow-up query such as;
“Which American ship is nearest Dublin?”
“Which is nearest Norfolk?”
because we would have no available meaning for the anaphor, “which [American ship] ”, in the second query This problem is discussed in 
8.5 General Remarks
We conclude that an NLU requires a high level query language, and that the structure of the language should enable it to represent the ‘meaning’ of such grammatical constructions as — noun-phiases, verb-phiases, etc. As a general guide we should want it to be able to represent any structure that can be ana-phorically referred to.
On the other hand the query language must have all the properties of formal languages:
— A computer (database) oriented vocabulary
— No ambiguities
— Semantic functions that are not dependent on a broader context
— Rigorously defined semantics
NATURAL LANGUAGE ENQUIRY 43
Therefore all syntactic links in the natural language query must be given a rigorous semantic interpretation before attempting to generate formal queries. This involves semantic checks which tie:
— adjectives and classifiers to the head noun they modify
— qualifiers and relative clauses to the head noun, or noun phrase, they modify
— direct and indirect objects and adverbial clauses to the verbs they modify.
It also involves resolving anaphora and finding the referents of definite noun-phrases It is unnecessary, however, to do any more than this, since further processing simply complicates the NLU
Thus we would require the formal language to embody enough intelligence to
(1) Manipulate the parse tree
(2) Deal with non-pragmatic aspects of reference, negation and quantificationf.
(3) Generate the necessary procedure calls for extracting the information from the database.
9. DBMS INDEPENDENCE
Because the data model imposes structural restrictions on the NLU it is impossible to create a genuinely portable natural language interface. Particularly in systems such as REL and INTELLECT where the NLU extracts semantic information from the database, the very grammatical analysis must be tailored to the concepts of the data model.
DBMS independence can be obtained by using a high-level data model which maps onto a range of data structures. Thus INTELLECT and EUFID use a high-level query language as an interface which can be tailored to different databases.
Another solution to DBMS independence is that of LIFER. When attached to a particular body of information, such as naval data, English queries are translated into high-level formal queries about ships, etc. The application-oriented query language can be interpreted onto a range of different databases. Thus the LADDER system is able to use a distributed database with a different DBMS at each node, PLANES uses registers to store the meaning of a query, The query translator simply extracts these meanings and yields a formal database query. This enables the PLANES parser to be free of the structural restrictions of its DBMS, However, the fixed set of registers does restrict the range and complexity of possible queries whatever the power of the query language itself.
10 TOPIC INDEPENDENCE
Both PLANES and the LADDER grammar are “semantic grammars” which must be rewritten for each database. It would appear, however, that given a new set of
f There is not, we confess, a clear distinction between semantics and pragmatics The force of “non-pragmatic” here is that the evaluation of a formal query should not be subject to dispute (“That is not what the query meant . . .”)
44 NATURAL LANGUAGE ENQUIRY
subnets, the overall design of the PLANES parser could be carried over to any field of information.
The attempt to create parsers for English which are purely syntactic has largely been abandoned. Second generation language systems (Wilks ), all utilise the meanings of words during the parsing process.
A second-generation, topic-independent parser can be built by utilising a generalised semantic system such as Wilks’s preference semantics  or Schank’s conceptual dependency . Two NLUs for database enquiry have been built around preference semantics, one at IBM, Bari  and one, still under construction, at Cambridge University  . The task of tying a preference system to a database vocabulary is very difficult and complicated.
A more economical, though less powerful, solution is to extract the necessary semantics from the database (REL, INTELLECT, EUFID), However, there is never enough semantic information in the database. In the first place databases often use codes (e.g. “m” for male, “f” for female). The English equivalent for such codes must be added, by hand, to the dictionary. More serious problems, such as English verbs (section 3.3 above) require more work in adapting the NLU to the interface. It appears that the more work done in adapting an NLU to a new topic the better the resulting English language coverage.