Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swapped arguments with subject raising? #11

Closed
goodmami opened this issue Apr 11, 2019 · 5 comments
Closed

Swapped arguments with subject raising? #11

goodmami opened this issue Apr 11, 2019 · 5 comments

Comments

@goodmami
Copy link
Member

goodmami commented Apr 11, 2019

It looks like the semantic arguments of subject raising swap depending on the construction used. Consider the following (I've indicated the questionable parts of the MRS in the images below):

  • "Kim appears to sleep."
    Kim-appears-to-sleep

  • "It appears Kim sleeps."
    It-appears-Kim-sleeps

The _appear_v_to nodes occupy the same place in the graph (both are the scopal top and link only to _sleep_v_1), but the role (or argument position) is different. In the first sentence the ARG2 links to _sleep_v_1, while in the it-clefted expletive-it version the ARG1 does.

The SEM-I lists two predicate synopses:

  _appear_v_to : ARG0 e, ARG1 u, ARG2 h.
  _appear_v_to : ARG0 e, ARG1 h, ARG2 i.

Although it is unclear why one has 'u' and the other 'i' for the optional argument. But this part of the SEM-I is generated automatically, so it is just reflecting the variation that is encoded in the grammar.

Note that filling that argument ("Kim appears to me to sleep." and "It appears to me Kim sleeps") does not affect change the argument order (i.e., they are also swapped as before).

This appears to me to be a bug.

@goodmami
Copy link
Member Author

I edited the issue because the example wasn't an it-cleft but an expletive it. There is another issue with it-clefts (#8). Although "It is appearing that Kim sleeps." also exhibits the same argument swapping. I think the original sentence ("Kim appears to sleep.") has the proper semantics.

Also, this does not happen with some other kinds of raising: "Kim expected Pat to sleep" and "It was expected that Pat sleep." both have _sleep_v_1 on the ARG2. Similarly, both "That Kim sleeps is bad" and "It is bad that Kim sleeps." have _sleep_v_1 on _bad_a_for's ARG1.

@danflick
Copy link
Collaborator

I agree that the ARGn assignments should be the same for "Kim appears to sleep" and "It appears that Kim sleeps", so the reported behavior is indeed a bug. But since there are other verbs such as "follow" that take an expletive-it subject and only a sentential complement (with no optional PP, and hence no second semantic argument), it seems better to treat the obligatory sentential complement consistently as the ARG1, and the optional PP as the ARG2. So once I have checked in the corrections, you should see only the one SEM-I entry:
_appear_v_to : ARG0 e, ARG1 h, ARG2 i.
and this should be used for both variants: subj-raising and expl-it subject.

@goodmami
Copy link
Member Author

Ok thanks. My statement that "Kim appears to sleep" has the proper semantics was based mainly on my comparisons to expect, but on further reflection those are rather different semantically so such a comparison is not motivated. I agree with your choice of argument order on _appear_v_to (and related predicates).

It would be nice to have some established consistency in the argument order for categories of words. I could probably put together some kind of regression-test-like setup to ensure things are as we expect across grammar versions. These lists of words/predicates could probably also be documented somewhere (the ErgSemantics wikis?). E.g.:

  • follow, help, ...
  • appear, seem, ...
  • expect, ask
  • promise, ...
  • try, ...

Although I guess if you know the lexical type you can look them up in the LTDB, but frankly I have a hard time decoding lexical type names.

@fcbond
Copy link
Member

fcbond commented Apr 13, 2019 via email

@danflick
Copy link
Collaborator

I will aim to add more explicit documentation to lexical types to assist in their decoding, and add some better descriptions of more general lexical types such as those for control. Closing this particular issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants