G22.2590 - Natural Language Processing - Spring 2003 Prof. Grishman
Lecture 8 Outline
March 13, 2003
Discuss term project possibilities.
Discuss name taggers (HMM and pattern) available in Jet.
Some applications of NLP, such as grammar checking, depend only on the
syntactic form of an input. Most applications, however, are dependent
on what a sentence 'means'. For example, for information
extraction, we want to find mentions of a type of an event, however expressed.
For question answering, we need to connect the question to a body of knowledge
which can provide the answer. In fact, as we shall see when we consider
the processing of extended (multi-sentence) texts, we generally must integrate
the sentence with a great deal of 'background knowledge' in order to understand
what it melns. How should we express the meaning of an utterance?
Clearly we can express the meaning in natural language. Why is
this not satisfactory for analyzing the meaning? The components (the
words) are ambiguous; even sentences in isolation are ambiguous.
Resolving these ambiguities can be difficult. Even though syntactic
analysis has made some relationships explicit, others are still implicit;
for example, it does not indicate the quantificational structure of a sentence.
Furthermore, the rules for inferring new facts from given facts in natural
language may be very complicated.
Formal Languages for Meaning Representation
In order to analyze and manipulate the meaning of sentences, we will transform
the sentences into a meaning representation language. We want to
transform the sentences into a language which
[J&M also mention the characteristic of having a canonical form for
each meaning. This is an ultimate goal rather than an easily achieved
criterion. However, we can see both syntactic analysis and semantic
analysis as moving in this direction -- reducing paraphrase, i.e.,
reducing the variation in form for a given meaning.]
has simple rules of interpretation and inference, and in particular
has a logical structure determined by its form
is sufficiently expressive to capture the range of natural language
meanings we shall require for our applications
These are the properties of the languages of logic. Actual
systems may use different representations, but they are generally equivalent
to the formal language (extensions of predicate calculus) we will use for
The simplest form is propositional logic, but it is not powerful enough
for our purposes. Predicate logic combines predicates and their arguments.
Predicate logic has simple rules of inference, such as modus ponens (from
A and A==>B, infer B).
terms (constants, variables, and functions)
atomic formulas (predicate + arguments)
logical connectives (not, and, or, implies)
Predicate calculus is intended for representing “eternal truths” (like
the facts of mathematics). We face several problems when we try to
use it for representing events. First, how many arguments does an
event have (consider J&M example of eating, p. 524)? In natural
language, the same type of event may be described with many different sets
of arguments and modifiers (time, location, speed, ...). We can use
postulates to relate these, but that requires many such postulates
and may make commitments we do not intend. Second, we need to individuate
events (say that two events are the same or different; count events).
We can address this problem by reification -- treating events as objects
(J&M p. 527).
Other issues of expressiveness
There are many other issues which we may need to address in our meaning
generalized quantifiers (for ‘some’, ‘most’, …)
tense and aspect
modality and belief (need to allow formulas as arguments: “John believes
Fred likes Mary” = believe(John,like(Fred,Mary)) )
presupposition (“All the men on Mars drink Coca-Cola.”)
fuzziness (“The milk is warm.”)
Representations for information extraction
Information extraction applications are generally concerned with identifying
specific, individual events and relations between entities. They
need to capture event modifiers such as time and location, but not quantification.
Such applications typically use a frame or slot-filler representation.
For each type of event (or set of event types taking the same arguments)
we define a frame (template), with one slot containing a unique identifier
of the event, and one slot for each possible argument/modifier. Similarly,
a frame is defined for each type of entity. Slots may be filled with
constants or the identifiers of other events or entities.