Difference between _look_v_for and _look_v_1/for_p?

ERG
#1

Using ACE to parse “look for apples in the bag” generates (among others) the three parses below.

Is there a difference in intended semantics between the part of the MRS concerned with “looking for something in somewhere” or is it just three ways of expressing the same semantics?

Parse 1:
_look_v_for: e2,x3,x8
_in_p_loc: e14,x8,x15

Parse 2:
_look_v_1: e2,x3
_for_p: e8,e2,x9
_in_p_loc: e14,x9,x15

Parse 3:
_look_v_1: e2,x3
_for_p: e8,e2,x9
_in_p_loc: e14,e2,x15

Here are the full MRSs:

Parse 1:

[ TOP: h0
INDEX: e2
RELS: < 
[ _the_q LBL: h16 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] RSTR: h17 BODY: h18 ]
[ _bag_n_of LBL: h19 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] ARG1: i20 ]
[ pronoun_q LBL: h4 ARG0: x3 [ x PERS: 2 PT: zero ] RSTR: h5 BODY: h6 ]
[ pron LBL: h7 ARG0: x3 [ x PERS: 2 PT: zero ] ]
[ udef_q LBL: h9 ARG0: x8 [ x PERS: 3 NUM: pl IND: + ] RSTR: h10 BODY: h11 ]
[ named LBL: h12 CARG: "Apple" ARG0: x8 [ x PERS: 3 NUM: pl IND: + ] ]
[ _in_p_loc LBL: h12 ARG0: e14 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: x8 ARG2: x15 ]
[ _look_v_for LBL: h1 ARG0: e2 [ e SF: comm TENSE: pres MOOD: indicative PROG: - PERF: - ] ARG1: x3 ARG2: x8 ]
>
HCONS: < h0 qeq h1 h5 qeq h7 h10 qeq h12 h17 qeq h19 > ]

                        ┌_bag_n_of__xi:x15,i20
 _the_q__xhh:x15,h17,h18┤
                        │                       ┌pron__x:x3
                        └pronoun_q__xhh:x3,h5,h6┤
                                                │                      ┌_look_v_for__exx:e2,x3,x8
                                                └udef_q__xhh:x8,h10,h11┤
                                                                       │   ┌named__cx:Apple,x8
                                                                       └and┤
                                                                           └_in_p_loc__exx:e14,x8,x15


Parse 2:

[ TOP: h0
INDEX: e2
RELS: < [ udef_q LBL: h10 ARG0: x9 [ x PERS: 3 NUM: pl IND: + ] RSTR: h11 BODY: h12 ]
[ _the_q LBL: h16 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] RSTR: h17 BODY: h18 ]
[ _bag_n_of LBL: h19 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] ARG1: i20 ]
[ _apple_n_1 LBL: h13 ARG0: x9 [ x PERS: 3 NUM: pl IND: + ] ]
[ _in_p_loc LBL: h13 ARG0: e14 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: x9 ARG2: x15 ]
[ pronoun_q LBL: h4 ARG0: x3 [ x PERS: 2 PT: zero ] RSTR: h5 BODY: h6 ]
[ pron LBL: h7 ARG0: x3 [ x PERS: 2 PT: zero ] ]
[ _for_p LBL: h1 ARG0: e8 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: e2 ARG2: x9 ]
[ _look_v_1 LBL: h1 ARG0: e2 [ e SF: comm TENSE: pres MOOD: indicative PROG: - PERF: - ] ARG1: x3 ]
>
HCONS: < h0 qeq h1 h5 qeq h7 h11 qeq h13 h17 qeq h19 > ]

                                               ┌_bag_n_of__xi:x15,i20
                       ┌_the_q__xhh:x15,h17,h18┤
                       │                       │   ┌_apple_n_1__x:x9
                       │                       └and┤
                       │                           └_in_p_loc__exx:e14,x9,x15
 udef_q__xhh:x9,h11,h12┤
                       │                       ┌pron__x:x3
                       └pronoun_q__xhh:x3,h5,h6┤
                                               │   ┌_for_p__eex:e8,e2,x9
                                               └and┤
                                                   └_look_v_1__ex:e2,x3


Parse 3:

[ TOP: h0
INDEX: e2
RELS: < 
[ udef_q LBL: h10 ARG0: x9 [ x PERS: 3 NUM: pl IND: + ] RSTR: h11 BODY: h12 ]
[ _apple_n_1 LBL: h13 ARG0: x9 [ x PERS: 3 NUM: pl IND: + ] ]
[ _the_q LBL: h16 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] RSTR: h17 BODY: h18 ]
[ _bag_n_of LBL: h19 ARG0: x15 [ x PERS: 3 NUM: sg IND: + ] ARG1: i20 ]
[ pronoun_q LBL: h4 ARG0: x3 [ x PERS: 2 PT: zero ] RSTR: h5 BODY: h6 ]
[ pron LBL: h7 ARG0: x3 [ x PERS: 2 PT: zero ] ]
[ _for_p LBL: h1 ARG0: e8 [ e SF: prop TENSE: untensed MOOD: indicative ] ARG1: e2 ARG2: x9 ]
[ _in_p_loc LBL: h1 ARG0: e14 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: e2 ARG2: x15 ]
[ _look_v_1 LBL: h1 ARG0: e2 [ e SF: comm TENSE: pres MOOD: indicative PROG: - PERF: - ] ARG1: x3 ]
>
HCONS: < h0 qeq h1 h5 qeq h7 h11 qeq h13 h17 qeq h19 > ]

                       ┌_apple_n_1__x:x9
 udef_q__xhh:x9,h11,h12┤
                       │                       ┌_bag_n_of__xi:x15,i20
                       └_the_q__xhh:x15,h17,h18┤
                                               │                       ┌pron__x:x3
                                               └pronoun_q__xhh:x3,h5,h6┤
                                                                       │   ┌_for_p__eex:e8,e2,x9
                                                                       └and┤
                                                                           ├_look_v_1__ex:e2,x3
                                                                           └_in_p_loc__eex:e14,e2,x15
#2

The parses are not equivalent, and I believe you’re looking for the first one.

_look_v_for corresponds to “look for” as a phrasal verb meaning to “search for” or “seek”.

Parses 2 and 3 have _look_v_1 and _for_p as separate predicates, which corresponds to “looking” as a intransitive, i.e. “having a look”, and “for” meaning “on behalf of” (or some other sense). E.g. “Kim wanted to look but couldn’t make it today. So I’m looking for Kim.”

The difference between parses 2 and 3 is the attachment of “in”: either the apples are in the bag (parse 2) or the looking event is in the bag (parse 3), e.g. “This is an enormous bag that you can walk around in. Kim wanted to look but couldn’t make it today. So I’m looking for Kim in the bag.”

1 Like
#3

First: Thank you! Very clear as always.

Second: How did you learn this? Maybe I’m just missing it, but I don’t think this knowledge is obtainable by exhaustively following the links on: ErgSemantics - Deep Linguistic Processing with HPSG (DELPH-IN). I keep feeling like this kind of stuff must be written down somewhere that I haven’t found… Any help or pointers (or secret manuals) is appreciated!

#4

I’m afraid I don’t have any secret manuals :sweat_smile:

And actually, my master’s thesis was about PP-attachment ambiguity, which basically boils down to these three cases. So this was probably one of the first things I learnt about ERG semantics. But I suppose that learning about each semantic phenomenon in the ERG by writing a master’s thesis is not a sustainable strategy…

I agree with you that it seems to be missing from the documentation. On the ERG Semantics Inventory page, “verb particle constructions” is one of the bullet points without an associated page. It’s in the “Phenomenon Inventory from Lexical Types” section, because these verbs can be identified by the lexical type, e.g. the entry for “look for” inherits from v_pp_e_le (the e means that the preposition is semantically “empty”). There are a number of lexical types, to cover various kinds of phrasal verb.

Wikipedia has a fairly good overview of the phenomenon. In the ERG, phrasal verbs have a single predicate, where the “sense” field contains the preposition(s).

1 Like
#5

Yep, that’s one that we identified but didn’t get to. I hope that @Dan Stephan and I will one day have time to keep working on that project, but we haven’t for a while.

However, I can give you at least one update, which is that the DELPH-IN wiki has migrated to the GitHub page. So I’d recommend looking at the documentation here:

I don’t think there are any content changes, but the software is at least more responsive, and should there be content changes one day, that’s where they’ll end up.

2 Likes
#6

Hi @ebender , the lack of documentation about ERG is a huge obstaculeis many times. Not only to interpret the final MRS (as here) but also to deeply understand the derivation. In LKB we have the “compare” functionality that we can use to choose interactively among the possible parsers. But choosing the analysis expose internals from ERG (rule names and types) . Many times the name of the identifiers are far from clear. I have already told that to @Dan, the LTD from @bond also shows the limitations on the lack of documentation being mostly useful for someone already familiar with the acronyms used by Dan.

At IBM, because I am promoting the use o DELPH-IN I hear that I can ask for resources (people) … how that can help here? What I can do to help improve the documentation?

#7

Totally agree, and I also am happy to help, contribute, write docs, etc.