tools for theta theory | draft uil-ots course, fall...
TRANSCRIPT
Tools for Theta Theory — Draft
Uil-OTS Course, Fall 2002
Jan van Eijck
March 4, 2003
Abstract
This draft document consists of a formalisation together with a documentedimplementation, of coded verb concepts for theta theory, in particular thetheta system proposed in [Rei00, Rei01, Rei02]. The coded concepts areprovided with a semantics given in terms of events, with the event semanticsset up in such a way that events can be extracted from first-order modelswith underspecified relations. An example of such an underspecified firstorder model is provided in the text. In fact, the text gives an implementationof event semantics based on first order logic.
To put the theta system to work, a parser for a simple phrase structuregrammar with agreement features has been provided, together with an in-terpretation mechanism for sentences of the fragment in a first order modelwith underspecified relations. The implementation of verb concepts with or-dered lists of realized theta roles allows for a particularly elegant quantifierscoping algorithm.
The code you will find in this document is annotated Haskell [JH+99],written in literate programming style [Knu92]. The whole document consistsof a number of documented Haskell modules. The text in the rectangledboxes is the actual program code. The code was tested with [JR+] and[Tea].
Contents
1 Introduction 3
1.1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Theta Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Overview of this Document . . . . . . . . . . . . . . . . . . . 71.5 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Coded Concepts for Verbs 9
2.1 Theta Roles and Concepts . . . . . . . . . . . . . . . . . . . . 92.2 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Concept Transformations . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Reflexivisation . . . . . . . . . . . . . . . . . . . . . . 182.4.2 Decausativisation . . . . . . . . . . . . . . . . . . . . . 202.4.3 Saturation . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6 Extending the Concept List . . . . . . . . . . . . . . . . . . . 262.7 Features and Agreement . . . . . . . . . . . . . . . . . . . . . 27
3 Domain and Model 30
3.1 Representing a Domain of Entities . . . . . . . . . . . . . . . 303.2 Representing a Model for Predicate Logic . . . . . . . . . . . 33
4 Events 36
4.1 Formalisation of Events . . . . . . . . . . . . . . . . . . . . . 364.2 Events as Structured Objects . . . . . . . . . . . . . . . . . . 384.3 Occurring of Events . . . . . . . . . . . . . . . . . . . . . . . 394.4 A Datatype for Events . . . . . . . . . . . . . . . . . . . . . . 394.5 Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1
4.6 The Reflexivisation Transformation . . . . . . . . . . . . . . . 444.7 The Saturation Transformation . . . . . . . . . . . . . . . . . 444.8 Event Properties . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Syntax 47
5.1 A Simple Phrase Structure Grammar . . . . . . . . . . . . . . 475.2 Categories for DPs, VPs and Sentences . . . . . . . . . . . . . 485.3 A Simple Phrase Structure Parser . . . . . . . . . . . . . . . 535.4 Boring Latex and System Stuff . . . . . . . . . . . . . . . . . 63
6 Semantics 68
6.1 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2 Arbitrary Arity Relations . . . . . . . . . . . . . . . . . . . . 686.3 Boolean Algebras of Relations . . . . . . . . . . . . . . . . . . 716.4 The Need for Flexible Type Assignment . . . . . . . . . . . . 736.5 Lifting the Types of DP Interpretations . . . . . . . . . . . . 736.6 Scope Reversal of Quantifiers . . . . . . . . . . . . . . . . . . 766.7 Extracting Relations from Event Lists . . . . . . . . . . . . . 776.8 Interpretation of the Categories . . . . . . . . . . . . . . . . . 806.9 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.10 Quantifier Scoping . . . . . . . . . . . . . . . . . . . . . . . . 85
2
Chapter 1
Introduction
1.1 Revision History
The first version of this document was presented as a series of classroomhandouts end of October 2002. This is an expanded and revised update ofthat first version. It is expected that expansion and revision will continueon the basis of results and experiences of the ‘theta system implementationproject’.
1.2 Prerequisites
The reader of this document is supposed to be somewhat familiar with func-tional programming in Haskell. Haskell is freely available from the internetat www.haskell.org. Recommended Haskell tutorials are [HFP96] and thefirst two chapters of [DvE02]. Further documentation on Haskell can befound on www.haskell.org.
1.3 Theta Theory
Theta theory is the theory of the way in which thematic roles like Agent,Patient, Cause, Instrument, and so on, function in the thematic structureof predicates in the lexicon and, more generally, in syntax. In Governmentand Binding theory [Cho81] and in the later Minimalist Program [Cho92],lexical entries for verbs are provided with a theta grid in which the thematic
3
roles are given that the verb assigns. The verb kill, e.g., would assign twothematic roles, one for Agent and one for Patient.
Although thematic relations have been with us for a long time — earlyreferences for an analysis in terms of “abstract thematic roles” are [Gru65]and [Jac72] — it seems fair to say that most linguistic work in theta theoryis informal and speculative. Also, the theory of thematic roles has receivedrelatively little attention from formal semanticists (with [Dow89] as one ofthe exceptions).
There is no general agreement on the number of theta roles that shouldbe distinguished. [Rei00] came up with the proposal to link theta roles tofeature clusters defined in terms of ± c (‘c’ for ‘cause’) and ± m (‘m’ for‘mental’). There are 9 consistent subsets of the feature set
{ +c, –c, +m, –m },
and they can get linked to theta roles as follows:
Agent [+c+m] Instrument [+c–m]Experiencer [–c+m] Patient, Theme [–c–m]Cause [+c] Animate [+m]Source, Subject Matter [–m] Goal [–c]None [ ]
The particular choice of ‘causal’ and ‘mental’ as tags for the features ismaybe not that important. Other name tags would do just as well. [Myl99]discusses the following examples from [Gri90].
(1.1) (a) Michael worries about the situation in Bosnia (cf. fear).
(b) The situation in Bosnia worries Michael (cf. frighten).
What causes the alternation of the Theme and Experiencer roles in thisexample? In discussing the answer given in [Gri90] to this question, [Myl99]make the following remark:
Once we accept that two “dimensions” of analysis are required,we can see that the essence of Grimshaw’s analysis of fear andfrighten can be reduced to the following two questions: which en-tity (if any) is or comes to be in a state specified by the predicate,and which entity (if any) has a controlling role in the situation?
4
This information can be expressed in terms of features, and thealternation in (1.1) can be expressed as a “switch” in the valueof a single feature.
The features are called ± Control and ± SpecState in [Myl99]. I take itthat ± Control corresponds more or less to ± c, and ± SpecState more orless to ± m. The important thing about the theta features is perhaps nottheir precise names, but the fact that they give us a means of structuringthe domain of thematic roles. An significant difference between [Myl99] and[Rei00] is that [Rei00] gives up the attempt to define a ranking or hierarchyfor all theta arguments, and adopts the position that theta theory merelyputs constraints on the ordering of theta roles, in particular concerning thequestion which theta roles can be realized as subjects (“. . . can be mergedexternally”) and which cannot (“. . . have to merge internally to the VP”).
The thematic role assignments of a verb are part of the link between languageand reality (the realm of things outside language that language is ‘about’).To implement thematic roles by means of type constraints in semanticswould be a mistake, for in John kicked the door and John kicked Bill, the
door and Bill are both in the thematic role of Patient, but this cannot betaken to imply that the door and Bill have to be things of the same kind(except in the trivial sense of being the type of things that can receive kicks).
What we will do, therefore, is define Predicates as links between sets ofthematic roles (implemented as lists) and sets of events (implemented aslists). The events themselves have a number of roles, identifiable by in-dices 1, · · · , n, and what the predication does is establish a one-to-one mapbetween theta feature clusters and these roles. Here is an example of apredicate:
kill 1 2 3Cause Patient Instrument
If Max kills Lucy with an axe, then Max is the cause, Lucy is the patient,and the axe is the instrument. In terms of feature clusters, the predicatelooks like this:
kill 1 2 3[+c] [–c–m] [+c–m]
Of course, this is just for illustration. There may also be a theta role forlocation, and perhaps there are still other roles. In general, to interpret a
5
predicate with n thematic roles, the predicate will get as its denotation anevent set consisting of events with n roles defined on them.
This document started out as an attempt to formalize the main ideas givenin the system that evolves in [Rei00, Rei01, Rei02]. In [Dim] a draft of anevent semantics for this system is given, and a number of desiderata for thesemantic component of the system are listed. It is my aim to make theimplementation comply with these desiderata.
Most linguistic work in theta theory tends to be linked to informal versionsof event semantics [Dav67, Par90], but any serious formalisation of thetatheory should adopt a more formal approach to event semantics than thatof Parsons or Davidson. [Dim] suggests algebraic semantics as a possibility.The events that are used in the implementation given in this documentare constructed in such a way that they satisfy the minimal axioms of anyreasonable version of algebraic event semantics:
1. The actual events of a model form a set (or, in the implementation, alist).
2. There are event type predicates (in the implementation represented asevent lists).
3. Event predicates satisfy certain implicational relations. In particular,a relation involves can be defined on them: “kissing involves touching”.
4. There is a finite set of roles which are partial functions from eventsto individuals. In the formalisation I propose, the identification ofthe roles is part of the verb concept, and the roles are assigned by aprocess of concept generation.
Part of the point of theta theory is to come up with a semantics for verbsthat exhibits more flexibility than the traditional lambda formulas fromtype theory. Essentially, the theta clusters in an event predicate should beaccessible in any order.
The semantics for the theta system proposed in the present formalisationemploys events, but it is also shown how event properties can be constructedout of relations and relations out of events properties. This possibility ofback and forth conversion offers linguists a flexible event semantics, while atthe same time providing a relational semantics along lines that are familiarto logicians.
6
In the course of my formalisation attempt, a strong connection developedwith the logic of n-ary relations. This is a perspective that is almost com-pletely absent from current linguistic work in this area. I will attempt toshow that an infusion with the logic of relations is exactly what is neededfor a vigorous formal theory of thematic relations.
1.4 Overview of this Document
In the first part of this document we address the problem of linking codedconcepts to the inference engine. We give a formal specification of codedconcepts for verbs (henceforth: concepts), and link each concept to a suitablesemantic interpretation.
For purposes of illustration, we interpret the concepts in a highly idealisedmodel of reality, namely a first order model. Still our semantics is given interms of events, so we will have to spell out how events can be constructedfrom the information present in a first order model. To keep matters simpletense is ignored in the semantics: the first order model should be viewed as akind of ‘snapshot’ of reality. Our first order model allows underspecificationof relations as an extra feature. We need this to account for the semanticeffect of argument saturation.
It is standard practice among linguists to state the semantics of verb con-cepts in terms of sets of events satisfying the verb concept. To comply withthat standard, we provide a formalization of events, and a back and forthtranslation mechanism between event semantics and relational semantics.This allows us to extract the actual events from a first order model, andconversely, to transform a set of actual events over a domain into a firstorder model over that domain.
To be able to see what our implementation of verb concept and transforma-tions on verb concepts does, we provide tools for syntactic analysis and formodel-theoretic interpretation. Syntactic analysis proceeds in two stages:first we check whether a sentence fits a simple phrase structure analysis,and if it does, the further constraints given by theta theory are imposed.
1.5 Disclaimer
This is by no means a full implementation of the theta system or any othersystem of theta theory, but it is a start, and it has at least the merit of
7
being fully explicit about coding of verb concepts, about interpretation ofverb concepts in terms of event predicates, and about the link between eventsemantics and relational semantics.
8
Chapter 2
Coded Concepts for Verbs
2.1 Theta Roles and Concepts
Declare a module for Concepts. Import the modules List for list processing,Features for features and agreement, Domain for definition of a domain ofentities, Model for specification of a first order model, and Events for eventprocessing. The module List is a standard Haskell module. The contents ofFeatures, Domain, Model and Events are given further on in this document.
module Concepts
where
import List
import Features
import Domain
import Model
import Events
Theta roles are clusters of theta features. In the implementation, such clus-ters are represented as agreement lists (Section 2.7).
As a reminder of the link between theta roles and feature clusters, we declarea datatype for theta roles, and specify a procedure for mapping agreementlists to theta roles.
9
data Role = Agent | Instrument
| Experiencer | Patient
| Cause | Animate
| Source | Goal
| None deriving (Eq,Show)
Extract theta roles from feature lists:
trole :: Agreement -> [Role]
trole feats | length (ca feats) > 1 = []
| length (me feats) > 1 = []
| elem PC feats =
case me feats of [PM] -> [Agent]
[MM] -> [Instrument]
[] -> [Cause]
| elem MC feats =
case me feats of [PM] -> [Experiencer]
[MM] -> [Patient]
[] -> [Goal]
| otherwise =
case me feats of [PM] -> [Animate]
[MM] -> [Source]
[] -> [None]
The theta roles will not be used in what follows, but the code serves asa reminder of the correspondence between feature clusters and theta roles.Also, the code makes clear that PC is used for +c, MC for -c, PM for +m, MMfor -m.
2.2 Predicates
We will represent predicates as tuples consisting of a key, a list of thetaroles, and a list of events serving as an interpretation for the predicate.
10
The length of the list of theta roles of a predicate has to match the depth ofthe events in the interpretation of the concept: you cannot access an eventrole that does not exist.
Call the list of all theta roles for a predicate a labeling for the predicate.Here is a type declaration for labelings:
type Labeling = [Agreement]
Here is a datatype for predicates:
type Predicate = (String,Labeling,[Ev])
The String argument is for identification purposes.
In theta theory, the standard semantics for coded verb concepts is an eventsemantics. A concept for a verb V denotes the property of events given by:
λe.v(e),
where v gives the appropriate property of events. To check a certain verbpredication, at an appropriate level we will check for existential closure ofthis property:
∃e.v(e).
This is can be stated in an equivalent way as:
{e | v(e)} 6= ∅.
In our implementation, this is rendered in terms of lists, as:
[ e | v(e) ] 6= [].
Thus, we start out by associating with every predicate a list of actual events(actual with respect to the model of evaluation), with the number of rolesof the events matching the number of theta roles (realized or not) of thepredicate.
11
Predicates can be generated from labelings and verb meanings (lists ofevents), provided the size of the labeling matches the depth of the eventsin the verb meaning. In case the verb meaning list is empty, this cannot bechecked. In case the verb meaning list is non-empty this can be checked bychecking the depth of the first event on the list. (This hinges on the factthat all events on an event list interpreting a verb phrase have the samedepth.)
genPRED :: String -> Labeling -> [Ev] -> Predicate
genPRED str labs [] = (str,labs,[])
genPRED str labs (e:es)
| depth e == length labs = (str,labs,e:es)
| otherwise = error "size mismatch"
We assume the following predicates (this list will be extended as the imple-mentation progresses):
break 1 2 3[+c] [–c–m] [+c–m]
kill 1 2 3[+c] [–c–m] [+c–m]
open 1 2[+c] [–c–m]
drop 1 2[+c] [–c–m]
shave 1 2[+c+m] [–c–m]
wash 1 2[+c+m] [–c–m]
give 1 2 3[+c+m] [–c–m] [–c+m]
sell 1 2 3[+c+m] [–c–m] [–c+m]
Note the difference in the first theta cluster between the predicates for‘shave’, ‘wash’ ‘give’ and ‘sell’ with those for ‘break’, ‘kill’, ‘open’ and ‘drop’.
12
The first theta role in ‘drop’, ‘open’, etc., is [+c], but the first theta role inthe concepts for ‘shave’, ‘wash’, etc., is [+c+m].
Here are predicates for ‘break’, ‘open’, ‘kill’, ‘drop’. The event lists breaking,killing, opening and dropping are defined in Section 4.8.
breakPRED, killPRED, openPRED, dropPRED :: Predicate
breakPRED = genPRED "break" [[PC],[MC,MM],[PC,MM]] breaking
killPRED = genPRED "kill" [[PC],[MC,MM],[PC,MM]] killing
openPRED = genPRED "open" [[PC],[MC,MM]] opening
dropPRED = genPRED "drop" [[PC],[MC,MM]] dropping
Here are predicates for ‘shave’ and ‘wash’. Again, we refer to Section 4.8 forthe definition of the event lists used in these predicates.
shavePRED, washPRED :: Predicate
shavePRED = genPRED "shave" [[PC,PM],[MC,MM]] shaving
washPRED = genPRED "wash" [[PC,PM],[MC,MM]] washing
Here are predicates for ‘give’ and ‘sell’:
givePRED, sellPRED :: Predicate
givePRED = genPRED "give" [[PC,PM],[MC,MM],[MC,PM]] giving
sellPRED = genPRED "sell" [[PC,PM],[MC,MM],[MC,PM]] selling
2.3 Concepts
The difference between a predicate and a concept is that in a concept it isindicated which of the theta roles of the predicate are realized, and in whichorder. In the datatype for concepts we have two agreement lists: one forthe realized theta roles, one for the labeling of the predicate. Here is thedatatype for concepts:
13
type Concept = (String,[Agreement],Labeling,[Ev])
key is a function to extract the key (identifying string) from a concept;thetaRoles is a function to extract the list of realized theta roles from aconcept; labels is a function to extract the labeling from a concept. arityCgives the arity (the number of realized theta roles) of the concept.
key :: Concept -> String
key (str,_,_,_) = str
thetaRoles :: Concept -> [Agreement]
thetaRoles (_,thetas,_,_) = thetas
labels :: Concept -> Labeling
labels (_,_,labeling,_) = labeling
arityC :: Concept -> Int
arityC (_,thetas,_,_) = length thetas
eventsC :: Concept -> [Ev]
eventsC (_,_,_,evs) = evs
To illustrate these functions, we consider the following example context:
exampleCCPT =
("give",[[PM],[MC,MM]],[[PC,PM],[MC,MM],[PM]],giving)
Here is what we get:
Concepts> exampleCCPT
("give",[[+m],[-c,-m]],[[+c,+m],[-c,-m],[+m]],[[L,G,M],[M,V,L]])
Concepts> key exampleCCPT
"give"
14
Concepts> thetaRoles exampleCCPT
[[+m],[-c,-m]]
Concepts> labels exampleCCPT
[[+c,+m],[-c,-m],[+m]]
Concepts> arityC exampleCCPT
2
Concepts> eventsC exampleCCPT
[[L,G,M],[M,V,L]]
Given the labelling list of a concept, a mapping can be computed from therealized theta roles to the appropriate roles in the concept meaning (theevents in the event list).
The function findIdxs finds the indices of the elements of a list satisfyinga given property.
findIdxs :: (a -> Bool) -> [a] -> [Int]
findIdxs p xs = [ i | (x,i) <- zip xs [1..], p x ]
The function rM (role map) can be used to find the index of a specific thetarole or list of theta roles in a labeling.
rM :: [Agreement] -> Labeling -> [Int]
rM thetas labeling =
[ i | theta <- thetas,
i <- findIdxs (==theta) labeling ]
This is used in roleM to find the indices of the realized theta roles of aconcept.
roleM :: Concept -> [Int]
roleM ccpt = rM (thetaRoles ccpt) (labels ccpt)
15
Concepts> rM [[PM]] (labels exampleCCPT)
[3]
Concepts> rM [[MC,MM]] (labels exampleCCPT)
[2]
Concepts> rM [[MC]] (labels exampleCCPT)
[]
Concepts> roleM exampleCCPT
[3,2]
These results of applying rM and roleM tell us that the [+m] role of theconcept can be accessed with index 3, that the [-c-m] role of the concept canbe accessed with index 2, and that the concept does not have a [-c] role.
Given a list of theta roles and a predicate, you can create a concept thatrealizes the theta roles in the list, provided all of the theta roles in the listare present in the predicate:
pred2ccpt :: [Agreement] -> Predicate -> Concept
pred2ccpt thetas (key,labs,events)
| all (\ x -> elem x labs) thetas =
(key,thetas,labs,events)
| otherwise =
error ("unassigned theta roles" ++ listing)
where listing = show (thetas \\ labs)
Let us now construct verb concepts from predicates. We will assume that alltheta roles are realized, except for the Instrument role in ‘kill’ and ‘break’:
breakCCPT, killCCPT, openCCPT, dropCCPT :: Concept
breakCCPT = pred2ccpt [[PC],[MC,MM]] breakPRED
killCCPT = pred2ccpt [[PC],[MC,MM]] killPRED
openCCPT = pred2ccpt [[PC],[MC,MM]] openPRED
dropCCPT = pred2ccpt [[PC],[MC,MM]] dropPRED
16
To ‘killing’ and ‘breaking’ with instrument roles we assign concepts of theirown:1
break1CCPT, kill1CCPT :: Concept
break1CCPT = pred2ccpt
[[PC],[MC,MM],[PC,MM]] breakPRED
kill1CCPT = pred2ccpt
[[PC],[MC,MM],[PC,MM]] killPRED
Concepts for ‘shave’ and ‘wash’:
shaveCCPT, washCCPT :: Concept
shaveCCPT = pred2ccpt [[PC,PM],[MC,MM]] shavePRED
washCCPT = pred2ccpt [[PC,PM],[MC,MM]] washPRED
Concepts for ‘give’ and ‘sell’:
giveCCPT, sellCCPT :: Concept
giveCCPT = pred2ccpt [[PC,PM],[MC,MM],[MC,PM]] givePRED
sellCCPT = pred2ccpt [[PC,PM],[MC,MM],[MC,PM]] sellPRED
What these entries give us is that the concepts for ‘break’, ‘open’, etc., arerepresented as tuples consisting of
1. A key,
2. a list of feature lists for specifying the roles realized in the concept, inthe order in which they are realized.
3. a list of feature lists for specifying all roles of the concept, and theorder in which they can be accessed,
1In later stages of the implementation, this should be taken care of by a rule.
17
4. a list of events, i.e., an event property (these event properties aredefined in the Events module listed below).
This allows us to solve the problem of feature cluster access to the conceptroles in a completely general way: if ccpt is a coded concept for a verb andtheta is a feature cluster, then
rM [theta] (labels ccpt)
points to the theta role of the events in the event list of the concept.
As we will see, the transformations on concepts will affect the ordering ofthe realized roles of a concept, but the rM function allows us to keep trackof the roles.
Finally, we put all concepts in a concept list.
concepts =
[ breakCCPT,
break1CCPT,
openCCPT,
killCCPT,
kill1CCPT,
dropCCPT,
shaveCCPT,
washCCPT,
giveCCPT,
sellCCPT ]
2.4 Concept Transformations
2.4.1 Reflexivisation
Reflexivisation applies with the following constraint. The first cluster in theentry it applies to must contain the feature +m.2
2A relaxation of this constraint that would allow for reflexivisation for all conceptswith a first cluster interpretable as [/+m] would be to rule out the feature -m on the firstcluster. The test that implements this condition is not (elem MM theta1).
18
The reflexivisation operation removes the second theta role of the concept.This is matched by the appropriate transformation of events. The seman-tic reflexivisation transformation refl :: [Ev] -> [Ev] is defined in theEvents module.
Since reflexivisation cannot always be applied, we should have a means toindicate failure of application. A crude solution is to generate an errormessage. We will do something more useful. In case the transformationapplies, we let the transformation function produce a unit list containingthe transformed concept. Failure of application will be indicated by returnof the empty list.
reflTRANSF :: Concept -> [Concept]
reflTRANSF (str,(theta1:theta2:thetas),labels,events)
| elem PM theta1 =
[(str,
(theta1:thetas),
labels,
refl (list2pair (rM [theta1,theta2] labels)) events)]
| otherwise = []
where list2pair [i,j] = (i,j)
reflTRANSF _ = []
The transformation takes a concept with at least two theta roles (indicatedby theta1:theta2:thetas), and produces (a list containing) a new conceptwhere the second theta role is removed, and where a semantic operation isapplied to the input event list events. If the first theta role does not havefeature +m the empty list is returned.
In case the input concept does not contain at least two theta roles, theempty list is returned.
The reflexivisation transformation affects the mapping from realized thetaroles to event roles. We get:
Concepts> roleM shaveCCPT
[1,2]
Concepts> roleM rs where [rs] = (reflTRANSF shaveCCPT)
[1]
19
Concepts> roleM giveCCPT
[1,2,3]
Concepts> roleM rg where [rg] = (reflTRANSF giveCCPT)
[1,3]
2.4.2 Decausativisation
One of the differences between passivisation and decausativisation is thatthe first can apply to Agent ([+c+m]) roles, while the second only appliesto Cause ([+c]) roles:
(2.1) eat [+c+m],[-c-m]
(a) The apple was eaten
(b) *The apple ate
(2.2) break [+c],[-c-m]
(a) The vase was broken
(b) The vase broke
The differences in meaning between ‘The vase was broken’ and ‘the vasebroke’ are quite subtle. They all seem to have to do with whether a causecan be inferred or not. The first seems to entail (2.3), the second does not.
(2.3) Someone (or something) broke the vase.
At the present level of semantic sophistication (where all the information wehave at our disposal is relational first order information) it may seem a bithard to account for these subtle differences.
And yet, it can be done. We will let our domain contain one special entityUnspec, which is neither a person nor a thing. We will take it that sayingthat something happens spontaneously is the same as saying that Unspec
caused it.3 E.g., if a stone drops by itself, then Unspec dropped it, andsince Unspec is neither a person nor a thing, it is not the case that anyoneor anything dropped it. In this case, The stone dropped should turn out
3You may think of Unspec as Nature or God, depending on your metaphysics. Or, ifyou prefer to remain agnostic, don’t think anything about it at all.
20
true, while The stone was dropped should turn out false. The semantic sat
transformation on event lists has the appropriate effect: see the Events
module.
Semantically, we interpret decausativisation as the identity function on eventsets: the decausativisation transformation does nothing.
One further sublety: unaccusative alternates may look different from thetransitive verbs they derive from. One example in English is kill. We will putsuch cases in an exception list, and use this to define a function unaccForm
that gives the unaccusitive form of a verb.
unaccExceptions :: [(String,String)]
unaccExceptions =
[("kill","die"),
("fell","fall")]
unaccForm :: String -> String
unaccForm str =
maybe str id (lookup str unaccExceptions)
Do not try to understand the definition of unaccForm, unless you are familiarwith the Maybe monad. This is what the function does:
Concepts> unaccForm "break"
"break"
Concepts> unaccForm "kill"
"die"
Again, we indicate success by return of a unit list and failure of applicationby return of the empty list.
21
decausTRANSF :: Concept -> [Concept]
decausTRANSF (str,theta1:theta2:thetas, roles, events)
| theta1 == [PC] = [(unaccForm str,
theta2:thetas,
roles,
events)]
| otherwise = []
decausTRANSF _ = []
The decausativisation transformation affects the mapping from realized thetaroles to event roles. We get:
Concepts> roleM breakCCPT
[1,2]
Concepts> roleM nb where [nb] = (decausTRANSF breakCCPT)
[2]
2.4.3 Saturation
The saturation transformation, to be used, e.g., in passives, has no con-straint. Still, the transformation fails to apply if not at least two realizedtheta roles are present. Again, we let a unit list result indicate success andan empty list result indicate failure.
satTRANSF :: Concept -> [Concept]
satTRANSF (str,theta1:theta2:thetas,labels,events) =
[(str,
theta2:thetas,
labels,
sat i events)]
where [i] = rM [theta1] labels
satTRANSF _ = []
The saturation transformation sat on event lists is defined in module Events.
22
This transformation takes a list of indices for the event roles it has to satu-rate.
The saturation transformation affects the mapping from realized theta rolesto event roles. We get:
Concepts> roleM breakCCPT
[1,2]
Concepts> roleM sb where [sb] = (satTRANSF breakCCPT)
[2]
Concepts> roleM giveCCPT
[1,2,3]
Concepts> roleM sg where [sg] = (satTRANSF giveCCPT)
[2,3]
Exercise 1 Consider the verbs break and wash, and the noun phrases Max,Lucy, the stone and the vase. List all the different sentences that the system
should be able to generate using these words, given the coded concepts for
the verbs and given the three transformations on concepts.
2.5 Merging
Merging is the process of deciding which argument of a verb cluster will endup as the external argument (the argument corresponding to the syntacticsubject of the sentence).
The following constraints apply:
• Non-empty clusters consisting of negative features only (negative clus-ters) merge internally.
• Non-empty clusters consisting of positive features only (positive clus-ters) merge externally.
This is where theta theory has its empirical clout. The constraints rule outverb concepts with both an Agent and a Cause role realized, or with bothan Agent and an Animate role realized, with both a Cause and an Animate
role realized.
Of course, the theory can always be made to fit the facts again by simpleadjustment of the thematic roles. Suppose we assume the following predicatefor give:
23
give 1 2 3[+c+m] [–c–m] [+m]
Then the second constraint on merge is violated, so we better assign a featurecluster like [–c+m] to the third argument position.
For a full appreciation of the merging constraints it should be borne in mindthat lack of an external role does not rule out a verb concept. There is asyntactic provision to the effect that sentences must have subjects (calledthe Extended Projection Principle or EPP). To cater for this as well, werephrase the constraints as follows:
• Non-empty clusters consisting of negative features only (negative clus-ters) merge internally, unless there are only negative clusters present.
• Non-empty clusters consisting of positive features only (positive clus-ters) merge externally.
In our implementation, the first item on the list of realized theta clustersis the item corresponding to the syntactic subject of the sentence. We willimplement merge as follows. Let the shuffle of a list be the result of consid-ering all cases of selecting one element from the list and putting it upfront,without changing the order of the other elements. E.g., the shuffle of thelist [1, 2, 3, 4] is the following list of lists:
[[1, 2, 3, 4], [2, 1, 3, 4], [3, 1, 2, 4], [4, 1, 2, 3]].
By shuffling the list of realized theta roles, we consider them all as candidatesfor external merge. The only thing we have to do is to rule out the shuffleresults that violate one of the two merging constraints.
Here is the implementation of the shuffle operation. It uses the delete
function, defined in the List module. Since delete employs an equalitytest, shuffle expects an input list from class Eq.
shuffle :: Eq a => [a] -> [[a]]
shuffle xs = [ x : (delete x xs) | x <- xs ]
The first constraint on merge uses the property of being an all-negativefeature cluster:
24
negCluster :: Agreement -> Bool
negCluster theta = notElem PC theta && notElem PM theta
The first constraint (in the weakened form that takes EPP into account) isimplemented by ruling out feature lists starting with an all-negative featurecluster, unless all feature clusters are all-negative.
negInternal :: [Agreement] -> Bool
negInternal [] = error "empty list of theta roles"
negInternal (x:xs) = not (negCluster x)
|| all negCluster xs
The second constraint on merge uses the property of being an all-positivefeature cluster:
posCluster :: Agreement -> Bool
posCluster theta = notElem MC theta && notElem MM theta
The second constraint is implemented by ruling out feature lists having anall-positive feature cluster in their tails.
posExternal :: [Agreement] -> Bool
posExternal [] = error "empty list of theta roles"
posExternal (_:xs) = not (any posCluster xs)
Using these ingredients, we are ready for defining the merge. First on listsof theta roles:
25
merge :: [Agreement] -> [[Agreement]]
merge thetas =
[ newthetas | newthetas <- shuffle thetas,
negInternal newthetas,
posExternal newthetas ]
Next on verb concepts:
mergeCCPT :: Concept -> [Concept]
mergeCCPT (key,thetas,labs,events) =
[ (key,newthetas,labs,events) |
newthetas <- merge thetas ]
2.6 Extending the Concept List
We use the transformations plus the merge operation to extend the list ofconcepts:
allconcepts =
concepts
++
[ m | c <- concepts,
r <- reflTRANSF c,
m <- mergeCCPT r ]
++
[ m | c <- concepts,
d <- decausTRANSF c,
m <- mergeCCPT d ]
26
2.7 Features and Agreement
In this module we define a number of useful features. First we declare themodule:
module Features
where
import List
Define a datatype for features (only some of them will be relevant for thetheta system, but no matter):
data Feature = Masc | Fem | Neutr
| Sg | Pl
| Fst | Snd | Thrd
| Pts | Mts
| Nom | Acc
| PM | MM | PC | MC
| On | With | By | To
deriving (Eq,Ord)
Make sure that features are shown in a reasonable format.
27
instance Show Feature
where
show Masc = "M"; show Fem = "F"
show Neutr = "N"
show Sg = "Sg"; show Pl = "Pl"
show Fst = "1"; show Snd = "2"
show Thrd = "3"
show Pts = "+ts"; show Mts = "-ts"
show Nom = "nom"; show Acc = "acc"
show PM = "+m"; show MM = "-m"
show PC = "+c"; show MC = "-c"
show On = "on"; show By = "by"
show With = "with";show To = "to"
Define feature lists and indices:
type Agreement = [Feature]
type Idx = Int
Selecting the gender, number, person, case, tense, theta (± cause, ± mental)part of a feature list:
gen, nr, ps, cs, ts, ca, me, th
:: Agreement -> Agreement
gen = filter (\x -> elem x [Masc, Fem, Neutr])
nr = filter (\x -> elem x [Sg, Pl])
ps = filter (\x -> elem x [Fst, Snd, Thrd])
cs = filter (\x -> elem x [Nom, Acc])
ts = filter (\x -> elem x [Pts, Mts])
ca = filter (\x -> elem x [PC, MC])
me = filter (\x -> elem x [PM, MM])
th = filter (\x -> elem x [PC, MC, PM, MM])
28
Define a function combine that computes the features of a combined category(with feature clashes reported by []):
combine :: Agreement -> Agreement -> [Agreement]
combine fs1 fs2 =
[ feats | length (gen feats) <= 1,
length (nr feats) <= 1,
length (ps feats) <= 1,
length (cs feats) <= 1,
length (ts feats) <= 1,
length (ca feats) <= 1,
length (me feats) <= 1 ]
where
feats = (nub . sort) (fs1 ++ fs2)
Define a function agree indicating whether there is a feature clash or notwhen two feature lists are combined.
agree :: Agreement -> Agreement -> Bool
agree fs1 fs2 = not (null (combine fs1 fs2))
29
Chapter 3
Domain and Model
Before we can move to the events module, we will need representations for adomain of entities and for a first order model. Next, the events that we needwill be created out of the information contained in the first order model.
3.1 Representing a Domain of Entities
To illustrate the type e, we construct a small example domain of entitiesconsisting of individuals A, . . . , Z, by declaring a datatype Entity.
module Domain where
import List
data Entity = A | B | C | D | E | F | G
| H | I | J | K | L | M | N
| O | P | Q | R | S | T | U
| V | W | X | Y | Z | Unspec
deriving (Eq,Bounded,Enum)
The special entity Unspec will play an important part in our account of un-derspecified relations. It will allow us to define relations with some argumentplaces unspecified.
30
The stuff about deriving (Eq,Bounded,Enum) is there to enable us to doequality tests on entities (Eq), to refer to A as the minimum element and M
as the maximum element (Bounded), and to enumerate the elements (Enum).
To display the entities on the screen, we put the entities in the class Show,and define a show function for it. This displays the special entity Unspec as*.
instance Show Entity where
show (A) = "A"; show (B) = "B"; show (C) = "C";
show (D) = "D"; show (E) = "E"; show (F) = "F";
show (G) = "G"; show (H) = "H"; show (I) = "I";
show (J) = "J"; show (K) = "K"; show (L) = "L";
show (M) = "M"; show (N) = "N"; show (O) = "O";
show (P) = "P"; show (Q) = "Q"; show (R) = "R";
show (S) = "S"; show (T) = "T"; show (U) = "U";
show (V) = "V"; show (W) = "W"; show (X) = "X";
show (Y) = "Y"; show (Z) = "Z"; show (Unspec)= "*"
Because Entity is a bounded and enumerable type, we can put all of itselements in a finite list:
entities :: [Entity]
entities = [minBound..maxBound]
This gives:
Domain> entities
[A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,*]
We also include some utility functions in this module, for moving back andforth between function and list representations of predicates and relations.
31
pred2list :: (Enum a, Bounded a) => (a -> Bool) -> [a]
pred2list p = filter p [minBound..maxBound]
list2pred :: Eq a => [a] -> a -> Bool
list2pred = flip elem
brel2pairs :: (Enum a, Bounded a) =>
(a -> a -> Bool) -> [(a,a)]
brel2pairs r = [(x,y) | x <- [minBound..maxBound],
y <- [minBound..maxBound],
r y x ]
pairs2brel :: Eq a => [(a,a)] -> a -> a -> Bool
pairs2brel zs y x = elem (x,y) zs
trel2triples :: (Enum a, Bounded a) =>
(a -> a -> a -> Bool) -> [(a,a,a)]
trel2triples r = [(x,y,z) | x <- [minBound..maxBound],
y <- [minBound..maxBound],
z <- [minBound..maxBound],
r z y x ]
triples2trel :: Eq a => [(a,a,a)] -> a -> a -> a -> Bool
triples2trel ws z y x = elem (x,y,z) ws
Arity reduction on functions:
self :: (a -> a -> b) -> a -> b
self = \ f x -> f x x
32
Example relations:
r :: Entity -> Entity -> Bool
r = pairs2brel [(A,A),(A,B),(A,D),(B,C),(C,C),(D,C)]
s = self r
3.2 Representing a Model for Predicate Logic
All we need to specify a first order model in Haskell is a domain of entitiesand suitable interpretations of proper names and predicates. The domainof entities was given above as Entity.
module Model where
import Domain
Interpretations for proper names and definite descriptions:
ann, bill, johnny, theboy, lucy, maxx :: Entity
ann = A; bill = B; johnny = J
theboy = J; lucy = L; maxx = M
disease, nature, thevase, thegun, thestone, thewindow
:: Entity
disease = D; nature = N; thevase = V
thegun = G; thestone = S; thewindow = W
Interpretations for predicates:
33
man,boy,woman,tree,leaf,person,thing :: Entity -> Bool
man = list2pred [B,J,M]
woman = list2pred [A,C,L]
boy = list2pred [J]
tree = list2pred [T,U]
leaf = list2pred [X,Y,Z]
What a person or a thing is can be defined in terms of the predicates definedso far: a person is a man or a woman, and a thing is everything which isneither a person nor the special object Unspec. This gives Unspec the specialstatus that we need for a proper definition of semantic operation.
person = \ x -> (man x || woman x)
thing = \ x -> not (person x || x == Unspec)
Meanings for two-placed predicates, represented as
Entity -> Entity -> Bool.
Note the use of Unspec for defining underspecified relations for kill and drop.
openR, shaveR, washR, dropR :: Entity -> Entity -> Bool
openR = pairs2brel [(J,W),(S,W)]
shaveR = pairs2brel [(A,M),(J,J),(B,B)]
washR = pairs2brel [(M,L),(B,B),(M,M),(J,J),(A,A),(A,W)]
dropR = pairs2brel [(T,X),(U,Y),(U,Z),(Unspec,V)]
Meanings for three-placed predicates, represented as
Entity -> Entity -> Entity -> Bool.
We will interpret the transitive verbs ikll and break as three place relations,with the first argument giving the agent, the second argument the patient,and the third argument the instrument.
34
breakR,killR :: Entity -> Entity -> Entity -> Bool
breakR = triples2trel [(M,V,S), (J,W,G)]
killR = triples2trel
[(M,L,G), (Unspec,A,D), (Unspec,J,Unspec)]
What these entries say is that Max broke the vase with a stone, and Johnnythe window with a gun.
The verbs give and sell are also interpreted as ternary relations.
giveR,sellR :: Entity -> Entity -> Entity -> Bool
giveR = triples2trel [(M,V,L),(L,G,M)]
sellR = triples2trel [(J,J,M),(J,T,M),(A,U,M)]
Exercise 2 Check for each member of the list of sentences of Exercise 1
whether that sentence is true or false in this model.
35
Chapter 4
Events
4.1 Formalisation of Events
First order logic is based on thing splitting: basic ingredients are n-aryrelations and individual objects. R(a, b) expresses the fact that a relation R
holds between a and b. This analysis splits the fact into objects satisfyingcertain properties.
For a very long time (this goes back to Panini’s description of the struc-ture of Sanskrit, in the fifth or sixth century BC [KS69, Par90]), linguistshave favoured a different view of semantic reality. They like to analyse themeanings of sentences involving transitive verbs in terms of events:
(Subject (Verb Object))
is true if and only if an event e occurs which is of the type V denoted by theverb, and which has the subject s of the verb as its agent and the object o
of the verb as its patient:
∃e(Occurs(e) ∧ V (e) ∧ Agent(e) = s ∧ Patient(e) = o).
Is there a way to move from the thing splitting for first order logic to theevent splitting needed for natural language analysis? This is a hard one toanswer, given that nobody knows exactly what events are.
What constitutes an event? If my kissing my wife is an event, would mykissing my wife and stroking the cat (at the same time) be a single event ortwo events? Why?
36
It was established by a law court in the US recently that the attack on theTwin Towers constituted a single event rather than two events. This rulingis highly relevant for insurance claims related to the attack, for insurancecompanies put a ceiling X on the amount of damage money they will payin a case of calamity. In case of a single calamity they they have to payamount X, in case of two calamities, they have to pay twice that amount.
In the light of this difficulty of establishing what events are, it seems rea-sonable to proceed as follows. We will simply construct a datatype with anumber of important properties that events should have, and declare theelements of this datatype to be events. Some requirements on events are thefollowing:
1. Existence of an event (type) is not the same as occurring of that event.
2. There should be a function Occur from events to truth values withthe obvious property that events occur iff they correspond to truestatements.
3. There should be a functions from events to a number of roles for thatevent.
4. There should be predications on events that allow us to classify events(as “kissing” events, “kicking” events, and so on).
5. There should be transformations on event predications, such as satu-
ration, reflexivisation, and perhaps others.
6. There should be an involves relation on event predications, to expressfacts such as “kissing involves touching”.
From a formal point of view, what an object is like is determined by how itbehaves under the operations that are defined on it. For events the crucialoperations are the role functions 1st role, 2nd role, and so on, plus trans-formations like the saturation transformation, and so on. Can we find adatatype satisfying these requirements? Can we keep it simple? We don’t(yet) want to get involved in the business of reification of events [HvL].
A criticism of a certain representation of events should always take the form:“If you represent them like this, the agent function gives the wrong result”,etcetera. Thinking like this is an acquired habit, by the way; it is can bepicked up in courses of mathematics or logic or computer science.
37
4.2 Events as Structured Objects
We propose the following simple way to reanalyse the basic fact R(a, b) asan event e:
e = (λy(λxR(x, y), a), b)
The advantage of this representation is that we can retrieve the relation andthe roles. In this example, the relation is λyλx.R(x, y). Let us agree tocount the roles of an event from the inside out. Then the first role in theexample is a, and the second role is b.
A perhaps subtle point is the difference between the predication R(a, b)and the event (λy(λxR(x, y), a), b). To appreciate the distinction, first notethat the predication and the event have different types. The type of thepredication is t, that of the event is (e → (e → t, e), e). The type of thepredication is simply a truth value, the type of the event is built from truthvalues and entities with the operations of pairing and functional abstraction.Next, note that the relation λyλx.R(x, y) and the two roles a and b cannotbe retrieved from the predication R(a, b), simply because R(a, b) denotes atruth value, and truth values do not contain relations or entities. The reasonthat the relation and the roles can be retrieved from the event is becausethe event was built from the relation and the roles in the first place.
So, events are structured objects, with types given by the following datatypedeclaration. In the definition, we use e for the type of events.
• A basic event has the form p, where p has type t (t is a truth value),
• A complex event has the form (F, a), where F has type e → e anda is an entity.
Basic events are propositions, complex events are constructed out of simplerevents and entities. The complexity of an event can reach arbitrary depth:Relations of arbitrary arity can be mapped to event sets without loss ofinformation.
Note that events are built from entities and truth values with the typetheoretic machinery of abstraction and pairing. The type e that we use for
38
events is shorthand for
t,
(e → t, e),(e → (e → t, e), e),(e → (e → (e → t, e), e), e),
...
In other words, e is a polymorphic type.
This allows for a natural definition of the various roles of a complex event.
• If e is a basic event, it has no role.
• If (F, a) is a complex event of depth n, its n-th role is a, its n − 1-throle is the n − 1-th role of F (a), and so on.
4.3 Occurring of Events
Events either happen (or: take place, or: occur) or they don’t happen. Wewill say that an event e is actual in a first order model M if e occurs in M ,where occurring in M is defined as follows:
• For a basic event e = p to occur in M is simply for its proposition tobe true in M . Thus, p occurs in M iff p is true in M .
• For a complex event to occur in M is defined recursively: (F, b) occursin M iff F (b) occurs in M .
Immediately from this definition we get that saying that an event occurs isequivalent to asserting the corresponding fact. The function occurs has typee → t, it maps events to truth values, to True in case the event occurs, toFalse in case it does not.
We will take care to map relations to actual events. Let us say that for anevent to exist in a first order model M is the same as for that event to occurin M .
4.4 A Datatype for Events
First we declare a module for events, and we import modules for a domainand a (first order) model.
39
module Events where
import Domain
import Model
A datatype for events.
data Ev = Basic Bool
| Compl (Entity -> Ev) Entity
The roles of an event, represented as a list of entities.
roles :: Ev -> [Entity]
roles (Basic _) = []
roles (Compl f a) = roles (f a) ++ [a]
To show an event, we show its roles:
instance Show Ev where
show e = show (roles e)
The depth of an event equals the length of its role list.
depth :: Ev -> Int
depth = length . roles
Occurrence of an event:
40
occurs :: Ev -> Bool
occurs (Basic b) = b
occurs (Compl f a) = occurs (f a)
Extracting a particular role from an event by means of its index:
role :: Int -> Ev -> Entity
role _ (Basic b) = error "no such role"
role n (Compl f a) | depth (f a) == (n-1) = a
| otherwise = role n (f a)
4.5 Conversions
Conversion between predicates/relations and events: from predicates toevents.
A one place predicate P on a model M = (D, I) is a set of elements of thedomain D of the model. If a model M = (D, I) and a predicate λx.Px onM are given, the corresponding set of events is given by:
{(λx.Px, d) | d ∈ D ∧ Pd is true in M}
Here is the implementation:
pred2ev :: (Entity -> Bool) -> Entity -> [Ev]
pred2ev p agent =
[ Compl (\ x -> Basic (p x)) agent | p agent ]
pred2evs :: (Entity -> Bool) -> [Ev]
pred2evs p = [ e | a <- entities,
e <- pred2ev p a ]
Conversion between predicates/relations and events: from relations to events.
41
A two place relation R on a model M is a set of pairs of elements of thedomain of the model. If a model M = (D, I) and a relation λyλx.Ryx onM are given, the corresponding set of events is given by:
{(λy(λx.Ryx, d1), d2) | d1, d2 ∈ D ∧ Rd2d1 is true in M}
And so on, for relations of higher arity.
Here is the implementation, for binary relations:
brel2ev :: (Entity -> Entity -> Bool)
-> Entity -> Entity -> [Ev]
brel2ev r role1 role2 =
[ Compl (\ y ->
Compl (\ x ->
Basic (r y x)) role1) role2 |
r role2 role1 ]
brel2evs :: (Entity -> Entity -> Bool) -> [Ev]
brel2evs r = [ e | a <- entities,
b <- entities,
e <- brel2ev r a b ]
We can do the same for ternary relations:
42
trel2ev :: (Entity -> Entity -> Entity -> Bool)
-> Entity -> Entity -> Entity -> [Ev]
trel2ev r role1 role2 role3 =
[ Compl (\ z ->
Compl (\ y ->
Compl (\ x ->
Basic (r z y x)) role1) role2) role3 |
r role3 role2 role1 ]
trel2evs ::
(Entity -> Entity -> Entity -> Bool) -> [Ev]
trel2evs r = [ e | a <- entities,
b <- entities,
c <- entities,
e <- trel2ev r a b c ]
And so on, but we leave it at this.
Conversion between predicates/relations and events: from sets of actualevents to predicates.
Let E be a set of actual events that have a depth ≥ i. Then the predicatethat results from abstraction over role i is given by:
λx.∃e ∈ E(Rolei(e) = x).
Here is the implementation:
evs2pred :: Int -> [Ev] -> Entity -> Bool
evs2pred i es = \ x -> any (\e -> role i e == x) es
Conversion between predicates/relations and events: from sets of actualevents to relations. Let E be a set of actual events that have a depth≥ max(i, j). Then the corresponding relation is given by:
λyλx.∃e ∈ E(Rolei(e) = x ∧ Rolej(e) = y).
43
Here is the implementation:
evs2brel :: Int -> Int -> [Ev] -> Entity -> Entity -> Bool
evs2brel i j es = \ y x ->
any (\e -> (role i e == x && role j e == y)) es
4.6 The Reflexivisation Transformation
This is a transformation on event lists. It takes a pair of two roles and a listof events and transforms the event list into a list of ‘reflexive’ events. Thetransformation is defined by selection of the events for which the roles listedin the first argument pair coincide.
refl :: (Int,Int) -> [Ev] -> [Ev]
refl (i,j) events =
[ e | e <- events, role i e == role j e ]
Aside There is another way of defining refl:
refl’ :: (Int,Int) -> [Ev] -> [Ev]
refl’ (i,j) = (pred2evs 1). self . (evs2brel i j)
This uses the composition of three mapping functions. But note that refl’flattens the events in a way that refl does not.
4.7 The Saturation Transformation
What this should do is make sure that somebody or something realizes therole listed in the first argument. The only entity in the domain that is nota somebody or a something is ∗ (Unspec).
44
When the semantic transformation of saturation for a role i is performed ona set of events E, it should yield the following subset of E:
{e ∈ E | ∃y Rolei(e) = y}. (4.1)
Now suppose the elements of E are such that role ri is defined on them.Then the operation is vacuous, and the result is that (4.1) equals E itself.Suppose, on the other hand, that the elements of E are such that role ri isnot defined on them. Then (4.1) is ill-defined.
To let saturation make semantic sense, we must let the existential quantifier∃y in 4.1 range over the entities in the domain of our model, excluding thedummy object ∗ that we used for defining underspecified relations on ourmodel. This interpretation of existential quantification over the domain isreasonable, for ∗ is not a proper entity in the domain. Therefore, the setgiven in (4.1) is the same as that given in (4.2).
{e ∈ E | Rolei(e) 6= ∗}. (4.2)
This interpretation makes the semantic operation of saturation non-vacuous.It leads to the following implementation:
sat :: Int -> [Ev] -> [Ev]
sat i events = [ e | e <- events, role i e /= Unspec ]
4.8 Event Properties
Event properties are represented as lists. We create them from the infor-mation in the first order model by means of the mapping from relations toevents.
opening, shaving, washing, dropping :: [Ev]
opening = brel2evs openR
shaving = brel2evs shaveR
washing = brel2evs washR
dropping = brel2evs dropR
45
Some event properties created by mapping ternary relations to event lists:
breaking, killing, giving, selling :: [Ev]
breaking = trel2evs breakR
killing = trel2evs killR
giving = trel2evs giveR
selling = trel2evs sellR
Exercise 3 Can you think of still other ways to formalize events? It was
said above that the proper way to arrive at formalisations of events is to
first determine what events should do, and next construct objects that do
just that. Bear in mind that role functions for the 1st, 2nd, . . . , role should
be definable, that a function for checking whether an event is actual should
be definable, and that operations like reflexivisation should continue to make
sense for your formalization.
46
Chapter 5
Syntax
5.1 A Simple Phrase Structure Grammar
We will implement a parser based on the following simple phrase structuregrammar.
S =⇒ DP VP
DP =⇒ Name
DP =⇒ Pers
DP =⇒ DET CN
DET =⇒ every | some | no | the
VP =⇒ Aux VP-ts [DP]
VP =⇒ VP+ts [DP]
Aux =⇒ was | has
The category Pers is for personal pronouns. [DP] indicates an empty ornon-empty list of DPs. We will use feature agreement to get basic factsabout case right, such as I broke the vase and Max shaved me versus *Me
broke the vase and *Max shaved I.
Of course, this parser will overgenerate a lot. E.g., all of the following willget a parse:
(5.1) ?Max broke.
(5.2) ?The vase broke Max.
47
(5.3) *Max broke the vase Lucy.
(5.4) The vase was broken.
(5.5) *The vase was broken Max.
(5.6) *The vase was broken Max Lucy.
(5.7) The vase has broken.
(5.8) *The vase has broken Max.
(5.9) *The vase has broken Max Lucy.
And so on. It will be the task of the theta system to make the properselection from the generated trees, and give them the appropriate meanings.
5.2 Categories for DPs, VPs and Sentences
The module Cat imports the standard List module and the Features mod-ule.
module Cat
where
import List
import Features
Recall the datatype for features that was declared in the Features module,together with functions gen, nr, ps, cs, ts, ca, me, th for filtering outsubclasses of the features (Section 2.7).
These are used in the following declaration of the class of categories.
Declare a class Cat for categories that carry feature information, with a func-tion fs that gives the feature list of a category, functions gender, number,sperson, scase, stheta for the syntactic gender, number, person, case andtheta features of the category.
48
class (Eq a, Show a) => Cat a where
fs :: a -> Agreement
gender, number, sperson, scase, stheta :: a -> Agreement
gender cat = gen (fs cat)
number cat = nr (fs cat)
sperson cat = ps (fs cat)
scase cat = cs (fs cat)
stheta cat = th (fs cat)
For the phonological realisation component in the lexicon we will use strings.Here is an appropriate datatype:
type Phon = String
Sentences are in class Cat.
data Sent = Sent DP VPbar
deriving Eq
instance Cat Sent
where
fs (Sent dp vpbar) = []
It should be possible to display sentences on the screen, so Sent should bein class Show. We will do so explicitly, and we define the show function forsentences that uses indentation.
instance Show Sent
where
show (Sent dp vpbar) =
"S" ++ "\n " ++ show dp
++ "\n " ++ show vpbar
49
Proper names, personal pronouns and complex DPs carry explicit featureinformation. The feature information of a complex DP are inherited fromits CN.
data DP = Name Phon Agreement
| PERS Agreement
| DP DET CN
deriving Eq
instance Show DP
where
show (Name phon ftrs) = "DP " ++ phon ++ show ftrs
show (PERS ftrs) = "PERS" ++ show ftrs
show (DP det cn) = "DP " ++ show det ++ show cn
instance Cat DP
where
fs (Name _ ftrs) = ftrs
fs (PERS ftrs) = ftrs
fs (DP det cn) = fs cn
The entries EVERY, SOME, NO, THE:
data DET = EVERY | SOME | NO | THE
deriving (Eq,Show)
instance Cat DET
where fs _ = []
Common nouns are all stored in the lexicon, with the appropriate featureinformation.
50
data CN = LexCN Phon Agreement
deriving Eq
instance Show CN
where
show (LexCN phon ftrs) = ’ ’:phon ++ show ftrs
instance Cat CN
where
fs (LexCN _ ftrs) = ftrs
data Prep = ON | WITH | BY | TO
deriving (Eq,Show)
instance Cat Prep
where
fs ON = [On]
fs WITH = [With]
fs BY = [By]
fs TO = [To]
data PP = PP Prep DP
deriving (Eq,Show)
instance Cat PP
where fs (PP prep dp) = (nub . sort) (fs prep ++ fs dp)
51
data AUX = BE | HAVE
deriving (Eq,Show)
instance Cat AUX
where fs _ = [Pts]
VP gets its features from the VP below, but the ±ts feature is deleted.
data VPbar = TsdVP VP
| AuxVP AUX VP
deriving (Eq,Show)
instance Cat VPbar
where
fs (TsdVP vp) = filter (/= Pts) (fs vp)
fs (AuxVP _ vp) = filter (/= Mts) (fs vp)
Verbs get strung together with lists of DPs to form VPs.
52
data VP = Verb Phon Agreement [DP]
deriving Eq
instance Show VP
where
show (Verb phon ftrs []) =
phon ++ show ftrs
show (Verb phon ftrs dplist) =
phon ++ show ftrs ++ showDPs dplist
showDPs [] = ""
showDPs (dp:dps) = "\n " ++ show dp ++ showDPs dps
instance Cat VP
where
fs (Verb _ ftrs _) = ftrs
5.3 A Simple Phrase Structure Parser
Parse Strategy
The parser works in a simple left to right fashion. Its input is a list of words,and it will attempt to parse the beginning of the input list as a phrase ofthe appropriate category.
If a parse fails it will return an empty list. If it succeeds it returns a list ofpairs, one for each parse that was found. (As it happens, the grammar weare going to use is not ambiguous, but in principle the parser can handlestructural ambiguities.)
First element of a pair in the parse output is the phrase that was found bythe parse, second element is the remainder of the input list. A very simpleexample:
parseDP ["max", "shaved", "bill"]
will yield:
53
[(Name "max" [Masc,Sg,Thrd], [ "shaved", "bill"])]
We start by declaring a module, and importing the stuff we need: List andChar (two standard modules), and Cat and Concepts.
module Parser
where
import List
import Char
import Features
import Cat
The parser will operate on lists of words. Here is the datatype for such lists:
type Words = [String]
DPs
parseDP :: Words -> [(DP,Words)]
parseDP = \xs ->
[ (DP det cn,zs) | (det,ys) <- parseDET xs,
(cn, zs) <- parseCN ys ]
++
[ (dp,ys) | (dp,ys) <- lexDP xs ]
Names in the lexicon:
54
lexDP :: Words -> [(DP,Words)]
lexDP ("ann":xs) = [(Name "ann" [Fem,Sg,Thrd],xs)]
lexDP ("bill":xs) = [(Name "bill" [Masc,Sg,Thrd],xs)]
lexDP ("johnny":xs) = [(Name "johnny" [Masc,Sg,Thrd],xs)]
lexDP ("max":xs) = [(Name "max" [Masc,Sg,Thrd],xs)]
lexDP ("lucy":xs) = [(Name "lucy" [Fem,Sg,Thrd],xs)]
lexDP ("disease":xs) = [(Name "disease" [Neutr,Sg,Thrd],xs)]
For simplicity we treat a few definite descriptions as names.
lexDP ("theboy":xs) =
[(Name "theboy" [Masc,Sg,Thrd],xs)]
lexDP ("the":"vase":xs) =
[(Name "thevase" [Neutr,Sg,Thrd],xs)]
lexDP ("the":"gun":xs) =
[(Name "thegun" [Neutr,Sg,Thrd],xs)]
lexDP ("the":"stone":xs)=
[(Name "thestone" [Neutr,Sg,Thrd],xs)]
lexDP ("the":"window":xs)=
[(Name "thewindow" [Neutr,Sg,Thrd],xs)]
It is also useful to give the parser a little help with nothing and nobody.
lexDP ("nothing":xs) = lexDP ("no":"thing":xs)
lexDP ("nobody":xs) = lexDP ("no":"person":xs)
Personal pronouns:
55
lexDP ("i":xs) = [(PERS [Sg,Fst,Nom],xs)]
lexDP ("me":xs) = [(PERS [Sg,Fst,Acc],xs)]
lexDP ("you":xs) = [(PERS [Snd],xs)]
lexDP ("he":xs) = [(PERS [Masc,Sg,Thrd,Nom],xs)]
lexDP ("him":xs) = [(PERS [Masc,Sg,Thrd,Acc],xs)]
lexDP ("she":xs) = [(PERS [Fem,Sg,Thrd,Nom],xs)]
lexDP ("her":xs) = [(PERS [Fem,Sg,Thrd,Acc],xs)]
lexDP ("it":xs) = [(PERS [Neutr,Sg,Thrd],xs)]
lexDP _ = []
Determiners
Only a few, just for purposes of illustration.
lexDET :: Words ->[(DET,Words)]
lexDET ("every":xs) = [(EVERY,xs)]
lexDET ("some":xs) = [(SOME,xs)]
lexDET ("a":xs) = [(SOME,xs)]
lexDET ("no":xs) = [(NO,xs)]
lexDET _ = []
parseDET :: Words -> [(DET,Words)]
parseDET = lexDET
CNs
56
lexCN :: Words ->[(CN,Words)]
lexCN ("man":xs) = [(LexCN "man" [Masc,Sg,Thrd],xs)]
lexCN ("woman":xs) = [(LexCN "woman" [Fem,Sg,Thrd],xs)]
lexCN ("boy":xs) = [(LexCN "boy" [Masc,Sg,Thrd],xs)]
lexCN ("person":xs) = [(LexCN "person" [Sg,Thrd],xs)]
lexCN ("thing":xs) = [(LexCN "thing" [Neutr,Sg,Thrd],xs)]
lexCN ("tree":xs) = [(LexCN "tree" [Neutr,Sg,Thrd],xs)]
lexCN ("leaf":xs) = [(LexCN "leaf" [Neutr,Sg,Thrd],xs)]
lexCN ("window":xs) = [(LexCN "window" [Neutr,Sg,Thrd],xs)]
lexCN _ = []
parseCN :: Words -> [(CN,Words)]
parseCN = lexCN
DP-lists
parseDPs :: Words -> [([DP],Words)]
parseDPs = \ xs ->
if parseDP xs == []
then [([],xs)]
else [ (dp:dps, zs) | (dp,ys) <- parseDP xs,
(dps,zs) <- parseDPs ys ]
Preps
57
lexPrep :: Words -> [(Prep,Words)]
lexPrep ("on":xs) = [(ON,xs)]
lexPrep ("by":xs) = [(BY,xs)]
lexPrep ("with":xs) = [(WITH,xs)]
lexPrep ("to":xs) = [(TO,xs)]
lexPrep _ = []
parsePrep :: Words -> [(Prep,Words)]
parsePrep = lexPrep
PPs
parsePP :: Words -> [(PP,Words)]
parsePP = \xs ->
[ (PP prep dp,zs) | (prep,ys) <- parsePrep xs,
(dp, zs) <- parseDP ys ]
Auxiliaries
lexAUX :: Words -> [(AUX,Words)]
lexAUX ("was":xs) = [(BE,xs)]
lexAUX ("has":xs) = [(HAVE,xs)]
lexAUX _ = []
parseAUX :: Words -> [(AUX,Words)]
parseAUX = lexAUX
58
VPbars
Note the check on the ±ts feature.
parseVPbar :: Words -> [(VPbar,Words)]
parseVPbar = \xs ->
[ ((AuxVP aux vp),zs) | (aux,ys) <- parseAUX xs,
(vp,zs) <- parseVP ys,
notElem Pts (fs vp) ]
++
[ ((TsdVP vp),ys) | (vp,ys) <- parseVP xs,
elem Pts (fs vp) ]
VPs
59
lexVP :: Words -> [(VP,Words)]
lexVP ("broke":xs) = [(Verb "break" [Pts] [],xs)]
lexVP ("broken":xs) = [(Verb "break" [Mts] [],xs)]
lexVP ("killed":xs) = [(Verb "kill" [Pts] [],xs),
(Verb "kill" [Mts] [],xs)]
lexVP ("died":xs) = [(Verb "die" [Pts] [],xs)]
lexVP ("opened":xs) = [(Verb "open" [Pts] [],xs),
(Verb "open" [Mts] [],xs)]
lexVP ("shaved":xs) = [(Verb "shave" [Pts] [],xs),
(Verb "shave" [Mts] [],xs)]
lexVP ("shaven":xs) = [(Verb "shave" [Mts] [],xs)]
lexVP ("washed":xs) = [(Verb "wash" [Pts] [],xs),
(Verb "wash" [Mts] [],xs)]
lexVP ("dropped":xs) = [(Verb "drop" [Pts] [],xs),
(Verb "drop" [Mts] [],xs)]
lexVP ("gave":xs) = [(Verb "give" [Pts] [],xs)]
lexVP ("given":xs) = [(Verb "give" [Mts] [],xs)]
lexVP ("received":xs) = [(Verb "receive" [Pts] [],xs),
(Verb "receive" [Mts] [],xs)]
lexVP ("sold":xs) = [(Verb "sell" [Pts] [],xs),
(Verb "sell" [Mts] [],xs)]
lexVP ("bought":xs) = [(Verb "buy" [Pts] [],xs),
(Verb "buy" [Mts] [],xs)]
lexVP _ = []
parseVP :: Words -> [(VP,Words)]
parseVP = \xs ->
[ (Verb phon ftrs dps,zs)|
(Verb phon ftrs _,ys) <- lexVP xs,
(dps,zs) <- parseDPs ys,
all (\ dp -> notElem Nom (fs dp)) dps ]
Sentences
60
Note the use of agree to check subject/verb concord, and the case check onthe subject by means of notElem Acc (fs dp).
parseSent :: Words -> [(Sent,Words)]
parseSent = \xs ->
[ (Sent dp vpbar,zs) | (dp,ys) <- parseDP xs,
(vpbar,zs) <- parseVPbar ys,
agree (fs dp) (fs vpbar),
notElem Acc (fs dp) ]
Scanning and Parsing The scan function scans an input string and putswhitespace in front of punctuation marks.
scan :: String -> String
scan [] = []
scan (x:xs) | x == ’.’ = ’ ’:x:scan xs
| otherwise = x:scan xs
The parse function uses the predefined function words to split the input intoseparate words. Punctuation marks should come out as separate words; weuse scan for that. Also, for robustness, we convert everything to lowercase.A sentence should end with a period.
parse :: String -> [Sent]
parse string = let
string’ = map toLower string in
[ s | (s,["."]) <- parseSent (words (scan string’)) ]
Now try it out:
61
Parser> parse "I broke the vase."
[S
PERS[Sg,1,nom]
VP break[+ts]
DP thevase[N,Sg,3]]
Parser> parse "Me broke the vase."
[]
Parser> parse "Max broke."
[S
DP max[M,Sg,3]
VP break[+ts]]
Parser> parse "Max broke the vase."
[S
DP max[M,Sg,3]
VP break[+ts]
DP thevase[N,Sg,3]]
Parser> parse "Some man broke the vase."
[S
DP SOME man[M,Sg,3]
VP break[+ts]
DP thevase[N,Sg,3]]
Parser> parse "The vase broke."
[S
DP thevase[N,Sg,3]
VP break[+ts]]
Parser> parse "The vase was broken."
[S
DP thevase[N,Sg,3]
AuxVP BE break[-ts]]
Parser> parse "The vase has broken."
[S
DP thevase[N,Sg,3]
AuxVP HAVE break[-ts]]
Parser> parse "The vase was broken Max."
[S
DP thevase[N,Sg,3]
AuxVP BE break[-ts]
DP max[M,Sg,3]]
Parser> parse "Max has broken the vase."
[S
62
DP max[M,Sg,3]
AuxVP HAVE break[-ts]
DP thevase[N,Sg,3]]
Parser> parse "max has broken the vase lucy the gun."
[S
DP max[M,Sg,3]
AuxVP HAVE break[-ts]
DP thevase[N,Sg,3]
DP lucy[F,Sg,3]
DP thegun[N,Sg,3]]
Parser> parse "Some tree dropped every leaf."
[S
DP SOME tree[N,Sg,3]
VP drop[+ts]
DP EVERY leaf[N,Sg,3]]
5.4 Boring Latex and System Stuff
Here is module for stand-alone use. This module can be used to compilea program that parses the argument that the program is called with, andwrites the resulting parse tree in LATEX format to a temporary file.
module Main
where
import System
import Parser
import Cat
Define a class of types that can be displayed with LATEX. For this class afunction latex is defined for displaying the members of the category outin LATEX format. In the case of the members of class Cat, we will employthe tree format of the LATEX package qtree. Qtree is a package written byJeffrey Mark Sisskind, with a front end by Alexis Dimitriadis. The reader is
63
referred to the documentation of this package for details of the code below.Bear in mind also that \ is a special character in Haskell, and that \\ hasto be used for quoting the backslash character.
First we say that the Latex class is a subclass of the Show class, and thatmembers of the class should have a function latex defined on them.
class Show a => Latex a where
latex :: a -> String
Next, we declare every category to be an instance of Latex, and we definethe latex function for the category.
instance Latex Sent where
latex (Sent dp vpbar) = "[.S " ++ latex dp ++ " "
++ latex vpbar ++ " ]"
instance Latex DP where
latex (Name phon ftrs) =
"[.DP {" ++ phon ++ show ftrs ++ "} ]"
latex (PERS ftrs) =
"[.DP {" ++ show ftrs ++ "} ]"
latex (DP det cn) =
"[.DP " ++ latex det ++ latex cn ++ " ]"
instance Latex DET where
latex EVERY = "[.DET {every} ]"
latex SOME = "[.DET {some} ]"
latex NO = "[.DET {no} ]"
latex THE = "[.DET {the} ]"
64
instance Latex CN where
latex (LexCN phon ftrs) =
"[.CN {" ++ phon ++ ’}’:show ftrs ++ " ]"
instance Latex AUX where
latex BE = "[.AUX {be} ]"
latex HAVE = "[.AUX {have} ]"
instance Latex VPbar where
latex (TsdVP vp)
= "[.{$\\overline{\\text{VP}}$} "
++ latex vp ++ " ]"
latex (AuxVP aux vp)
= "[.{$\\overline{\\text{VP}}$} "
++ latex aux ++ latex vp ++ " ]"
instance Latex VP where
latex (Verb phon ftrs dplist)
= "[.VP {" ++ phon
++ show ftrs ++ "} "
++ latexDPs dplist
++ " ]"
where
latexDPs [] = ""
latexDPs (dp:dps) = latex dp ++ " " ++ latexDPs dps
Now that we have the latex formatting function defined for every category,we can define a LATEX tree drawing function:
65
trees :: String -> [String]
trees string =
[ "\\Tree " ++ latex s | s <- parse string ]
The main function of the module is called main. This is the function thatgets called when the module is compiled for stand-alone use.
main :: IO ()
main = do {
args <- getArgs;
let trs = trees (concat args)
in
writeFile "/tmp/tree.tex"
(if null trs
then "NO PARSE" else (concat trs));
}
This parses a sentence, and saves a LATEX-formatted tree of the parse to atemporary file (/tmp/tree.tex) for later display.
LATEX display can then yield trees like the following:
S
DP
max[M,Sg,3]
VP
VP
break[+ts] DP
thevase[N,Sg,3]
66
S
DP
DET
some
CN
leaf[N,Sg,3]
VP
AUX
be
VP
drop[-ts]
If the program is compiled as prs, then the following is an example of aUNIX shell script for displaying parse trees:
#1/bin/bash
pushd /tmp
/home/jve/bin/prs "$1"
latex ParseTree
popd
xdvi -mfmode ljfour:600 /tmp/ParseTree &
Call this script parse. Once installed, this script can be invoked from thecommand line, as follows:
$ parse "Max broke the vase."
67
Chapter 6
Semantics
6.1 Interpretation
For interpretation we need everything we have collected in our toolkit so far.
module Interp
where
import List
import Features
import Domain
import Model
import Events
import Concepts
import Cat
import Parser
6.2 Arbitrary Arity Relations
The problem of encoding relations in type theory in such a way that the usuallogical operations can be applied to them (relations should be ‘conjoinable’,
68
as the jargon has it) has been studied extensively in the semantic literature.See, e.g., [Mus89a, Mus89b], where it is shown that relations instead offunctions can be taken as the basic ingredients of type theory.
We will adopt a slightly different approach, by defining a type for arbitraryarity relations in polymorphic type theory. Declare Rel as a datatype ofarbitrary arity relations, as follows.
data Rel = R1 Bool | R2 (Entity -> Rel)
Extracting the relation from an event:
rel :: Ev -> Rel
rel (Basic b) = R1 b
rel (Compl f a) = R2 (\ x -> rel (f x))
Applying a relation to its argument:
apply :: Rel -> Entity -> Rel
apply (R1 _) _ = error "no argument position left"
apply (R2 f) a = f a
An arity function for determining the arity of a relation.
arity :: Rel -> Int
arity (R1 _) = 0
arity (R2 f) = arity (f A) + 1
Encoding relations of various arities into Rels:
69
encode0 :: Bool -> Rel
encode0 b = R1 b
encode1 :: (Entity -> Bool) -> Rel
encode1 f = R2 (\ x -> encode0 (f x))
encode2 :: (Entity -> Entity -> Bool) -> Rel
encode2 f = R2 (\ x -> encode1 (f x))
encode3 :: (Entity -> Entity -> Entity -> Bool) -> Rel
encode3 f = R2 (\ x -> encode2 (f x))
If we know the arity of a relation, it can be decoded into the appropriatefunction of type Entity -> ... -> Bool. Note that the decoding functiondecode0 is only defined for relations of arity 0, the function decode1 onlyfor relations of arity 1, and so on:
decode0 :: Rel -> Bool
decode0 (R1 b) = b
decode1 :: Rel -> Entity -> Bool
decode1 (R2 f) = \ x -> decode0 (f x)
decode2 :: Rel -> Entity -> Entity -> Bool
decode2 (R2 f) = \ x -> decode1 (f x)
decode3 :: Rel -> Entity -> Entity -> Entity -> Bool
decode3 (R2 f) = \ x -> decode2 (f x)
Finally, here is a flexible means of representing a relation as a list of tuples(represented in turn as lists):
70
rel2lists :: Rel -> [[Entity]]
rel2lists (R1 b) = [[] | b ]
rel2lists (R2 f) =
[ tuple ++ [x] | x <- entities,
tuple <- rel2lists (f x) ]
This gives:
Interp> trel2triples giveR
[(L,G,M),(M,V,L)]
Interp> (rel2lists . encode3) giveR
[[M,V,L],[L,G,M]]
So why didn’t we use the type [[Entity]] as the type of arbitrary arityrelations in the first place? The trouble is that the type [[Entity]] doesnot guarantee a fixed arity in the way Rel does. Translating from Rel to[[Entity]] yields lists that are all of the same length, with the length deter-mined by the arity of the relation. But the type [[Entity]] is more generalthan that. List members can have different lengths, which is undesirable forthe representation of relations.
6.3 Boolean Algebras of Relations
In this section we define generalisations of the boolean operations to rela-tions.
Conjoining of relations of the same arity is a generalisation of conjunctionfor booleans. The result is conjoining relations r and s is called the booleanmeet of r and s, and is often denoted with ru s. It is implemented like this:
71
conjR :: Rel -> Rel -> Rel
conjR r s | arity r == arity s = conjR’ r s
| otherwise = error "different arities"
where
conjR’ (R1 b) (R1 c) = R1 (b && c)
conjR’ (R2 f) (R2 g) =
R2 (\ x -> conjR’ (f x) (g x))
Disjoining relations works the same way. The result of disjoining r and s iscalled the boolean join of r and s, and is denoted with r t s.
disjR :: Rel -> Rel -> Rel
disjR r s | arity r == arity s = disjR’ r s
| otherwise = error "different arities"
where
disjR’ (R1 b) (R1 c) = R1 (b || c)
disjR’ (R2 f) (R2 g) =
R2 (\ x -> disjR’ (f x) (g x))
Finally, here is an operation for negating a relation. The negation of arelation r is often written as r.
negR :: Rel -> Rel
negR (R1 b) = R1 (not b)
negR (R2 f) = R2 (\ x -> negR (f x))
These definitions illustrate that relations of the same arity form a booleanalgebra [DP90, Hal63].
These operations are what is needed for performing logical relations on com-plex VPs, to get interpretations for to hurt but not kill, to break or drop, to
give or sell, and so on. Here are some illustrations:
Interp> rel2lists (disjR (encode2 breakR) (encode2 dropR))
72
[[M,V],[S,V],[*,V],[G,W],[J,W],[T,X],[U,Y],[U,Z]]
Interp> rel2lists (disjR (encode3 giveR) (encode3 sellR))
[[M,V,L],[L,G,M],[J,J,M],[J,T,M],[A,U,M]]
Note that the generalized operations for conjunction, disjunction and nega-tion are in fact generalizations of conjunction, disjunction and negation forBooleans. Booleans can be viewed as 0-ary relations, and we have general-ized the operations to n-ary relations, for arbitrary n.
6.4 The Need for Flexible Type Assignment
There is extensive semantic literature on the need for flexible type assign-ment to syntactic categories (see, e.g., [Hen93]). Many of the argumentsfor this have to do with the need to account for various scoping ambiguitiesresulting from the interaction of quantified DPs with other quantified DPsor with intensional verb contexts.
Now note that the type Rel is flexible, for this type can do duty for thewhole family of types t, e → t, e → e → t, and so on.
In the semantics for the theta system we will use the flexible type Rel forthe interpretations of verbs, and we will perform a ‘flexible lift’ on DP inter-pretations, so that a DP can be viewed as an operation on verb meanings,i.e., as a function of type Rel -> Rel. For this perspective on the semanticsof DPs, compare [Kee87, Kee92].
6.5 Lifting the Types of DP Interpretations
An important conversion function that we need is that from a characteristicfunction of properties to a function that maps relations to relations (typeRel -> Rel). We will use this to lift the type of DP interpretations.
Consider the problem of applying a function of type
(Entity -> Bool) -> Bool
not to a property (type Entity -> Bool), but to a relation with arity > 1.Note that Entity -> Bool can be viewed as a the type of a relation of arity1, and Bool as the type of a relation of arity 0. Thus,
73
(Entity -> Bool) -> Bool
is the type of reduction of 1-ary to 0-ary relations.
So what about the general case: the reductions of n + 1-ary relations ton-ary relations?
The general shape of a relation of arity n + 1 is:
λyλx1 · · · λxn.r (6.1)
Here, r is a Boolean expression (type Bool). To apply a property functionto this, we will first convert the n + 1 place relation to another n + 1 placerelation that takes it arguments in a different order:
λx1 · · · λxnλy.r (6.2)
Call the conversion from (6.1) to (6.2) wrapping.
Now we know our specification: we want to get from (6.1) to (6.2). Howcan we bring this about?
Let W (λyλx1 · · · λxn.r) be the result of wrapping the relation (λyλx1 · · · λxn.r).Then the operation W can be defined by recursion as follows:
W (λy.r) := (λy.r)
W (λyλx1 · · · λxn.r) := λx.W λy((λyλx1 · · · λxn.r)(y)(x))
Here is the implementation:
wrap :: Rel -> Rel
wrap (R1 _) = error "no property"
wrap (R2 f) =
if arity (f A) == 0 then R2 f
else R2 (\ x -> wrap (R2 (\ y -> apply (f y) x)))
Converting a property function f into a relation transformer is done by firstwrapping the argument relation, and next reducing that wrapped relationby recursion.
If the wrapped argument relation has the form λy.r, with r of type Bool,then property function f can be applied to it, yielding a boolean f(λy.r).
74
If the wrapped argument relation has the form λx1 · · · λxnλy.r, the newrelation is given by (6.3).
λx1 · · · λxn.f(λy.r) (6.3)
So this is what reduction of a relation λx1 · · · λxnλy.r should yield. Ourobvious next question is: how is the operation defined that yields this result?
Let (6.4) be the result of reducing f with λx1 · · · λxnλy.r.
R f (λx1 · · · λxnλy.r). (6.4)
Then our question becomes: how is R defined? The recursion that definesthe operation R can be expressed as follows:
R f (λy.r) := f(λy.r)
R f (λx1 · · · λxnλy.r) := λx.R f ((λx1 · · · λxnλy.r)(x)).
Here is the implementation:
reduce :: ((Entity -> Bool) -> Bool) -> Rel -> Rel
reduce f r
| arity r == 1 = R1 (f (decode1 r))
| otherwise = R2 (\ x -> (reduce f (apply r x)))
Using this, the conversion function that we need for lifting the types of DPinterpretations is defined as follows (assume f is the DP interpretation andr is the interpretation of the verb):
lift = λfλr.R f (W r).
Here is the implementation:
lift :: ((Entity -> Bool) -> Bool) -> Rel -> Rel
lift = \ f r -> reduce f (wrap r)
Note that if r has arity n + 1, then lift f r has arity n. Thus, lift isindeed a reducer of n + 1-arity relations to n-ary relations.
75
6.6 Scope Reversal of Quantifiers
We have defined generalized negation and generalized quantification as oper-ators of type Rel -> Rel. A difference between these two kinds of operatorsis that generalized negation does not reduce the arity of its argument rela-tion, but generalized quantification does. The relational operator interpre-tation of a DP reduces the arity of its argument relation by 1, for applyingthe generalized quantifier to the relation consumes one of the arguments ofthe relation.
Now suppose we want to swap the scope of two generalized quantifier oper-ations. We can view the scope swap as an operation of the following type:
qscopeReversal :: (Rel -> Rel) -> (Rel -> Rel) -> (Rel -> Rel)
The swap takes two operators Q1 and Q2 and creates a new operator thatshould express the effect of giving Q2 scope over Q1.
How should this scope swapping operation be defined? Just defining it asQ2 · Q1, for performing Q2 after Q1 and thereby giving Q2 wide scope, isalmost right, but not quite. The problem is that this switches the argumentpositions that the operators work on.
Look at it like this. In Q1(Q2r), Q2 gets applied to r first, so it applies tothe outermost argument of r. Suppose r has arity n, then Q2 applies tothe n-th argument, and produces a new relation Q2r of arity n − 1. Next,Q1 applies to the outermost argument of Q2r, and produces a new relationQ1(Q2r) of arity n − 1.
Now suppose we want to perform the applications in the opposite order.Then Q1 has to apply to r first, but Q1 still should apply to the n − 1-thargument position of r. Next, we should get a new relation Q1r, and Q2
should apply to what used to be the n-th argument of r. To bring thisabout, we have to define the reverse scoping as follows:
Q2 · Q1 · S,
where S is a swap operation defined by:
S := λrλxλy.(ry)x.
Here is the implementation:
76
swap :: Rel -> Rel
swap = \ r ->
R2 (\ x ->
R2 (\ y ->
(apply (apply r y) x)))
qscopeReversal :: (Rel -> Rel) -> (Rel -> Rel)
-> (Rel -> Rel)
qscopeReversal = \ q1 q2 -> q2 . q1 . swap
Thus, for scope reversal, we first swap the two outermost argument placesof the relation, and next apply the two quantifiers in reversed order.
For a scope reversal of a quantifier and a negation no argument swapping isneeded, as the negation operation is not an arity reducer.
In Section 6.10 we will see that the presence of ordered lists of realized thetaroles on verb concepts allows us to generate all the possible scope readings ofa sentence in a particularly easy way, by swapping the quantifiers in parallelwith the corresponding realized theta roles.
6.7 Extracting Relations from Event Lists
The initial interpretation of verbs is stated in terms of event propertiesλe.K(e) (for “the property of being an event of type K”). In our imple-mentation, these event properties are represented as lists of events, type[Ev].
Events are our flexible means of making sense of the various numbers andkinds of roles that may be involved in a verb denotation. Once the thetasystem has been applied to the verb concept we know all that we need toknow about the theta roles involved and the DPs they are linked to. Thisinformation can then be used to extract a relation out of the event propertythat interprets the verb. The arity of the relation will depend on the numberof realized theta roles of the verb.
Our second important conversion function is a function to extract relations(type Rel) from event lists (type [Ev]). Not all of the roles present in theevent need to be involved. What we need for extraction of the appropriate
77
relation is a list of the realized theta roles of the verb.
So the first argument of the extraction operation is a list of roles. Theseroles are extracted in reverse order, for we want the last role in the list tocorrespond to the outermost argument of the relation, and the first role inthe list to correspond to the innermost argument (in linguistic terminology,this is the ‘external’ argument) of the relation.
As an example, consider the verb concept involved in the interpretation ofthe following sentence.
(6.5) The vase was given to Lucy.
The verbal concept will have the clusters [-c,-m] (for the thing that wasgiven) and [+c] for the recipient of the giving, realized in that order. So wehave a concept that looks roughly like this:
("give",[[-c,-m],[+c]],[[+c,+m],[-c,-m],[+c]],[[L,G,M],[M,V,L]])
The first element in the quadruple gives the key (its a “give” concept), thesecond element gives the theta roles that are realized, the third element givesthe list of all theta roles of the events that interpret the concept, and thefourth element gives (a simplified representation of) the list of events thatinterprets the giving relation in the model. This element says that in themodel, Lucy gives the gun to Max, and Max gives the vase to Lucy.
Now what is the relation we need to extract? It is the relation which takes asits first argument the beneficient of the giving, and as second argument theobject of the giving, and yields True just in case there is a giving event withthis object and this beneficient. Thus, if we interpret (6.5) in the examplemodel, the sentence should evaluate to True.
So in the example, we first have to extract the theta role for the beneficient,which is the third role, next the theta role for the object, which is the secondrole.
To extract for role i from an event list, we filter on the property of havingrole i in some event in the list.
Here is the implementation:
78
extract :: [Int] -> [Ev] -> Rel
extract is es = extr (reverse is) es
where
extr [] es = R1 (not (null es))
extr (i:js) es =
R2 (\ x ->
extr js (filter (\e -> role i e == x) es))
Some examples to check what we have done:
ex1 = (rel2lists . extract [1,2]) shaving
ex2 = (rel2lists . extract [2,1]) shaving
ex3 = (rel2lists . extract [1]) (refl (1,2) shaving)
ex4 = (rel2lists . extract [2]) (refl (1,2) shaving)
ex5 = (rel2lists . extract [2,3]) giving
ex6 = (rel2lists . extract [1,2,3]) giving
ex7 = (rel2lists . extract [2,1,3]) giving
This gives:
Interp> ex1
[[B,B],[J,J],[A,M]]
Interp> ex2
[[M,A],[B,B],[J,J]]
Interp> ex3
[[B],[J]]
Interp> ex4
[[B],[J]]
Interp> ex5
[[V,L],[G,M]]
Interp> ex6
[[M,V,L],[L,G,M]]
Interp> ex7
[[V,M,L],[G,L,M]]
79
6.8 Interpretation of the Categories
Interpretation of DPs
For the interpretations of DPs we use the familiar PTQ procedure proposedby Richard Montague. Interpretations of DPs are property functions, sothey have type (Entity -> Bool) -> Bool. The interpretations of propernames have type Entity. In order to lift this type to that of propertyfunctions, we interpret the names as functions for checking whether a givenproperty is a property of the bearer of the name.
Note that DP interpretations for DPs inside a verb phrase will have to belifted a second time: see below.
intDP :: DP -> (Entity -> Bool) -> Bool
intDP (Name "max" _) = \ p -> p maxx
intDP (Name "ann" _) = \ p -> p ann
intDP (Name "bill" _) = \ p -> p bill
intDP (Name "johnny" _) = \ p -> p johnny
intDP (Name "theboy" _) = \ p -> p theboy
intDP (Name "lucy" _) = \ p -> p lucy
intDP (Name "disease" _) = \ p -> p disease
intDP (Name "nature" _) = \ p -> p nature
intDP (Name "thevase" _) = \ p -> p thevase
intDP (Name "thegun" _) = \ p -> p thegun
intDP (Name "thestone" _) = \ p -> p thestone
intDP (Name "thewindow" _) = \ p -> p thewindow
intDP (DP det cn) = (intDET det) (intCN cn)
Interpretation of DETs
First order quantifiers:
80
every, some, no ::
(Entity -> Bool) -> (Entity -> Bool) -> Bool
every = \ p q -> all q (filter p entities)
some = \ p q -> any q (filter p entities)
no = \ p q -> not (some p q)
Use this in the interpretation of determiners:
intDET :: DET ->
(Entity -> Bool) -> (Entity -> Bool) -> Bool
intDET EVERY = every
intDET SOME = some
intDET NO = no
Interpretation of CNs
intCN :: CN -> Entity -> Bool
intCN (LexCN "man" _) = man
intCN (LexCN "woman" _) = woman
intCN (LexCN "boy" _) = boy
intCN (LexCN "person" _) = person
intCN (LexCN "thing" _) = thing
intCN (LexCN "tree" _) = tree
intCN (LexCN "leaf" _) = leaf
Interpretation of Coded Verb Concepts
Here we use the extraction function for converting an event list to a relationof the appropriate arity.
81
intConcept :: Concept -> Rel
intConcept ccpt =
extract (roleM ccpt) (eventsC ccpt)
Interpretation of DP Lists We can lift the interpretation of a singleDP from type (Entity -> Bool) -> Bool to type Rel -> Rel by means ofconv . intDP. Using this, we interpret the list of DPs on a Verb-complementDP list as a function of type Rel -> Rel, as follows.
• The empty list of DPs is interpreted as the identity function on rela-tions.
• If the DP list is nonempty, we want the first DP on the list to workon the last argument of the relation that interprets the VP. We alsowant the first DP on the list to have wider scope than the other DPson the list.
The following implementation has these effects.
intDPs :: [DP] -> Rel -> Rel
intDPs [] = id
intDPs (dp:dps) = ((lift . intDP) dp) . (intDPs dps)
The relation transformer that is applied last will have widest scope, so infact what we have done is implementing a fixed scoping mechanism wheresubject outscopes direct object, direct object outscopes indirect object, andso on. In so far as the order of the DP list reflects surface word order, ourscoping mechanism gives surface scope order. For generating other possiblescopings, this needs to be modified: see Section 6.10.
Interpretation of VP An VP can be considered as a pair consisting of aconcept and a list of DPs. Then we can interpret by applying the functionthat interprets the DP list to the function that interprets the verb.
82
To get at the meaning of the verb, we look up its concept via the conceptkey.
lookupConcept :: Phon -> [Concept]
lookupConcept phon =
[ ccpt | ccpt <- allconcepts, key ccpt == phon ]
Note that allconcepts includes the concepts to which reflexivisation ordecausativation have applied.
Interpretation of Sentences If all goes well, the arity of the relationthat interprets the verb concept matches the number of DPs in the sentence(including the subject DP). To check this, we use the function arityC onconcepts.
The result of this check may be that certain parses are rejected at this stage.Therefore intSent is implemented as a function of type Sent -> [Bool].If the arity check fails, the empty list is returned. Otherwise, the functionreturns a unit list with the appropriate truth value.
To get at the truth value, the 0-arity relation that results from applying theinterpretation of the DP list to the interpretation of the verb concept getsconverted with decode0.
intSent :: Sent -> [Bool]
For sentences with VPs without auxiliaries, we use the appropriate verbconcepts from the lexicon (with or without reflexivisation applied).
intSent (Sent dp (TsdVP (Verb phon _ dps))) =
[ decode0 ((intDPs (dp:dps)) (intConcept concept))
| concept <- lookupConcept phon,
arityC concept == length (dp:dps) ]
83
For sentences with the auxiliary be we use saturated verb concepts.
intSent (Sent dp (AuxVP BE (Verb phon _ dps))) =
[ decode0 ((intDPs (dp:dps)) (intConcept sconcept))
| concept <- lookupConcept phon,
sconcept <- satTRANSF concept,
arityC sconcept == length (dp:dps) ]
6.9 Evaluation
eval :: String -> [[Bool]]
eval string = [ intSent s | s <- parse string ]
If a sentence has no parse according to the phrase structure grammar thatour parser is based on, this is indicated by [].
Interp> eval "Max broken the vase."
[]
If a sentence has a parse, but the parse tree violates the arity constraintsimposed by the theta system, this is indicated by [[]].
Interp> eval "Max broke the vase Lucy the gun."
[[]]
If the sentence has a parse, and the parse tree satisfies the arity constraints ofthe theta system, we get a result of the form [bs]], where bs is a non-emptylist of booleans.
Interp> eval "Max broke the vase."
[[True,False]]
84
This indicates that the theta system assigns two different readings, and thatthe first of these is true, the second false.
Exercise 4 Can you see what the readings are? Are both of them reason-
able? If not, how should the unreasonable reading get excluded?
We can now demonstrate that we capture the semantic distinction betweenThe vase dropped and The vase was dropped :
Interp> eval "The vase dropped."
[[True]]
Interp> eval "The vase was dropped."
[[False]]
6.10 Quantifier Scoping
We show in this section that the ordered list of realized theta roles on averb concept allows us to formalize and implement a particularly simple andelegant quantifier scoping algorithm. Our approach to scoping can be viewedas a ‘clean’ version of Richard Montague’s Quantifying In Rule [Mon73]. Thecleanup is made possible by the fact that our relational approach avoids theuse of free variables in syntax or semantics.
Our quantifier scoping algorithm can also be viewed as a ‘clean’ version ofthe quantifier storage approach proposed in [Coo75, Coo83] (cleaner, again,because no free variables are involved).
If we want to consider all different scope orders of n quantifiers then we haveto look at the n! = 1 × · · · × n different permutations of the quantifiers.
We start out from of a function that gives all the permutations of a finitelist:
85
perms :: [a] -> [[a]]
perms [] = [[]]
perms (x:xs) = concat (map (insrt x) (perms xs))
where
insrt :: a -> [a] -> [[a]]
insrt x [] = [[x]]
insrt x (y:ys) = (x:y:ys) : map (y:) (insrt x ys)
This gives:
Interp> perms [1,2,3]
[[1,2,3],[2,1,3],[2,3,1],[1,3,2],[3,1,2],[3,2,1]]
In our case, where we have verb concepts with realized theta roles togetherwith lists of DPs corresponding to the realized roles, all we have to do ispermute the theta role list and the DP list in parallel.
permsInPar :: [a] -> [b] -> [([a],[b])]
permsInPar xs ys = map unzip (perms (zip xs ys))
This gives:
Interp> permsInPar [1,2,3] [5,6,7]
[([1,2,3],[5,6,7]),([2,1,3],[6,5,7]),([2,3,1],[6,7,5]),
([1,3,2],[5,7,6]),([3,1,2],[7,5,6]),([3,2,1],[7,6,5])]
Use permsInPar to generate lists of triples consisting of a list indicatingthe permutation of surface scope order, the concept with its realized thetarole list under that permutation, and list of DPs, again under the samepermutation of surface order.
86
permCcptDPs :: Concept -> [DP] -> [([Int],Concept,[DP])]
permCcptDPs (key,thetas,labels,evs) dps =
[ (rM nthetas thetas,(key,nthetas,labels,evs),ndps)
| (nthetas,ndps) <- permsInPar thetas dps ]
The first element of the result triple is a list indicating the way surface scopeorder got permuted, the second element gives the concept with permutedtheta roles, and the third element gives the permuted DP list.
The scope algorithm will produce a list of pairs consisting of an indicationof the way in which surface order got permuted, and a boolean for the truthvalue of the interpretation of the sentence under this scope ordering.
allScopings :: Sent -> [([Int],Bool)]
To generate all scopings of a sentence, permute the list of realized theta rolesof its verb in parallel with its DP list, and evaluate the results.
allScopings (Sent dp (TsdVP (Verb phon _ dps))) =
[ (indexlist,decode0 ((intDPs ndps) (intConcept ncpt)))
| concept <- lookupConcept phon,
arityC concept == length (dp:dps),
(indexlist,ncpt,ndps) <-
permCcptDPs concept (dp:dps) ]
This gives:
Interp> map allScopings (parse "Every tree dropped a leaf.")
[[([1,2],True),([2,1],False)]]
This indicates that under the surface scope order reading of the DPs thesentence is true in the example model, but under the reverse scope orderreading of the DPs (“There is a specific leaf that every tree dropped”) thesentence is false.
87
Interp> map allScopings (parse "No man killed a woman.")
[[([1,2],False),([2,1],True)]]
Under the surface scope reading this is false, under the reverse scope readingthis is true, for there is a woman in the model that did not fall victim toany man.
We don’t have to-PPs yet, but the following sentence should be read as “Noman gave a thing to every woman.” Here is the result of evaluating it underevery possible scope ordering:
Interp> map allScopings (parse "No man gave a thing every woman.")
[[([1,2,3],True),([2,1,3],True),([2,3,1],True),
([1,3,2],True),([3,1,2],False),([3,2,1],True)]]
Same for sentences with an auxiliary verb be.
allScopings (Sent dp (AuxVP BE (Verb phon _ dps))) =
[ (indexlist,decode0 ((intDPs ndps) (intConcept ncpt)))
| concept <- lookupConcept phon,
sconcept <- satTRANSF concept,
arityC sconcept == length (dp:dps),
(indexlist,ncpt,ndps) <-
permCcptDPs sconcept (dp:dps) ]
This gives (note again that “Some thing was given no woman” should beread as “Some thing was given to no woman”):
Interp> map allScopings (parse "Some thing was given no woman.")
[[([1,2],True),([2,1],False)]]
Acknowledgements
I am indebted to Tanya Reinhart for introducing me to the linguistic sideof theta theory, in the course of our joint Uil-OTS class on the Theta Sys-tem (Fall 2002). Thanks to Alexis Dimitriadis for helpful discussion onthe semantics of the theta system, to Willemijn Vermaat for advice on treedrawing, and to Herman Hendriks for providing useful references.
88
Bibliography
[Cho81] N. Chomsky. Lectures on Government and Binding. Foris, Dor-drecht, 1981.
[Cho92] N. Chomsky. A minimalist program for linguistic theory. MITPress, 1992.
[Coo75] R. Cooper. Montague’s Semantic Theory and Transformational
Syntax. PhD thesis, University of Massachusetts at Amherst,1975.
[Coo83] R. Cooper. Quantification and Syntactic Theory. Reidel, Dor-drecht, Dordrecht, 1983.
[Dav67] D. Davidson. The logical form of action sentences. In N. Rescher,editor, The Logic of Decision and Action, pages 81–95. The Uni-versity Press, Pittsburgh, 1967.
[Dim] A. Dimitriadis. Towards an event semantics for the theta system.Uil-OTS Manuscript, October 2002.
[Dow89] D. R. Dowty. On the semantic content of the notion of ‘the-matic role’. In B. Partee, G. Chierchia, and R. Turner, editors,Properties, Type, and Meanings, volume 2, pages 69–130. Kluwer,Dordrecht, 1989.
[DP90] B.A. Davey and H.A. Priestley. Introduction to Lattices and Or-
der. Cambridge University Press, Cambridge, 1990.
[DvE02] K. Doets and J. van Eijck. Reasoning, computation and represen-tation using Haskell. Draft Textbook. Available from www.cwi.
nl/~jve/RCRH/RCRH.ps.gz, 2002.
[Gri90] J. Grimshaw. Argument Structure. MIT Press, 1990.
89
[Gru65] J.S. Gruber. Studies in Lexical Relations. PhD thesis, MIT, 1965.Published in revised form in 1976.
[Hal63] P. Halmos. Lectures on Boolean Algebras. Van Nostrand, 1963.
[Hen93] H. Hendriks. Studied Flexibility; Categories and Types in Syntax
and Semantics. PhD thesis, ILLC, Amsterdam, 1993.
[HFP96] P. Hudak, J. Fasel, and J. Peterson. A gentle introduction toHaskell. Technical report, Yale University, 1996. Available fromthe Haskell homepage: http://www.haskell.org.
[HvL] F. Hamm and M. van Lambalgen. Event calculus, nominalisation,and the progressive. Manuscript, ILLC and Univ. of Tuebingen,2000.
[Jac72] R. Jackendoff. Semantic Interpretation in Generative Grammar.MIT Press, 1972.
[JH+99] S. Peyton Jones, J. Hughes, et al. Report on the programminglanguage Haskell 98. Available from the Haskell homepage: http://www.haskell.org, 1999.
[JR+] Mark P. Jones, Alastair Reid, et al. The Hugs98 user manual.http://www.haskell.org/hugs/.
[Kee87] E. Keenan. Unreducible n-ary quantification in natural language.In P. Gardenfors, editor, Generalized Quantifiers, Linguistic and
Logical Approaches, pages 109–150. Reidel, Dordrecht, 1987.
[Kee92] E. Keenan. Beyond the Frege boundary. Linguistics and Philos-
ophy, 15(2):199–221, 1992.
[Knu92] D.E. Knuth. Literate Programming. CSLI Lecture Notes, no. 27.CSLI, Stanford, 1992.
[KS69] P. Kiparski and J.F. Staal. Syntactic and semantic relations inPanini. Foundations of Language, 5:83–117, 1969.
[Mon73] R. Montague. The proper treatment of quantification in ordi-nary English. In J. Hintikka e.a., editor, Approaches to Natural
Language, pages 221–242. Reidel, 1973.
[Mus89a] R. Muskens. Meaning and Partiality. PhD thesis, University ofAmsterdam, 1989.
90
[Mus89b] R. Muskens. A relational formulation of the theory of types. Lin-
guistics and Philosophy, 12:325–346, 1989.
[Myl99] T. Mylne. A feature-based system for classifying semantic roles.In Proceedings of the 1999 Conference of the Australian Linguistic
Society, 1999.
[Par90] T. Parsons. Events in the Semantics of English. The MIT Press,Cambridge, MA, 1990.
[Rei00] T. Reinhart. The theta system: syntactic realization of verbalconcepts. Technical report, OTS Working Papers, 2000.
[Rei01] T Reinhart. A synopsis of ”the Theta system”. Manuscript, 2001.
[Rei02] T. Reinhart. The theta system — an overview. To appear inTheoretical Linguistics, 2002.
[Tea] The GHC Team. The Glasgow Haskell compiler (GHC). http:
//www.haskell.org/ghc/.
91