[MUD-Dev] Re: Prepositions and parsing
clawrenc at cup.hp.com
clawrenc at cup.hp.com
Mon May 12 09:30:04 CEST 1997
In <9705101628.7zjv at ami-cg.GraySage.Edmonton.AB.CA>, on 05/10/97
at 12:40 PM, cg at ami-cg.graysage.edmonton.ab.ca (Chris Gray) said:
>[Chris L:]
>:How about, "beside", "behind", "above", "between", "near", "close to",
>:"over" etc? I'm specifically looking for intelligent handling that
>:will allow the following sequence:
>:
>: > put the book on the table
>: OK.
>: > put the paper under the book
>: OK.
>: > l
>: There is a table here with a book on it.
>: > get book
>: OK.
>: > l
>: There is a table here with a paper on it.
>It strikes me (after very little thought!) that the semantics is
>harder than the syntax. You have to implement some kind of concept of
>objects which are so small and flat that they can be put under other
>objects, thus being hidden, but not harmed. That's a fairly
>special-case set of objects, and if you are doing that, then you'll
>likely have a whole mess of other kinds of objects. By the time you
>have set up the semantics for all of that, the parsing might look
>easy!
I see this as two sides of the problem, and in a different order:
1) Figure out how to do the prepositions.
2) Figure out how represent them.
Sure, you can put/hide/whatever an elephant under a small slip of
paper, he just won't be hidden very well. Reversing it of course, the
paper gets hidden very nicely under the elephant. As such I don't
seet hsi as a classification problem, but a mechanics problem.
1) Can item A be put into that position relative to item B?
2) What results as of this placement?
3) What is the visibility/accessability of this placement?
>To handle the above stuff, you don't even need to have prepositional
>phrases attached to objects. In terms of my parser, you just have a
>couple of variants of 'put', one with a "separator word" of 'on', and
>the other with 'under'. Those would automatically trigger the verb
>handlers:
>
> putOn("book", "table");
> putUnder("paper", "book");
Yeah, this is the obvious tack to take but it breaks down gloriously
on the ambiguities you also identified, and also gets way too fun for
the "get" side of life.
>With this technique you do have to duplicate all verbs that can
>meaningfully accept such prepositions, but how many is that?
<shrug> I have a feeling more than I would like to admit.
>Of
>course, in the above example, you would want to be able to "get the
>paper under the book", in which case you now do need prepositional
>phrases as part of noun stuff.
And here comes the really nbasty context-driven ambiguities:
put the paper under the book on the table.
Does this mean to take the paper that is currently under the book and
to put it on the table, or does it mean to take the paper and place it
under the book which is located on the table?
I suspect that I'll have to arrive at a general handler for such which
attempts to resolve both conditions and then picks the one which is
actually support (ie there is no book on the table so it must be the
other parse, or there is no paper under a book so it must be the other
parse, or it is unresolvable).
>It doesn't make a lot of sense to have
>a "get <np> under <np>" verb (a "get under <np>" does make sense), so
>here the 'under' would have to start a prepositional phrase. That
>would have to be available to the verb handling code, in order to
>direct the search for the object. So, perhaps the answer is that a
>"separator word" on a verb takes precedence over prepositions. So, in
>"put the book behind the pillar", we would trigger the "putBehind"
>verb, rather than go looking for a book behind the pillar. Hmm.
It seems more friendly and not terribly more expensive to me to have
the parse try and resolve *both* sides of the ambiguity, and to then
pick as to which is supportable in the current context.
>Does
>this only work for my parsing scheme where the verbs identify the
>objects? If you have to identify the objects before you can find the
>verbs, then the problem is harder - sort of a chicken and egg thing.
Bingo. And here it gets really messy. You end up with a really
glorious hodge-podge between a global parser and a a per-object
parser. Consider the case of:
shoot the paper under the book on the table
Does that mean to shoot the paper which is located under a book which
is located on the table, or to shoot a free paper such that it moves
to be under the book which is located on the table, or to shoot the
paper such that it moves from under the book to being on the table?
>Another aspect of these phrases is that they don't always indicate
>where to look for the object, but sometimes just provide more
>description of the objects. If a camera takes a picture of a book,
>then you have "a photograph of a book".
Bingo. Context nightmares.
--
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------------(*) Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list