Abstract: In this chapter, we will re-package our grammar and lexicon such that we arrive at a modular framework of semantics construction. Later on, we will be experimenting with various semantic construction techniques differing from λ-calculus.. Incorporating these changes, and keeping track of what is going on, requires a disciplined approach towards grammar design. So we will take the opportunity and get to know some basic principles of software engineering on the way. That is, we will re-structure our program such that it is:
Modular: Each component should have a clear role to play and a clean interface with the other components.
Extensible: The grammar should be easy to upgrade, should the need arise.
Reusable: We should be able to reuse a significant portion of the grammar, even when we change the underlying representation language.
Sticking to these simple principles, we will build an overall framework that will serve us unchanged throughout the rest of this course.
Table of Contents
Architecture of our Grammar This section gives an overview of the general architecture we've adopted for our flexible and modular implementation of a semantics construction system.
The Syntax Rules In this section we turn to the core DCG rules that we are going to use in our semantics construction system. But we first have to deal with syntax. So we now turn to the core DCG rules that we are going to use. Let's look at our diagram (» o2838): We're in the blue part in the upper half of the left (blue) side. So what we're talking about now will remain fixed throughout the rest of the course. This basically means that for what's to come later, we will consider the problem of syntax as solved.We will first discuss what syntax rules we would like to use. We will immediately see why we can't - and then solve the problem.
The Semantic Side Now we're going to look at the semantic construction copmonent of our new implementation. As we've stated, we plan to use our framework with different semantic formalisms. So the semantic construction part we're going to implement can't stay fixed throughout the course. Rather, we'll explicitely want to change it from time to time. And of course we want to be able to do so with as few complications as possible. We'll add a call to an interface predicate (named combine/3) to each of our syntax rules. And when we want to upgrade to a different method of semantic construction, we'll often be able to do so by simply re-implementing combine/3. Now we're going to look at the upper right (the reddish) side of our diagram (» o2838): Semantic construction. As we've stated above, we plan to use our framework with different semantic formalisms. So the semantic construction part we're going to implement can't stay fixed throughout the course. Rather, we'll explicitely want to change it from time to time. And of course we want to be able to do so with as few complications as possible. Let's recall an observation we made some time ago: Any systematic method of semantic construction has to use the information provided by syntactic structure. So one thing is for sure: As different as they may be, any of the formalisms for semantic construction we possibly come to use will have to communicate with our syntax component. We'll incorporate this insight into our framework as follows: We'll add a call to an interface predicate (named combine/3) to each of our syntax rules. And when we want to upgrade to a different method of semantic construction, we'll often be able to do so by simply re-implementing combine/3.
Looking Up the Lexicon In this section we look at the lexicon. In a lexical lookup, the syntax component needs to find the syntactic category for a given input token, while the semantic component has to be provided with the associated meaning representation. Our strategy will again be to factor out as much as possible of the semantic side, as this side is what will change with different formalisms. Up to now, we've been focussing on the upper half of our diagram (» o2838), the part where words (and meanings) are combined. Let's now focus on the lower half, where words and meanings come from: Let's look at the lexicon. In a lexical lookup, the syntax component needs to find the syntactic category for a given input token, while the semantic component has to be provided with the associated meaning representation. Our strategy will again be to factor out as much as possible of the semantic side, as this side is what will change with different formalisms.
Lambda at Work In this section we plug the components of our new semantics construction system together and provide a user-interface.
Exercise
Find out how copula verbs are handled in the lexicon and grammar, and how our implementation generates the semantic representations for sentences like Mary is a therapist and Mary is not John. You may either hand in your solution in (hand-)written form or send us a an E-mail. In the latter case, you can use the Prolog notation for λ-terms. E.g. for John walks, the solution might look like this:
John ~> lambda(A,A@john)
walks ~> lambda(B,walk@B)
John walks ~> lambda(A,A@john)@lambda(B,walk(B))
<=> walk(john).
Add a treatment of ditransitive verbs such as offer to the implementation discussed in this chapter. Use the following formalization as a starting point: λRλOλg.O@λo.R@λr(OFFER(g,o,r)) Hint: Move along the lines of transitive verbs. First specify the lexicon/4-fact and the lexical and phrasal DCG rules. Then specify the semantic macro and finally design an appropriate combine rule. Don't forget the brackets in your complex applications, e.g. ((A@B)@C)!
Test your solution with sentences like Mary offers John a siamese cat.
Find a suitable λ-expression for the determiner no (or use what you've thought out in » Beispiel: EX EX.LAM.NOEX_EX.LAM.NO) and add it to our implementation. Test your solution with sentences like No man walks.
[Hint: remember the special treatment of determiners!]
Extend our implementation such that it covers negated sentences like It is not the case that Mary walks.
Hint: Find out how if-then-sentences are treated.
This is an important exercise!
Test the coverage of our system. Try to find some sentences where the semantic representations returned by our implementation are not satisfactory. Are the problems due to our implementation, or due to the mechanism of λ-based semantic construction itself?
[Mid-term project]
Localize the system we've implemented. That is, take it to a language of your choice by adapting the lexicon and grammar accordingly. The range of constructions and phenomena covered should be the same or comparable to what is covered by the English version we've discussed. If you want to cover different semantic phenomena, you'll probably have to extend the semantic macros, too.
Your solution should contain a sort of report, documenting the changes you make, as well as the difficulties you encounter. Do you think that the difficulties are particular to the language you've chosen? Does the modular character of the system support you in your work?