[developers] "Quite" problematic: MRS -> EDS conversion
Guy Emerson
gete2 at cam.ac.uk
Thu Jul 26 16:59:06 CEST 2018
"Browne was hired in January"
- in the 1214 ERG, the ARG1 of _in_p_temp is the ARG0 of _hire_v_1.
- we can therefore choose _hire_v_1 as the representative EP
"it was in January that Browne was hired"
- we need to add something to mark the cleft construction (presumably now
in ICONS)
- otherwise, nothing else needs to change in the semantics
- if nothing else changes, we can choose _hire_v_1 as the representative
EP, for the same reason as above
- in the 1214 ERG, there is a loc_nonsp that mediates between _in_p_temp
and _hire_v_1, but I think this is a bug
As explained in that wiki page, loc_nonsp is used for implicit locatives,
but there's nothing implicit here, because we have an explicit "in". For
example, compare:
"Browne was hired"
"it was Browne that was hired"
- in the 1214 ERG, the only difference between the two is the _be_v_itcleft
(which presumably is going to move to ICONS), and I think this is correct
- whatever difference we have here should also be the only difference
between "Browne was hired in January" and "it was in January that Browne
was hired"
Am 25.07.2018 20:19 schrieb "Michael Wayne Goodman" <goodmami at uw.edu>:
Forgot to CC the list...
On Wed, Jul 25, 2018 at 10:53 AM, Michael Wayne Goodman <goodmami at uw.edu>
wrote:
> On Wed, Jul 25, 2018 at 2:21 AM, Guy Emerson <gete2 at cam.ac.uk> wrote:
>
>> For "It was in January that Browne was hired", is the MRS correct? I was
>> surprised to see both _in_p_temp and loc_nonsp mediating between mofy(Jan)
>> and _hire_v_1. Is there a reason to have both? It would seem more
>> consistent to have just _in_p_temp, which takes the intrinsic variable of
>> _hire_v_1 as its ARG1. This would match the MRS for "Brown was hired in
>> January". Adding the it-cleft seems to have the side effect of adding
>> loc_nonsp.
>>
>
> Hmm, good point (this is relevant, for those following along:
> http://moin.delph-in.net/ErgSemantics/ImplicitLocatives). I think this
> version of the ERG is simply unable to link up the ARG1 of _in_p_temp to
> the index of _hire_v_1. Notice that the ARG1 of _in_p_temp is
> underspecified, so the loc_nonsp is required, then, to establish the
> relationship. Other analyses that do not have loc_nonsp don't actually get
> us a _in_p_temp that hooks up with _hire_v_1; rather, the "in January" is
> modifying the "was" (i.e., not an it-cleft analysis). Also, if I remove
> the loc_nonsp and change the ARG1 of _in_p_temp to select the ARG0 of
> _hire_v_1, the MRS no longer generates. I'm not sure if the original
> selected analysis is an underspecification of some valid ambiguity or a
> technical compromise to deal with limitations in our rules of composition.
>
>
>> The reason this is relevant is that, without the loc_nonsp, there would
>> be no need to look at TENSE.
>>
>
> I'm not following here. What would change in the graph to make _hire_v_1
> stand out as the representative EP?
>
>
>> 2018-07-24 23:18 GMT+01:00 Michael Wayne Goodman <goodmami at uw.edu>:
>>
>>> Answering one of my own questions; see below...
>>>
>>> On Fri, Jul 20, 2018 at 10:49 PM, Michael Wayne Goodman <goodmami at uw.edu
>>> > wrote:
>>>>
>>>>
>>>> If anyone has read this far, I have a question: both the ERG and Jacy
>>>> have a [ TENSE untensed ] property, but is this a more widespread
>>>> convention? I'm reluctant to rely on it because I want to avoid
>>>> parametrizing my semantic conversion functions for grammar-specific values.
>>>>
>>>
>>> I surveyed some grammars, and noted that the following use [ TENSE
>>> untensed ]: ERG, Jacy, gg, SRG
>>>
>>> The following do not: NorSource, Semitic Grammar (HeGram), BURGER, HaG,
>>> KRG, INDRA, Zhong
>>>
>>> Also note:
>>> * HaG has [ TAM untensed ] exported in the VPM, but not [ TENSE untensed
>>> ]
>>> * Zhong does not use the TENSE property at all
>>>
>>> So I think it's safe to say that it's *not* a widespread convention
>>> among medium-sized or larger grammars.
>>>
>>> One alternative to this specific tense property is the pos field of
>>> predicates, which is part of MRS and not grammar-defined. The idea is that
>>> predicates of certain pos values are more likely to modify others, such as
>>> verbs modifying nouns ("sleeping dog"), adpositionals modifying verbs ("ran
>>> quickly", "ran in the park"), degree modifiers on adpositionals ("ran very
>>> quickly", "the cat was very much in the bag"), etc. Abstract predicates
>>> (which do not formally have a pos) would come last, I suppose. But I'm not
>>> certain that such a gradation is not language-specific, and there are
>>> probably counter-examples.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180726/d4854265/attachment.html>
More information about the developers
mailing list