Semantic Parsing and Meaning Representations › What Makes a Good Meaning Representation?

Before comparing logical forms, AMR graphs, and SQL, we need criteria. A representation is not good in the abstract. It is good relative to a task.

A representation can be adequate for one specified task and insufficient for another. Compare the target with the task requirements: which distinctions must it preserve, what supervision is available, and which errors matter?

• Expressivity: Can the representation express the distinctions the task requires? A SQL query can express aggregation and joins. A first-order formula can express quantification and negation. An AMR graph can express predicate-argument structure and reentrancy, but it does not encode quantifier scope in the way first-order logic does.
• Compositionality: Does the representation have a systematic way to combine meanings of parts? Lambda calculus gives a clean composition rule through function application. SQL has a grammar with compositional semantics, but natural-language phrases do not always map neatly onto SQL clauses.
• Executability: Can the representation be evaluated against a world, database, or interpreter? Executability gives us verification. We can run a SQL query, evaluate a logical formula in a model, or execute a program. It also gives us weak supervision: we can train a parser from denotations even when we lack gold logical forms.
• Learnability: Is the representation easy enough to annotate and search over? A representation that is too expressive may have a huge space of possible parses. A representation that is too simple may lose task-relevant meaning.
• Interpretability: Can a human inspect the representation and understand why the system produced it? Logical forms and SQL are relatively readable. Neural model hidden states are not.
• Ambiguity handling: Does the representation force a single reading, or can it represent alternatives and underspecification? "Every student reads a book" has at least two readings. A parser that outputs one fully resolved, reading-specific logical form has chosen one reading.

These criteria ask different questions. A logical form makes predicates, bindings, and scope explicit, but mapping language to that form requires choosing the intended analysis. Detailed logical-form annotation can require substantial semantic work. SQL is a natural fit when the data and computation can be expressed relationally. Base AMR concentrates on predicate-argument structure and abstraction across paraphrases while omitting some distinctions. The useful comparison is with the task requirements.

A useful exercise is to compare a candidate representation with these criteria before writing any code. For a calendar assistant, for instance, the representation might contain an intent, a single date and time, and participants. An application can validate those fields and map them to calendar operations. The listed fields do not directly encode recurrence exceptions; those require an agreed extension. A small field set constrains the output structure, but learnability also depends on the data, grounding requirements, and model. If a reasoning task needs quantification, a logical form can make the intended scope explicit while requiring choices about predicates and bindings.