Semantic Construction

Abstract:
In this chapter, we make the step from syntax to semantics - the study of meaning. The central question we're going to look at is the following: Given a sentence, how do we get to its meaning? And, being programmers, the next thing that interests us is: How can we automate this process? This is, we're going to look at the task of semantic or meaning construction . But don't be afraid, our work in the previous lectures wasn't for nothing. One of the first things we're going to see is that syntactic structure plays a crucial role in meaning construction.

Table of Contents

Introduction
Meaning as such is a very abstract concept.

First-Order Logic: Basic Concepts
In order to talk about meanings, we need a way for representing them. In this chapter, we're going to use the language of first-order logic for this purpose. So, when we say that we construct a meaning representation for some sentence, that means that we construct a formula of first-order logic that we take to represent this meaning.You may say: "What's the point in that? You're not giving the meaning of that sentence, you're just translating it to some artificial language that nobody uses." Is the situation really like that? No! Using first-order logic as a meaning-representation language has many advantages. Here are two of them:We assume that you've already heard about first order logic. In the following we'll only shortly review its syntax, and not say anything about (first-order) semantic concepts like truth or models for formulas. The reason is simply that these don't play a great role in the rest of the chapter. There, it's enough to have some intuition about what's the right first order formula for a given sentence. So as regards semantics, all we will do is sometimes give rough natural language equivalents to first-order formulas and their building blocks, to help you get this intuition.

Building Meaning Representations
Now that we've learned something about first-order logic how to work with it in Prolog, it is time to have a look at the major issue of this chapter, which is:Given a sentence of English, how do we get to its meaning representation?This question is of course far too general for what we can achieve in one chapter of this course. So let's rather ask a more specific one: "Is there a systematic way of translating such simple sentences as John loves Mary and A woman walks into first-order logic?" The important point here is the demand of being systematic. Next, we will discuss why this is so important.

The Lambda Calculus
Towards the end of the last section we saw how to transfer as much information as possible about the syntactic structure of a sentence into a kind of proto-semantic representation. But we still completely lack a uniform way of combining the collected semantic material into well-formed first order formulas.In this section we will dicuss a mechanism that fits perfectly for this task. It will allow us to explicitely mark gaps in first-order formulas and give them names. This way we can state precisely how to build a complete first order formula out of separate parts. The mechanism we're talking about is called λ-calculus. For present purposes we shall view it as a notational extension of first order logic that allows us to bind variables using a new variable binding operator λ. Here is a simple λ-expression: λx.WOMAN(x) The prefix λx. binds the occurrence of x in WOMAN(x). That way it gives us a handle on this variable, which we can use to state how and when other symbols should be inserted for it.

Implementing Lambda Calculus
Our decision to perform semantic construction with the aid of an abstract "glue" language (namely, λ-calculus) has pleasant consequences for grammar writing, so we would like to make the key combinatorial mechanisms (functional application and β-conversion), available as black boxes to the grammar writer. From a grammar engineering perspective, this is a sensible thing to do: when writing fragments we should be free to concentrate on linguistic issues.In this section we build the required black box. With such a black box available, we will be able to use a little DCG for semantic construction. We will decorate a slightly extended version of our dCGExample.pl (known from » Context Free Grammars) with extremely natural semantic construction code and start building representations.


Exercise

  1. Look at the semantics construction in » Advanced Topics: Proper Names and Transitive Verbs again. Work through the functional applications and β-reductions required to build the VP and S representations. Make sure you understand the role-reversing idea used in the TV semantic representation.
  2. Find a suitable λ-expression for the determiner no and add it to our implementation of λ-calculus. Test your solution with sentences like No man walks.
    Extend semanticDCG.pl accordingly.
    Hint:
    [Hint: Start by writing down the formulas for A witch flies. and Every witch flies. and comparing them. Then trace back how the difference between these formulas is reflected in the determiner representations. Finally, write down the formula for No witch flies., compare it to the other ones and make according changes to one of the two determiner representations already there.]
  3. Starting off from our treatment of transitive verbs (» Advanced Topics: Proper Names and Transitive Verbs), how would you handle ditransitive verbs such as offer? Give a semantic representation for offer, as well as semantically annotated grammar rules to analyse sentences like A witch offers Harry a broomstick.
  4. [Project]
    This exercise is about extending the chart parser from » Passive Chart Parsing such that it produces semantic representations. Here's a simplified version of the grammar ourEng.pl that we used there: simplifiedEng.pl . This simplified version contains only the kind of constructions that we already know how to deal with semantically.
    1. Extend the phrasal rules of this grammar with arguments for semantic construction along the lines of semanticDCG.pl .
    2. Add a semantic representation to each lexical entry as a third argument. Use Prolog variables for the λ-bound variables.
    3. Now extend the chartparser from » Passive Chart Parsing to deal with the semantic information. To get rid of the Prolog variables in the lexical entries, just add a call to vars2atoms/1 immediately after the lexicon is accessed in process_chart_bottomup/0.
    4. Add relative clauses to the grammar. For the syntactic part, just have a look at ourEng.pl . As regards the semantics: The predication from the relative clause should simply be conjoined to the predication from the noun that is modified. For instance, the representation assigned to man who walks should look like this when fully β-reduced: λx.(MAN(x)WALK(x))
      So what you have to do is think of a representation for the relative pronouns that leads to this result when combined with the representations for walks (that is λx.WALK(x)) and man (that is λx.MAN(x)) in the order determined by the syntax tree.