Natural Language Interfaces to Databases - An Introduction

• An NLIDB lets users access database information by typing requests in a natural language such as English.Source: §1 · p. 1
• A Loqui dialogue illustrates linked follow-up questions, including a short reference to a previously mentioned choice.Source: §1 · pp. 1–2
• The paper introduces key NLIDB concepts and research lines, but does not provide complete descriptions or comparisons of particular systems.Source: §1 · p. 2
• Its coverage runs from NLIDB history and linguistic problems to architectures, portability, restricted input, reasoning, less-explored topics, and the state of the art.Source: §1 · p. 2

2 Some history

• Late-1960s and early-1970s systems such as Lunar were built for particular databases and were not easily adapted to others.Source: §2 · p. 2
• Late-1970s Ladder could be configured for different DBMSs, but its semantic grammars required new grammars for new applications and proved difficult to port.Source: §2 · pp. 2–3
• Chat-80 translated English into Prolog and its widely circulated code informed later systems, while Team targeted easy configuration by database administrators.Source: §2 · p. 3
• Ask connected natural-language access to built-in and external applications, while Janus integrated heterogeneous systems and supported temporal questions.Source: §2 · p. 3
• Although commercial NLIDBs appeared, they remained research or exotic systems rather than widespread standard database interfaces.Source: §2 · p. 3
• Object-oriented databases and more complex relational storage structures could make NLIDBs harder to produce, while generic language front-ends could be connected to database evaluators.Source: §2 · pp. 4–5

Some advantages of NLIDBs

• Native-language input avoids learning an artificial interface in principle, but current NLIDBs accept limited subsets and still require users to learn which questions they handle.For some users, identifying an NLIDB's coverage may be harder than learning a formal query language or another interface.Source: Some advantages of NLIDBs · p. 6
• Natural-language queries can express negation and universal quantification more easily than most graphical or form-based interfaces, while discourse context supports brief anaphoric or elliptical follow-ups.Examples include asking which department has no programmers and which company supplies every department.Source: Some advantages of NLIDBs · p. 7

Some disadvantages of NLIDBs

• Users may misread coverage limits, confuse linguistic with conceptual failures, and assume reasoning abilities that most NLIDBs lack.Some systems attempt to clarify why a question cannot be handled with diagnostic messages.Source: Some disadvantages of NLIDBs · pp. 7–8
• Natural-language input can be verbose and ambiguous, and NLIDBs usually require lengthy configuration unlike built-in formal-query interpreters or largely automated form interfaces.Graphical interfaces can rely largely on mouse input.Source: Some disadvantages of NLIDBs · p. 8
• None of the three interfaces was a winner; performance was roughly similar on most queries, while NLIDBs seemed better on many-table queries and queries unlike training examples.The comparison involved 55 subjects using SQL, SunSimplify, and Datatalker/Natural Language.Source: Some disadvantages of NLIDBs · p. 8
• Intellect usability findings characterize NLIDBs as effective for casual users with good database knowledge doing restricted-domain question answering [18], while another study calls them a practical alternative.The paper reports these findings from usability experiments, not as a comparison of particular NLIDBs.Source: Some disadvantages of NLIDBs · pp. 8–9

4 Linguistic problems

• The survey is illustrative rather than exhaustive, and notes that these challenges also occur in natural-language-understanding systems generally.Source: §4 · p. 9

4.1 Modifier attachment

• Modifier attachment can yield competing readings; domain knowledge may distinguish them, while genuinely ambiguous cases can be presented as paraphrases or answers labeled by reading.Pre uses a rightmost-attachment heuristic for relative clauses.Source: §4.1 · pp. 9–10

4.2 Quantifier scoping

• Quantifier scope changes whether students may take different courses or must share one; proposed heuristics prefer left-to-right order or give stronger determiners wider scope.For “every student” and “some course,” both heuristics favor the reading allowing different courses.Source: §4.2 · p. 10

4.3 Conjunction and disjunction

• “And” can mean “or” when conjunction is conceptually impossible, but can remain ambiguous; Eufid and Parlance may convert it or return answers for both readings.The examples contrast applicants who cannot live in two states with cases where “and” has two plausible readings.Source: §4.3 · pp. 10–11

4.4 The nominal compound problem

• Noun-noun and adjective-noun compounds have context-dependent meanings; some systems require each possible modifier combination to be configured explicitly.For example, “large department” must be defined in terms of the underlying database concepts in Ldc-1.Source: §4.4 · p. 11

4.5 Anaphora

• Anaphora links pronouns and noun phrases to discourse entities; resolution can favor recent entities satisfying grammatical and semantic constraints, while echoing an interpretation lets users spot misresolution.The example shows a system replacing a pronoun with its understood meaning in the echoed question.Source: §4.5 · pp. 11–12

4.6 Elliptical sentences

• Elliptical follow-ups rely on prior context, so requiring each query in full burdens exploration; Xcalibur uses discourse-expectation and contextual-substitution rules.Some systems, such as Chat-80, focus on stand-alone questions and do not support elliptical questions.Source: §4.6 · p. 13

4.7 Extragrammatical utterances

• Everyday requests may contain misspellings or ill-formed input, but existing NLIDBs handle only simple cases, including dropped articles, agreement errors, capitalization, punctuation, and spelling.Ask also corrects spelling and missing-space errors.Source: §4.7 · pp. 13–14

5.1 Pattern-matching systems

• Pattern matching is simple and can return reasonable answers outside its designed patterns, but shallow interpretation can cause serious errors, as illustrates.A system mistook “in” in a request about employees in Los Angeles for Indiana’s postcode and reported employee states.Source: §5.1 · pp. 14–15

5.2 Syntax-based systems

• Syntax-based systems parse questions and map parse trees to database queries, but direct mapping to real-life languages such as SQL is difficult.They usually rely on application-specific database query languages designed to facilitate this mapping.Source: §5.2 · pp. 15–16

5.3 Semantic grammar systems

• Semantic grammars encode domain knowledge to enforce semantic constraints and guide database-table selection, but require a new grammar for each domain.The paper notes that a grammar built for specimens is useless for an employee-and-salary application.Source: §5.3 · p. 17

5.4 Intermediate representation languages

• Intermediate-representation systems map parsed input to a high-level logical query, then translate it into the database’s query language; syntax rules may be domain-independent while lexical information is domain-dependent.The semantic interpreter uses a lexicon and, in some systems, a world model to represent domain classes and predicate-argument constraints.Source: §5.4 · pp. 17, 18, 19, 21
• World-model hierarchies and predicate-argument constraints can flag class mismatches, such as asking for clients’ salaries, and rule out an ambiguity that assigns a driving licence to a company.The same constraints allow a technician’s salary query because technician is a subclass of employee.Source: §5.4 · pp. 19–21
• As supported natural-language coverage grows, some queries may exceed single SQL queries; systems must restrict input or run multiple queries and combine their answers, with iteration or recursion handled by the NLIDB.SQL lacks constructs such as iteration and recursion, while full natural language is more expressive than a single SQL query.Source: §5.4 · pp. 22–23
• Logical intermediate representations decouple linguistic front ends from DBMS-specific query generators, supporting DBMS portability, reusable front ends, and added reasoning modules.The database query generator can be rewritten when porting to a different DBMS; reasoning modules can operate between semantic interpretation and query generation.Source: §5.4 · p. 23

5.5 Response generation

• Response generation must go beyond printing tuples: it may need to explain failures, flag false presuppositions, and answer yes/no questions with useful additional information.In the Loqui examples, the system reports a false presupposition and provides information beyond yes/no answers.Source: §5.5 · pp. 23–24
• Paraphrasing reconstructed queries can help users detect misinterpretations, while response formatting can expand encoded data and some systems can display results graphically.Tqa presents a natural-language reconstruction of the SQL query; Natural Language can present some retrieved data in graphics such as pie charts.Source: §5.5 · p. 24

5.6 Multiple underlying systems

• Intellect can transparently query heterogeneous databases through separate DBMS queries, then collect and join partial results into one answer.Source: §5.6 · p. 25
• Ask routes natural-language requests to appropriate software systems, while Janus can combine databases and expert systems to answer a question.Source: §5.6 · p. 25

6.1 Knowledge-domain portability

• Knowledge-domain reconfiguration typically teaches the system new words and concepts and their database mappings, with the work assigned to users with different levels of technical expertise.Depending on the system, configuration may involve programmers, knowledge engineers, database administrators, or end users.Source: §6.1 · pp. 26–27
• Morphology modules can derive word forms from stems and rules, reducing manual entry of forms, while configurable built-in dictionaries can include domain terminology.Deriving forms is particularly important for highly inflected languages.Source: §6.1 · p. 26

6.2 DBMS portability

• With an intermediate representation, a new DBMS may require only a rewritten query-translation module; shared query languages can allow minor modifications, while systems without an intermediate representation may need extensive changes.A separated linguistic front-end may remain unchanged when the new DBMS contains data in the same knowledge domain.Source: §6.2 · p. 28

6.3 Natural language portability

• Changing an NLIDB to another natural language can be difficult because language assumptions may be embedded in it; systems using the described architecture typically require changes to syntax rules, semantic rules, and the lexicon.The paper cites attempts at Portuguese Chat-80 and a Swedish version of CLE.Source: §6.3 · p. 28

6.4 Hardware and programming language portability

• Portability across hardware and programming languages was once hindered by systems limited to expensive research computers and specialized languages; low-cost computers and widely available Prolog and Lisp later eased it.Source: §6.4 · p. 28

7 Restricted NL input

• Explicitly restricting allowable expressions makes system limits clear to users and can simplify NLIDB design.The paper contrasts this with attempts to expand linguistic coverage.Source: §7 · pp. 28–29

7.1 Restricted NL syntax

• Pre rejects questions where a conjoined relative clause is followed by a nested clause, as its pattern does not allow that structure.The example's final clause refers to an entity in the preceding conjoined clause rather than to the earlier nested-clause target.Source: §7.1 · p. 29
• Pre permits a specific question pattern whose noun phrases select reported attributes, nested clauses traverse relations, and conjoined clauses filter entities.The pattern is designed to support mapping questions to navigation graphs and is claimed to be easy to remember and to clarify what the system can answer [40].Source: §7.1 · pp. 29–30

7.2 Menu-based systems

• Nlmenu continuously updates word and phrase menus from the grammar of the partial sentence, allowing only understandable sentences while letting users browse supported questions.It is typically customized for a new application in 1–30 man-hours; menu searching can become tedious for long questions, though it avoids spelling errors and supports pointing-device input.Source: §7.2 · pp. 31–32

8.1 Reasoning about the world

• Reasoning modules use domain knowledge to answer questions whose answers are not explicitly stored, and can reason from database facts using rules.The paper argues that this reasoning should be an independent layer available to NL and graphical interfaces, rather than code belonging only to an NLIDB.Source: §8.1 · pp. 32–34

8.2 Reasoning about the user’s goals

• Reasoning about user goals can prevent an inappropriate response by preserving a likely destination goal while relaxing a carrier preference.For a request about an American Airlines flight to Dallas, the proposed rules drop the carrier constraint rather than the destination constraint when both cannot be satisfied.Source: §8.2 · p. 35

8.3 Dialogue systems

• Dialogue-oriented systems are driven by a controller that reasons about user and system goals and beliefs, rather than by processing each question in isolation.The controller uses rules to guide the dialogue, while interpretation, generation, and world-reasoning modules handle messages and information retrieval.Source: §8.3 · pp. 36–37

9.1 Database updates

• Natural-language updates can be ambiguous or cause unintended side effects because users may not know database constraints; Piquet ranks interpretations using a model of the user's database view.Among candidate interpretations, its heuristics prefer those causing fewer side effects with respect to that view.Source: §9.1 · pp. 38–39

9.2 Meta-knowledge questions

• Meta-knowledge questions ask what is known or what the system can handle; modal questions ask whether something can or must be the case.Examples include asking what information is in the database or whether an employee can earn more than a manager.Source: §9.2 · p. 39

9.3 Temporal questions

• Most NLIDBs target snapshot databases and present-state questions, while temporal questions are limited by temporal-language semantics and the handling of time-dependent information.The paper notes research on interfaces to temporal databases, which are designed to store past or future states and support time.Source: §9.3 · p. 40

9.4 Multimodal interfaces

• Shoptalk combines language, forms, menus, and pointing so users can express quantification in language and specify locations graphically.Its form-filling also helps distinguish modifiers, such as the object location from the destination description.Source: §9.4 · pp. 40–41

• The survey outlines typical systems and central issues but is incomplete; most systems discussed are exploratory, and academic interest has waned since the 1980s.Source: §10 · pp. 42–43
• Without standard benchmarks, appraisals of the field remain impressionistic and subjective because evaluating a complete NLIDB is complex.Source: §10 · p. 42
• Areas such as dictionaries and parsing have seen substantial research and development, and practical modules can be constructed fairly straightforwardly.Source: §10 · p. 42
• Even relatively well-understood areas lack an agreed theory or technique, while other aspects retain difficult theoretical problems.Source: §10 · pp. 42–43
• Commercial systems may support database queries in English, but their availability does not mean completely unrestricted natural-language querying is solved.Source: §10 · p. 43
• Keyboard-only NLIDBs are unlikely to be highly practical long term, but remain testbeds for techniques such as semantic interpretation.Source: §10 · p. 43