Re: THEORY: Parsing for meaning.

--- Paul Bennett <paul-bennett@...> wrote:

> On Sun, 25 Jun 2006 21:11:36 -0400, Eugene Oh
> <un.doing@...> wrote:
>
> > This reply might not be exactly what you were
> looking for, but I was
> > wondering whether you've read the June 16th issue
> of the Economist, in
> > which is an article about machine translation.
<snip>

I read a paper about that technique a few years ago.
I'll have to look it up again and refresh my memory.

>
> I actually started thinking about this principle
> around a year or so ago.
> I gave up when I couldn't figure out what the
> minimal atomic units of
> linguistic knowledge should be[*], but I did also
> envisage extending the
> system to allow it to attempt to determine cognates,
> and plausibly build a
> tree of relatedness given semantically identical
> corpora in a set of
> languages. They seem to be based on a generalization
> of the same problem.
>
> [*]Heck, if I knew *that*, I could put Chmosky out
> of business... ;-)
>
> Paul
>
And therein lies the difference between a scientist
and an engineer. The scientist begins by trying to
_understand_ the problem and the engineer begins by
trying to _solve_ the problem. I think many problems
ultimately get solved by engineers who don't fully
understand the problem to begin with, but manage to
find something that works anyway.

I hate to confess my ignorance, but I really don't
understand what your reply was saying. I'm probably
all wet, but I have a hunch that the less I know about
formal linguistics the better chance I'll have to
solve the problem. After all the average 3-year-old
manages to speak and understand the language with no
formal lingusitics knowledge at all. My pattern
matching is an attempt to simulate by computer what I
think the human child does; match the incoming data
stream to patterns previously encountered.

For example, no amount of purely linguistic knowledge
will help you to parse "Join me in a song." Is "song"
an enterable object? How do I go "into" a song? The
fact is, it's an idiomatic phrase that should NOT be
"parsed" at all, but merely recognized by simply
looking it up in a list of patterns.

The same goes for a huge number of (possibly
parameterized, and certainly nestable) fixed-format
chunks that should never be "parsed", but simply
looked up in a table of patterns.

For example, consider these non-parsable fragments:
"fix you up with...", "as far as I know...", "Tell you
what.", "hard to come by", "What makes you think [I
need your help?]", "His head shot up.", "How would you
like to...", "threw his arms around...", "You're out
of luck.", "at the top of his lungs", "I'll walk you
through it.", "spend the day...", "chewing the fat",
"nosing around", "check things out", "call it a day",
"ears perked up", "accent so thick...", "came back to
my senses.", "what's eating you?", "I turned her
down", "take it easy", "shelling out", "hang around",
"one of those days.", "Who cares [what he thinks?]",
"slow on the uptake", "what's going on?", "he hung up
on me", etc. etc.

I honestly believe that language aquisition consists
of one hundred percent pattern learning and pattern
matching and zero-point-zero percent rules. "Rules"
are just a method of abstracting and cataloging
patterns. Enumerate all the patterns and you don't
need any rules.

--gary

Reply