Semantic Parsing and Meaning Representations

A language model can answer a question in fluent English. But sometimes the useful output is not another sentence. It is a database query, a logical formula, a graph, or a program that a machine can check, execute, or reason over. If you ask, "Which departments have more than two enrolled students?", a helpful answer might be a list of department names. A more useful and inspectable answer might be a SQL query that computes that list from your actual database.

A stored answer may become stale when the database changes. A query records a procedure that can be executed against a new snapshot and checked against expected rows. Producing that query separates the interpretation of the question from the computation of the answer.

Semantic parsing is the task of turning natural language into a formal meaning representation. The representation might be first-order logic, a lambda-calculus expression, an Abstract Meaning Representation (AMR) graph, a SQL query, a regular expression, or a sequence of API calls. What ties these together is that the output has a syntax and a semantics. The syntax tells you what expressions are well formed. The semantics tells you what those expressions mean. For example, a formula can denote a truth value, a SQL query a result table, and an executed program an output.

The phrase "meaning representation" is deliberately broad. The target depends on the task. Formal-semantic analyses can use logical formulas and model-theoretic truth; computational-linguistic meaning representations include AMR graphs, frame-based structures, and logical forms. Database interfaces can target SQL, task-oriented assistants can produce API calls, and planning systems can use action sequences and state transitions. These targets have explicit formation rules and an intended interpretation. Executable representations additionally specify how to evaluate or run the structured object.

This chapter builds on the semantic ideas from Part VIII: Semantics and Information Extraction. Earlier, we treated word senses, sentence meaning, semantic roles, relations, events, and entity linking as separate problems. Here we connect them. A semantic parser must decide what the words mean, how they combine, what entities and relations they refer to, and what formal object the whole utterance denotes. The chapter also builds on tokenization from Part V: Subword Tokenization and syntax from Part VII: Linguistic Form: Morphology and Syntax. Formal representations do not remove the need for linguistic analysis. They make the analysis explicit.

Designing a parser raises some of the same questions as semantic analysis: what counts as a predicate or argument, how to represent scope, and whether presupposed or implicit content matters for the task. A task-specific parser may deliberately omit distinctions that a broader semantic analysis would retain. Building the parser makes those choices explicit.

The definition leaves the representation language open on purpose. What counts as a meaning representation depends on the downstream task. For a question-answering system over a database, the representation language might be SQL. For a theorem prover, it might be first-order logic. For a virtual assistant, it might be a JSON object that names an intent and its slots. The representation must specify which structures are well formed and what distinctions they preserve. Whether a valid structure can be executed depends on the target language and application.

The central tension is compositionality versus coverage. A compositional analysis of "Alice likes Bob" derives its meaning from the meanings of "Alice", "likes", and "Bob" and from how they combine. But natural language is also ambiguous, underspecified, context-dependent, and messy. A formal representation must preserve the distinctions its task needs. For a learned parser, representation complexity must be considered alongside the data and search procedure; execution is an additional requirement when the application needs to run the output. That tradeoff runs through every representation in this chapter.

It helps to see the tension as two failure modes. If the representation is too weak, it cannot say what the task needs, and the parser is forced to throw away distinctions that matter. If the representation introduces distinctions unsupported by the data, annotation and search can become harder and learning may require additional supervision. Good representation design balances these failure modes.