<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> If we have separate parts to the predicate, then we can write a lexical rule for causative by (schematically):<br> <br> [ intrans-verb<br> .... PRED-STEM 1<br> .... SENSE inch <br> ]<br> <br> -> <br> <br> [ trans verb<br> ... PRED-STEM 1<br> ... SENSE caus<br> ]<br> <br> or e.g., a noun to verb conversion by changing the POS part of the PRED (as well as adding a specific SENSE). I would want the values for SENSE to be in a type hierarchy, which is exported as part of the SEM-I (in fact, regardless of whether lexical rules are used or not, I think this is the right thing to do)<br> <br> Yes, this is non-monotonic. I see it as having a very different status from monotonicty in accumulation of relations. On a theoretical level, I'm happy with this being given as an option to the grammar writer. I wouldn't want it to be used in all cases - in fact, even with causative formation, there's a case for constructing the causative in English by adding a CAUSE predicate, though I don't want to advocate that personally - but both formally and psycholinguistically, at least some of the regularities we might capture with lexical rules are different in status from the fully productive parts of compositional semantics. <br> <br> I see a word's meaning (here using `word' as a deliberately vague term) as a semantic space, with some parts differentiated from the others by syntactic cues of various sorts, some (but not all) of which we capture in the ERG etc. The use of the POS and SENSE mechanisms to differentiate parts of that space allow us to make the link with those aspects of syntax which we do capture. It is not an ideal mechanism, but I think it's the best we can do within the constraints of the type of formalism we're using. Viewed in this way, lexical rules enable us to capture regularities between different word spaces. Humans are clearly capable of expanding their spaces on the fly in response to a new type of use of a word, which sometimes corresponds to applying a lexical rule productively. Derivational morphology (at least in some cases) gives another, very related, form of structure to the spaces. <br> <br> At the risk of confusing this picture, though, `small' phrases have some things in common with lexical and derivaional meaning - obviously English compound nouns but also adjective-noun combination. At best, what we can do with the ERG is provide a skeleton of meaning via compositional semantics - and that's actually complicated with the `stone lion' examples. I won't rry and explain this further here, however.<br> <br> More practically - I don't see an issue with generation because of the non-monotonicity. We might just use such rules statically - either manually specifying entries as equivalent to the rule operation or, more interestingly, allowing automatic construction of entries as rule-created. (To the extent that the ERG is a reflection of a large number of individuals' grammars, it is more reasonable theoretically to treat the lexicon as static than it would be if it were purely a reflection of one individual's grammar.) In this case there are no implications for the generator. If the rules are used productively, we would need a mechanism for avoiding overgeneration, but if we adopt the convention that the rules always change the SENSE, then we'll only generate a corresponding form if the generator is given an appropriate predicate as input and the look-up process is not significantly complicated (as far as I can see).<br> <br> Since people started talking about the gpreds, I also wanted to mention that it would be convenient for some applications if we had ordinary predicates as well as the decomposed forms available. e.g., I would like to have a regular `who' predicate as well as the decomposed version. This would imply Schroedinger *MRSs - alternatively I'd be happy to have it instead of the decomposed version, and generate the decomposed version via paraphrase rules.<br> <br> Best wishes to all,<br> <br> Ann<br> <br> <div class="moz-cite-prefix">On 31/12/2015 00:22, Emily M. Bender wrote:<br> </div> <blockquote cite="mid:CAMype6eLJHnEdY_e2HdfjDs=sP12zH6JB3745Kopw8gurJYHHQ@mail.gmail.com" type="cite"> <div dir="ltr">Dear Ann, Dear all,<br> <br> I wanted to follow up on a comment Ann made in the recent thread<br> on predicate naming in MRS. I've changed the subject line because<br> I think this is orthogonal to the main discussion in the previous thread.<br> <br> Ann's comment:<br> <br> ---------- Forwarded message ----------<br> From: Ann Copestake <<a moz-do-not-send="true" href="mailto:aac10@cl.cam.ac.uk">aac10@cl.cam.ac.uk</a>><br> Date: Mon, Dec 28, 2015 at 2:54 PM<br> Subject: Re: [developers] predicate naming in MRS<br> To: <a moz-do-not-send="true" href="mailto:developers@delph-in.net">developers@delph-in.net</a><br> <br> [...]<br> <br> The case issue also relates to treating the predicates as having a three-part structure (lexeme/pos/sense) throughout the codebase (with an option to allow simpler names for toy grammars). This is something we have been discussing for a long time ... I believe that this is the right way to look at predicate symbols in *MRS - i.e., as an additional annotation on lexemes. There would be advantages to doing this in the grammar - it allows for alternations that change sense to be implemented in lexical rules. If we do this, then the lexeme part should reflect the conventional spelling, which might include case variation (and, naturally, non-ASCII characters).<br> <br> [...]<br> <br> I was surprised by this remark, because lexical rules changing predicate <div>symbols (if that's what you mean, Ann) strikes me as non-monotonic.</div> <div>Can you clarify?</div> <div><br> </div> <div>Thanks,</div> <div>Emily</div> <div><br> <br> <br> --<br> Emily M. Bender<br> Professor, Department of Linguistics<br> Check out CLMS on facebook! <a moz-do-not-send="true" href="http://www.facebook.com/uwclma">http://www.facebook.com/uwclma</a></div> </div> </blockquote> <br> </body> </html>