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.

Semantic Analysis

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.]

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 presentation.

Predicate Logic

The simplest form is propositional logic, but it is not powerful enough for our purposes.  Predicate logic combines predicates and their arguments.  Basic elements: Predicate logic has simple rules of inference, such as modus ponens (from A and A==>B, infer B).

Representing events

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 meaning 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 representation language:

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.